1. 程式人生 > >如何處理PB級別資料(1)——Elasticsearch與Solr 選型

如何處理PB級別資料(1)——Elasticsearch與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的開源搜尋引擎解決方案*

說明:Lucene 是一個 JAVA 搜尋類庫,它本身並不是一個完整的解決方案,需要額外的開發工作。

優點:成熟的解決方案,有很多的成功案例。apache 頂級專案,正在持續快速的進步。龐大而活躍的開發社群,大量的開發人員。它只是一個類庫,有足夠的定製和優化空間:經過簡單定製,就可以滿足絕大部分常見的需求;經過優化,可以支援 10億+ 量級的搜尋。

缺點:需要額外的開發工作。所有的擴充套件,分散式,可靠性等都需要自己實現;非實時,從建索引到可以搜尋中間有一個時間延遲,而當前的“近實時”(Lucene Near Real Time search)搜尋方案的可擴充套件性有待進一步完善

說明:基於 Lucene 的,支援分散式,可擴充套件,具有容錯功能,準實時的搜尋方案。

優點:開箱即用,可以與 Hadoop 配合實現分散式。具備擴充套件和容錯機制。

缺點:只是搜尋方案,建索引部分還是需要自己實現。在搜尋功能上,只實現了最基本的需求。成功案例較少,專案的成熟度稍微差一些。因為需要支援分散式,對於一些複雜的查詢需求,定製的難度會比較大。

說明:Map/Reduce 模式的,分散式建索引方案,可以跟 Katta 配合使用。

優點:分散式建索引,具備可擴充套件性。

缺點:只是建索引方案,不包括搜尋實現。工作在批處理模式,對實時搜尋的支援不佳。

說明:基於 Lucene 的一系列解決方案,包括 準實時搜尋 zoie ,facet 搜尋實現 bobo ,機器學習演算法 decomposer ,摘要儲存庫 krati ,資料庫模式包裝 sensei 等等

優點:經過驗證的解決方案,支援分散式,可擴充套件,豐富的功能實現

缺點:與 linkedin 公司的聯絡太緊密,可定製性比較差

說明:基於 Lucene,索引存在 cassandra 資料庫中

優點:參考 cassandra 的優點

缺點:參考 cassandra 的缺點。另外,這只是一個 demo,沒有經過大量驗證

說明:基於 Lucene,索引存在 HBase 資料庫中

優點:參考 HBase 的優點

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