MongoDB,真的是正確的選擇嗎?

我讀到了一篇關於紅帽公司的 Satellite 不再支持 MongoDB 的帖子,我也知道很多人認爲此舉源自許可條款方面的修改。這不禁讓我想起過去幾年來,一直不斷有關於 MongoDB 如何可怕、以及用戶不應該將其作爲選項的聲音與文章。然而,就在這重重阻力之下,MongoDB 仍然發展成一款更爲成熟的產品。那麼,到底發生了什麼?一切反對的聲音,真的單純來自 MongoDB 早期實施 / 營銷過程中犯下的錯誤嗎?或者說,人們一直沒能真正客觀準確地評判 MongoDB 是否適合自己?

讀到這裏,很多朋友可能認爲我是打算幫 MongoDB 辯護一番。關於這個問題,請大家參考本文末尾的免責聲明,我會在那裏明確表達自己的立場。

趨勢聚焦

首先需要說明的是,多年以來我一直在使用各類軟件;但即使如此,我也僅僅經歷了衝擊整個行業的諸多趨勢當中的一小部分。我目睹了 4GL、AOP、敏捷、SOA、Web 2.0、AJAX 以及區塊鏈等等事物的崛起……繼續列舉下去,這份清單幾乎可以無窮無盡。每一年都會出現改變整個軟件工程領域的新趨勢。其中一些很快陷入困境,而另一些則從根本上顛覆了軟件的開發方式。

當任何一種創新成果帶着巨大的吸引力出現在我們面前,人們很快開始積極涌入,而這又會引導更多本打算旁觀一下的受衆參與其中,最終在整個行業掀起一般熱潮。Gartner 公司專門就此發佈相關報告,其定義的炒作週期(雖然存在爭議)確實在很大程度上正確評估了有價值技術從誕生到發展再到趨於成熟 / 消亡的整個過程。

但每隔一段時間,又會出現一種不同於其它的創新(有時候也表現爲舊有技術再度復甦)。這種創新由其中的某一特定實現所驅動。以 NoSQL 浪潮爲例,其就受到了 MongoDB 出現以及快速崛起的重大推動。MongoDB 並不是這股潮流的直接推手;它只是一種恰逢其時的解決方案,正好遇上互聯網巨頭們遭遇的數據挑戰只有非關係數據庫才能很好 地解決。正因爲如此,谷歌公司的 Bigtable 與 Facebook 的 Cassandra 等項目相繼出現。然而,MongoDB 仍然是大多數開發人員最易於獲取、同時也最爲熟悉的 NoSQL 數據庫選項。

旁白:說到這裏,大家可能會想,我這不是把列數據庫、鍵 / 值存儲或者多種其它數據存儲類型都給混雜到 NoSQL 這個陣營裏頭了嗎?哈哈,這裏我得說一句,您說得沒錯!但那個時候,這種混淆就是現實,而且相當嚴重。每個人都高舉着 NoSQL 的旗幟,每個人都堅稱他們離不開 NoSQL——但實際上,他們並沒有真正理解其中涵蓋的不同技術元素。對於很多人來說,MongoDB 實際上就是 NoSQL。

開發人員對此做出了積極的迴應。無模式數據庫能夠近乎無限地擴展,因此可以應對任何挑戰的基本思路確實非常誘人。因此在 2014 年左右,我們發現幾乎到處都有人在使用 MongoDB——正如短短一年之前,還到處有人在使用 MySQL、PostgreSQL 或者 SQL Server 這類關係數據庫一樣。在被問到爲什麼要使用 MongoDB 時,他們的迴應各不相同:從常見的“實現網絡規模擴展”到“我的數據結構非常鬆散,特別適合無模式數據庫”可謂不一而足。

最重要的是需要明確一點,MongoDB 以及文檔數據庫這一類解決方案,能夠幫助人們搞定很多傳統關係數據庫無法應對的難題:

  • 嚴格的模式:在傳統數據庫當中,如果我們掌握的是動態數據,則必須創建一堆隨機的“雜項”數據列以將數據作爲數據塊進行推送;或者使用 EAV 設置等等……而這一切,都有着嚴重的缺陷。
  • 難於擴展:在傳統數據庫當中,如果我們的數據規模太過龐大則將無法被直接存放在單一服務器當中;相比之下,MongoDB 的內置功能允許大家跨越多臺計算機實現數據擴展。
  • 架構修改難題:可遷移!在使用關係數據庫時,變更數據庫結構無疑是一項巨大的挑戰(特別是在您的數據量不斷增大這一背景之下)。MongoDB 承諾顯著簡化這一過程,使得結構調整變得更爲輕鬆順手,用戶能夠持續更新架構並快速完成遷移。
  • 寫入性能:MongoDB 的性能相當不錯,特別是在配合正確的配置方式之後。MongoDB 開箱即用的寫入配置雖然成爲不少人抨擊它的理由,但也確實帶來了一些令人印象深刻的性能數字。

買者自負

MongoDB 能夠帶來的潛在優勢無疑是巨大的,面對特定問題類型的用戶確實可以從中獲益良多。如果不配合其它背景信息或者不具備使用經驗,看了上文的朋友一定認爲 MongoDB 真正改變了數據庫系統領域的遊戲規則,甚至堪稱整個行業的大救星。情況當然沒那麼絕對——除了上述優勢之外,MongoDB 也存在不少問題,下面我會一一列出。

公平地講,10gen/MongoDB 公司並不是沒有考慮到這些問題,他們只是做出了自己的權衡。

  • 事務丟失:事務可以說是衆多關係數據庫(注意,不是全部,但確實是大多數)的核心特徵。事務機制意味着用戶能夠以原子方式執行多項操作,並始終確保數據內容保持一致。當然,使用 NoSQL 數據庫,您也可以在單一文檔當中包含事務,或者使用兩段提交等策略獲得類似事務的語義。但關鍵在於,這一切必須得由用戶親自動手完成……而且要保證一切正確無誤,可能是一項頗具挑戰且需要投入大量精力的工作。事實上,除非數據庫中的數據已經進入無效狀態,否則我們通常會意識不到究竟出現了多少數據丟失問題——究其原因,是因爲我們無法保證操作的原子性。 注意:很多朋友可能要提醒我,MongoDB 4.0 已經於去年引入了事務機制,但其中仍然存在不少侷限性。正如不少報道已經指出,用戶需要首先評估其能否滿足自己的需求。
  • 關係完整性(外鍵)丟失:如果您的數據之間存在關係,那麼這種關係就是一種客觀現實。幾乎所有數據中都包含某種關係,如果數據庫沒有強制體現這些關係,就得由應用程序負責構建。具體來講,由數據庫強制執行這些關係將幫助應用程序減輕大量負擔,從而降低軟件工程師們的日常工作量。
  • 缺乏執行數據結構的能力:強模式有時候代表着一種短板,但其同時也可能成爲確保數據擁有良好結構的有力機制。只要加以合理運用,其就能夠提供一種強大的機制,用以確保您的數據在結構上與您的期望完全契合。相比之下,MongoDB 這類文檔數據庫能夠在模式層面帶來令人難以置信的靈活性,但這種靈活性同時會將責任轉嫁到維護者身上,強制要求其保持數據清潔。如果沒有給予應有的關注,那麼我們最終不得不在應用程序當中添加大量代碼,從而消化那些在結構上與預期不符的數據。相信很多朋友都聽過這樣一句話:你的應用總有一天需要重寫,但數據卻將永遠存在。 注意:MongoDB 支持模式驗證,這項功能非常有用,但卻仍無法帶來可與關係數據庫相媲美的保障。首先,添加或修改架構驗證不會影響集合中的任何現有數據,因此我們需要自行確保數據更新以匹配新的架構。換言之,到底是否滿足需求還是得由用戶自己決定。
  • 缺少自定義查詢語言 / 工具生態系統:SQL 在剛剛出現時絕對掀起了一場革命,而且時至今日仍然代表着一種客觀標準。SQL 是一種非常強大的語言,但同時也給用戶帶來了使用挑戰。我們必須使用由 JSON 片段組成的自定義查詢語言查詢數據庫;即使對於經驗豐富的 SQL 專業人士而言,這也絕對不是一項輕鬆的工作。另外,SQL 數據庫擁有一整套互操作工具,從 IDE 到報告工具皆在其中。而一旦將數據遷移至不支持 SQL 數據庫,即意味着其中大多數工具將無法繼續使用。更可怕的是,即使想找到新的辦法將數據放入能夠繼續使用這些工具的其它 SQL 數據庫,其難度也遠遠超過大多數人的想象。

很明顯,不少決定使用 MongoDB 項目的開發人員並沒有深入理解他們做出的權衡究竟意味着什麼。事實上,很多開發者常常將 MongoDB 視爲應用程序的主數據存儲區,而這樣的決定通常意味着極爲昂貴的維護成本。

還有哪些不同的解決思路?

當然,並不是每位開發者都會盲目跳進這個坑,然後摔個暈頭轉向。但這樣的情況也着實不少,相信未來幾年會有不少項目在意識到問題後將 MongoDB 剔除出去。雖然有馬後炮的嫌疑,但如果這些組織能夠在做出技術選擇之前先拿點時間按部就班進行一番思考,那麼完全有能力避免這樣的折騰。

那麼,我們該如何確定哪些技術方案對自己的用例具備實際意義?目前已經出現不少嘗試性項目,希望就技術評估工作構建一套系統性框架。但我認爲,事情本不需要弄得這麼複雜。

只需要提出兩個主要問題,就足以合理評估衆多技術方案;但其中的挑戰在於找到能夠負責任地回答這些問題的人,他們願意花時間回答這些問題,同時確保答案當中不存在任何偏見。

如果沒有遇到某些特定問題,就不需要引入新的工具。就這樣。

問題一:我打算解決什麼問題?

如果我們沒有遇到某些特定問題,就不需要引入新的工具。說完。不要拿着解決方案反回來尋找問題,這是一種爲了使用工具而使用工具的行爲。換言之,如果不存在能夠證明新技術優於現有技術的具體需求,那麼就不要費力搞些沒必要的決策。很多朋友可能是因爲看到其他人在用某些新方案,才決定就其必要性進行一番討論。在這種情況下,我們不妨從最簡單的層面出發:他們到底面對着怎樣的問題,您又是否面對同樣的問題?觀察其他人的行爲傾向非常簡單,但合理評判其行爲在我們自己場景中的適用性卻相當困難。

問題二:我放棄了什麼?

這個問題明顯更難回答,因爲我們必須深入剖析並確保對舊有 / 新的技術都擁有很好的理解。有時候,在利用新技術構建某些實際方案之前,我們不太可能真正理解其內涵。或者,我們必須找到那些曾在新技術身上投入過大量時間的實踐者並聽取他們的意見。

如果這兩種方式都不可行,那麼您真的需要考慮如何通過最小投資確定該工具是否具有價值。另外,如果進行了前期投資,又是否會增加撤銷計劃的難度?

人類總會把事情弄糟

我們必須記住,在嘗試以客觀中立的方式回答這些問題時,總會有人性因素跑出來作祟。爲了有效評估技術,我們必須克服一系列認知偏見,下面僅舉幾例:

  • 從衆心理 – 每個人都聽過這種說法,但卻仍然很難擺脫出來。總之,請確保在選擇技術時,完全是因爲它能夠解決您的實際需求,而非某些看似很牛的傢伙也在做同樣的事。
  • 厚今薄古 – 不少軟件開發人員總是傾向於低估長久以來使用的原有技術,同時過高估計新技術帶來的好處。這不是軟件工程師所特有的問題,每個人骨子裏都有點這樣的毛病。
  • 存在偏見 – 我們都傾向於關注已經存在的情況,並忽略尚不明確的情況。而這一點與“厚今薄古”心態交織起來,有可能造成嚴重的破壞。因爲這意味着我們不僅在本質上就更認可新技術,同時也在刻意忽略新技術中存在的弊端。

客觀地看待事物是一種挑戰,而瞭解並努力克服可能影響判斷的偏見,將幫助大家做出更爲合理的決策。

總結陳詞

當某一創新成果出現(或者復甦)時,我們需要非常謹慎地回答以下兩個問題:

  • 這款工具是否能爲我們解決實際問題?
  • 我們是否真正理解該工具在開發中所做出的權衡?

如果您無法自信地回答這兩個問題,請退後一步重新進行評估。

那麼,讓我們回到主題:MongoDB 到底是不是理想的數據庫選項?是的,它當然是;但與大多數軟件工程問題一樣,這得分具體情況。對於那些爲這兩個問題找到了確切答案的團隊而言,其中很多人發現了實際價值,並正在不斷挖掘 MongoDB 的巨大潛力。而對於那些還沒有回答這些問題的朋友,希望大家能夠從中掌握一些應對炒作週期的寶貴教訓——也祝願各位不要在學習過程中付出過高的代價。

免責聲明

這裏我想澄清一點,我既不喜愛 MongoDB,也不討厭它。簡單來說,我一直沒遇上過真正適合利用 MongoDB 處理的現實問題。我知道,10gen/MongoDB 公司確實犯過一些錯誤,包括在項目推出早期採用不安全的默認設置,並在一切應該或者不應該的場合下(特別是各種黑客馬拉松活動)將 MongoDB 描述爲一切數據需求的終極解決方案。沒錯,這些都是不太好的決定,但我也認爲這些狀況都爲本文主旨提供有力的支持——所有問題,都可以通過技術評估快速發現。保持理智,拒絕盲目,同志們加油!

原文鏈接

Was MongoDB Ever the Right Choice?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章