MongoDB應用從設計到實現 | 深度解讀

本文由IT大咖說整理自MongoDB大中華區高級顧問 張耀星先生 在 MongoDB中文社區深圳用戶組大會 上的演講。你知道MongoDB嗎？它到底是怎樣的一個軟體，和傳統關係資料庫有什麼區別，在實際應用中又能做些什麼事。本文帶你走近MongoDB，了解它從設計到實現的全過程。 本文3216字，閱讀時間預計15分鐘。

張耀星，MongoDB大中華區高級顧問，加入IT行業10餘年，從事過電商，手游及各類網站的設計製作工作。曾擔任跨境電商網站http://dx.com架構師，Universal Orlando Resort前端總工程師等。現就職於MongoDB為國內各大企業提供MongoDB諮詢服務。

大家好，我是中文社區的張耀星，平時在社區的微信群里跟大家互動比較多。今天在線下跟大家做一些交流。今天我演講的內容是關於MongoDB的應用，如何從設計到實現的全過程，該做什麼事情，要避免怎樣的問題，做一個經驗上的介紹。

MongoDB的哲學

在座的朋友可能有些去參加過MongoDB的考試。目前在中國一共只有不到20位朋友通過了這個考試。在這個考試中有一個章節，叫做MongoDB的哲學。它需要我們去了解MongoDB背後設計的思想。

大家第一次看到MongoDB的時候肯定會有一些疑問，這是什麼東西？和普通的資料庫有什麼區別？到底能幹什麼？

我們可以去網上看看用過的人怎麼說。把大家的觀點都看過之後，才能對MongoDB有一個更深入的了解。了解之後我們會發現，其實MongoDB和關係資料庫最本質的一個區別是，關係資料庫是關係型的，而MongoDB是一個非關係型資料庫。

在過去的幾十年中，都是關係模型佔領統治地位。在大家的心中已經根深蒂固地把資料庫和關係模型畫上了等號。所以使用的時候很多人在思維的轉化方面非常困難，也直接導致了使用方式的不正確，以至於MongoDB在性能上的表現達不到期望的標準。

從實際上來說，關係模型只是一個理論，理論和現實還是有一定差距的。我們用理論只是為了更好的描述現實中的一些東西，讓大家更容易理解。關係資料庫和非關係資料庫這兩種理論同樣是以前在用關係模型來描述現實中的東西。在這麼多年後，我們要扭轉一下之前的這種固有思維。

MongoDB要做的就是把數據變成一個應用，直接能夠使用而不需要再進行額外處理的一個過程。而且它要非常快的把數據緩存在內存當中，它要能做各種各樣的事情。這個其實就是我們常說的反範式。但是到目前為止，反範式不再是我們唯一的選擇。在範式的基礎上，我們可以選擇反範式的模型來設計資料庫。這就是MongoDB背後的思想，跟關係資料庫最明顯的一個區別。

如何使用MongoDB解決實際問題

首先我們應該去了解這個問題有什麼特點，不同的特點會決定我們如何來選擇一個合適的資料庫。

如果我們決定用MongoDB來實現這個軟體，我們的過程和傳統過程不一樣的地方就在於詳細設計。在關係模型的應用當中，詳細設計包含了資料庫設計、數據結構設計。要把這個數據結構轉換成一個關係模型，就需要設計資料庫模型來做這個事情。主要區別就在於，用MongoDB來實現之後，我們要得到數據結構，並了解我們會怎樣使用這個數據結構，然後才進行數據模型的設計。也就是說我們的數據模型沒有一個固定的原則，而是根據我們怎樣去使用這個數據，來決定怎樣才是更好的數據模型。

關係模型是根據所需要的數據結構範式化得到一個關係模型，非關係模型同樣是根據應用所需要的數據結構，根據不同的原則來決定這個數據最終變成什麼樣子。

使用非關係資料庫的關鍵點

第一個就是要轉變思路。我們的原則是怎樣方便應用更高效的去使用讀取或者去寫入。思路首先要轉變過來，否則後面做的所有的工作都得推翻重來。不要按照關係資料庫的思路來設計非關係數據的模型。

第二個就是要積累經驗。只有在積累一定的經驗之後，看到一些數據時就會知道，如果這個數據用非關係模型來設計應該是怎樣的。

第三個就是最重要的背後思想。在MongoDB的這個應用中，我們把數據看作是應用的一部分而不是獨立的一個部分。以前進行軟體迭代的時候，做完分析概要設計編碼測試之後，要進行下一輪的迭代，要再具體做需求分析等等。以前我們的這個過程只是針對應用來做，但對MongoDB來說，這個過程不光要針對應用來做，還要針對數據來做。當需求改變之後，數據結構也需要相應的去改變。把數據和應用緊密地聯繫在一起，這樣才能保證應用能夠以最高效的方式讀取或者去寫入數據。

實際應用

第一次接觸MongoDB的時候，我當時想找個有一些關係資料庫不能滿足的特點的應用，而且這個系統要對現有的系統影響不大，它又要能用上MongoDB的一些特性。最後我在12年的時候做了跟大家一樣的選擇，我用它來存日誌。後來我把這個做成了一個開源的項目。

對MongoDB的需求

第一 速度要快

記日誌肯定不能影響現有系統的運行。日誌的量非常大，但通常不必保存很久，也會要進行一些查詢，記日誌也就是這些基本的要求。如果沒有這個系統，寫到文件系統上，就要用記事本或者文件編輯工具去打開，然後搜索會很麻煩，當時我們考慮到這一點，所以做成了這樣一個系統，大家隨時都可以去查日誌。

第二 寫入

按照日誌的範式化模型來做，系統會要求我們先寫日誌，再寫一堆異常，導致效率非常低。用MongoDB來做的話，利用非關係資料庫的一個目的，把它全部寫在一起，節省更多的時間，能夠讓我們更高效的去寫入。如果把設計成模型的話，那這些查詢也都很容易地滿足到。關係模型可以根據每一個innerException來查詢，但是它要寫入更多次會更慢，處理邏輯會更複雜，讓應用的邏輯更複雜，這就是它的一個優勢和一個劣勢。

第三 方案

我們一直強調的就是沒有最好的方案，只有最合理的方案，這是設計當中很重要的一個原則。

第四 模式演化

現在加入了一個新的需求，把一些自定義的數據加到日誌里。對MongoDB來說反而是一件更容易的事情，我們把自定義的結構寫在了原來的文檔中，這樣的話能夠使擴展起來非常容易。模式的演化會造成數據結構有非常大的變化，因為數據結構是根據讀寫模式來決定的，所以如果當需求發生了很大變化的時候，可能讀寫的模式都已經改變了，這個時候就要重新做一個設計，數據要遷移，這都是有可能發生的。這也是我們前面所提到的一個很重要的思路——數據是應用的一部分，它會隨著應用一起迭代。這也是MongoDB設計的過程中一個很重要的原則。

這就是今天分享的全部的內容，謝謝大家！