基于MongoDB的非關系型數據庫的設計與開發

任明飛 李學軍 崔蒙蒙 楊雙龍 孫小奇

摘要：隨著社會的發展和軟件技術的不斷進步，互聯網的數據量也呈現出爆炸型增長，此外數據的類型也變得更加多樣，傳統的關系型數據庫在對海量級的數據和多種類型的非結構化數據的處理上已經無法滿足開發人員的需求，NoSQL即非關系型數據庫憑借本身的優勢得到了迅速發展，其中MongoDB就是一個基于分布式，文件存儲的NoSQL數據庫。該項目通過基于MongoDB的非關系型數據庫的設計與開發，展示了非關系型數據庫和傳統的關系型數據庫的區別以及MongoDB的主要技術和使用方式。

關鍵詞：關系型數據庫;非關系型數據庫;MongoDB;分布式;文件存儲

中圖分類號：TP311

文獻標識碼：A

文章編號：1009-3044（2019）34-0001-02

1 MongoDB概述

MongoDB是一個基于分布式，文件存儲的非關系型數據庫，其特點是高性能、易部署、易使用，存儲數據方便。 不同于傳統關系型數據庫將數據以表的形式進行存儲，在MongoDB中數據是以文檔的形式進行存儲。文檔為BSON格式，其內部可以包含多種類型的文件、數據也可以內嵌別的文檔，模式十分白由。MongoDB也被稱作非關系型數據庫當中最像關系數據庫的，是一個介于關系數據庫和非關系數據庫之間的產品，其功能也是眾多非關系數據庫當中最豐富的。

MongoDB在存儲上的高拓展性使得其在面對海量級數據時比其他的數據庫更加具備優勢，其數據模型自由可變，存儲內容可按照需求隨意拓展，所以也適用于一些新應用，需求容易改變，數據模型無法確定，或者想快速迭代開發的產品。由于其高效的實時插入、更新與查詢性能，并具備網站實時數據存儲所需的復制及高度伸縮性。因此適用于常見的游戲場景、物流場景和物聯網場景等。

MongoDB作為一個非關系型數據庫也有一些局限性。MongoDB事務僅支持限于本機的單文檔事務，某些需要參與遠程事務，或者需要跨表，跨文檔原子性更新的高事務性應用不建議使用，另外MongoDB目前并不支持jom操作，需要復雜查詢的應用也不建議使用。

2 MongoDB文檔模式設計

MongoDB的文檔數據以BSON（JSON格式的一種拓展）格式存儲，可以存儲列表、key-value以及層次結構更加復雜的文檔。由于文檔存儲的靈活性和復雜性導致開發者在自由組織文檔結構的同時必然會面對應用層查詢困難的問題，因此基于Mon-goDB的非關系型數據庫在設計階段對文檔模式的設計尤為重要。

2.1 數據對象分析

本次開發的實例項目為旅游類內容管理網站項目，主要涉及的數據對象有景點數據對象，評論數據對象以及旅游攻略數據對象。

景點數據對象包含景點的圖文介紹，基本信息，位置信息，評論等。旅游攻略數據對象包含旅游攻略的發布者信息，內容信息，點贊評論或者轉發信息等。評論數據對象包含評論者信息，內容信息和點贊信息等。

結合實際應用場景分析，每個景點都有各自的基本信息以及游客們的評論信息，一個景點可以有多條評論，因此景點數據對象和評論數據對象之間是一對多的關系，其他同理可得數據對象關系如圖1所示。

2.2 關系模型和文檔模型對比

結合項目中主要的數據對象進行分析。從數據存儲的角度來講：

關系型數據庫在設計時必須滿足范式的要求，即關系型數據庫在定義表結構時要求每一個單元格的數據必須為不可再分割的原子項。使用關系型數據庫對旅游攻略數據對象進行存儲至少需要建立四張表。分別是文章表、評論表、點贊表、附件表，其中評論表、點贊表和附件表都持有文章表主鍵。形成主外鍵關系。顯然，數據更加復雜的景點數據對象以及數量龐大的評論數據對象都不是一張表就可以實現存儲的。并且這些數據模型各自之間還存在對應關系，也需要使用外鍵進行關聯。關系型數據庫光是在數據的存儲上就十分困難。

集合就是MongoDB文檔組，其文檔下的屬性可以是一個數據項、一個對象或者是一個數組。在使用MongoDB處理旅游攻略數據對象時，只需要一個旅游攻略數據對象的文檔集合就可以，文檔內部包括，文章內容屬性，文章發表時間屬性，文件狀態屬性，評論數組屬性，點贊數組屬性，文章附件數組屬性等其他信息。對于其他數據對象可以采取相同操作，文檔包含的都是以bson格式存儲的不同數據對象，由于bson數據便于解析，而且可以存儲多種類型的數據內容，使得MongoDB的存儲效率極高。

從應用層面來講：對需求進行提升，需要在文章列表中就展示文章內容、評論、附件和點贊信息。使用關系型數據庫就需要先從文章表中查詢出文章列表，再根據每一個文章的主鍵到其他表中獲取信息。如果列表要求顯示10條記錄，就需要執行11次的sql語句。而在這樣的需求下，mongoDB仍然是只需要執行一次查詢就可以獲取到全部數據。

2.3 文檔模式設計

MongoDB可以將模式設計劃分為內嵌模式（Embedded）和引用模式（References）。

內嵌模式適合數據對象之間的關系是一對一或一對多的。但其局限性在于MongoDB的文檔最大16M，面對大數組性能欠佳。在開發過程中，如果數據對象模型數量不多，關系結構不復雜。這種情況下選擇內嵌模式，可能一種對象只需要對應一個集合即可。由于內嵌模式的局限性。內嵌的數組過大時，例如一個明星的博客可能有幾十萬或者幾百萬的回復，這個時候如果把回復內容放到一個數組里，可能會超出16M的限制。這個時候就應該考慮使用引用方式。

引用模式適合多對多的關系，并且兩個對象都是主要對象。它的局限性在于查詢和寫入數據需要多次查詢、寫入，并且不支持跨表事務性。實現方式是不同的數據對象建立兩個集合，通過在集合中存儲其他對象的ID值實現關聯，這種方式和關系型數據庫十分相似，從查詢操上講，可能需要兩次以上才能把需要的數據取回來。另外現階段MongoDB并不支持跨表的事務性，所以對于強事務的應用場景應當慎用引用模式。

開發過程中完全依靠數據對象關系并不能完美解決選擇內嵌還是引用的問題，在這些時候就需要了解MongoDB的文檔模式設計的設計原則：MongoDB的設計是為應用程序服務，而并非為了存儲的優化。設計MongoDB的目的是為了實現應用程序的最佳性能。這些和關系型數據庫設計的原則有很大不同，為了達到性能的優化可能需要去做一些反范式的內容。因此MongoDB文檔設計模式的選擇除了考慮數據本身的特點之外還應當考慮應用層面對數據的操作。

3 MongoDB文檔模式實現

通過上文的分析，對項目中的數據對象進行文檔設計和實現，景點數據對象由于自身結構復雜，內容圖片以及附加信息過多，自身數據大小遠大于評論數據對象和旅游攻略數據對象，因此在景點數據對象和其他兩個數據對象之間的模式選擇引用模式，兩種數據之間的聯系則通過數據對象中的標識ID進行聯系。旅游攻略數據對象和評論數據對象之間選擇的是內嵌模式。由于采用引用模式的文檔模型在邏輯上和關系型數據庫十分相似，本文不再贅述，主要分析使用內嵌模式的旅游攻略數據對象的文檔模式實現。

對數據文檔模式的設計和實現時應當結合數據自身特點和其在應用層面的操作共同考慮。分析實際應用場景中旅游攻略展示的效果除了文章本身的內容，還應當包含點贊列表。點贊用戶的頭像、昵稱;以及評論列表，評論內容，評論用戶的頭像、呢稱等。結合上文，對旅游攻略數據對象和評論點贊數據對象之間采取的是內嵌模式。故而我們在文檔設計模式上首先構建了旅游攻略數據對象，在旅游攻略數據對象內部嵌套了多個包含評論內容，用戶以及圖片文字等信息的評論數據對象。

對以上文檔模型進行分析，該文檔設計模式中在景點對象內嵌了所有的點贊對象和評論對象，結合需求分析同時也需要在用戶對象中內嵌相應的評論和點贊對象，在MongoDB這種文檔型數據庫選擇這種設計是沒有必要的，反而造成了大量的數據冗余。另一個問題是在上述的設計里存儲用戶評論內容的圖片或者頭像等URL也占據了大量的空間，實際情況是，評論用戶數據的URL相對來說是全局穩定的，基本不會發生變化。

根據以上幾個問題，我們重新優化了文檔模型的設計，在對象內部嵌套comment_obj_id與praise_obj_idj兩個字段，用以存儲兩個對象的id。文檔數據內部的URL、username信息全部移除，因為對需求進行分析可以發現，業務抽象上來說URL、username這類信息實際上是非常穩定的，不會發生特別大的頻繁變化。并且這兩類信息實際上都應該是跟uid綁定的，每個uid含有指定的URL.username。是最簡單的keV-value模型。所以，這類信息可以通過一層緩存加速讀取查詢。

對比可以發現，優化后的結構要比優化前小了幾個數量級。雖然兩者都滿足MongoDB文檔模式設計的要求規范，但是后者在存儲空間占用以及查詢的性能上都遠優于前者。

4 總結

通過本次MongoDB數據庫的設計與開發，體現了MongoDB在數據存儲，檢索上的強大優勢，以及MongoDB在復雜數據以及海量數據存儲方面遠超傳統關系型數據庫的優異性能。MongoDB的文檔模型設計自由，但絕對不是等同于關系型數據庫的粗暴聚合，并且當前的MongoDB還存在一定的局限性，因此在設計階段，還需要結合實際需求和業務，進行合理的設計。

參考文獻：

[1] Peter Bakkum（美）.MongoDB實戰[M].徐雷，譯.華中科技大學出版社，2017.

[2] KristinaChodorow（美）等.MongoDB權威指南[M].程顯峰，譯.人民郵電出版社，2011.

[3]王光磊.MongoDB數據庫的應用研究和方案優化[J].中國科技信息，2011.

【通聯編輯：代影】

收稿日期：2019-08-28

作者簡介：任明飛（1996-），男，河南焦作人，河南科技大學本科在讀，研究方向為非關系型數據庫、數據庫分布式部署。