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

[[380769]]

明確兩者定位

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

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

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

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

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

MongoDB有多個存儲引擎可以選擇, 而且MongoDB不僅看重數(shù)據(jù)的分析, 對數(shù)據(jù)的管理同樣看重, 總的來說MongoDB更傾向于數(shù)據(jù)的存儲和管理, 可以作為數(shù)據(jù)源對外提供。

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

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

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

全文檢索的需求

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

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

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

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

所以評估項目是否對全文檢索有比較高的需求要重點考量。

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

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

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

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

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

硬件資源方面

如果從資源占用方面角度看，MongoDB可以支持存儲文件類型的數(shù)據(jù), 作為數(shù)據(jù)庫也有數(shù)據(jù)壓縮能力, es則因為大量的索引存在需要占用大量的磁盤和內(nèi)存空間。

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

運維部署

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

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

可以負責的說mongodb對運維部署人員的要求要比ES明顯要高很多。用ES集群，你會明顯感覺你對它的掌控力更強。

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

性能方面

寫入性能與查詢性能對比方面，mongodb在除了全文索引之外的絕大部分場景是會比ES要高一些的，尤其是寫入性能！！！

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

我們在多個實際項目中，對ES集群的查詢性能與寫入性能還都是比較滿意的。

總結(jié)

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

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

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

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

綜合考量下來，絕大部分場景用ES相對就可以比較好的滿足了，除非對寫性能有極高的要求，除非字段未來會頻繁變更。

最后，大家還是要根據(jù)自己項目的真實需求，進行綜合評估和測試。