基于MongoDB的非關(guān)系型數(shù)據(jù)庫(kù)的設(shè)計(jì)研究

施瑩超

摘要：為了解決傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)所存在的海量級(jí)數(shù)據(jù)處理效率低下等問(wèn)題，利用MongoDB技術(shù)，制定了MongoDB存儲(chǔ)架構(gòu)，并采用當(dāng)前的主流技術(shù)，提出一套行之有效的非關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)方案。首先對(duì)MongoDB技術(shù)進(jìn)行了詳細(xì)的介紹，然后基于數(shù)據(jù)庫(kù)連接、創(chuàng)建集合、基本操作實(shí)現(xiàn)這3個(gè)方面入手，設(shè)計(jì)了基于MongoDB非關(guān)系型數(shù)據(jù)庫(kù)，這一數(shù)據(jù)庫(kù)的實(shí)現(xiàn)為后期相關(guān)數(shù)據(jù)庫(kù)的設(shè)計(jì)工作提供了重要的參考依據(jù)。

關(guān)鍵詞：?關(guān)系型數(shù)據(jù)庫(kù)?非關(guān)系型數(shù)據(jù)庫(kù)??前端界面??總體架構(gòu)

中圖分類號(hào)：TP311.1

Research?on?the?Design?of?Non-Relational?Databases?Based?on?MongoDB

SHI?Yingchao

Xizang?Agricultural?and?Animal?Husbandry?University，?Linzhi?，?Xizang?Autonomous?Region，860000?China

Abstract：?In?order?to?solve?the?problems?of?low?efficiency?in?processing?massive?data?in?traditional?relational?databases，?this?article?uses?MongoDB?technology?to?develop?a?MongoDB?storage?architecture，?and?adopts?current?mainstream?technologies?to?propose?an?effective?design?scheme?of?non-relational?databases.?Firstly，?it?introduces?MongoDB?technology?in?detail，?and?then?designs?a?non-relational?database?based?on?MongoDB?from?three?aspects：?database?connection，?collection?creation?and?basic?operation?implementation.?The?implementation?of?this?database?provides?important?reference?for?the?design?of?related?databases?in?the?later?stage.

Key?Words：?Relational?database;?Non-relational?database;?Front-end?interface;?Overall?architecture

隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，數(shù)據(jù)庫(kù)技術(shù)為了更好地適應(yīng)環(huán)境變化，開始不斷創(chuàng)新。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)無(wú)法保障動(dòng)態(tài)網(wǎng)站的響應(yīng)速度，因此出現(xiàn)了新型非關(guān)系型數(shù)據(jù)庫(kù)，該數(shù)據(jù)庫(kù)的出現(xiàn)和應(yīng)用，可以有效地解決海量數(shù)據(jù)多重問(wèn)題。本文對(duì)比基于MongoDB的非關(guān)系型數(shù)據(jù)庫(kù)與SQLserver數(shù)據(jù)庫(kù)的性能，并采用實(shí)例分析的方式[1]，全面化分析和研究MongoDB數(shù)據(jù)庫(kù)關(guān)鍵技術(shù)，同時(shí)，利用node.計(jì)算機(jī)圖形圖像處理技術(shù)，封裝處理MongoDB數(shù)據(jù)庫(kù)，從而凸顯出該數(shù)據(jù)庫(kù)在提高動(dòng)態(tài)網(wǎng)站響應(yīng)速度的優(yōu)勢(shì)。所以，在MongoDB技術(shù)的背景下，設(shè)計(jì)科學(xué)的非關(guān)系型數(shù)據(jù)庫(kù)是技術(shù)人員需要思考的內(nèi)容。

1?MongoDB技術(shù)

• 數(shù)據(jù)庫(kù)介紹

數(shù)據(jù)庫(kù)是指長(zhǎng)時(shí)間存儲(chǔ)在計(jì)算機(jī)中的數(shù)據(jù)集合，其具有一定的共享性、組織性特點(diǎn)。數(shù)據(jù)庫(kù)在具體運(yùn)用中，按照數(shù)據(jù)結(jié)構(gòu)，對(duì)數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行有效的組織和管理。數(shù)據(jù)庫(kù)內(nèi)存中所運(yùn)行的程序一旦設(shè)計(jì)不合理，很容易導(dǎo)致數(shù)據(jù)出現(xiàn)丟失、泄露等風(fēng)險(xiǎn)[2]。所以，需要采用持久化存儲(chǔ)的方式，將運(yùn)行的數(shù)據(jù)直接存儲(chǔ)到硬盤中，從而保證數(shù)據(jù)存儲(chǔ)的安全性和可靠性，而數(shù)據(jù)庫(kù)在實(shí)現(xiàn)數(shù)據(jù)持久化存儲(chǔ)方面發(fā)揮出重要作用。數(shù)據(jù)庫(kù)主要包含以下兩種。

1. 關(guān)系型數(shù)據(jù)庫(kù)（SQL）。利用二維表關(guān)系模型，對(duì)所需數(shù)據(jù)進(jìn)行組織與存儲(chǔ)，典型的關(guān)系型數(shù)據(jù)庫(kù)如MySQL數(shù)據(jù)庫(kù)、MicrosoftSQLServer數(shù)據(jù)庫(kù)等。
2. 非關(guān)系型數(shù)據(jù)庫(kù)（NoSQL）。非關(guān)系型數(shù)據(jù)庫(kù)在具體應(yīng)用中，主要采用鍵值對(duì)的方式，對(duì)所需數(shù)據(jù)進(jìn)行組織和存儲(chǔ)，MongoDB、NoSQL是非關(guān)系型數(shù)據(jù)庫(kù)的常見(jiàn)代表。

以上兩種數(shù)據(jù)庫(kù)區(qū)別如下。

（1）存儲(chǔ)結(jié)構(gòu)。MicrosoftSQLServer數(shù)據(jù)庫(kù)在具體構(gòu)建時(shí)，需要在參照數(shù)據(jù)庫(kù)、表、記錄3個(gè)層次結(jié)構(gòu)的基礎(chǔ)上，采用表格的方式，對(duì)所需數(shù)據(jù)進(jìn)行存儲(chǔ)；MongoDB數(shù)據(jù)庫(kù)在具體構(gòu)建時(shí)，需要參照數(shù)據(jù)庫(kù)、集合、文檔對(duì)象結(jié)構(gòu)，在此基礎(chǔ)上采用鍵值對(duì)方式，存儲(chǔ)相關(guān)的數(shù)據(jù)。（2）成本。MongoDB具有易部署、成本低等特點(diǎn)，該數(shù)據(jù)庫(kù)屬于典型的開源軟件，無(wú)需像MicrosoftSQLServer數(shù)據(jù)庫(kù)那樣花費(fèi)較高成本。（3）查詢速度。MongoDB數(shù)據(jù)庫(kù)在具體應(yīng)用中，需要將所需數(shù)據(jù)直接存儲(chǔ)到緩存空間中，無(wú)需經(jīng)過(guò)SQL層解析處理，而MicrosoftSQLServer數(shù)據(jù)庫(kù)需要將數(shù)據(jù)直接存儲(chǔ)到硬盤中，因此，其查詢速度相對(duì)較低，遠(yuǎn)遠(yuǎn)低于MongoDB數(shù)據(jù)庫(kù)。

• MongoDB簡(jiǎn)介

MongoDB作為一種非關(guān)系型數(shù)據(jù)庫(kù)，主要是在參照分布式文件存儲(chǔ)原理提出的，MongoDB主要用于對(duì)Web網(wǎng)站的高效化開發(fā)，可以對(duì)所需要數(shù)據(jù)進(jìn)行實(shí)時(shí)插入、查詢與更新等[3]。MongoDB具有容易操作、維護(hù)方便、容易存儲(chǔ)等優(yōu)勢(shì)，并且還可以將存儲(chǔ)的數(shù)據(jù)直接復(fù)制。MongoDB作為一種非關(guān)系型數(shù)據(jù)庫(kù)，與關(guān)系型數(shù)據(jù)庫(kù)高度一致，并且其文檔（Document）屬于MongoDB基本數(shù)據(jù)單位[4]，而文檔數(shù)據(jù)的結(jié)構(gòu)包括多個(gè)關(guān)聯(lián)值、鍵等。集合與關(guān)系型數(shù)據(jù)庫(kù)中的表非常相似，所以采用分類存儲(chǔ)，在相應(yīng)集合中應(yīng)用文檔存儲(chǔ)。數(shù)據(jù)庫(kù)（DataBase）內(nèi)部含有大量的集合[5]。如下圖1所示為MongoDB數(shù)據(jù)庫(kù)層次結(jié)構(gòu)，可以看出數(shù)據(jù)庫(kù)的層次關(guān)系，單個(gè)數(shù)據(jù)庫(kù)管理軟件內(nèi)部中擁有多個(gè)集合，而集合主要是指數(shù)據(jù)庫(kù)中同種類型的數(shù)據(jù)，單個(gè)集合內(nèi)含有若干個(gè)文檔，文檔主要是指數(shù)據(jù)庫(kù)中一條條數(shù)據(jù)，字段主要是指每條數(shù)據(jù)所對(duì)應(yīng)的屬性名稱。在本次設(shè)計(jì)時(shí)，主要用到Mongoose對(duì)象模型工具，該工具主要是借助node.js所開發(fā)的。在異步環(huán)境下，可以直接執(zhí)行Mongoose。

2基于MongoDB非關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)實(shí)現(xiàn)

本文以“旅游類的電子導(dǎo)游項(xiàng)目”為實(shí)例項(xiàng)目，主要運(yùn)用管理員、消息、新聞等多個(gè)數(shù)據(jù)庫(kù)模型。為保證該項(xiàng)目用戶登錄功能實(shí)現(xiàn)效果，結(jié)合MongoDB基本操作，完成對(duì)如表1所示的用戶信息表的設(shè)計(jì)以及如圖2所示的用戶E-R圖繪制。另外，采用舉例說(shuō)明的方式，介紹MongoDB對(duì)象模型MongoDB數(shù)據(jù)庫(kù)實(shí)現(xiàn)相關(guān)操作。

2.1數(shù)據(jù)庫(kù)需求分析

在設(shè)計(jì)和實(shí)現(xiàn)一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的過(guò)程中，理解并滿足用戶需求是至關(guān)重要的。為了實(shí)現(xiàn)這一目標(biāo)，我們可以將需求分析過(guò)程劃分為兩個(gè)主要的操作步驟，這兩個(gè)步驟緊密相連，共同構(gòu)成了用戶與數(shù)據(jù)庫(kù)交互的核心。首先，用戶對(duì)本地?cái)?shù)據(jù)進(jìn)行瀏覽與管理，并通過(guò)Excel文件將文件批量導(dǎo)入，也可以直接在MongoDB數(shù)據(jù)庫(kù)中導(dǎo)入序列文件。這種直接導(dǎo)入的方式對(duì)于處理結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)，尤其是大數(shù)據(jù)量的情況，可以大大提高效率；其次，數(shù)據(jù)的處理。用戶對(duì)于數(shù)據(jù)進(jìn)行查找與瀏覽后，下載序列文件。通過(guò)細(xì)致地分析和設(shè)計(jì)數(shù)據(jù)庫(kù)的用戶操作流程，創(chuàng)建一個(gè)既滿足用戶需求，又具有高效、安全和易用特性的系統(tǒng)，為用戶的數(shù)據(jù)管理與分析提供支持。

2.2數(shù)據(jù)庫(kù)連接

在進(jìn)行數(shù)據(jù)庫(kù)連接時(shí)，首先，使用require語(yǔ)句，完成對(duì)所需模塊的加載，在此基礎(chǔ)上，創(chuàng)建所需要的數(shù)據(jù)庫(kù)；其次，運(yùn)用connect語(yǔ)句，確保各個(gè)數(shù)據(jù)庫(kù)之間建立良好的連接關(guān)系，connect語(yǔ)句中的url主要用于對(duì)服務(wù)器地址的指定。

2.3創(chuàng)建集合

當(dāng)數(shù)據(jù)庫(kù)連接完畢后，需要做好對(duì)集合規(guī)則和集合的設(shè)定和創(chuàng)建，集合創(chuàng)建主要包含以下兩個(gè)環(huán)節(jié)：（1）采用schema定義的方式，對(duì)集合規(guī)定進(jìn)行科學(xué)設(shè)定，并對(duì)整個(gè)集合中存在的字段類型進(jìn)行精確化描述，字段功能與表結(jié)構(gòu)性極其類似；（2）使用規(guī)則，創(chuàng)建集合。在這個(gè)過(guò)程中，僅僅可以創(chuàng)建schema中所定義好的屬性。在創(chuàng)建這些屬性時(shí)，主要運(yùn)用model方法。在model函數(shù)中，主要運(yùn)用集合名稱、集合規(guī)則兩個(gè)參數(shù)。運(yùn)用Model方法，對(duì)于構(gòu)造函數(shù)實(shí)施返回處理，借助構(gòu)造函數(shù)將內(nèi)容添加到集合內(nèi)，創(chuàng)建文檔。而文檔創(chuàng)建首先需要?jiǎng)?chuàng)建集合實(shí)例。其次，結(jié)合實(shí)例對(duì)象，調(diào)用save方法，確保數(shù)據(jù)安全、可靠地傳輸和存儲(chǔ)于數(shù)據(jù)庫(kù)中。此外，采用構(gòu)造create函數(shù)法，創(chuàng)建所需文檔。

2.4總體架構(gòu)設(shè)計(jì)

該系統(tǒng)整合了網(wǎng)絡(luò)、服務(wù)器、存儲(chǔ)等構(gòu)成虛擬化資源池，基于應(yīng)用系統(tǒng)的需要，靈活分配物理資源，提高資源利用率。同時(shí)，利用資源池動(dòng)態(tài)可伸縮的特點(diǎn)，部署在分布式應(yīng)用系統(tǒng)內(nèi)，數(shù)據(jù)層采用MongoDB，可以確保整體功能的負(fù)載均衡。接口層提供對(duì)外的數(shù)據(jù)訪問(wèn)接口、查詢接口，使層與層之間的交互更加方便。展示層則是用戶操作界面，確保界面簡(jiǎn)潔明了。

2.5基本操作的實(shí)現(xiàn)

采用服務(wù)器組建MongoDB分布式集群，服務(wù)器配置相同，操作系統(tǒng)為Ubuntu?20.04，磁盤容量?1TB、CPU為4核、內(nèi)存為8GB。MongoDB非關(guān)系型數(shù)據(jù)庫(kù)負(fù)責(zé)對(duì)基本操作的增加、刪除、修改等，利用圖2所示的node.js操作數(shù)據(jù)庫(kù)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的基本操作。另外，利用MongoDB技術(shù)，直接調(diào)用model模塊，實(shí)現(xiàn)數(shù)據(jù)操作。

另外，以“數(shù)據(jù)庫(kù)信息增加”為實(shí)例，演示運(yùn)用代碼添加數(shù)據(jù)過(guò)程，其他集合操作與數(shù)據(jù)添加操作極其類似。通常情況下，MongoDB數(shù)據(jù)庫(kù)主要調(diào)用insert（）方法、save（）方法，將數(shù)據(jù)插入到集合中。

3結(jié)語(yǔ)

綜上所述，本文所設(shè)計(jì)的MongoDB非關(guān)系型數(shù)據(jù)庫(kù)具有成本低、易操作、寫入便捷高效等特點(diǎn)。但是，該數(shù)據(jù)庫(kù)也存在以下弊端：（1）一旦旅游數(shù)據(jù)規(guī)模過(guò)大，會(huì)嚴(yán)重影響旅游數(shù)據(jù)查詢速度；（2）該數(shù)據(jù)庫(kù)在刪除記錄數(shù)據(jù)后，不能立即釋放存儲(chǔ)空間，導(dǎo)致空間占用率相對(duì)較高。為解決該數(shù)據(jù)庫(kù)存在的弊端，技術(shù)人員要合理優(yōu)化設(shè)計(jì)非關(guān)系型數(shù)據(jù)庫(kù)。

參考文獻(xiàn)

[1] 宋瑜輝，張俠，艾琳，等.基于Mongodb的智能電網(wǎng)大數(shù)據(jù)存儲(chǔ)設(shè)計(jì)[J].電子制作，2020（19）：64-67.

[2] 劉江濤，王亮亮，崔夏陽(yáng)，等.基于Node.js和MongoDB的鐵路選線案例系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].鐵路計(jì)算機(jī)應(yīng)用，2021，30（9）：42-46.

[3] 彭燦華，韋曉敏.基于MongoDB的艦橋SCADA系統(tǒng)實(shí)時(shí)數(shù)據(jù)庫(kù)構(gòu)建[J].艦船科學(xué)技術(shù)，2020，42（22）：163-165.

[4] 鄔學(xué)敏，高靜.基于MongoDB蒙古高原家畜基因組大數(shù)據(jù)管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].軟件，2022，43（12）：4-8，14.

[5] 李鑫.基于MongoDB數(shù)據(jù)庫(kù)的智能醫(yī)療分布式數(shù)據(jù)提取算法[J].微型電腦應(yīng)用，2022，38（1）：150-153，163.