MongoDB：逐漸層得無關緊要

標籤：

我與MongoDB的關係可分為三個階段。對於目前處於第三階段的我來說，這款產品似乎變得無關緊要了。很快你就會明白為什麼我這麼說。

　　階段一：癡迷

　　我與MongoDB的第一次接觸十分神奇：一個poliglot持久性架構用它來處理部分系統，而架構的關聯式模式卻不是很適合。然而它運行得十分漂亮：快速、易於安裝和使用，並且運轉良好。不得不說，MongoDB很適合應用於此類情況。

　　它的表現震驚了我：事實上，我主要的查詢語言是JavaScript，這已經十分了不起。我從未奢望類似的東西能運行得如此出色。在那段時間裡，我詳細瞭解了這款產品以及如何管理它配給的文檔模型。

　　階段二：現實

　　也許這個階段更好的名字應該是成熟。在這個階段，我知道在什麼情況下該使用MongoDB，更重要的是，什麼時候不該使用MongoDB。這時，你會發現MongoDB是一款很好卻需要謹慎使用的產品。它提供的文檔模型強大到能幫你解決很多但卻不是全部問題：實際上，只是相當多而已。

　　我是從自己和別人的失敗上意識到了這個問題。很多人非常興奮的想要把世界簡化成一個模式，於是MongoDB就可以成為所有問題最完美的解決方案。但每當這些時刻，一些不符合想象卻真實存在的事實就會砸到你臉上證明你的想法是錯誤的：

　　關聯式模式並沒有它們表現的那麼糟糕。事實上，這種模式目前十分流行，而且在未來很長一段時間內它的地位都不會改變，究其原因：它管用。並且與NoSQL相反，我們手裡有各種適用於此模式的好的或者壞的的實踐方法。

　　ACID事務。MongoDB有一點惱人的地方：不能建立一個交易處理多個文檔。於是問題來了：多數情況下，你必須同時進行多文檔處理。

　　在你知道你的系統需要什麼之前，所有以上談到的強大效能，都和你關係不大。

　　在這個階段，所有的激動人心和相見恨晚都消失了，這是所有人都會有的。這時，你會知道這款工具可以做什麼以及不能做什麼。這是最好的階段。

　　階段三：無關緊要

　　現在MongoDB對於我來說已經變得無關緊要了。當然不是指文檔模型，而是產品。有一天早上我醒來，突然意識到我不再需要MongoDB了，因為對於我的項目來說，其替代品更具吸引力。它們是分批來的。

　　第一波：TokuMX

　　TokuMX是MongoDB的一個分支，我喜歡稱之為“MongoDB迷人的雙胞胎兄弟”。它與MongoDB使用同樣的通訊協定，採用基本相同的命令，並可與MongoDB 100%相容。但它具有一些MongoDB沒有的強大優勢：

　　可以進行多文檔ACID處理。

　　快於MongoDB(快50倍速)。

　　儲存消耗比MongoDB少90%。

　　與MongoDB 100%相容。所有你需要做的就是將MongoDB執行個體更換成TokuMX，然後轉移資料(這是相當容易的)，這樣你就大功告成了。

　　是的，與MongoDB一樣，它也是開源的，而且有運行非常好的免費版本。當然，它也不是完全無懈可擊。它有兩個局限：

　　沒有Windows發布(Distribution )。

　　目前Java庫還不能提供MongoDB ACID執行的本地支援。它可以使用，但仍需要一些樣板代碼。

　　TokuMX第一次讓我意識到MongoDB對我來說似乎無關緊要。當然，這可能只是暫時的：在日後版本發布後，MongoDB仍有可能擊敗TokuMX。但是，也只能寄希望於日後版本。目前為止，它做不到。

　　第二波：PostgreSQL

　　如果說TokuMX讓我覺得MongoDB無關緊要，那麼PostgreSQL 9.2則強化了這一印象。自9.2版本，PosetgreSQL開始對JSON和JSONB資料類型提供支援。這是一個有意思的解決方案，因為它，我可以得到關聯式模式中具有文檔靈活性的好的部分。而所有這一切都基於同樣的產品。太好了!

　　但是MongoDB曾比PostgreSQL的具有更高效能。我說“曾”是因為PostgreSQL 9.4版本使其變成了曆史：最近的基準顯示，PostgreSQL在處理JSON資料類型上比MongoDB更快。我沒有想要比較PostgreSQL和TokuMX，但鑒於兩者現在都比MongoDB擁有更好的效能，我想大家已經清楚我的觀點了。

　　結論

　　與 TokuMX 和 PostgreSQL 相比較使得 MongoDB 處於劣勢。但它仍然是一款很好的產品，而且會繼續改進來與這些替代產品競爭，然而目前來看它最多隻能排在第三名。不過資本市場對 MongoDB 非常認可，最新訊息顯示，2015年MongoDB獲8000萬美元融資，估值超過15億美元。期待MongoDB的改進和發展。

MongoDB：逐漸層得無關緊要