何時棄用 MongoDB？| 技術頭條

即使位列數據庫排行榜的 Top 5，MangoDB 的日子也並不好過。

自去年 10 月，MangoDB 宣佈將開源許可協議從 GNU AGPLv3 切換至 Server Side Public License 之後，AWS、RedHat、Fedora、Debian、Lyft 等項目以及企業隨即相繼宣佈將移除 MangoDB，一時之間，MangoDB 成為眾矢之的。但捫心自問，MangoDB 真的如此糟糕嗎？我們又該如何做出正確的選擇？

作者 | Justin Etheredge

譯者 | 彎月

責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

最近，我讀到了一篇關於紅帽公司的Satellite不再支持MongoDB的文章（有些人說這是因為許可條款方面的修改。）這不禁讓我想起過去幾年裡，我經常看到有關文章說為何MongoDB如此可怕，以及為何大家都不應該再使用MongoDB。然而，與此同時，MongoDB已經發展成為一款更為成熟的產品。那麼 ，情況究竟如何呢？難道所有的這些仇恨真的只是由於MongoDB在早期實現和營銷中犯下的錯誤嗎？還是說人們責怪MongoDB，只是因為他們沒能正確地評價MongoDB是否適合自己？

趨勢聚焦

多年來，我一直在從事軟件行業，但即便如此，我也只是經歷了一小部分對該行業帶來了衝擊性的趨勢。我目睹了4GL、AOP、敏捷、SOA、Web 2.0、AJAX、區塊鏈，以及等等諸多技術的崛起。每年軟件工程領域都會出現新的趨勢。其中一些很快就遭遇了失敗，還有一些則從根本上改變了軟件開發的方式。

隨著創新技術開始引領潮流，人們的興趣驟然而生，於是大家紛紛開始湧入，或者看到其他躍躍欲試的人群為其造勢。高德納公司為整個過程專門定義了“技術成熟度曲線”（The Hype Cycle），雖然存在爭議，但該曲線確實正確地評估了一項有價值的技術的發展成熟過程。

但每隔一段時間，就會出現一種新的創新（或者是舊已有技術的再度復甦），而這種創新由其中的某一種特定的實現所驅動。以NoSQL為例，其就受到了MongoDB的出現以及迅速崛起的大幅推動。這場運動並非源自MongoDB，但是大型互聯網公司的數據挑戰確實推動了非關係型數據庫的迴歸。Google的Bigtable和Facebook的Cassandra等項目相繼湧現，然而，MongoDB才是大多數開發人員最易獲取，也是最方便實現的NoSQL數據庫。

注：現在，你可能在想，我這不是把列式數據庫、鍵/值存儲或眾多其他數據存儲類型都混雜到了NoSQL旗下嗎？你說的沒錯，但是當時這種情況確實發生了。每個人都一股腦扎進NoSQL中，堅稱他們離不開NoSQL，但實際上他們並沒有真正理解其中所涉及的不同技術。對於很多人來說，MongoDB就是NoSQL。

開發人員對此表示反對。無模式數據庫無限擴展的概念可以應對任何挑戰，因此非常誘人。在2014年左右，幾乎到處都有人在使用MongoDB，而放到一年前人們都還都在使用MySQL、Postgres或SQL Server這樣的關係數據庫。如果你問他們MongoDB，他們的回答各不相同：有人的說辭很老套“網絡規模擴展的需要”，也有人經過了深思熟慮“我的數據結構非常鬆散，特別適合無模式數據庫”。

重要的是不要忘記，MongoDB和一般的文檔數據庫可以解決傳統關係數據庫無法應對的如下難題：

• 嚴格的模式：在關係數據庫中，如果你有動態的數據，則不得不創建一堆隨機的“雜項”數據列，將數據按塊保存起來，或者使用 EAVEAV設置……所有這些方法都存在嚴重的缺陷。
• 難以擴展：在關係數據庫中，如果你的數據過於龐大，則無法保存到一太服務器中；而MongoDB擁有跨多臺計算機擴展數據的機制。
• 難以修改模式：數據無法遷移！在關係數據庫中，變更數據庫的結構是一項巨大的挑戰（特別是你的數據量十分龐大的情況下）。MongoDB可以大幅簡化這一過程，而且很容易上手，你可以不斷更新你的模式並快速移動。
• 寫入性能：MongoDB的性能非常好，尤其是按照某種方式配置的情況下。MongoDB開箱即用的寫入配置受到的抨擊最多，但也確實帶來了出色的性能。

注意事項

MongoDB提供的潛在優勢非常大，尤其是對於面臨某些特定類型的問題的人。如果不配合上下文，或對於沒有經驗的人來說，閱讀了上述列表就會以為MongoDB確實給數據庫系統帶來了顛覆性的改變。然而，上述優勢還存在一些注意事項，下面我會一一列出。

公平地說，10gen / MongoDB Inc.並不是沒有考慮到這些問題，他們只是做出了權衡利弊。

• 沒有事務 ：事務可以說是許多關係數據庫的核心特徵（雖然不是全部，但確實是大多數）。事務意味著你能夠以原子方式執行多項操作，並始終確保數據保持一致。當然，在NoSQL數據庫中，你可以在一個文檔中包含一個事務，或者也可以通過分兩個階段提交的策略實現事務機制。但關鍵在於，這項工作必須由你自己完成……而且要保證正確無誤的話，這可能也是一項富有挑戰性且需要付出大量精力的工作。除非你看到數據庫中的數據出現非法的狀態，否則你往往無法意識到數據丟失的問題，只因為你無法保證操作的原子性。注意：很多人可能會提醒我，MongoDB 4.0已經於去年引入了事務機制，但是仍然存在很多侷限性。正如本文開頭所說，請評估是否能夠滿足你的需求。
• 沒有關係完整性（外鍵）：如果你的數據之間存在關係，那麼你就需要將這些關係保存下來。幾乎所有數據中都包含某種關係，如果數據庫強制體現這些關係，那麼就必須由你的應用程序來負責。如果數據庫強制執行這些關係，那麼就可以大大減輕應用程序的負擔，從而減輕工程師的工作量。
• 缺乏執行數據結構的能力：強模式有時候可能會帶來痛苦，但它們也能成為確保數據結構良好的強大機制。如果合理利用，你就可以通過這種強大的機制，確保你的數據在結構上符合你的期望。MongoDB等文檔數據庫在模式方面提供了驚人的靈活性，然而，這種靈活性會將責任轉嫁到維護者身上，由他們負責數據的清潔。如果你不付出這些努力，那麼最終你不得不在應用程序中大量代碼，處理那些結構上與預期不符的數據。我們常常說：應用遲早需要重寫，但數據將永遠存在。注意：MongoDB支持模式驗證，該功能非常有用，但仍然無法提供可以與關係數據庫相媲美的保障。主要在於添加或修改模式驗證不會影響集合中現有的數據，你需要確保更新的數據匹配新模式。因此，到底是否滿足需求還得由你自己來決定。
• 自定義查詢語言/沒有工具生態系統：SQL在剛剛出現時絕對掀起了一場革命，從那以後再也沒有任何變化。SQL是一種非常強大的語言，但也富有挑戰性。你必須使用由JSON片段組成的自定義查詢語言查詢數據庫，對於經驗豐富的SQL人員來說，這是一個巨大的退步。此外，我們有一整套可與SQL數據庫互操作的工具，從IDE到報告工具，應有盡有。切換到不支持SQL的數據庫意味著你就無法使用大多數的工具了，或者你也可以想辦法將輸入保存到SQL數據庫中，那麼你就可以繼續使用這些工具了，只不過這個過程可能比你想象得還難。

許多使用MongoDB的開發人員沒有深入理解他們為權衡付出的代價，而且他們常常將MongoDB作為應用程序的主要數據存儲。而這樣的決定通常意味著極為昂貴的成本。

我們應該怎麼做？

當然，並不是每位開發人員都會不計後果地一頭扎進去。但這樣的情況也著實不少，未來幾年會有不少項目在意識到不適合後放棄MongoDB。如果這些組織能夠花點時間系統地考慮一下他們做出的技術選擇，那麼也許就不會有那麼多人做出這樣的選擇了。

那麼，我們怎樣才能確定哪種技術適合實際情況呢？目前已經有不少人嘗試為評估技術創建系統性的框架，例如“軟件公司引入技術的框架”（http://www.wohlin.eu/spi96.pdf），“評估軟件技術的框架”（https://pdfs.semanticscholar.org/4268/30dd5dd944d3b75ec56b2a3b151c18afbaf9.pdf）。但我認為不需要弄得如此複雜。

我們只需要通過以下兩個主要問題，就合理地評估眾多技術，但是難點在於找到能夠負責任地回答這些問題的人，他們願意花時間回答這些問題，同時確保答案中毫無偏見。

“如果你沒有遇到某個特定問題，就不需要引入新的工具。”

問題一：我需要解決哪些問題？

如果你沒有遇到某個特定問題，就不需要引入新的工具。你可以就此打住。不要拿著解決方案反過來找問題。如果你沒有遇到問題，那麼就不需要新技術來更好地解決問題，所以就不需要決策。如果你是看到別人在使用某種技術，才考慮自己也使用，那麼你應該先想一想他們遇到的問題，然後再問問自己是否也面臨同樣的問題。當你看到別的公司使用某種技術時，自己也會情不自禁，難點在於判斷你自己是否也面臨相同的困難。

問題二：我放棄了什麼？

很明顯，這個問題更加難以回答，因為你必須深入剖析，並對新舊兩種技術都有很好的理解。有時候，在使用新技術構建出產品之前，你很難真正掌握這項技術，你也可以諮詢那些在這項技術上花費了大量時間的人。

如果你既沒有實際的使用經驗，也沒有人可以諮詢，那麼就應該考慮如何通過最小的投資確認該技術是否有價值。此外，如果你進行了投資，那麼撤銷這項決策的難度有多大？

人類總是把事情搞砸

你必須時刻牢記，如果你想不偏不倚地回答這些問題，那麼就必須與人類的天性作鬥爭。為了有效地評估技術，必須克服一系列的認知偏差，下面僅舉幾個例子：

• 從眾心理：相信每個人都聽說過，但要克服這一點卻非常艱難。請確保只選擇能夠解決你的實際需求的技術，而不要盲目跟風。
• 喜新厭舊：許多軟件開發人員都會低估他們長期使用的技術，同時高估新技術的優勢。這不僅僅是軟件工程師特有的問題，每個人都有這樣的傾向。
• 正面特點效應：有時我們只能看到眼前的東西，而會忽略不存在的東西。如果這一點與“喜新厭舊”的心理交織起來，那麼有可能造成嚴重的破壞。因為你不僅更加看重新技術，還會忽視新技術中存在的弊端。

客觀地看待事物是一種挑戰，但瞭解可能影響到你的偏見，有助於你做出更合理的決策。

總結

當一項新的創新出現（或復甦）時，我們需要非常謹慎地回答以下兩個問題：

• 這個工具能為我們解決實際問題嗎？
• 我們是否清楚其中的權衡利弊？

如果你無法自信地回答這兩個問題，那麼就需要後退一步，重新進行評估。

MongoDB到底是不是正確的選擇？是，它當然是，但是與大多數軟件工程中的問題一樣，你需要視情況而定。對於那些在這兩個問題上有明確答案的團隊來說，他們很多人都發現了MongoDB的價值，而且他們還會不斷挖掘更多的價值。對於那些沒有具體答案的人，希望他們能夠從中吸取寶貴的教訓（而不用付出慘重代價），學習如何駕馭技術成熟度曲線。

免責聲明

我想澄清一點，我既不喜愛MongoDB，也不討厭它。我根本沒遇到過真正適合MongoDB的問題。我瞭解10gen/MongoDB公司確實犯過一些錯誤，包括在項目早期採用不安全的默認設置，並在所有場合下（特別是在黑客馬拉松活動中）推廣MongoDB，將其描述成一切數據需求的終極解決方案。沒錯，這些可能都是錯誤的決定，但我認為這也證實了本文所闡述的觀點——所有問題都可以通過技術評估快速發現。

原文：https://www.simplethread.com/was-mongodb-ever-the-right-choice/

本文為 CSDN 翻譯，如需轉載，請註明來源出處。作者獨立觀點，不代表 CSDN 立場。