在我開始接觸 Elasticsearch 時，我也有疑問：那就是 Elasticsearch 和 MongoDB 兩個都是以 NoSQL 形式來管理資料庫的，那么它們之間到底是有什么區別呢？根據 DB-Engine 的報告，Elasticsearch 在搜索領域排名第一，遙遙領先于其它的資料庫：

而在資料庫管理方面，MongoDB 比 Elasticsearch 更為普及：

在今天的文章中，我們來講述一下它們之間的比較，

Elasticsearch 和 MongoDB 是用于管理 NoSQL 資料的兩個最流行的分布式資料存盤， 這兩種技術都具有高度可擴展性，并且以面向檔案的設計為核心， 然而，這兩種技術之間存在差異，了解這些差異以便為你的用例選擇正確的技術非常重要， 這篇博文將對比 Elasticsearch 與 MongoDB，并檢查這兩個資料庫在多個領域的差異，

關于 Elasticsearch

Elasticsearch 是一個開源、Java 撰寫的分布式 RESTful 搜索引擎， 它建立在 Apache Lucene 之上，并使用索引和分片概念通過 HTTP Web 界面和資料分發擴展了 Lucene 的功能， Elasticsearch 中的索引類似于資料庫， 它在命名空間下組織資料，具有定義的模式（schema），并且可以劃分為多個分片以進行水平擴展， Elasticsearch 中的每條記錄都存盤為 JSON 物件，稱為 “檔案”（document），

Elasticsearch 的一些核心功能包括：

• 分布式搜索
• 高可用性
• REST 介面
• 強大的查詢 DSL
• 多租戶
• 地理搜索
• 水平擴展

盡管擁有豐富的功能集串列，但 Elasticsearch 并不是適用于所有場景的完美資料存盤， 在為你的應用程式選擇正確的資料存盤時，需要考慮一些限制，

關于 MongoDB

MongoDB 是一個用 C++ 撰寫的面向檔案的資料庫，其設計目的是處理分布在多個地理位置的 TB 級資料， 在 MongoDB 中，可以創建多個資料庫，每個資料庫可以有多個集合（表）， 與 Elasticsearch 一樣，MongoDB 中的每條記錄都作為我們稱為 “檔案”（document）的 JSON 物件進入存盤， MongoDB 也是無模式（schemaless）資料庫，支持內置的安全功能，如身份驗證、訪問控制和加密，

MongoDB的一些核心特性是：

• 分布式檔案存盤
• 高可用性
• 無模式（schemaless）
• 強大的查詢和聚合
• 水平擴展
• 內置安全性
• 強大的索引功能
• 地理搜索
• GridFS 存盤任何大小的檔案

MongoDB 最大的限制是它無法快速提供全文搜索，并且缺乏一些搜索功能，比如對文本進行標記，

Elasticsearch 與 MongoDB：詳細比較

如上圖所示，這些技術在設計和功能上有很多相似之處， 也就是說，它們在性質上差異很大， Elasticsearch 主要是一個搜索服務器，而 MongoDB 主要是一個資料庫， 讓我們看看它們在其他領域的區別，

用例

你的用例對于決定哪種技術最合適至關重要， 當需要全文搜索時，Elasticsearch 永遠是更好的選擇， Elasticsearch 在日志分析方面也贏得了競爭，因為它不僅提供了廣泛的聚合查詢，還支持 Kibana、Logstash 和 Beats 等產品——所有這些都使日志分析變得更加容易，

另一方面，當資料是 NoSQL 格式并且你需要一個高度可擴展的資料庫，需要 CRUD 操作而不支持全文搜索時，MongoDB 是一個可靠的選擇， MongoDB 還借助基于文本的索引支持全文查詢，但它的搜索速度很慢，并且缺少搜索服務器附帶的分詞器和分析器，

組態檔

Elasticsearch 和 MongoDB 的安裝包在各種 Linux、windows 和 Mac 作業系統下都可用， 安裝軟體包后，可以開始使用默認配置，但這里有一些重要的配置引數，您應該在將它們投入生產之前對其進行修改， 以下所有配置選項均按 Linux 作業系統顯示，

如果你是 Linux 系統，你將在 /etc/elasticsearch/config 目錄下找到 Elasticsearch 的組態檔，如下所示：

config
|-- elasticsearch.keystore
|-- elasticsearch.yml
|-- jvm.options
|-- log4j2.properties
|-- role_mapping.yml
|-- roles.yml
|-- users
`-- users_roles

然而，所有 MongoDB 配置只能在 /etc/mongod.conf 下的單個檔案中完成，

備份恢復

默認情況下，Elasticsearch 和 MongoDB 都提供備份和恢復功能，

Elasticsearch 在插件的幫助下使用 _snapshot REST 端點執行增量備份，其備份目標可以從檔案系統到云存盤而有所不同， 快照的好處是它們本質上是增量的， 你可以輕松洗掉舊快照，并且快斬訓復配置超級簡單， 但是，快照 API 不提供可查詢的備份，

例如，

要在 S3 存盤桶中進行 Elasticsearch 備份，你必須使用以下命令在每個 Elasticsearch 節點上安裝 S3 存盤庫插件：

sudo bin/elasticsearch-plugin install repository-s3

然后在你的 AWS s3 存盤桶中注冊一個存盤庫：

curl -X PUT "localhost:9200/_snapshot/test_s3_repository?pretty" -H 'Content-Type: application/json' -d'

{
  "type": "s3",
  "settings": {
    "bucket": "s3_bucket_name"
  }
}  

一旦存盤庫注冊了存盤庫，就可以使用以下命令開始拍攝快照：

curl -X PUT "localhost:9200/_snapshot/test_s3_repository/snapshot_1?pretty"

MongoDB 提供了多種執行備份的方法， 第一個是“mongodump”工具，它隨 MongoDB 安裝一起提供，是 DevOps 團隊最常用的解決方案， 雖然 mongodump 有一些限制——它不進行增量備份并且對大型資料庫無效——但它提供了 1) 可查詢備份、2) 整個資料庫備份和 3) 單個集合等功能，

要在 MongoDB 中實作增量備份，需要使用 MongoDB oplog，它是一個 capped 集合， 還可以通過拍攝檔案系統的快照來創建 MongoDB 部署的備份， 這會復制 MongoDB 的底層資料檔案， MongoDB 的企業版允許你訪問其他選項，例如 MongoDB Atlas、MongoDB Cloud Manager 和 MongoDB Ops Manager，

要使用 mongodump 進行備份，你只需運行以下命令：

mongodump --db <database_name> --host <mongohost_ip_address>

但是，與 Elasticsearch 快照不同，mongo 轉儲將保存在本地磁盤上，而不是保存到 S3 存盤桶或任何其他云存盤中，

支持處理關系資料

NoSQL 資料存盤有利于擴展、寫入和讀取查詢的高吞吐量，但是，它們不能處理關系資料，也不具備關系資料庫提供的 ACID 屬性，關系資料庫將資料存盤在行和列中，雖然你可以輕松規范化，但 Elasticsearch 和 MongoDB 支持檔案模型，因此，他們專注于以非規范化格式保存資料，

雖然這些資料存盤中的資料建模沒有硬性規定，但習慣上依賴于在檔案中保留重復資料或執行應用程式端連接，

盡管有其局限性，但 Elasticsearch 有兩個用于處理關系資料的內置功能：1) nested 和 2) joined 模型，

MongoDB 還有兩種處理關系資料的方法，一種是嵌入式檔案模型，其中相關物件作為子檔案進入存盤，另一種是參考模型，它包括從一個檔案到另一個檔案的鏈接或參考，

資料存盤架構：Lucene 與 C++

Elasticsearch 建立在 Lucene 之上，并使用 Lucene 段在倒排索引中寫入資料，元資料資訊（例如索引映射、設定和其他集群狀態）寫入 Lucene 之上的 Elasticsearch 檔案中，

Lucene 段的問題在于它們本質上是不可變的，并且每次提交都會創建一個新段（segment），這些片段根據合并設定在幕后合并，這使得資料更新成為繁重的操作，因為當每個檔案更新到位時，會生成一個新檔案并覆寫以前的檔案，

為了避免生成過多的段和大量的 I/O，Elasticsearch 為每個索引維護一個事務日志，避免每個索引操作上的低級別 Lucene 提交，事務日志對于在發生崩潰或資料損壞事件時恢復資料也很有用，

MongoDB 的底層存盤模型與 Elasticsearch 完全不同， MongoDB 是用 C++ 撰寫的，并使用記憶體映射檔案將磁盤上的資料檔案映射到記憶體中的位元組陣列，它使用雙向鏈表資料結構來組織資料，每個檔案都包含一個鏈接串列，鏈接到每個其他檔案以及引擎蓋下的實際 BSON 編碼資料， MongoDB 使用日志日志來幫助在硬關機的情況下進行資料庫恢復，最終，如果系統記憶體不足或其他系統資源的利用率非常高，MongoDB 行程將自行關閉，

這些差異表明 MongoDB 是為 1) 高寫入和 2) 更新吞吐量而構建的，而不會導致高 CPU 和磁盤 I/O 問題，

檔案大小

Elasticsearch 支持的默認最大檔案大小最多為 100 MB，盡管你可以將此最大值增加到 2GB — Lucene 的限制， 但是，重要的是要記住，非常大的檔案通常會產生其他問題，

默認情況下，MongoDB 支持最大 16 MB 的檔案存盤， 你可以使用 GridFS 功能存盤更大的檔案，

許可模型、監控和安全

Elasticsearch 是一個免費及開源的軟體，目前你可以使用較為寬松的 Elastic 許可 v2 及 SSPL，詳細閱讀，請參閱文章 “Elastic：隆重推出授權更加簡單且寬松的 Elastic 許可 v2；SSPL 仍可選擇使用”，

MongoDB 也是免費使用的，其社區版附帶服務器端公共許可證 (SSPL) v1.0，社區版包含所有核心 MongoDB 功能，如基本監控工具和安全性，如果您計劃探索和使用 MongoDB 管理、高級監控、記憶體資料庫引擎和 BI-Connector 等高級功能，你可以選擇 MongoDB 企業版，

編程語言：Java vs. Lucene

Elasticsearch 是用 Java 撰寫的，MongoDB 是用 C++ 撰寫的； 但是，這兩種技術都以多種語言提供廣泛的客戶端支持， Elasticsearch 有適用于 Java、Javascript、Ruby、GO、.NET、PHP、Perl、Python 和 Rust 的客戶端， 此外，還有幾個社區貢獻的客戶端可用于 C++、Scala 和 R 等語言，

MongoDB 為 C、C++、Scala 和 Swift 等語言提供了更廣泛的驅動程式， MongoDB 也有多個社區貢獻的客戶端，

概括

Elasticsearch 和 MongoDB 都針對特定用例進行了設計，但在某些常見場景中，選擇一種工具而不是另一種可能會更復雜， 在此博客中，我們審查并比較了這兩種技術的各種特性，以幫助你做出這些更困難的決定，

總而言之，MongoDB 是一個非常流行且可擴展的 NoSQL 資料庫，是面向檔案的資料庫的領導者， 當用例需要具有高吞吐量事務的高度可擴展的資料庫時，它通常是最佳解決方案， 在處理全文搜索、日志分析、發現例外和根本原因檢測方面，Elasticsearch 無疑是贏家，