我最近發現 （例如，由於許可證更改）。 這讓我想到，在過去的幾年裡，我看到了很多關於 MongoDB 有多糟糕以及任何人都不應該使用它的文章。 但在這段時間裡，MongoDB 已經成為一個更加成熟的產品。 發生了什麼？ 所有的仇恨真的都是新DBMS上市之初的失誤造成的嗎？ 或者人們只是在錯誤的地方使用了 MongoDB？
如果你突然覺得我在為 MongoDB 辯護，請閱讀 在文章的最後。
新趨勢
公平地說，我在軟件行業工作的時間比我多，但我仍然只是衝擊我們行業的趨勢的一部分。 我見證了 4GL、AOP、Agile、SOA、Web 2.0、AJAX、區塊鏈的興起……這個列表是無止境的。 每年都有新的趨勢。 有些正在迅速消失，而另一些正在從根本上改變軟件的開發方式。
每一個新趨勢都會引起普遍的興奮：人們要么跳上船，要么看到其他人產生的噪音並跟隨人群。 該流程由 Gartner 編入 . 雖然值得商榷，但這張圖粗略地描述了技術在最終變得有用之前會發生什麼。
但時不時會有（或有第二次出現，如本例）一項新的創新，僅由它的一個特定實施驅動。 就 NoSQL 而言，這種炒作在很大程度上是由 MongoDB 的出現和迅速崛起推動的。 MongoDB 並沒有開啟這個趨勢：事實上，大型互聯網公司開始出現處理大量數據的問題，這導致了非關係型數據庫的回歸。 一般運動始於 Google 的 Bigtable 和 Facebook 的 Cassandra 等項目，但 MongoDB 成為大多數開發人員可以訪問的 NoSQL 數據庫最著名和最易訪問的實現。
注意：您可能認為我將文檔數據庫與列數據庫、鍵/值存儲或屬於 NoSQL 通用定義的許多其他類型的數據存儲混淆了。 你是對的。 但當時，一片混亂。 人人都痴迷NoSQL，它已經成為一切 絕對 必要的，儘管許多人沒有看到不同技術的差異。 對於許多人來說，MongoDB 已經成為 與...同義 NoSQL。
開發人員跳上了它。 無模式數據庫可以神奇地擴展以解決任何問題的想法非常誘人。 2014年左右，好像一年前使用MySQL、Postgres、SQL Server等關係型數據庫的地方，都在部署MongoDB數據庫。 當被問及原因時，您可能會得到從平庸的“這就是網絡的規模”到更深思熟慮的“我的數據結構非常鬆散並且非常適合沒有模式的數據庫”的答案。
重要的是要記住，MongoDB 和一般的文檔數據庫解決了傳統關係數據庫的許多問題：
- 嚴格的計劃：對於關係數據庫，如果您有動態生成的數據，您將被迫創建一堆隨機的“不同”數據列，將數據塊推送到其中，或者使用配置 ……所有這些都有明顯的缺點。
- 縮放難度：如果數據太多以至於一台服務器放不下，MongoDB 提供了允許它在多台機器上橫向擴展的機制。
- 複雜的電路修改: 沒有遷移！ 在關係數據庫中，更改數據庫的結構可能是一個巨大的問題（尤其是當有大量數據時）。 MongoDB 已經能夠大大簡化這個過程。 並使其變得如此簡單，您可以隨時隨地更新模式並非常快速地繼續前進。
- 寫入性能：MongoDB 的性能很好，尤其是在適當調整的情況下。 即使是經常受到批評的 MongoDB 的開箱即用配置，也顯示出一些令人印象深刻的性能數據。
所有風險由您承擔
MongoDB 的潛在好處是巨大的，特別是對於某些類別的問題。 如果您在不了解上下文並且沒有經驗的情況下閱讀上面的列表，那麼您可能會覺得 MongoDB 確實是一個革命性的 DBMS。 唯一的問題是上面列出的好處伴隨著一些警告，其中一些列在下面。
公平地說，10gen/MongoDB Inc. 沒有人。 不會說下面的不是真的，這些只是妥協。
- 交易損失答：事務是許多關係數據庫（不是全部，但大多數）的核心特徵。 事務意味著您可以原子地執行多個操作，並可以確保數據保持一致。 當然，對於 NoSQL 數據庫，事務性可以在單個文檔中，或者您可以使用兩階段提交來獲得事務性語義。 但是您必須自己實現此功能……這可能是一項困難且耗時的任務。 通常直到您看到數據庫中的數據進入無效狀態時您才意識到這個問題，因為無法保證操作的原子性。 注意：許多人告訴我，去年 MongoDB 4.0 中引入了事務，但有一些限制。 文章的結論保持不變：評估該技術如何滿足您的需求。
- 關係完整性丟失（外鍵）：如果您的數據有關係，那麼您將不得不在應用程序中應用它們。 擁有一個尊重這些關係的數據庫將減輕應用程序的大量工作，從而減輕您的程序員的工作量。
- 無法應用數據結構：嚴格的模式有時可能是個大問題，但如果使用得當，它們也是一種用於良好數據結構的強大機制。 像 MongoDB 這樣的文檔數據庫提供了令人難以置信的模式靈活性，但這種靈活性消除了保持數據清潔的責任。 如果您不處理它們，您最終將在您的應用程序中編寫大量代碼來說明未以您期望的形式存儲的數據。 正如他們在我們公司 Simple Thread 中經常說的那樣……應用程序總有一天會被重寫，但數據將永遠存在。 注意：MongoDB 支持模式驗證，這很有用但不提供與關係數據庫相同的保證。 首先，添加或更改架構驗證不會影響集合中的現有數據。 您必須確保根據新模式更新數據。 自己決定這是否足以滿足您的需求。
- 自己的查詢語言/失去工俱生態：SQL 的出現是一場絕對的革命，從那以後什麼都沒有改變。 這是一種非常強大的語言，但也非常複雜。 需要用一種新的語言構建數據庫查詢，由 JSON 片段組成，這被有 SQL 經驗的人視為一大退步。 從 IDE 到報告工具，有一整套與 SQL 數據庫交互的工具。 遷移到不支持 SQL 的數據庫意味著您無法使用這些工具中的大部分，或者您需要將數據轉換為 SQL 才能使用它們，這可能比您想像的要困難。
許多轉向 MongoDB 的開發人員並沒有真正理解其中的取捨，並且經常一頭扎進將其設置為他們的主要數據存儲。 在那之後，要回去往往是非常困難的。
可以做些什麼？
不是每個人都是頭先跳後墜入谷底的。 但是有相當多的項目在它不適合的地方安裝了 MongoDB 基礎——他們將不得不使用它很多年。 如果這些組織花一些時間系統地考慮他們的技術選擇，許多人會做出不同的選擇。
如何選擇合適的技術？ 已經有幾次嘗試創建一個系統的技術評估框架，例如 и ，但在我看來，這是一種不必要的複雜性。
只需提出兩個基本問題，就可以對許多技術進行明智的估值。 問題在於找到能夠負責任地回答他們的人，花時間尋找答案並且沒有偏見。
如果您沒有遇到問題，則不需要新工具。 點。
問題 1：我想解決什麼問題？
如果您沒有遇到問題，則不需要新工具。 點。 無需尋找解決方案，然後提出問題。 除非您面臨的問題是新技術不能比您現有的技術更好地解決問題，否則這裡沒有什麼可討論的。 如果您正在考慮使用這項技術，因為您看到其他人使用它，請考慮他們遇到的問題並詢問您是否遇到這些問題。 擁抱技術很容易，因為其他人正在使用它，困難在於知道你是否面臨同樣的問題。
問題 2：我錯過了什麼？
這當然是一個比較難的問題，因為你必須對新舊技術都進行深入挖掘和理解。 有時你無法真正理解一個新的，直到你用它構建了一些東西或者有一個有這種經驗的同事。
如果您兩者都沒有，那麼考慮用最少的可能投資來確定該工具的價值是有意義的。 如果您進行了投資，那麼要扭轉這個決定會有多難？
人們總是毀掉一切
在嘗試盡可能公正地回答這些問題時，請記住一件事：你必須與人性作鬥爭。 為了有效地評估技術，必須克服許多認知偏差。 這裡僅僅是少數：
- 人人都知道他，但還是很難對付他。 只要確保該技術真正適合您的實際需求即可。
- 許多開發人員傾向於低估他們已經使用了很長時間的技術，而高估了新技術的好處。 不僅是程序員，每個人都會受到這種認知偏差的影響。
- 我們傾向於看到什麼是什麼，而忽視什麼不是。 這可能會導致混亂，再加上新奇效應，因為你不僅天生高估了新技術，而且忽視了它的缺點。.
客觀評估並不容易，但了解潛在的認知偏差將幫助您做出更理性的決定。
總結
當一項創新出現時，需要非常謹慎地回答兩個問題：
- 這個工具能解決實際問題嗎？
- 我們善於理解權衡取捨嗎？
如果您不能自信地回答這兩個問題，請退後幾步思考一下。
那麼 MongoDB 通常是正確的選擇嗎？ 當然可以； 與大多數工程技術一樣，它取決於許多因素。 在回答這兩個問題的人中，許多人已經從 MongoDB 中受益，並將繼續這樣做。 對於那些還沒有經歷過的人，我希望你們已經學到了關於穿越炒作週期的寶貴且不太痛苦的一課。
免責聲明
我想澄清一下，我既不喜歡也不討厭 MongoDB。 我們只是沒有 MongoDB 最適合解決的那種問題。 我知道 10gen/MongoDB 公司。 一開始非常大膽，設置不安全的默認值並在任何地方（尤其是在黑客馬拉鬆上）推廣 MongoDB 作為處理任何數據的一站式解決方案。 這可能是一個錯誤的決定。 但它證實了這裡描述的方法：即使對技術進行膚淺的評估，也可以非常快速地檢測到這些問題。
來源： www.habr.com