當前是雲端計算和資料快速增長的時代,今天的應用程式正以PB級和ZB級的速度生產資料，但人們依然在不停的追求更高更快的效能需求。隨著資料的堆積，如何快速有效的搜尋這些資料，成為對後端服務的挑戰。本文，我們將比較業界兩個最流行的開源搜尋引擎，Solr和ElasticSearch。兩者都建立在Apache Lucene開源平臺之上，它們的主要功能非常相似，但是在部署的易用性，可擴充套件性和其他功能方面也存在巨大差異。

關於Apache Solr

Apache Solr基於業界大名鼎鼎的java開源搜尋引擎Lucene，Lucene更多的是一個軟體包，還不能稱之為搜尋引擎，而solr則完成對lucene的封裝，是一個真正意義上的搜尋引擎框架。在過去的十年裡，solr發展壯大，擁有廣泛的使用者群體。solr提供分散式索引、分片、副本集、負載均衡和自動故障轉移和恢復功能。如果正確部署，良好管理，solr就能夠成為一個高可靠、可擴充套件和高容錯的搜尋引擎。不少網際網路巨頭，如Netflix，eBay，Instagram和Amazon（CloudSearch）均使用Solr。

solr的主要特點：

• 全文索引
• 高亮
• 分面搜尋
• 實時索引
• 動態聚類
• 資料庫整合
• NoSQL特性和豐富的文件處理（例如Word和PDF檔案）

關於Elasticsearch

與solr一樣，Elasticsearch構建在Apache Lucene庫之上，同是開源搜尋引擎。Elasticsearch在Solr推出幾年後才面世的，通過REST和schema-free（不需要預先定義 Schema，solr是需要預先定義的）的JSON文件提供分散式、多租戶全文搜尋引擎。並且官方提供Java，Groovy，PHP，Ruby，Perl，Python，.NET和Javascript客戶端。

分散式搜尋引擎包含可以華為為分片（shard）的索引，每一個分片可以有多個副本（replicas）。每個Elasticsearch節點可以有一個或多個分片，其引擎既同時作為協調器（coordinator ），將操作轉發給正確的分片。

Elasticsearch可擴充套件為準實時搜尋引擎。其中一個關鍵特性是多租戶功能，可根據不同的用途分索引，可以同時操作多個索引。

Elasticsearch主要特性：

• 分散式搜尋
• 多租戶
• 查詢統計分析
• 分組和聚合

熱度對比

在開始比較前，我們可以檢視兩者在google中的搜尋熱度，可以看出在2013年後，Elasticsearch與Solr相比具有很大的吸引力，但這並不意味著Apache Solr已經死了。雖然不少人不認可，但Solr仍然是最流行的搜尋引擎之一，具有強大的開源社群支援。

安裝與配置

相對來說，Elasticsearch更易於安裝，與Solr相比非常輕量級。 Solr的分發軟體包大小的當前版本（6.4.2）大約為150 MB，而Elasticsearch分發軟體包大小的當前版本（5.2.2）僅為32.2MB。

但是，如果Elasticsearch管理不好，這種易於部署和使用可能會成為一個問題。基於JSON的配置很容易，但如果你想為檔案中的每個配置指定註釋，那麼它不適合你。Solr也提供了Rest API，可以通過集合API建立自定義分片集合，記錄聚類演算法和執行自定義分片。

總的來說，如果你的應用程式使用JSON，那麼Elasticsearch是一個更好的選擇。否則，使用Solr，因為它的schema.xml和solrconfig.xml有很好的文件。

索引和搜尋

資料來源

Solr接受來自不同來源的資料，包括XML檔案，逗號分隔符（CSV）檔案和從資料庫中的表提取的資料以及常見的檔案格式（如Microsoft Word和PDF）。

Elasticsearch還支援其他來源的資料，例如ActiveMQ，AWS SQS，DynamoDB（Amazon NoSQL），FileSystem，Git，JDBC，JMS，Kafka，LDAP，MongoDB，neo4j，RabbitMQ，Redis，Solr和Twitter。還有各種外掛可用。

搜尋

Solr專注於文字搜尋，而Elasticsearch則常用於查詢、過濾和分組分析統計，Elasticsearch背後的團隊也努力讓這些查詢更為高效。因此當比較兩者時，對那些不僅需要文字搜尋，同時還需要複雜的時間序列搜尋和聚合的應用程式而言，毫無疑問Elasticsearch是最佳選擇。

索引

兩者都支援使用停用詞和同義詞來匹配文件。

在Solr中，索引間進行join必須是單個分片和其他節點上的副本集進行關聯來搜尋文件間關係（例如SQL連線）。而Elasticsearch提供更高效的has_children和top_children查詢來檢索這樣的相關文件。

可擴充套件性和分散式

搜尋引擎需要處理數以百萬級的文件，基於此搜尋引擎應該是可複製的，模組化的和可擴充套件的，支援叢集和分散式架構。

專為雲而設計

Elasticsearch非常易於擴充套件，擁有足夠多的需要大叢集的使用案例。

Solr 基於Apache ZooKeeper也實現了類似ES的分散式部署模式。ZooKeeper是成熟和廣泛使用的獨立應用程式。

相對比，Elasticsearch有一個內建的類似ZooKeeper的名為Zen的元件，通過內部的協調機制來維護叢集狀態。

可以說Elasticsearch是轉為雲而設計，是分散式首選。

分片拆分和再平衡

shards是luence索引的分割槽單元，solr和elasticsearch均使用。你可以通過在叢集中的不同計算機上執行shard來分發索引。隨著SolrCloud的引入，Solr開始支援shard拆分，這允許您通過拆分現有shard來新增更多shard。相比之下，ElasticSearch仍然不支援這一點，事實上，實際上阻止了這種做法。ES通過向設定中新增更多計算機，可以使用自動碎片平衡功能。相比之下，Solr允許新增分片（使用隱式路由時）或分割（使用複合ID時），但不能刪除分片。它允許您增加副本。在Elasticsearch中，預設情況下每個索引具有五個分片。它不允許您更改主分片的數量，但它允許您增加副本的數量。分片再平衡對於水平擴容非常有用。當新增新機器時，它將自動重新平衡不同機器中可用的分片。

社群

Solr有一個廣泛的開源社群。任何人都可以貢獻給Solr，新的Solr開發人員或程式碼提交者只能根據功能選擇。 Elasticsearch在技術上是開源的，但不完全。所有貢獻者都可以訪問原始碼，使用者可以進行更改並提供。但最終的變化由Elastic（執行Elasticsearch和其他軟體的公司）的員工確認和完成。因此，Elasticsearch更多地由單個公司驅動，而不是整個社群。

Solr貢獻者和提交者跨越多個組織，而Elasticsearch提交者僅來自Elastic。還有人指出，Solr的強大社群有一個健康的專案管道和許多知名公司參與。這些成員還通過在整個開發和工程過程中做出貢獻來投資該平臺。

兩者都有很好的使用者群和豐富的開發人員社群，但ElasticSearch相較於Solr更新。 Solr已經存在了更長的時間，所以它的生態系統是發達的，擁有更大的使用者群。

文件

Solr在這裡得分很高。它是一個非常有據可查的產品，具有清晰的示例和API用例場景。 Elasticsearch的文件組織良好，但它缺乏好的示例和清晰的配置說明。

選Solr 還是 Elasticsearch?

通過上面的對比，很難確定誰是最終贏家。其實，無論選擇Solr還是Elasticsearch，你首先需要了解您的使用者場景和未來的需求。我們來總結一下：

請記住：

• Elasticsearch由於其易用性而在較新的開發人員中更受歡迎
• 但是如果你已經在使用solr了，請繼續使用它，因為遷移到Elasticsearch並不會帶來具體的優勢
• 如果您需要它來處理分析查詢以及搜尋文字，Elasticsearch是更好的選擇，特別是收集日誌，做分析處理（參考前面發的ELK 安裝使用http://www.cnblogs.com/xiaoqi/p/elk-part1.html）

總之，兩者都是功能豐富的搜尋引擎，並且或多或少地給出相同的效能，只要它們被設計和實施得很好。