【51CTO獨家專訪】隨著非關系型數據庫的發展，很多企業由于自身的考慮，一直在關系型與非關系型的選擇之間徘徊。51CTO的記者在2011年的QCon大會北京會場上有幸請到了視覺中國的技術總監潘凡先生，為我們談一談視覺中國的數據庫選擇之路，潘凡先生說：“適合的就是***的。”以下是根據訪談內容整理而成的文字記錄，以方便大家閱讀。

關于被訪者

潘凡

未受過正式高等教育，一名普通的財務會計，出于對編程的熱愛和沖動，97年起轉行投入軟件開發行業，從事過若干年的.Net和Java開發，也曾是一名Perl/PHP程序員和Linux狂熱推動者。

2000年前曾先后供職于賽迪網和賽迪數據，從事電子商務相關研究工作。2001年起創業，致力于將互聯網應用架構引入傳統零售行業，構建了基于web服務的零售商業應用，實現了PDA移動終端/POS/PC基于互聯網整合成功案例，先后在部分500強企業成功實施運行至今。在創業期間又和朋友一起創建了視覺中國網站。

目前供職于視覺中國網站，擔任技術總監和架構師，關注領域包括可伸縮的網站架構，NoSQL應用實踐以及后現代的Perl編程。

[[21452]] 

左為潘凡先生，右為51CTO記者

對數據庫的選擇——09年是一個轉折點

潘凡：在視覺中國成立之初，我們選用的數據庫是MySQL，09年之后我們才選用了MongoDB作為我們的支撐數據庫。

51CTO：您在放棄MySQL的時候，沒有考慮過使用Oracle或者SQL Server？

潘凡：視覺中國是根據業務的需要來進行的選擇，初始時，我們并不是想去放棄MySQL，實際上當時我們選擇MongoDB的一個初衷是希望選擇一個NoSQL的產品做一個輔助的方案。但是在實際的項目實施中，我們發現MongoDB這種NoSQL數據庫的很多功能可以代替MySQL，因此我們決定使用MongoDB。

我們選擇替換，不是說MySQL這種數據庫產品不好，而使用Oracle或者SQL Server，實際上我們不是選擇一個普通的數據產品來代替另一個數據庫產品。我們本身的出發點是尋找一個可以支持MySQL的輔助產品。只是碰巧讓我們找到了可以替代MySQL原有工作的一種數據庫。

51CTO：也就是說這種“放棄”不是必然，只是一種巧合。

潘凡：是的，我們最開始就是想把MongoDB作為MySQL的一個輔助，現在有一種方案叫做SQL+NoSQL，這也是我們的選擇。只是后來我們發現這種方法可以簡化，就只用了MongoDB。

51CTO：視覺中國的這種選擇，也相當于在學習中前行，有沒有遇到很多困難？

潘凡：困難是肯定有的，而且還有很多。困難的來源一方面來源于MongoDB的年輕。雖說它的發展很快，但是畢竟是年輕的產品，技術不是特別的成熟，所以會出現很多很多的問題。但是他們有一個好的技術團隊，對產品的版本更新速度很快，對問題的響應速度很快，這對我們解決問題是很大的支撐。一方面是我們的技術，遇到困難，解決困難，在這個過程中，我們得到了很多經驗，為后續的工作做了很好的準備；總結了很多教訓，引以為戒吧。

MongoDB的穩定性——單機vs auto-sharding

51CTO：視覺中國的數據量能達到多少呢？

潘凡：視覺中國的數據量并不太大，我們將數據進行分組，大概分為四組，每組的平均數據量大概是幾百萬到七、八千萬。

51CTO：在這種數量級，MongoDB的穩定性如何呢？

潘凡：基本上沒有出現大的問題。正常情況下，不會出現莫名其妙的宕機。

只有在極其異常的情況下，比如：機房整體斷電、全部機柜的電源突然全部跳了，在這種情況下，曾經出現過數據的丟失。

但是現在1.8以后的版本，這種情況基本就沒有了。

51CTO：MongoDB在處理大規模的數據是的穩定性又是如何的呢？

潘凡：視覺中國的數據量是有限的，只能到***別；但是，根據國外的案例來看，數據量已經達到十億、百億的級別，MongoDB的使用基本沒有出現過太大的問題。如果現在我們不通過auto-sharding，自己手動刪片，也是很不錯的。
 

51CTO：現在版本的MongoDB本身是否有什么不足或者不穩定因素？

潘凡：MongoDB的單機版，也就是非sharding版本目前來說還是很穩定的。

但是，sharding版本的問題主要集中在mongos即它的路由處理（路由器），很多朋友也和我討論過類似的問題。對于這個問題，我們現在處于觀望的態度，因為對原有數據的遷移畢竟是一個很漫長的過程，不過我們會在新的項目中嘗試使用這種auto-sharding的技術。

MongoDB的優化——索引的優化

51CTO：在對數據維護時，有什么值得注意的嗎？

潘凡：硬件上，我們要把空間留的足夠了，內存也要稍微多給一些。對于MongoDB的優化主要是圍繞索引，對于索引的優化。索引的使用如果要講究一點技巧的話，剩余的運維動作還是很簡單的。

值得一提的是，與MySQL相比，這是MongoDB的優點，也是缺點，就是可選擇的優化途徑是有限的，但是能把有限的幾種做好，基本也夠用了。

下一頁有相關專訪視頻

#p#

筆者在茶歇時間，與參會的一下用戶進行了簡單的溝通，以后是溝通內容：

1. 51CTO：您公司使用的是什么數據庫呢？
2. 途牛網：我們使用的是MySQL的數據庫。
3. 51CTO：您公司想過使用非關系型數據庫嗎？
4. 途牛網：我們對這種技術正在研究，但是考慮成本，短期內不會使用吧。

1. 51CTO：您關注什么數據庫呢？
2. 大學生：我們學校教的是SQL Server，所以我們在外面做兼職基本也是選用SQL Server。
3. 51CTO：您聽說過非關系型數據庫嗎？
4. 大學生：這方面我們不太關注。

編者語：

無論選用哪種數據庫，都要根據公司的情況來判斷，畢竟這種轉移是十分耗費成本的。SQL+NoSQL的方法，十分值得關注。另外優化是十分重要的，但是優化是有技巧的，萬不可胡亂優化。

【編輯推薦】

1. 走進MongoDB的世界 展開MongoDB的學習之旅
2. 微軟研究人員：NoSQL需要標準化
3. 視覺中國的NoSQL之路：從MySQL到MongoDB
4. MongoDB1.8發布，分布式文檔數據庫