如何分析MongoDB的好壞

本篇文章給大家分享的是有關(guān)如何分析MongoDB的好壞，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

對(duì)剛剛接觸 MongoDB 的人來(lái)說(shuō), MongoDB就是一個(gè)NoSQL類(lèi)型的文檔數(shù)據(jù)庫(kù).  文檔中包含的鍵值對(duì)，構(gòu)成了MongoDB的數(shù)據(jù)基本單位。

不過(guò)可以肯定的是MongoDB的確是當(dāng)前***的NoSQL數(shù)據(jù)庫(kù). 它已被廣泛接受并且適合各種各樣的場(chǎng)合 (盡管不是所有項(xiàng)目都使用它)。

我將根據(jù)過(guò)去幾年來(lái)我使用MongoDB所得出的經(jīng)驗(yàn)，簡(jiǎn)短的介紹下MongoDB的好處、壞處和它丑陋的地方。

好處

自 MongoDB 流行以來(lái)，它的好處應(yīng)該多于壞處和丑陋的地方. 如若不是，開(kāi)發(fā)者們也不會(huì)接受它. 下面是一些MongoDB好的方面。

靈活的數(shù)據(jù)模型

當(dāng)今動(dòng)態(tài)的用戶案例以及不斷變化的應(yīng)用，擁有一個(gè)靈活的數(shù)據(jù)模型是一種福音。靈活的數(shù)據(jù)模型意味著沒(méi)有預(yù)先定義的模式，文檔可以基于任何鍵值持有任何值的集合。

富有表現(xiàn)力的查詢語(yǔ)法

MongoDB的查詢語(yǔ)句是非常具有表現(xiàn)力且易于理解的。許多人會(huì)說(shuō)這不像SQL語(yǔ)句。但是當(dāng)我們能向前發(fā)展，且查詢語(yǔ)句更簡(jiǎn)單并具表現(xiàn)力的時(shí)候，為什么我們還要堅(jiān)持類(lèi)似SQL的查詢語(yǔ)句呢?

容易學(xué)習(xí)

MongoDB很容易學(xué)習(xí)，并且能快速上手。基本的安裝、執(zhí)行不會(huì)超過(guò)幾個(gè)小時(shí)。 更強(qiáng)大的設(shè)置可能是復(fù)雜的，但是我會(huì)晚點(diǎn)再談?wù)撨@方面。

根據(jù)上面這些特點(diǎn)想必你應(yīng)該很容易把它揉進(jìn)你的項(xiàng)目中。

性能

查詢性能是MongoDB的長(zhǎng)處. 它把大多數(shù)可操作的數(shù)據(jù)存儲(chǔ)在內(nèi)存中. 所有的數(shù)據(jù)是固化在硬盤(pán)中的, 但在查詢過(guò)程中,  它不會(huì)從硬盤(pán)中過(guò)去數(shù)據(jù)(那樣太慢). 它直接從本地內(nèi)存中獲取數(shù)據(jù)，因此速度就會(huì)更快.  所以，為數(shù)據(jù)設(shè)置正確的索引并且提供足夠的內(nèi)存便能發(fā)揮MongoDB的性能優(yōu)勢(shì)。

可伸縮性和可靠性

MongoDB 具有很高的可伸縮性, 在碎片數(shù)據(jù)使用方面. 橫向可伸縮性在大多數(shù)NoSQL數(shù)據(jù)庫(kù)中是一大亮點(diǎn). MongoDB 也不例外。

它也是高度可靠的，因?yàn)樗母北炯瘮?shù)據(jù)被異步的復(fù)制到更多的節(jié)點(diǎn)。

異步驅(qū)動(dòng)

對(duì)于所有的現(xiàn)代應(yīng)用程序而言使用異步的非阻塞IO是提速的關(guān)鍵。MongoDB異步驅(qū)動(dòng)程序支持***的語(yǔ)言。

文檔

擁有一個(gè)良好的文檔可以讓開(kāi)發(fā)人員的生活變得容易很多,特別是當(dāng)開(kāi)發(fā)人員面對(duì)的是新技術(shù)。MongoDB有出色的文檔。

文本搜索

如果你正在建設(shè)一個(gè)網(wǎng)站， 需要搜索您的所有數(shù)據(jù)，文本搜索是必不可少的。例如,一個(gè)使用具有文本搜索的數(shù)據(jù)庫(kù)的電子商務(wù)網(wǎng)站對(duì)用戶來(lái)說(shuō)更有利。

服務(wù)端腳本

如果你有一些操作需要在服務(wù)端而不是應(yīng)用端執(zhí)行，在MongoDB中，你可以那么做。把mongo語(yǔ)句放在一個(gè).js文件中，并用mongo命令執(zhí)行js文件。

文檔 = 對(duì)象

文檔數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)是對(duì)象可以在MongoDB中存儲(chǔ)為一個(gè)單獨(dú)的文檔。 這邊不需要對(duì)象關(guān)系映射(ORM)。

缺點(diǎn)

我們已經(jīng)看到了有關(guān)MongoDB的各種優(yōu)點(diǎn)，接下來(lái)要說(shuō)下缺點(diǎn)了。我敢肯定批評(píng)家對(duì)這部分更感興趣。如果使用不當(dāng)，MongoDB可能會(huì)做壞事。

現(xiàn)今，實(shí)際上很少有應(yīng)用程序需要事務(wù)，但是有一些程序還是需要的。不幸的是，  MongoDB不支持事務(wù)。因此當(dāng)一個(gè)請(qǐng)求中需要修改多個(gè)文檔或多個(gè)集合時(shí)就不要使用MongoDB。由于沒(méi)有ACID保證它可能會(huì)導(dǎo)致數(shù)據(jù)損壞?；貪L操作必須由你的應(yīng)用程序來(lái)處理。

沒(méi)有觸發(fā)器

在關(guān)系式數(shù)據(jù)庫(kù)中，有觸發(fā)器，在很多情況下它是十分有用的。但是在MongoDB中就沒(méi)這個(gè)了。

存儲(chǔ)

相比其他流行的數(shù)據(jù)庫(kù)MongoDB需要更多的存儲(chǔ)。 在 MongoDB  3.0中引入的WiredTiger解決了這個(gè)問(wèn)題，但是對(duì)于大多數(shù)應(yīng)用程序來(lái)說(shuō)使用WiredTiger不甚理想。

磁盤(pán)清理

MongoDB不會(huì)自動(dòng)清理磁盤(pán)空間。因此如果文檔被修改了或刪除了，磁盤(pán)空間不會(huì)被釋放。你必須通過(guò)手動(dòng)或重啟來(lái)釋放。

丑陋的

有時(shí)，丑陋可能比壞更糟糕。使用一項(xiàng)技術(shù)之前了解它的不足是很重要的。它不會(huì)阻止你使用它，但它可以讓你的活的非常艱難。

層次結(jié)構(gòu)

如果你有一個(gè)是遞歸包含孩子數(shù)據(jù)對(duì)象的數(shù)據(jù)模型 (如， 一個(gè)對(duì)象擁有與它相同數(shù)據(jù)類(lèi)型的孩子對(duì)象并且層級(jí)很多)，  MongoDB的文檔結(jié)構(gòu)就會(huì)變得非常丑陋。對(duì)這些遞歸嵌入的文檔進(jìn)行索引、搜索和排序?qū)⒎浅＠щy。

Join(連接)

MongoDB中join兩個(gè)文檔是不容易的，雖然MongoDB 3.2支持左外連接 (lookup)，  但它尚未成熟。如果你的應(yīng)用程序需要在一個(gè)查詢中實(shí)現(xiàn)獲取多個(gè)集合中的數(shù)據(jù)，那可能無(wú)法實(shí)現(xiàn)。因此你必須使多個(gè)查詢，這可能會(huì)讓你的代碼看起來(lái)有點(diǎn)亂。

索引

雖然MongoDB標(biāo)榜速度是它的一大亮點(diǎn)，但它依賴(lài)于你建立了正確的索引。如果你建立的索引很糟糕或不正確順序的復(fù)合索引，那么  MongoDB可能是最慢的數(shù)據(jù)庫(kù)。

如果你有很多的過(guò)濾條件和排序字段，你可能會(huì)在一個(gè)集合上建立很多的索引，當(dāng)然這是不好的一個(gè)做法。

重復(fù)數(shù)據(jù)

你可能會(huì)有大量重復(fù)的數(shù)據(jù)，MongoDB不支持關(guān)系式。修改這些重復(fù)數(shù)據(jù)可能會(huì)比較困難，且由于缺少事務(wù)支持，我們還可能會(huì)損壞數(shù)據(jù)。

結(jié)論

綜述，只要你恰當(dāng)?shù)氖褂?，MongoDB是一個(gè)優(yōu)秀的數(shù)據(jù)庫(kù)，否則它會(huì)給你帶來(lái)麻煩。在不恰當(dāng)?shù)牡胤绞褂盟銓?huì)吃到苦頭。

認(rèn)真的分析以及咨詢專(zhuān)家。正確的使用你絕對(duì)會(huì)愛(ài)上它。

至于壞的和丑陋的部分,你可以一些使用設(shè)計(jì)模式來(lái)解決其中的一些問(wèn)題，在我的文章解釋了 MongoDB設(shè)計(jì)模式。

MongoDB的***實(shí)踐

下面列出了幾個(gè)MongoDB的***實(shí)踐:

硬件

• 確保你的數(shù)據(jù)集能放入內(nèi)存中

使用壓縮

• 每臺(tái)服務(wù)器運(yùn)行單個(gè)MongoDB

• 對(duì)于寫(xiě)入數(shù)據(jù)較多的應(yīng)用使用固態(tài)硬盤(pán)

數(shù)據(jù)模型

• 一條記錄的所有數(shù)據(jù)都存在一個(gè)文檔中

• 避免大尺寸的文檔

• 避免不必要的長(zhǎng)字段名

• 去掉不必要的索引

• 刪除其它索引前綴的索引

應(yīng)用程序

• 只修改變化的字段

• 避免否定式查詢

• 對(duì)于復(fù)雜的查詢運(yùn)行explain()(查看執(zhí)行計(jì)劃)

• 在可能的情況下使用覆蓋查詢.

• 在需要的時(shí)候使用批量插入.

安裝和配置

• 擁有至少一個(gè)從庫(kù)和一個(gè)仲裁

• 當(dāng)數(shù)據(jù)非常重要時(shí)應(yīng)設(shè)置參數(shù) write concern 為2

• 有每日的數(shù)據(jù)轉(zhuǎn)儲(chǔ)備份。

以上就是如何分析MongoDB的好壞，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。