項(xiàng)目啟動(dòng)，預(yù)估超過(guò)10億的文檔數(shù)據(jù)要存儲(chǔ)，那么我們選擇Elasticsearch or Mongodb？

[[380769]]

明確兩者定位

MongoDB和Elasticsearch都屬于NoSQL范疇的數(shù)據(jù)庫(kù),且都屬于文檔型數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)。

所以這兩者的眾多功能和特性高度重合, 但其實(shí)兩者定位還是有所不同。

MongoDB是文檔型數(shù)據(jù)庫(kù), 提供數(shù)據(jù)存儲(chǔ)和管理服務(wù)。

Elasticsearch作為一個(gè)搜索引擎,定位是提供數(shù)據(jù)檢索服務(wù),也就是說(shuō)重點(diǎn)是全文索引，即模糊匹配。

因此，Elasticsearch的設(shè)計(jì)會(huì)有所偏重，比如Mapping不可變,帶來(lái)的代價(jià)就是es不特別擅長(zhǎng)作為純文檔數(shù)據(jù)的管理者, es可以從其他數(shù)據(jù)源同步數(shù)據(jù)過(guò)來(lái)提供全文檢索和查詢,不特別擅長(zhǎng)自己對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)和管理。

MongoDB有多個(gè)存儲(chǔ)引擎可以選擇, 而且MongoDB不僅看重?cái)?shù)據(jù)的分析, 對(duì)數(shù)據(jù)的管理同樣看重, 總的來(lái)說(shuō)MongoDB更傾向于數(shù)據(jù)的存儲(chǔ)和管理, 可以作為數(shù)據(jù)源對(duì)外提供。

Elasticsearch則有很多插件可以使用,相對(duì)來(lái)講Elasticsearch更傾向于數(shù)據(jù)的查詢, 一般情況下elasticsearch僅作為數(shù)據(jù)檢索服務(wù)和數(shù)據(jù)分析平臺(tái), 不直接作為源數(shù)據(jù)管理者.

所以，如果系統(tǒng)中已有mongodb或其他數(shù)據(jù)庫(kù)作為主要數(shù)據(jù)存儲(chǔ)，而Elasticsearch主要負(fù)責(zé)從其中獲取部分?jǐn)?shù)據(jù)提供快速全文檢索即可，即mongdob+Elasticsearch的方案.

此文我更想闡述的是，當(dāng)項(xiàng)目考慮物理資源、運(yùn)維成本等方面限制時(shí)，不想同時(shí)引入兩套數(shù)據(jù)庫(kù)時(shí)，二者只能選擇一個(gè)時(shí)，我們選哪個(gè)呢？？

全文檢索的需求

首先，要仔細(xì)思考項(xiàng)目需求中，是否存在對(duì)全文檢索的需求，如果存在，檢索的條件是否復(fù)雜？是否很花式？檢索的性能要求是否非常高？

如果答案都是yes，那么基本上可以確認(rèn)就得選Elasticsearch了，一票否決mongodb。

Mongodb是可以滿足基本的模糊查詢功能的，我們?cè)趯?shí)際項(xiàng)目中，3個(gè)節(jié)點(diǎn)Mongodb集群內(nèi)存有4000萬(wàn)業(yè)務(wù)數(shù)據(jù)，在一個(gè)業(yè)務(wù)內(nèi)容上用regex模糊查詢一個(gè)關(guān)鍵詞，只模糊查前100條，基本可以1秒內(nèi)返回。

但是更高級(jí)一點(diǎn)的模糊查詢就很難支持了，并且涉及查詢count總量時(shí)就非常慢，經(jīng)常10秒以上才能返回結(jié)果。

所以評(píng)估項(xiàng)目是否對(duì)全文檢索有比較高的需求要重點(diǎn)考量。

字段是否經(jīng)常變換

如果業(yè)務(wù)重點(diǎn)在于數(shù)據(jù)的增刪改查，全文檢索的要求不高，那么Mongodb可能更適合。

比如，電商業(yè)務(wù)一個(gè)基本的功能模塊就是存儲(chǔ)各種品類的商品信息，各種商品的特性和參數(shù)各異，MongoDB靈活的文檔模型非常適合于這類業(yè)務(wù)。由于商品的品類繁多，存入集合中的每一種商品在字段上都有差異，并且未來(lái)還會(huì)添加新品類的商品。

這種數(shù)據(jù)字段預(yù)期未來(lái)會(huì)經(jīng)常變動(dòng)，顯然mongodb更好，ES字段變動(dòng)時(shí)處理起來(lái)比較麻煩，需要經(jīng)常變更mapping，代價(jià)很大，一般需要重新寫(xiě)入一個(gè)新的index，做reindexing來(lái)處理，在數(shù)據(jù)量達(dá)到一億以上時(shí)，需要大半天才能完成，并且對(duì)線上寫(xiě)入的業(yè)務(wù)是有一定影響的。

所以對(duì)于數(shù)據(jù)結(jié)構(gòu)經(jīng)常頻繁變化，一個(gè)集合中存儲(chǔ)多種字段不同的數(shù)據(jù)時(shí)，用monggodb會(huì)更好！

硬件資源方面

如果從資源占用方面角度看，MongoDB可以支持存儲(chǔ)文件類型的數(shù)據(jù), 作為數(shù)據(jù)庫(kù)也有數(shù)據(jù)壓縮能力, es則因?yàn)榇罅康乃饕嬖谛枰加么罅康拇疟P和內(nèi)存空間。

在mongodb不需要建太多索引的情況下，mongodb可能更節(jié)省一些資源，當(dāng)然影響最后占用內(nèi)存和磁盤空間的因素較多，這個(gè)也不完全絕對(duì)，所以需要根據(jù)實(shí)際情況去測(cè)一下。

運(yùn)維部署

在運(yùn)維部署方面，ES的一套工具ELK，現(xiàn)在叫Elastic Stash，自帶對(duì)集群的狀態(tài)監(jiān)控，安裝部署也較mongodb方便太多，對(duì)運(yùn)維人員來(lái)說(shuō)相比mongodb容易上手太多。

在彈性伸縮方面，ES相比mongodb也容易太多，真的容易太多，并且，ES水平擴(kuò)展更容易，能夠自動(dòng)均衡！

可以負(fù)責(zé)的說(shuō)mongodb對(duì)運(yùn)維部署人員的要求要比ES明顯要高很多。用ES集群，你會(huì)明顯感覺(jué)你對(duì)它的掌控力更強(qiáng)。

所以，在監(jiān)控運(yùn)維方面，ES明顯更具優(yōu)勢(shì)。

性能方面

寫(xiě)入性能與查詢性能對(duì)比方面，mongodb在除了全文索引之外的絕大部分場(chǎng)景是會(huì)比ES要高一些的，尤其是寫(xiě)入性能?。?！

在性能方面，我覺(jué)得如果追求極致的寫(xiě)入性能與寫(xiě)入實(shí)時(shí)性要求，那么應(yīng)該選擇mongdob，否則Elasticsearch也足夠用啦。

我們?cè)诙鄠€(gè)實(shí)際項(xiàng)目中，對(duì)ES集群的查詢性能與寫(xiě)入性能還都是比較滿意的。

總結(jié)

在日志應(yīng)用領(lǐng)域，兩者可以相互替代，但經(jīng)過(guò)上述對(duì)比，明顯選項(xiàng)ES更好。

如果你的業(yè)務(wù)場(chǎng)景就是需要一個(gè)文檔型的業(yè)務(wù)數(shù)據(jù)庫(kù)，比如我們目前負(fù)責(zé)建設(shè)的多個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)，主要是基本的增刪改查，那最好還是選mongodb。

如果你有要求復(fù)雜全文檢索又并發(fā)性能要求較高的業(yè)務(wù)場(chǎng)景，類似搜索服務(wù)，那最好的選擇還是elasticsearch。

但其實(shí)對(duì)大多數(shù)的中小公司來(lái)講，這兩者的數(shù)據(jù)管理能力并足夠滿足業(yè)務(wù)需求，都可以相互替代。

綜合考量下來(lái)，絕大部分場(chǎng)景用ES相對(duì)就可以比較好的滿足了，除非對(duì)寫(xiě)性能有極高的要求，除非字段未來(lái)會(huì)頻繁變更。

最后，大家還是要根據(jù)自己項(xiàng)目的真實(shí)需求，進(jìn)行綜合評(píng)估和測(cè)試。