是時候跟 MongoDB 說再見了

在過去的兩到三年的時間內，我一直在一個中等規模的項目中使用 MongoDB。

但因為各種技術上的原因，到了和 MongoDB 說再見的時候了，我的原因有以下幾點：

• MongoDB 當前的內存模型基于內存映射文件，這是一項已經宣布腦死亡的技術。在實際應用過程中，不具備伸縮性，沒有方法來控制內存的使用情況。
• 鎖機制: 一個可伸縮性的數據庫解決方案使用全局的服務器鎖是一個糟糕的設計，特別是因為當 MongoDB 支持原子操作。應該有更精細的鎖操作。
• 查詢引擎：目前 MongoDB 的每個查詢只允許使用一個索引，不知道為什么會有這樣的限制，完全沒有理由。其實 MongoDB 的索引模型和關系數據庫是差不多的。
• 查詢語言：使用 JSON 作為查詢語言是一個糟糕的決定，盡管當前 JSON 查詢語言支持標準查詢，但對一些操作確實有限制，無法在 JSON 中執行一些類似 SQL 的復雜查詢。
• Map-Reduce: MongoDB 的 Map-reduce 相似一個無用的贈送品。
• 數據分片：這是 MongoDB 的另外一個糟糕的功能，從一個單一的服務器到分區設置的步驟是非常巨大的，你需要最少兩個復制集才能做分片，三個配置服務器和負載均衡，有點像小鎮上的小房子旁建了一棟摩天大廈。
• 數據中心的意識：這是另外一個拼湊在一起的特性，復制集只支持一個主節點和多個從節點，只能去寫一個從節點。可以在跨多個數據中心運行復制集，但寫操作只能在一個數據中心的從節點。
• 默認關閉“安全”模式: 是誰做出這樣白癡的決定呢？看到很到報道稱數據丟失，多數是因為這個問題。
• 日志: MongoDB 預先分配了 3G 的數據用于日志記錄，這個數據是獨立于數據庫大小的，3G大小對一些小型系統來說簡直是瘋了。

社會化組件：10gen 和 MongoDB 試圖讓構建一個大型的可伸縮系統變得很簡單，但實際上并不如此。在過去，構建大型的可伸縮性系統是非常復雜的，需要專業的知識和經驗。盡管很多人覺得構建這樣一個系統很酷。有一點很清楚的是，如果你正在構建一個小型或者中型的系統，那么使用 MongoDB 將會是徒勞的，因為性能不佳的問題以及收效甚微。很多人不愿意深入去了解和挖掘 SQL 數據庫本身的功能和性能，輕易的作出了使用一些非 SQL 數據庫系統的決定，這樣的做法是不明智的，而且充滿危險。我這樣說可能太苛刻，不符合多樣性，但卻非常現實。

MongoDB 目前更多的是市場營銷和炒作，10gen 主要的目標是為了告訴全世界說 MongoDB 是如何的酷，原因很清楚：10gen 正試圖發揮在數據庫這一市場上與其他產品進行競爭，以便能更好的說服投資人支付更多的錢來幫助其發展，這當然是 10gen 合法的目標，但其技術的基礎卻是搖搖欲墜的。

英文原文，OSCHINA原創翻譯