作者 | Mark Smith
譯者 | 王者
策劃 | 萬佳
我加入 MongoDB 還不到一年，但學到了很多東西。在面試這家公司前，我從未真正使用過 MongoDB，盡管我聽過一些有關它的演講，并且它的簡單易用給我留下深刻印象。
但和大多數人一樣，我也聽說過這些可怕的說法：“它不支持關系模型。如果你想存儲文檔，那沒問題，但如果以后想要進行聚合該怎么辦？你將被困在這個錯誤的數據庫里！而且不管怎樣，它不支持事務！”
當我開始查找這些信息的來源，才意識到兩個問題：首先，這些帖子大多是十年前的，所以他們所說的是一個剛剛推出三年的產品，而不是今天這個成熟、經過實戰考驗的數據庫。其次，他們說的幾乎都不再是對的，而且在某些情況下從來都沒有對過。
所以我決定做一個演講(并寫了這篇文章)來逐一澄清這些錯誤的說法。
1
迷思 0：MongoDB 是 Web 可伸縮的
YouTube 上有個視頻，視頻里有幾只狗（看起來應該是狗吧？)。你可能已經看到了——其中一只是盲目的新技術追隨者，它盲目相信 MongoDB，沒有真正加以了解。另一只狗比較理性，第一只狗的盲從讓它感到沮喪。
在加入 MongoDB 第一天，我的一個朋友給我發了這個視頻鏈接，但此前，我已經看過了?？纯慈掌?，這段視頻已經流傳十多年了。當時真的很有趣，但現在呢？里面幾乎所有的東西都過時了。
事實上，MongoDB 公司很多人的 T 恤或筆記本電腦貼紙上都有這個角色，它是 MongoDB 的非官方吉祥物。
2
MongoDB 到底是什么?
在開始講“MongoDB 不是什么”之前，我們來總結一下 MongoDB 到底是什么。
MongoDB 是一個分布式文檔數據庫。集群(我們稱之為復本集)大多是自我管理的——當集群中的每臺機器都知道了其他服務器的所在，如果其中一個節點宕機或網絡出現問題，它們會自動加以處理。如果其中一臺機器被關閉或發生崩潰，其他機器會接管。要實現仲裁，群集中至少需要有 3 個節點。集群中的每臺服務器都有數據庫所有數據的完整副本。
集群是為了冗余，而不是為了可伸縮性。所有的客戶端通常只連接到一臺服務器——被選舉出來的主服務器，它負責執行查詢和更新，并將數據變更傳輸到備用機器。
你可以直接連接到備用服務器做一些有趣的事情，比如運行分析查詢。但一般來說，直接連接到備用節點意味著你可能會遇到一些舊數據，所以不應該連接到備用節點，除非你可以接受舊數據。
講完“分布式”，接下來講講“文檔數據庫”。
MongoDB 與傳統關系型數據庫的不同之處在于，它不是將數據保存成扁平的行，然后存儲在數據庫的表中，而是在文檔中存儲分層結構的數據——基本上與 JSON 對象類似。文檔存儲在集合中，集合實際上就是一堆文檔。每個文檔可以具有與集合中其他文檔不同的結構或模式。你還可以（而且應該）根據將要運行的查詢類型和存儲數據對集合中的文檔進行索引。如果你想要確保集合中的所有文檔都遵循一種結構，可以將 JSON 模式應用于集合，作為驗證器。
上面的文檔是一個例子，顯示了 1893 年的一部電影的信息！文檔是用PyMongo驅動程序獲取的。
注意，這里有些值是數組，比如“countries”和“cast”，而有些值是對象（我們稱它們為子文檔）。這就是 MongoDB 文檔的層次結構——它們不像關系數據庫中的表行那樣扁平。
還需要注意的是，它還包含一個原生 Python datetime 類型的“released”字段，以及一個特殊的 ObjectId 類型的值。或許這個不是真正意義上的 JSON 文檔？我們待會再來說這個……
上面的文檔是一個例子，顯示了 1893 年的一部電影的信息！文檔是用PyMongo驅動程序獲取的。
注意，這里有些值是數組，比如“countries”和“cast”，而有些值是對象（我們稱它們為子文檔）。這就是 MongoDB 文檔的層次結構——它們不像關系數據庫中的表行那樣扁平。
還需要注意的是，它還包含一個原生 Python datetime 類型的“released”字段，以及一個特殊的 ObjectId 類型的值。或許這個不是真正意義上的 JSON 文檔？我們待會再來說這個……
3
迷思 1：MongoDB 的版本是 3.2
如果你在 Debian Stretch 上使用apt get mongodb安裝 MongoDB，它會安裝 3.2 版本。不幸的是，這個版本已經是 5 年前的了！從那時起，已經發布了 5 個主要版本，它們包含大量的新特性，以及安全性、性能和可伸縮性方面的改進。
MongoDB 的當前版本是 4.4（截至 2020 年末）。如果你要安裝，應該安裝MongoDB社區服務器版，但最好請先了解一下MongoDB Atlas，也就是我們的托管數據庫即服務（DBaaS）產品！
4
迷思 2：MongoDB 是一個 JSON 數據庫
你肯定聽說過 MongoDB 是一個 JSON 數據庫的說法，特別是如果你最近訪問過 MongoDB 的主頁。
不過，正如前面提到的，MongoDB 不是一個 JSON 數據庫。它支持額外的數據類型，比如對象、原生日期對象、更多的數字類型、地理原語和高效的二進制類型等等。
MongoDB 實際上是一個 BSON 數據庫。
這似乎是一個微不足道的區別，但卻很重要。與基于文本的格式相比，它在存儲、傳輸和遍歷方面更高效，而且比 JSON 支持更多的數據類型。
MongoDB 存儲的是 BSON 文檔
用于查找的實際上也是 BSON 文檔
結果以 BSON 文檔的形式輸出
BSON 甚至是 MongoDB 的有線協議
如果你習慣了使用 JSON，可以將 MongoDB 看成是 JSON 數據庫，這就是為什么我們有時會這樣描述它！等你使用 MongoDB 一段時間，就會開始對 BSON 的優勢大加贊許。
4
迷思 3：MongoDB 不支持事務
一些第三方文章將 MongoDB 描述成 BASE 數據庫。BASE 是指“基本可用、軟狀態、最終一致”。
但這不是真的，從來都不是！MongoDB 從來都不是“最終一致”的。對主文檔的讀寫是強一致性的，對單個文檔的更新始終是原子的。軟狀態是指需要持續不斷的更新數據，否則數據就會過期，但 MongoDB 并非如此。
最后，如果太多的節點不可用，無法達成仲裁，MongoDB 將進入只讀狀態（降低可用性）。這是有意這么設計的，因為這樣可以確保在出現問題時保持一致性。
MongoDB 是一個 ACID 數據庫。它支持原子性、一致性、隔離性和持久性。
對單個文檔的更新始終是原子的，從 4.0 版本開始，MongoDB 也支持跨多個文檔和集合的事務。從 4.2 開始，甚至支持分片集群的跨分片事務。
雖然 MongoDB 支持事務，但在使用它時仍然要謹慎。事務是以性能為代價的，而且由于 MongoDB 支持豐富的分層文檔，如果你的模式設計正確，就沒有必要經?？缍鄠€文檔更新數據。
5
迷思 4：MongoDB 不支持關系
關于 MongoDB 另一個過時的說法是，你不能在集合或文檔之間建立關系。你可以使用聚合管道來連接文檔，它們非常強大，你可以使用直觀的查詢模型來查詢和轉換來自多個集合的數據。
MongoDB 從 2.2 開始就支持查找（連接）。
下面的示例文檔演示了將訂單集合和庫存集合連接之后，在返回的訂單文檔中包含了嵌入到數組的庫存文檔。
我認為，能夠在返回的主文檔中嵌入相關文檔比在關系連接中為每個關系復制行更直觀。
6
迷思 5：MongoDB 完全是關于分片
你可能聽人說過分片是 MongoDB 的一個很酷的特性。這絕對是 MongoDB 的一個很酷的核心特性。
分片是指將數據分成片段，并將每個片段放到不同的復制集或集群中。這是一種處理龐大數據集的技術。MongoDB 可以自動將數據和請求發送到正確的副本集，并將來自多個分片的結果合并起來。
但分片存在一個很根本的問題。
我在前面提到過，副本集的最小節點數是 3，這樣才能實現仲裁。在進行分片時，至少需要兩個副本集，因此至少需要 6 臺服務器。除此之外，你還需要運行多個 mongos 實例。mongos 是分片集群的代理，負責路由請求和響應。要實現高可用性，至少需要兩個 mongos 實例。
因此，這意味著一個分片集群最少需要 8 臺服務器，每增加一個分片，就會增加至少 3 臺服務器。
分片集群還會使數據變得難以管理，并且會限制可執行的查詢類型。如果你確實需要進行分片，那么分片對你來說確實是有用的，但更簡單的辦法是直接升級硬件，通常這樣更便宜、更容易。
數據的伸縮主要與 RAM 有關，所以如果可以的話，請購買更多的 RAM。如果 CPU 是瓶頸，那就升級 CPU。如果磁盤容量是個問題，那就買一個更大的磁盤。
MongoDB 的分片功能一直都在，如果對內存的需求超過了一臺計算機的容量，可以使用分片。你還可以使用分片功能做一些有趣的事情，比如地理位置固定，可以將用戶數據存儲在離用戶位置更近的地方，從而減少延遲。
在決定使用分片進行數據伸縮時，應該先考慮一下硬件升級是否是一個更有效的選擇。
你可以看看 MongoDB Atlas，MongoDB 的托管數據庫即服務（DBaaS）產品。MongoDB Atlas 不僅可以在你選擇的云平臺上托管數據庫，還可以根據需要伸縮數據庫，保持可用性，同時保持較低的成本。它將負責處理備份和冗余，還提供了額外的功能，如圖表、文本搜索、無服務器功能等等。
7
迷思 6：MongoDB 不安全
關于 MongoDB 的另一個誤解，是說它不安全。我個人認為，這對 MongoDB 來說是一種不公平的評判，但不可否認的是，在互聯網上有很多不安全的 MongoDB 實例，而且發生了幾起涉及數據泄露的事故。
從歷史上看，這是由于 MongoDB 的發行方式導致的。一些 linux 發行版曾經在發行 MongoDB 時啟用網絡并禁用身份驗證。
因此，如果你沒有防火墻，或者打開了防火墻上的 MongoDB 端口，那么你的數據就有可能被竊取。現如今，機器人很可能會找到你的數據，把你的數據加密，然后再加上一個文檔向你勒索比特幣。
我想說的是，如果你將一個不受保護的數據庫服務器放到互聯網上，那就是你的錯——這種情況肯定已經發生過很多次了，而且肯定有辦法不讓事態變得如此糟糕。
我們對 MongoDB 3.6 的一些默認設置進行了修復。MongoDB 不會連接到網絡，除非啟用身份驗證，或者你給服務器設置了一個特定標志來覆蓋這個行為。所以，如果使用不當，仍然可能不安全。不管怎樣，你至少要先閱讀一下手冊。
除此之外，在安全方面，MongoDB 還使用了行業標準，例如使用 TLS 對傳輸中的數據進行加密，使用 SCRAM-SHA-256 對用戶進行安全認證。
MongoDB 還提供了客戶端字段級加密(FLE)功能，數據在客戶端和傳輸過程中都是經過加密的。也就是說，如果第三方拿到數據庫服務器的訪問權限，但沒有客戶端訪問權限，也無法讀取加密的數據。
8
迷思 7：MongoDB 會丟失數據
這在 Hacker News 上是一個很經典的問題。有人發帖子分享他們如何成功地用 MongoDB 開發了一些東西，然后立刻有人評論說：“我知道這個人曾經把 MongoDB 里所有的數據都弄丟了，所以請避免同樣的事情發生。”
如果你繼續聯系這些用戶，并讓他們提交問題，他們就消失了。
MongoDB 被廣泛應用于那些非常關心數據保存問題的行業，從摩根士丹利、巴克萊和匯豐等大型銀行，到福布斯等大型出版品牌。我們從未收到過有關大規模數據丟失的報告。如果你確實有關于數據丟失的第一手故事要講，請向我們反饋，無論你是付費企業用戶還是開源用戶，我們都會認真對待。
9
迷思 8：MongoDB 只是一個玩具
看到這里，你就已經知道這是一個迷思了。
MongoDB 是一個用于存儲文檔的通用數據庫，它可以安全、原子地更新數據，可以與其他文檔連接，提供了豐富、強大和直觀的查詢語言。當你的數據規模大到一臺機器裝不下，可以進行分片，它還支持高級功能，例如用于保護敏感數據的客戶端字段級別加密、可以讓應用程序立即響應變更數據的變更流。
https://developer.mongodb.com/article/everything-you-know-is-wrong
