十一問MongoDB CTO，談NoSQL人氣王的擴展、事務及運維

【編者按】在“MongoDB成為首位10億美元初創”一文中，我們曾介紹過這個千禧年的寵兒――NoSQL領域的人氣王，只通過6年時間就將公司市值發展到12億美元，其成果相當于著名開源公司Red Hat 20年的發展。

總結MongoDB的成功之路，一大部分歸功于Web開發者，因為作為一個文檔數據庫，在許多場景下它都優于RDBMS，同時還可以獲得非常高的讀性能。此外，動態、靈活的模式更可以讓用戶在商用服務器上輕松的進行橫向擴展。

然而還是有很多潛在用戶抱有這樣的擔心――MongoDB的成功是否建立在過度的炒作之下。同時，有些則是擔心MongoDB還不夠成熟，認為其只適合某些Web應用，并且在事務上存在很大的風險。為了弄清這些問題，近日，InfoWorld的Eric Knorr走訪了MongoDB CTO兼聯合創始人Eliot Horowitz。

下為采訪譯文

Eric：對于MongoDB，業內通常會有這樣一個說法，MongoDB只適合初創公司，可以用它很方便的進行擴展。但是對于變化較少的企業級應用程序來說，這點似乎并不需要？

Eliot：我在與許多企業CIO交流的過程發現他們受許多問題困擾，其中之一就是一個項目究竟需要多少個開發者。另一個問題就是，有些想做的項目無法完成，可能是資源不足，也能使花費時間太長。

但有一點是肯定的，在使用MongoDB之后，這些問題出現的頻率減少，他們可以更快的完成一個事情。企業往往獲益于將系統拆分為多個可以交互的小型系統，而這些更小的系統完全可以看成是“初創公司” 。

Eric：你口中的他們從事的項目類型是？

Eliot：通常情況是獲得某個方面的single view，比如用戶。他們期望對大量不同的數據源進行抓取，然后清洗轉換成一個易于觀察的single view。

Eric：如果這么來看的話，這似乎是CRM的主要應用場景？

Eliot：這和CRM有很多區別，主要的不同在于，如果用戶擁有72個不同的CRM系統，那么將這些系統整合將難于登天。另外，還會存在風險問題，如果你擁有20個不同風險需求的系統，也期望采用不同的通信方式，這樣的話你就需要一個可以連接不同系統的服務。

Eric：即使發展至今，NoSQL的事務處理上仍然存在疑問，對于這一點你怎么看？

Eliot：為了更好的實現事務功能，MongoDB加入了越來越多的特性。同時，因為MongoDB本質上是一個分布式系統，所以你不需要擔心因為單一磁盤故障所造成的系統崩潰。

實際情況中，可能會使用兩個獨立的數據中心，對比只在一個物理硬盤上操作，用戶將獲得更強的可靠性，這些都是新型分布式環境所帶來的便利。但無可否認是模式發生了整體的變化，然而只要人們真正的了解了這個環境，肯定會更加偏向于分布式系統。

對于成熟。MongoDB已投入市場5年之久，當Oracle 5歲時，它肯定也沒有現在這么成熟。數據庫是個長期的工作，這個領域的產品需要更長時間能打磨，但是因為需求問題，我們已經成熟的非常快了，永遠比我們想象的快。MongoDB的企業應用流程一般是這樣的，在一個用例中測試==》投入生產環境==》任務關鍵型應用上使用，這個是1到2兩年后了。經過5年的發展后，我們已經看到MongoDB支撐著許多企業的任務關鍵性應用程序。

Eric：什么樣的任務關鍵型應用？

Eliot：其中一個情景就是user-facing數據。在Adobe的中，當人們使用Photoshop時，所有的數據都會保存在Adobe中，如果服務發生故障，將會產生非常麻煩的事情。同樣，在銀行和風險系統中也是如此。

Eric：MongoDB有在銀行系統中投入使用？

Eliot：如果你著眼銀行這個領域，許多事情變化都非常快，比如業務操作時的管理需求、業務操作方式等等。MongoDB可以快速的適應并跟隨變化，這點是其他系統做不到的。MongoDB能進入這個領域主要就是基于這個原因，即使它不像Oracle那樣成熟。同時，這也是開源技術背后需要公司來支撐的原因，開源道企業級應用有很大一部要走。

Eric：你好像一直在說新系統的打造，這是否意味著很少有遺留的企業系統遷至MongoDB？

Eliot：如果遺留的系統可以工作，那么為什么要遷移？這是完全沒意義的。我們看到許多新的應用程序基于MongoDB建立，可以說每時每刻都在發生。同時，如果遺留系統崩潰，那么通常情況下它會被重構和重新建立。但是如果遺留系統可以正常的工作，基于成本問題，相信不會有任何人做這種無意義的遷移。

因此，只有在重建時你才會看到遺留應用程序的遷移。如果你有接觸這種情況，你可能就會聽到工程師的抱怨：“因為不能快速演進，我們已遠落后產品路線圖了，因此在接下來的6個月內，我們必須要緊牙關完成這個遷移。”

Eric：都有哪些機構的工作者在推動MongoDB采用的前行？

Eliot：毫無疑問，開發者是最大的推動者。架構師因為一些架構上的問題使用MongoDB，有些情況下運營團隊使用MongoDB來減少運維復雜度，有些時候類似VP及CIO也期望使用它來創新。但是，我認為這些都只是基礎，重點在于使用并喜歡它的人們，他們可能會對CIO上報：瞧，我正在使用這個產品，我認為它可以在更廣泛的項目中投入使用，它肯定會運行的很好。

Eric：從運營的角度上看，我聽到反饋說MongoDB擴展并不像宣傳的那么容易，這些人的問題是出在了什么地方？你們是怎么回答的？

Eliot：我認為最大的問題在于MongoDB的底層系統設計是針對最大橫向擴展性及許多常見的運維操作，而當下這些最常見的運維操作可能還不是最簡單的。我們盡力讓MongoDB由一堆很小的獨立組件組成，讓用戶基于需求選擇來解決擴展難問題。

那么問題就發生了，使用這種新型的集群，你可能需要管理許多小的部分。從運維的角度來說，這確實令人煩惱。這個部分會在今年搞定，將會推出一套自動化系統，只需簡單的點擊就可以完成工作。同時，我們還將推出管理大型分布系統的工具，徹底解放運維人員。

Eric：在MongoDB中，一些最常見的錯誤是什么？

Elito：或許也不能稱之錯誤吧，MongoDB面臨最大的挑戰就是正確的數據模型。因為MongoDB非常靈活，所以用戶經常不考慮花時間去設計比較合適的模型，最終這將演變成搬著石頭砸自己的腳。

對于傳統的RDBMS來說，它們只提供簡單的模型和選項，而基于太多的硬性規則，用戶一般也不容易陷入困境，這點在MongoDB中就很可能發生。因此，用戶需要閱讀一些相關的書籍和文檔，避免誤區。

使用關系型數據庫的思維管理MongoDB，把MongoDB當做關系型數據庫來使用，這樣無疑會帶來困境而不是好處。

Eric：什么會讓你夜不能寐？

Eliot：對于我們來說，最大的挑戰就是讓產品運行良好，讓用戶喜歡MongoDB。毫無疑問的是，對比5年后的產品，當下在技術方面還存在很大的差距。坦率的說，在產品的這個生命周期，我們擁有了太多的用戶。

如果你對比MongoDB和其他數據庫的同個生命周期，MongoDB無疑擁有更多的用例，這點同樣表現在企業級應用上。因此我們必須要做好迭代速度與謹慎方面的考量，平衡好速度與可靠性，因為許多應用場景都是任務關鍵性應用。

原文鏈接：11 questions for MongoDB's CTO（編譯/仲浩  審校/魏偉）

免費訂閱“CSDN大數據”微信公眾號，實時了解最新的大數據進展！

CSDN大數據，專注大數據資訊、技術和經驗的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機器學習、智能算法等相關大數據觀點，大數據技術，大數據平臺，大數據實踐，大數據產業資訊等服務。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈