Solr vs. Elasticsearch誰是開源搜索引擎王者

當前是雲計算和數據快速增加的時代,今天的應用程序正以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）

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

本文主要內容爲翻譯http://logz.io/blog/solr-vs-elasticsearch/，感謝做者，感謝谷歌翻譯！