最近InfoQ發佈了“別了，MongoDB”（翻譯自衛報作者Philip McMahon等發表的英文博客 https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres） 一文引起比較大的反響。如果關心技術社區的朋友們都知道，圈子裏時不時會冒出一篇 (MySQL | PostgreSQL | MongoDB ) 遷移到 (MySQL | PostgreSQL | MongoDB ) 的文章。有些時候因爲選型不當，有些是因爲時間的變遷導致場景變化，有些時候是因爲有更先進的技術或者更適用產品出現。這些其實都符合技術正常變革的自然規律。但是衛報的這篇文章加上前不久的58簡歷泄露事件，讓MongoDB中文社區的核心成員們覺得有必要站出來澄清事實，以防止標題黨語不驚人死不休，以流量爲目的，完全無顧於技術的科學性和嚴肅性。
衛報遷移事件解析
其實這是衛報10年來第二次數據庫遷移，第一次是從Oracle。我們來看下這幾年的事件回放：
-
2011年4月，衛報成爲最早的MongoDB用戶之一，成功上線其構建在MongoDB之上的內容管理系統。
-
2011年11月，在QCon的一次大會上，Guardian的Mat Wall分享了他們選擇MongoDB的原因：
- 數據庫schema 經常需要升級，升級意味着編輯們無法使用系統
- 基於Oracle的老系統300多張表，10，000多行Hibernate XML配置，異常複雜
- 關係型數據庫難以進行性能擴展
（上述內容摘自於
https://www.infoq.com/presentations/Why-I-Chose-MongoDB-for-Guardian）
這個分享成了當時一個很大的成功案例，爲MongoDB成爲Gartner CMS魔力象限中排名第一第二的Adobe Experience Manager 及 Sitecore兩個CMS系統不約而同選用的數據庫奠定了基礎。
-
2015年，衛報因爲自己數據中心的備份系統出問題而決定把數據中心遷移到AWS雲上。注意，此時爲止並沒有出現什麼運維事故。
-
搬到AWS上以後，發生了兩次運維事故，一次是因爲NTP始終服務被中斷導致的，一次是因爲他們在應用程序啓動時創建索引導致的。
-
2017年， 以Philip McMahon爲首的IT團隊開始了爲期10個月的遷移工作，從基於AWS的MongoDB遷移到AWS的PostgreSQL。Philip列出了以下理由：
- 這兩年在AWS雲裏出了兩次運維故障
- MongoDB OpsManager未能兌現“無障礙數據管理”
- 官方未能及時幫助他解決問題，最終是自己解決了
- Philip團隊在花了10個月時間的努力之後，終於把他們系統的數據庫遷移到了AWS的PostgreSQL，隨後就發表了bye-bye MongoDB的博客。
好了，至此我們就瞭解大概情況了。
中文社區有話要說
- Philip的第一個要遷移的原因：NTP導致的運維故障。 MongoDB是分佈式集羣，需要時間統一，你自己在VPC裏面不小心把 NTP時鐘服務中斷了導致集羣不能正常工作，這是誰的鍋呢？
- Philip的第二個要遷移的原因： 應用程序啓動時構建索引導致服務不可用。關於這一點，如果是一個讀的懂英文文檔的開發者都會知道，無論是使用Spring或者Node.js，都會提到並不建議在程序裏來創建索引。 構建索引消耗很多資源並且執行時間不可控，按照MongoDB最佳實踐是要在複製集內進行滾動構建。實際上使用 OpsManager就可以很容易實現滾動建索引。這一點他自己也意識到了“可能不是一個好主意”。恩，怪我咯？
- Philip的第三個要遷移的原因：數據庫管理很重要而且很難。所以我們要換一個數據庫，從MongoDB換到PostgreSQL。因爲PostgreSQL不是數據庫， 就不用管理了？
- 沒有比較就沒有傷害，和上面提到的Mat Wall的Oracle遷移到Mongo的言之鑿鑿的原因比較，Philip的3大原因沒有一條是真正和MongoDB數據庫本身技術相關的。MongoDB丟了數據嗎？MongoDB自己崩潰了嗎？ 作爲衛報這個知名媒體，可以有一點邏輯嗎？
- 在衛報遷移到AWS之前，MongoDB運行都是正常的。所有的問題反而是在AWS裏發生的，特別是關於VPC。這說明了衛報IT團隊在雲管理能力上有所欠缺。按照他們的理論，亞馬遜多半也沒有實現“雲讓你不用再管理你自己的基礎架構”的口號吧？是不是也該從AWS遷移走呢？
寫到這裏，相信讀者已經能夠有所甄別。Philip團隊真正的痛點是他們無足夠的能力，也無意在這方面去增強自己的能力來維運自己的MongoDB集羣。這個出發點本身並無詬病，這是SaaS/PaaS 平臺存在的意義。MongoDB自己就提供基於AWS的託管服務，支持線下到雲中的無縫遷移。Philip確實提到了有一個超出他決策範圍的非技術原因（來自編輯部）讓他無法選擇該服務。換句話說，如果沒有編輯部的外在影響，Philip的完美解決方案就是：
衛報自管理的 AWS MongoDB -> 無縫遷移工具 -> 數據庫託管服務
這個方案可以完美解決：
- 1NTP 或類似的問題
- 數據庫管理（託管服務的基本價值）
- 應用程序構建索引（oops 不行, 這種自己挖坑自己踩的，哪個雲平臺恐怕都解決不了）
這種遷移由於不涉及到代碼改動，所需工作會大大減少。我們不知道Philip開始遷移方案的時候有沒有預料到會花費整個團隊10個月的時間，而且可能是Sleepless的10個月。但如果是在無縫遷移工具的幫助下，那麼這個切換可以在數天內完成。
所以，如果我們更客觀的來看，衛報作者發的那篇文章的題目其實更應該叫做：
別了，自運維數據庫，擁抱雲託管數據庫。
MongoDB中文社區參與撰稿成員：
徐雷 中文社區聯席主席 MongoDB實戰指南翻譯者
劉誠傑 中文社區上海分會長 平安集團高級DBA
李丹 中文社區北京分會長 邏輯思維首席DBA
周李洋 中文社區聯席主席, MongoDB Master, Teambition 運維總監
唐建法 中文社區主席
關於MongoDB中文社區
MongoDB 中文社區(mongoing.com) 成立於2014年，是大中華區獲得官方認可的中文社區。社區由來自官方的工程師，阿里騰訊等大型互聯網公司及業界MongoDB專家和MongoDB書籍作者等組成，。經過社區志願者們的不斷努力，目前已經有超過2萬的線上及線下成員。中文社區由博客、線下活動、技術問答、微信/qq羣、官方文檔翻譯等版塊組成，迄今爲止已經舉辦了數十場線下活動和線上直播，發表了數百篇技術文章及文檔，在社區裏支持了數以萬計的MongoDB用戶。