如何處理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的優缺點**:
優點
- Elasticsearch是分散式的。不需要其他元件，分發是實時的，被叫做”Push replication”。
- Elasticsearch 完全支援 Apache Lucene 的接近實時的搜尋。
- 處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高階設定。
- Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。
- 各節點組成對等的網路結構，某些節點出現故障時會自動分配其他節點代替其進行工作。
缺點
- 只有一名開發者（當前Elasticsearch GitHub組織已經不只如此，已經有了相當活躍的維護者）
- 還不夠自動（不適合當前新的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的優缺點
優點
- Solr有一個更大、更成熟的使用者、開發和貢獻者社群。
- 支援新增多種格式的索引，如：HTML、PDF、微軟 Office 系列軟體格式以及 JSON、XML、CSV 等純文字格式。
- Solr比較成熟、穩定。
- 不考慮建索引的同時進行搜尋，速度更快。
缺點
- 建立索引時，搜尋效率下降，實時索引搜尋效率不高。
Elasticsearch與Solr的比較*
當單純的對已有資料進行搜尋時，Solr更快。
當實時建立索引時, Solr會產生io阻塞，查詢效能較差, Elasticsearch具有明顯的優勢。
隨著資料量的增加，Solr的搜尋效率會變得更低，而Elasticsearch卻沒有明顯的變化。
綜上所述，Solr的架構不適合實時搜尋的應用。
實際生產環境測試*
下圖為將搜尋引擎從Solr轉到Elasticsearch以後的平均查詢速度有了50倍的提升。
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 的增大，查詢時的速度受到的影響會非常大