沒有一個技術天生完美，MongoDB 十年發展全紀錄

摘要： 2007 年，MongoDB 公司的前身 10gen 正式成立，2009 年 2 月開源資料庫 MongoDB 1.0 正式面世，以開源的方式進入市場接受考驗。時至今日，MongoDB 已經從一個在資料庫領域籍籍無名的“小透明”，變成了話題度和熱度都很高的“流量”資料庫。 2009...

2007 年，MongoDB 公司的前身 10gen 正式成立，2009 年 2 月開源資料庫 MongoDB 1.0 正式面世，以開源的方式進入市場接受考驗。時至今日，MongoDB 已經從一個在資料庫領域籍籍無名的“小透明”，變成了話題度和熱度都很高的“流量”資料庫。

• 2009 年 2 月，MongoDB 資料庫首次在資料庫領域亮相，打破了關係型資料庫一統天下的局面；
• 2014 年 12 月, MongoDB 收購了 WiredTiger 儲存引擎，大幅提升了 MongoDB 的寫入效能；
• 2016 年, MongoDB 推出 Atlas，在 AWS、 Azure 和 GCP 上的 MongoDB 託管服務；
• 2018 年 6 月, MongoDB 推出 ACID 事務支援，成為第一個支援強事務的 NoSQL 資料庫；
• 2018 年 11 月，MongoDB 將其開源授權修改為 SSPL；

10 年間，MongoDB 的每一次創新幾乎都引起了業界的討論。當然除了好訊息，MongoDB 也有一些其它的聲音傳出，例如 2017 年廣為人知的“MongoDB 贖金”事件，因預設不需要使用者名稱密碼登入的設定，屢次發生的企業資料洩露事件。

MongoDB 到底是個什麼樣的資料庫呢？作為資料庫，其到底經歷了怎樣的發展歷程，擁有哪些核心競爭力？展望未來，MongoDB 又將走向何方？…為了讓大家更加清晰全面的瞭解 MongoDB，我們特意邀請 MongoDB 中文社群發起人、MongoDB 官方大中華區首席架構師唐建法撰寫了本文。

眾所周知，資料庫是所有軟體中除了作業系統之外最複雜的軟體。按照 DB-Engines.com ， 一個專門跟蹤資料庫流行程度並每月釋出資料庫排名的一個網站的統計，排名前 5 的資料庫分別為 Oracle, MySQL, SQLServer, PostgreSQL 和 MongoDB。

從一個名不經傳的科技創業公司，到今天可以說是家喻戶曉的知名資料庫廠商；從一個籍籍無名的小透明資料庫，到現在成長為各大公司爭相採用的資料庫產品，MongoDB 到底經歷了怎樣的發展歷程？

MongoDB 編年史

技術發展重要節點及事件

文件資料庫鼻祖的誕生

2007 年, 10gen 創始人 Eliot 和 Dwight 在尋找一個能夠支援他們的雲端計算平臺的海量資料庫。不奇怪，當時成熟的資料庫基本上都是基於單機架構的傳統關係型資料庫如 Oracle, MS SQLServer 等。即便 Oracle 支援一些叢集部署，其擴充套件性也僅限於 2 到 4 臺伺服器的範圍。在沒有很好的解決方案的情況下，10gen 的創始人決定自己研發一個數據儲存服務，能夠把開發者使用的程式物件資料存到一個類似於資料庫的地方，並提供非常易用的 API 讓開發者可以對資料進行常見的增刪改查操作。為了最大程度方便開發者，Eliot 決定使用 JSON 作為資料格式來儲存。JSON 的資料在英文中被稱之為 JSON Document，這也是文件資料庫名字的由來。 事實上證明這個基於 JSON 的選擇，成就了一家偉大的新型資料庫公司。

MongoDB 自動分片

2010 年 8 月, 10gen 釋出了 MongoDB 1.6，第四個大版本。這個版本最大的一個功能就是 Sharding，自動分片。在關係型資料庫中，當資料量達到一定程度，單個節點伺服器資源充分飽和無法保證及時的服務響應時間時，通常會採用分割槽分表的資料庫優化方案。但是這些方案都是侵入式的，很多時候意味著應用程式需要做較大的改動，來配合資料庫端的改動。而 MongoDB 的自動分片，可以在一個叢集的幾個分片伺服器內自動進行資料的分佈和均衡。在儘可能把資料均勻的分佈到多個儲存節點的同時，為應用開發者提供無縫的體驗。開發者無須關心資料的具體位置，程式也不需要因為分片與否而進行修改。採用分片技術，開發者可以很容易使用數十甚至數百個節點。早期的使用者如百度就是基於這種分片技術，為 3 億多使用者、3000 億條資料量的百度雲盤檔案元資料管理提供有效的叢集解決方案。

MongoDB 支援儲存引擎 API 並引入 WiredTiger 儲存引擎

2014 年 12 月，MongoDB 收購了 Keith Bostic 和 Michael Cahil 的 WiredTiger 儲存引擎團隊，並將其整合到 3.0 版本中，成為一個新的儲存引擎。

在此之前，MongoDB 在儲存層使用的是作業系統自帶的 MMAP API 進行資料落盤持久化工作。從功能實現角度，使用 MMAP 使得早期團隊可以集中注意力在 MongoDB 的 API、查詢、索引計劃、資料同步等上層邏輯。但是隨著 MongoDB 使用場景的增多以及資料量的增加，MMAP 在大量寫入場景下的效能瓶頸日益凸顯，同時也成為了早期很多效能槽點的根源之一。

WiredTiger 的引入是 MongoDB 走向一個成熟資料庫的最重要的里程碑。在效能上，WiredTiger 較之老版本的 MongoDB 提升了 7-10 倍，有效地解決了之前 MMAP 在大量寫入下的效能瓶頸。

值得一提的是，Bostic 和 Cahil 在之前曾把他們的前一代產品 BerkerlyDB 賣給了 Oracle。Oracle 隨後推出以 BerkerlyDB 為核心的 Oracle NoSQL 資料庫。Oracle NoSQL 基本上是一個未被人聽說過的產品。從這一點上似乎證明了，對廣大開發者來說，首先要有一個易用的資料庫，然後才是一個高效能的資料庫。

MongoDB 支援 Join

2015 年 12 月，在釋出的 3.2 版本中，在 MongoDB 的聚合框架（Aggregation）中增加了一個不起眼的操作符: $lookup。 這個看上去雖小，但是意義巨大的功能意味著第一次作為一個 NoSQL 資料庫，MongoDB 終於開始支援了關係型資料庫的核心功能：關聯。從 3.2 開始，你可以一次同時查詢多個 MongoDB 的集合（表），不用像以前那樣，如果有多表查詢需要在程式碼中發起多個數據庫查詢，然後在記憶體中進行手工關聯。

MongoDB 成功上市納斯達克

2017 年 10 月，MongoDB 成功在納斯達克敲鐘，成為 26 年來第一家以資料庫產品為主要業務的上市公司。一年多後再看，MongoDB 的股價蹭蹭蹭的升了 4 倍多。如果我們和 Cloudera / Hortonworks 比較，兩家以 Hadoop 產品為主要業務的大資料科技公司，兩家現在加起來的市值，尚不如一個 MongoDB。這是為什麼？

最大的原因就是基於 Hadoop 產品的目標場景是大資料分析，首先用大量低成本儲存聚集所有企業內外部資料，然後用 MapReduce 技術來對客戶進行畫像，貼標，或者製作一些統計報表。雖然這些場景確有價值，較之於 MongoDB 驅動的操作型場景，如新型手機應用，遊戲，物聯網，數字化銀行等，無疑 MongoDB 支撐的是直接面向客戶的，更加有業務價值的應用。

MongoDB 贖金事件

隨著 MongoDB 的使用者數量持續快速增長，日漸成為企業的標準資料庫，MongoDB 的負面事件也不斷。2017 年網路上流傳最多的就是所謂的贖金事件。黑客們侵入使用者的 MongoDB 資料庫，把資料全部刪掉，然後留下一條訊息，要求使用者用比特幣支付價值幾千美元的贖金，才將資料庫資料恢復。

究其根底, 這個其實和很多 MongoDB 資料洩露，如後來的 58 同城 2 億份簡歷事件，具有同樣的技術原因：MongoDB，為了最大程度上方便程式設計師快速開發應用，預設方式下不需要設定使用者名稱密碼登入。這樣一來，很多粗心的程式設計師，特別是創業公司，往往在系統正式上線時候也沒有啟用鑑權。就譬如你買了一套房子卻沒有使用門鎖一樣。只要稍具一些安全常識，就可以妥善防範資料在公網上洩露，具體細節可以參考 MongoDB 中文社群之前發過的這篇博文 ( http://www.mongoing.com/archives/3738 ) 。

MongoDB 支援 ACID 多行多表強事務

2018 年 6 月，MongoDB 推出 4.0 版本。和 3 年前有點類似，本來要釋出 2.8 版本的，結果因為引入 WiredTiger 儲存引擎，版本改成了 3.0。 按原計劃本該釋出 3.8 的，但是由於引入了千呼萬喚始出來的多文件 ACID 強事務機制，MongoDB 決定版本改為 4.0.

ACID 事務機制已經是關係型資料庫如 Oracle, SQLServer，PostgreSQL 的標配。之前 MongoDB 對事務的支援僅限於單文件內。如果你在開發一個電商應用，在一筆交易內要完成插入訂單，扣庫存，推送到訊息佇列等操作，原先的 MongoDB 版本無法保證這幾個步驟的原子性，也沒有出錯情況下的回滾機制。 因為這個功能的缺失，很多開發者或架構師會在交易性的業務中有意避開 MongoDB。而隨著 4.0 的釋出，MongoDB 終於可以挺起胸昂起背，向世界宣佈 MongoDB 正式成為第一階層操作型資料庫，可以用來支撐幾乎所有的業務場景。

SSPL 開源協議

2018 年末 MongoDB 又一次被推上風口浪尖。這一次是 MongoDB 在 10 月份釋出了其修改版開源協議：從 AGPL 到 SSPL。對於大多數開發者來說，他們可能都不清楚他們一直以來用的 AGPL 到底是什麼樣的一個開源協議。簡單一點來說，對於 AGPL，如果不去修改 MongoDB 的原始碼，使用者基本上就是在符合開源協議的情況下使用 MongoDB。但是一旦涉及到原始碼的改動，比如說很多雲廠商在推出 MongoDB 服務的時候，為了滿足自己環境、效能、場景及管理的需求，幾乎無法避免不去修改原始碼。這樣情況下，按照 AGPL，雲廠商必須對外公佈你的改動，以及相關聯的軟體。但是 AGPL 裡面對於這一部分有一些比較模糊的地方，以至於很多雲廠商並沒有按照遊戲規則來進行開源。在這樣的情況下，MongoDB 推出了基於 AGPL 上的修改版：SSPL。對於絕大絕大部分的開發者或企業，SSPL 和 AGPL 沒有任何區別。只有那些在公有云上提供 MongoDB 託管服務 (MongoDB as a Service) 的公有云廠商會在 SSPL 協議下受到影響：要麼和 MongoDB 達成商業合作採用商業協議，要麼開源其所有云管理解決方案。

當然，MongoDB 不是唯一的一家開源軟體公司針對雲廠商改變開源協議。MongoDB 之前有 Redis，之後有 Kafka，都在類似的背景下作了開源協議修改。目前看來，開源社群似乎並不太喜歡這種商業化的運作，但是開發者可以記住：MongoDB 技術本身並無過錯，還是以前的那個開源的 MongoDB，還是可以在你的應用中幫你解決切實的資料管理問題。

MongoDB 社群發展

MongoDB 的成功，很大程度上是開發者社群起了非常關鍵的作用。MongoDB 則從一開始就全力以赴支援了開源社群，上到 CTO，下至開發工程師，大家在社群裡，論壇上，郵件組裡熱心的為使用者提供技術支援，吸取使用者的反饋。在現在仍然非常活躍的 Google Group，最早你可以看到這個郵件：

這個是當時的聯合創始人 Dwight 在群裡釋出關於 MongoDB 的功能改進。到了 2012 年，MongoDB 成立專門的技術支援團隊，其中有個成員 Stephen Steneker 組織起了專門的社群支援團隊，開始在 Stackoverflow 和 Google Groups 提供系統性的技術支援。

除了對社群提供技術支援，MongoDB 社群極具特色的使用者組織 MUG（MongoDB User Group）則是對推廣 MongoDB 技術最有影響力的一個渠道。這些使用者社群往往是由社群裡的 MongoDB 愛好者，在當地組織起來， 踴躍分享 MongoDB 截然一新的開發模式，和分散式系統解決的擴充套件性問題。

在中國地區也有同樣的 MUG 組織。 MongoDB 中文社群（ mongoing.com ）自 2014 年成立，專門服務大中華地區及其他地區使用中文的使用者。 中文社群由部落格、線下活動、技術問答、微信 /QQ 群、文件翻譯等模組組成，截至 2019 年社群已成功舉辦數十場人數超百的線下活動，發表關於 MongoDB 應用優質文章百餘篇，會員總數已超 2 萬，相關合作單位已達 20 多家。根據百度指數統計 MongoDB 的搜尋頻率明顯高於其他類似資料庫。中國地區的下載量也於 2017 年開始正式超過了美國成了全球最大的下載使用地區，這裡面中文社群功不可沒。

未來規劃及期望

1. 堅持開源和商業化兩條腿走路的策略

MongoDB CTO Eliot 非常明確 MongoDB 會將開源堅持到底。從很多方面看，Eliot 都是一個典型的程式設計師出身的技術 geek。 讓 MongoDB 成為程式設計師在開發應用時候的首選資料庫，可以說是他的個人夢想。要做到這一點，作為一個通用型的資料庫，其開發的易用性、功能的完善性、效能的穩定性以及資料的安全性，都需要大量的人力來投入。有一個成功的商業化支撐，才能充分保證這些複雜研發工作的高效、有序進行。所以 MongoDB 商業化上的成功，只會進一步讓社群使用者獲利。

從商業化的角度，MongoDB 雄心勃勃地在全球佈局。連續幾年 50% 左右的增長，位列快速增長軟體公司前三，使其獲得了華爾街投資者的青睞。前段時間 AWS DocumentDB 的釋出，大家都以為會給 MongoDB 帶來很大的打擊，事實上，開發者還是相信一個已經發展了 10 多年，經過了戰火洗禮的原生 MongoDB。當然，雲供應商鎖定也是讓開發者們考慮的一個重要地方：大家還是希望在需要的時候，可以自由的切換到其他的雲端計算供應商。

2. 加註雲資料庫

2016 年 MongoDB 釋出 Atlas，一個在 AWS,、GCP、 Azure 上面提供的跨雲 MongoDB 託管服務。 Atlas 成為 MongoDB 發展最快的一個業務。在雲端計算大方向下，MongoDB 正在大規模投入雲服務的建設中。

持續增強跨地域叢集，跨雲集群等雲上分散式能力

MongoDB Atlas 已經是目前在跨中心跨地域部署方面比較領先的一個雲資料庫。按照其主打的 Cloud-agonostic 的策略，很可能未來會提供跨雲集群部署能力，為企業提供最可靠的容災解決方案。

雲資料庫增值服務： Stitch

一個類似於 AWS Lambda 的無伺服器產品。允許開發者直接跳過虛擬機器部署，中介軟體安裝等步驟，直接在基於 Atlas 的 Stitch 平臺上提交程式碼並立即執行程式碼。Stitch 目前有以下幾大關鍵功能：

• Query Anywhere, 提供對 MongoDB 資料庫的訪問；

• Functions, 無伺服器架構下實現業務邏輯的地方，目前支援 javascript；

• 細顆粒度的許可權管理, 使用 GUI 配置方式快速定義應用的許可權管理；

• 外部 API 整合，平臺直接繼承了許多實用的 API 如 Twitter, Google, Facebook 等；

雲資料庫增值服務： Trigger

在 Atlas 上面提供的實時流計算處理能力，類似於傳統資料庫的觸發器，但是更加靈活，並且可以支援每小時數百萬的併發流資料處理能力。可以支援實時事件響應，狀態通知等場景

3. 補足分析型的短板

我可以找出一大堆用 MongoDB 來做大資料分析的客戶，如某世界級半導體企業用 MongoDB 替換 Hadoop 來管理產線大資料，為資料科學家的產品質量分析及事故溯源提供支援，又如某電信公司使用 MongoDB+Spark 來執行使用者行為分析並驅動實時精準促銷推送。這些場景都是上百至上千億的資料量。但是相對於用 MongoDB 來作為操作型資料庫（OLTP)，分析型的使用可能只是個零頭。如果要發展成為一個企業的標準資料庫，勢必要在分析上提供更多的能力，如海量資料的併發分析效能、多表關聯分析以及資料視覺化等。 前不久釋出的 MongoDB Charts 也彰顯了 MongoDB 在這一方面的發展方向。

結語

沒有一個技術是完美的，MongoDB 也不例外。但是回顧過去 10 年，MongoDB 從幾十乃至數百個 NoSQL/NewSQL 產品中脫穎而出，面對社交網路上大量的各種負面打擊，披荊斬棘殺出一條血路，獲得今天這個相對來說一個比較成功的市場地位，絕對不是一個偶然行為。 作為一個技術人，要具備一定的辨別能力，在網上充斥各種 MongoDB 資料洩露或者其他負面故事的背後，你要認識到作為一個文件型資料庫，MongoDB 的核心競爭力在於：

• 基於 JSON 的資料模型最接近開發者的面向物件的設計思維；

• 靈活動態的模型意味著在需求多變的時候極大簡化資料庫設計流程；

• 自動分片、多節點自動同步和跨中心能力支援各種現代化複雜部署需求。