2018 年 10 月，MongoDB 將其開源許可證從 GNU AGPLv3 切換到 Server Side Public License(SSPL)，並明確指出之所以會更改開源協議是因為部分雲計算公司在使用 MongoDB 的時候沒有遵循其開源協議。
2019 年 1 月 9 日，AWS 宣佈推出 Amazon DocumentDB，一個兼容 MongoDB 的數據庫。據 AWS 官網介紹，Amazon DocumentDB 是一種可支持 MongoDB 工作負載的快速、可擴展、高可用並完全託管的文檔數據庫服務。開發人員可以像現在一樣使用 MongoDB 應用程序代碼、驅動程序和工具來運行、管理和擴展 Amazon DocumentDB 上的工作負載，並享受更好的性能、可擴展性和可用性，而無需擔心管理底層基礎設施。
即使 MongoDB 更改協議，這塊蛋糕 AWS 也想照吃不誤？
事實上，MongoDB 修改開源協議要針對的對象很明確就是雲廠商，而 AWS 發佈 Amazon DocumentDB 的這一舉動無疑是對 MongoDB 的一次回應：既然你不爽我直接用 MongoDB，那沒關係我自己開發一個數據庫。
為什麼 AWS 要死盯著 MongoDB 的市場呢？根據 DB-Engines 發佈的數據庫流行度，MongoDB 目前排在第五位，如果縮小範圍到開源數據庫，MongoDB 排在第三位（前兩位為 MySQL 和 PostgreSQL），如果範圍縮小到文檔存儲數據庫，那麼 MongoDB 是大幅度領跑的。因此，雲廠商在提供雲數據庫服務時，MongoDB 自然就成為了必選，如果不選，那麼就意味著會有一大批客戶會轉到競爭對手那裡或者直接流失掉。
AWS 推出 Amazon DocumentDB 僅僅只是要克隆一個 MongoDB 嗎？顯然並不是，因為 MongoDB 在使用時很容易報錯，有人調侃，MongoDB 出錯都不是一個 Bug，而是它的特性。AWS 官方也印證了這一點：
- MongoDB 的 API 和表達性語言查詢雖然可以幫助客戶快速構建應用程序，但是實際情況是客戶往往只需要 API 提供的一小部分功能；
- 有客戶反饋在 MongoDB 上構建高性能、高可用性的應用程序非常困難，原因是設置和管理 MongoDB 集群實在太複雜了。有的應用程序可能需要每秒快速擴展到多兆字節（tbs）和數十萬次讀寫，因此，客戶不得不花費大量的時間和費用來管理大規模的 MongoDB 集群；
- 與本地部署一樣，MongoDB 託管系統也面臨著數據複製的挑戰，而且在發生故障之後往往需要很長的恢復時間。
很顯然，AWS 的野心並不只是要克隆一個 MongoDB，而是要做一個兼容 MongoDB 並且優於 MongoDB 的數據庫產品。
之前的 MongoDB 如何遷移到 Amazon DocumentDB 呢？
相信在聽到這個消息之後，很多人的第一反應都是“之前的 MongoDB 如何遷移到 Amazon DocumentDB 呢？”AWS 官方稱，客戶可以使用 AWS 數據庫遷移服務（DMS）輕鬆地將其本地或 EC2 MongoDB 數據庫遷移到 Amazon DocumentDB。Amazon DocumentDB 通過模擬 MongoDB 客戶端對 MongoDB 服務器的響應來實現 Apache 2.0 open source MongoDB 3.6 API，允許客戶將現有的 MongoDB 驅動程序和工具與 Amazon DocumentDB 一起使用。
前文我們提到了 AWS 想做的一個優於 MongoDB 的數據庫產品，那麼具體會體現在哪裡呢？
- Amazon DocumentDB 採用了分佈式、容錯、自我修復的存儲系統，集群可自動擴展到 64 TB，客戶無需為容量規劃而擔心；
- Amazon DocumentDB 只會將數據庫更改寫入存儲層，從而減少了數據庫 I/O，避免了跨網絡鏈接的低效數據複製；
- Amazon DocumentDB 在高級查詢處理、連接池、恢復、重建等方面做了優化，吞吐量可達當前 MongoDB 解決方案的兩倍；
- Amazon DocumentDB 採用了存儲和計算分離的架構，允許獨立擴展，開發者可在幾分鐘內添加 15 個低延遲讀取副本（無需考慮數據大小），讀取容量可提升至每秒數百萬個請求。
- Amazon DocumentDB 採用了 AWS 多可用區技術，可在 AWS 的三個 AZ 之間複製六份數據，可用性高達 99.99%。
在費用方面，AWS 也給出瞭解答，使用 Amazon DocumentDB 不需要預先付費，按使用量付費即可。
開源如何才能走出一條更好的路徑呢？
開源運動轟轟烈烈的進行了近 30 年，在技術創新和發展方面取得了一些成績，但是在商業變現方面至今也沒有探索出一條比較好的路徑。筆者在和專家交流時也贊同了這個觀點，“微軟 75 億收購 GitHub，這可能是開源商業變現最具參考的例子了，但是大家也只是有了一個模糊的概念：多少行代碼、多少開發者對應多少錢，並沒有真正探索出開源變現的路徑。”
開源項目、商業公司和用戶其實是一個三方矛盾的存在。開源項目並非是天上掉餡餅，也是要燒錢、花精力的，MongoDB 首席執行官 Dev Ittycheria 就曾表示，過去十年，在 MongoDB 的研發上投入了 3 億美元，所以開源項目背後的公司自然希望能夠源碼貨幣化，甚至是可以獨家貨幣化。對於用戶來說，他們只希望能在自己的系統中大規模運行源碼，並且能夠解決他們現階段的業務問題，提供性能，減少成本。而對於商業公司來說，就要平衡這兩方的矛盾。
以 Amazon DocumentDB 和 MongoDB 為例，如果未來 Amazon DocumentDB 在 AWS 的用戶中取得了成功，那麼 AWS 又將如何管理基於開源項目的服務呢？AWS 表示，當我們選擇推出基於開源項目的服務時，就做好了長期維護的準備，並且我們也會大力貢獻於此開源項目。
如果此次 Amazon DocumentDB 和 MongoDB 能夠長期穩定運行下去，那麼會不會為開源項目趟出一條更好的路徑呢？
參考鏈接：https://press.aboutamazon.com/news-releases/news-release-details/aws-announces-amazon-documentdb-mongodb-compatibility
閱讀更多 InfoQ 的文章
