MongoDB是不是正確的選擇？ - simplethread

banq發表於2019-03-27
MongoDBthread

MongoDB和一般的文件資料庫解決了傳統關聯式資料庫的一些問題：
  1. 嚴格的模式 - 使用關聯式資料庫，如果你有動態形態的資料，你不得不建立一堆隨機的“雜項”資料列，將資料作為一個資料塊推送，或使用EAV設定...所有這些都有重要意義缺點。
  2. 難以擴充套件 - 使用關聯式資料庫，如果您的資料太大而無法輕鬆地將其放入一臺伺服器中，MongoDB內建了允許您跨多臺計算機擴充套件資料的機制。
  3. 困難的架構修改 - 沒有遷移！使用關聯式資料庫，更改資料庫的結構可能是一個巨大的挑戰（特別是一旦您的資料變得非常大）。MongoDB承諾使這一過程變得更加簡單。它使得它很容易上手，你可以繼續更新你的架構並快速移動。
  4. 寫效能 - MongoDB的效能很好，特別是在以某種方式配置時。MongoDB開箱即用的寫入配置，這是它受到批評的重大事件之一，它允許它提供一些令人印象深刻的效能數字。

MongoDB提供的潛在好處是巨大的，特別是對於面臨某些類問題的人。在沒有上下文或經驗的情況下閱讀上面的列表會讓你相信它在資料庫系統方面真正改變了遊戲規則。唯一的問題是上面列出的好處帶來了一些警告，其中一些我在下面列出：
  1. 沒有事務 - 事務是許多關聯式資料庫的核心特徵（不是，不是全部，而是大多數）。進行事務意味著您可以原子地執行多個操作，並且可以確保您的資料保持一致。當然，使用NoSQL資料庫，您可以在單個文件中擁有事務，或者您可以使用兩階段提交等策略來獲得類似事務的語義。但關鍵是你必須自己做這項工作......而且要做到正確，這可能是一項具有挑戰性和勞動力密集的工作。在您開始看到資料庫中的資料進入無效狀態之前，您通常不會意識到您放棄了多少，因為您無法保證操作的原子性。
  2. 失去關係完整性（外來鍵） - 如果你的資料有關係，那麼你就會有關係。幾乎所有資料都有某種關係，如果您的資料庫沒有強制執行，那麼您的應用程式將不得不這樣做。讓資料庫強制執行這些關係可以從應用程式中解除安裝大量工作，從而減輕工程師的工作量。
  3. 缺乏執行資料結構的能力 - 強有力的模式有時可能是一種痛苦，但它們也可以成為確保資料結構良好的強大機制。如果您恰當地利用它們，它提供了一種強大的機制來確保您的資料符合您期望的形狀。像MongoDB這樣的文件資料庫可以在模式周圍提供令人難以置信的靈活性，但這種靈活性可以將責任轉移到維護者身上，以保持資料的清潔。如果您沒有付出這些努力，那麼您最終會在應用程式中新增大量程式碼，以便考慮可能不符合您預期形狀的資料。正如我們經常喜歡在簡單執行緒中說的那樣...您的應用程式將在某一天被重寫，您的資料將永遠存在。
  4. 自定義查詢語言/工具生態系統的丟失 - SQL出現時是一場絕對的革命，從那以後沒有任何變化。SQL是一種非常強大的語言，但也可能具有挑戰性。必須使用由JSON片段組成的自定義查詢語言查詢資料庫，對於經驗豐富的SQL人員來說，這將被認為是一大步。有一整套工具可與SQL資料庫互操作。從IDE到報告工具的一切。遷移到不支援SQL的資料庫意味著您無法使用大多數這些工具，或者您必須找到一種方法將資料放入SQL資料庫以便可以使用這些工具，這可能比您認為。

許多參與MongoDB的開發人員並沒有深入理解他們所做的權衡，而且他們常常將它作為應用程式的主要資料儲存區。這意味著這個決定通常是非常昂貴的。

未來幾年將有一些專案將MongoDB從其不適合的地方移除。如果這些組織中的許多組織花了一些時間來有條不紊地思考他們所做的技術選擇，那麼很可能他們中的許多人都沒有做出他們所做的決定。
那麼，您如何確定哪種技術對您的用例有意義？已經有一些嘗試建立用於評估技術的系統框架，例如“ 軟體組織中的技術引入框架 ”和“ 評估軟體技術的框架 ”，但我不認為它需要那麼複雜。
 

相關文章