【轉】搜索引擎選擇： Elasticsearch與Solr

原文地址：http://i.zhcy.tk/blog/elasticsearchyu-solr/

 

Elasticsearch簡介

Elasticsearch是一個實時的分佈式搜索和分析引擎。它能夠幫助你用史無前例的速度去處理大規模數據。

它能夠用於全文搜索，結構化搜索以及分析，固然你也能夠將這三者進行組合。

Elasticsearch是一個創建在全文搜索引擎 Apache Lucene™ 基礎上的搜索引擎，能夠說Lucene是當今最早進，最高效的全功能開源搜索引擎框架。

可是Lucene只是一個框架，要充分利用它的功能，須要使用JAVA，而且在程序中集成Lucene。須要不少的學習瞭解，才能明白它是如何運行的，Lucene確實很是複雜。

Elasticsearch使用Lucene做爲內部引擎，可是在使用它作全文搜索時，只須要使用統一開發好的API便可，而不須要了解其背後複雜的Lucene的運行原理。

固然Elasticsearch並不只僅是Lucene這麼簡單，它不但包括了全文搜索功能，還能夠進行如下工做:

• 分佈式實時文件存儲，並將每個字段都編入索引，使其能夠被搜索。

• 實時分析的分佈式搜索引擎。

• 能夠擴展到上百臺服務器，處理PB級別的結構化或非結構化數據。

這麼多的功能被集成到一臺服務器上，你能夠輕鬆地經過客戶端或者任何你喜歡的程序語言與ES的RESTful API進行交流。

Elasticsearch的上手是很是簡單的。它附帶了不少很是合理的默認值，這讓初學者很好地避免一上手就要面對複雜的理論，

它安裝好了就可使用了，用很小的學習成本就能夠變得頗有生產力。

隨着越學越深刻，還能夠利用Elasticsearch更多高級的功能，整個引擎能夠很靈活地進行配置。能夠根據自身需求來定製屬於本身的Elasticsearch。

使用案例：

• 維基百科使用Elasticsearch來進行全文搜作並高亮顯示關鍵詞，以及提供search-as-you-type、did-you-mean等搜索建議功能。

• 英國衛報使用Elasticsearch來處理訪客日誌，以便能將公衆對不一樣文章的反應實時地反饋給各位編輯。

• StackOverflow將全文搜索與地理位置和相關信息進行結合，以提供more-like-this相關問題的展示。

• GitHub使用Elasticsearch來檢索超過1300億行代碼。

• 天天，Goldman Sachs使用它來處理5TB數據的索引，還有不少投行使用它來分析股票市場的變更。

可是Elasticsearch並不僅是面向大型企業的，它還幫助了不少相似DataDog以及Klout的創業公司進行了功能的擴展。

Elasticsearch的優缺點:

優勢

1. Elasticsearch是分佈式的。不須要其餘組件，分發是實時的，被叫作」Push replication」。
2. Elasticsearch 徹底支持 Apache Lucene 的接近實時的搜索。
3. 處理多租戶（multitenancy）不須要特殊配置，而Solr則須要更多的高級設置。
4. Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。
5. 各節點組成對等的網絡結構，某些節點出現故障時會自動分配其餘節點代替其進行工做。

缺點

1. 只有一名開發者（當前Elasticsearch GitHub組織已經不僅如此，已經有了至關活躍的維護者）
2. 還不夠自動（不適合當前新的Index Warmup API）

Solr簡介

Solr（讀做「solar」）是Apache Lucene項目的開源企業搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態聚類、數據庫集成，以及富文本（如Word、PDF）的處理。Solr是高度可擴展的，並提供了分佈式搜索和索引複製。Solr是最流行的企業級搜索引擎，Solr4 還增長了NoSQL支持。

Solr是用Java編寫、運行在Servlet容器（如 Apache Tomcat 或Jetty）的一個獨立的全文搜索服務器。 Solr採用了 Lucene Java 搜索庫爲核心的全文索引和搜索，並具備相似REST的HTTP/XML和JSON的API。Solr強大的外部配置功能使得無需進行Java編碼，即可對其進行調整以適應多種類型的應用程序。Solr有一個插件架構，以支持更多的高級定製。

由於2010年 Apache Lucene 和 Apache Solr 項目合併，兩個項目是由同一個Apache軟件基金會開發團隊製做實現的。提到技術或產品時，Lucene/Solr或Solr/Lucene是同樣的。

Solr的優缺點

優勢

1. Solr有一個更大、更成熟的用戶、開發和貢獻者社區。
2. 支持添加多種格式的索引，如：HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。
3. Solr比較成熟、穩定。
4. 不考慮建索引的同時進行搜索，速度更快。

缺點

1. 創建索引時，搜索效率降低，實時索引搜索效率不高。

Elasticsearch與Solr的比較

當單純的對已有數據進行搜索時，Solr更快。

Search Fesh Index While Idle

當實時創建索引時, Solr會產生io阻塞，查詢性能較差, Elasticsearch具備明顯的優點。

search_fresh_index_while_indexing

隨着數據量的增長，Solr的搜索效率會變得更低，而Elasticsearch卻沒有明顯的變化。

search_fresh_index_while_indexing

綜上所述，Solr的架構不適合實時搜索的應用。

實際生產環境測試

下圖爲將搜索引擎從Solr轉到Elasticsearch之後的平均查詢速度有了50倍的提高。

average_execution_time

Elasticsearch 與 Solr 的比較總結

• 兩者安裝都很簡單；
• Solr 利用 Zookeeper 進行分佈式管理，而 Elasticsearch 自身帶有分佈式協調管理功能;
• Solr 支持更多格式的數據，而 Elasticsearch 僅支持json文件格式；
• Solr 官方提供的功能更多，而 Elasticsearch 自己更注重於核心功能，高級功能多有第三方插件提供；
• Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch。

Solr 是傳統搜索應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜索應用。

其餘基於Lucene的開源搜索引擎解決方案

1. 直接使用 Lucene

說明：Lucene 是一個 JAVA 搜索類庫，它自己並非一個完整的解決方案，須要額外的開發工做。

優勢：成熟的解決方案，有不少的成功案例。apache 頂級項目，正在持續快速的進步。龐大而活躍的開發社區，大量的開發人員。它只是一個類庫，有足夠的定製和優化空間：通過簡單定製，就能夠知足絕大部分常見的需求；通過優化，能夠支持 10億+ 量級的搜索。

缺點：須要額外的開發工做。全部的擴展，分佈式，可靠性等都須要本身實現；非實時，從建索引到能夠搜索中間有一個時間延遲，而當前的「近實時」(Lucene Near Real Time search)搜索方案的可擴展性有待進一步完善

• Katta

說明：基於 Lucene 的，支持分佈式，可擴展，具備容錯功能，準實時的搜索方案。

優勢：開箱即用，能夠與 Hadoop 配合實現分佈式。具有擴展和容錯機制。

缺點：只是搜索方案，建索引部分仍是須要本身實現。在搜索功能上，只實現了最基本的需求。成功案例較少，項目的成熟度稍微差一些。由於須要支持分佈式，對於一些複雜的查詢需求，定製的難度會比較大。

• Hadoop contrib/index

說明：Map/Reduce 模式的，分佈式建索引方案，能夠跟 Katta 配合使用。

優勢：分佈式建索引，具有可擴展性。

缺點：只是建索引方案，不包括搜索實現。工做在批處理模式，對實時搜索的支持不佳。

• LinkedIn 的開源方案

說明：基於 Lucene 的一系列解決方案，包括 準實時搜索 zoie ，facet 搜索實現 bobo ，機器學習算法 decomposer ，摘要存儲庫 krati ，數據庫模式包裝 sensei 等等

優勢：通過驗證的解決方案，支持分佈式，可擴展，豐富的功能實現

缺點：與 linkedin 公司的聯繫太緊密，可定製性比較差

• Lucandra

說明：基於 Lucene，索引存在 cassandra 數據庫中

優勢：參考 cassandra 的優勢

缺點：參考 cassandra 的缺點。另外，這只是一個 demo，沒有通過大量驗證

• HBasene

說明：基於 Lucene，索引存在 HBase 數據庫中

優勢：參考 HBase 的優勢

缺點：參考 HBase 的缺點。另外，在實現中，lucene terms 是存成行，但每一個 term 對應的 posting lists 是以列的方式存儲的。隨着單個 term 的 posting lists 的增大，查詢時的速度受到的影響會很是大