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

[[380769]]

明確兩者定位

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

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

MongoDB是文檔型數據庫, 提供數據存儲和管理服務。

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

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

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

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

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

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

全文檢索的需求

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

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

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

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

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

字段是否經常變換

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

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

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

所以對于數據結構經常頻繁變化，一個集合中存儲多種字段不同的數據時，用monggodb會更好！

硬件資源方面

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

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

運維部署

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

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

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

所以，在監控運維方面，ES明顯更具優勢。

性能方面

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

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

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

總結

在日志應用領域，兩者可以相互替代，但經過上述對比，明顯選項ES更好。

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

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

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

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

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