最近項目組安排了一個任務，項目中用到了全文搜索，基於全文搜索 Solr，可是該 Solr 搜索雲項目不穩定，常常查詢不出來數據，須要手動全量同步，並且是其餘團隊在維護，依賴性太強，致使 Solr 服務一出問題，咱們的項目也基本癱瘓，由於全部的依賴查詢都無結果數據了。因此考慮開發一個適配層，若是 Solr 搜索出問題，自動切換到新的搜索--ES。html

其實能夠經過 Solr 集羣或者服務容錯等設計來解決該問題。可是先不考慮自己設計的合理性，領導須要開發，因此我開始踏上了搭建 ES 服務的道路，從零開始，由於以前徹底沒接觸過 ES，因此經過本系列來記錄下本身的開發過程。mysql

什麼是全文搜索

什麼是全文搜索引擎？算法

百度百科中的定義：全文搜索引擎是目前普遍應用的主流搜索引擎。它的工做原理是計算機索引程序經過掃描文章中的每個詞，對每個詞創建一個索引，指明該詞在文章中出現的次數和位置，當用戶查詢時，檢索程序就根據事先創建的索引進行查找，並將查找的結果反饋給用戶的檢索方式。這個過程相似於經過字典中的檢索字表查字的過程。sql

從定義中咱們已經能夠大體瞭解全文檢索的思路了，爲了更詳細的說明，咱們先從生活中的數聽說起。數據庫

咱們生活中的數據整體分爲兩種：結構化數據 和 非結構化數據。編程

結構化數據：指具備固定格式或有限長度的數據，如數據庫，元數據等。
非結構化數據：非結構化數據又可稱爲全文數據，指不定長或無固定格式的數據，如郵件，word文檔等。

固然有的地方還會有第三種：半結構化數據，如XML，HTML等，當根據須要可按結構化數據來處理，也可抽取出純文本按非結構化數據來處理。api

根據兩種數據分類，搜索也相應的分爲兩種：結構化數據搜索和非結構化數據搜索。緩存

對於結構化數據，咱們通常都是能夠經過關係型數據庫(mysql，oracle等)的 table 的方式存儲和搜索，也能夠創建索引。對於非結構化數據，也即對全文數據的搜索主要有兩種方法：順序掃描法，全文檢索。安全

順序掃描：經過文字名稱也可瞭解到它的大概搜索方式，即按照順序掃描的方式查詢特定的關鍵字。例如給你一張報紙，讓你找到該報紙中「RNG」的文字在哪些地方出現過。你確定須要從頭至尾把報紙閱讀掃描一遍而後標記出關鍵字在哪些版塊出現過以及它的出現位置。markdown

這種方式無疑是最耗時的最低效的，若是報紙排版字體小，並且版塊較多甚至有多份報紙，等你掃描完你的眼睛也差很少了。

全文搜索：對非結構化數據順序掃描很慢，咱們是否能夠進行優化？把咱們的非結構化數據想辦法弄得有必定結構不就好了嗎？將非結構化數據中的一部分信息提取出來，從新組織，使其變得有必定結構，而後對此有必定結構的數據進行搜索，從而達到搜索相對較快的目的。這種方式就構成了全文檢索的基本思路。這部分從非結構化數據中提取出的而後從新組織的信息，咱們稱之索引。

還以讀報紙爲例，咱們想關注最近英雄聯盟S8全球總決賽的新聞，假如都是 RNG 的粉絲，如何快速找到 RNG 新聞的報紙和版塊呢？全文搜索的方式就是，將全部報紙中全部版塊中關鍵字進行提取，如"EDG"，"RNG"，"FW"，"戰隊"，"英雄聯盟"等。而後對這些關鍵字創建索引，經過索引咱們就能夠對應到該關鍵詞出現的報紙和版塊。注意區別目錄搜索引擎。

爲何要用全文搜索搜索引擎

以前，有同事問我，爲何要用搜索引擎？咱們的全部數據在數據庫裏面都有，並且 Oracle、SQL Server 等數據庫裏也能提供查詢檢索或者聚類分析功能，直接經過數據庫查詢不就能夠了嗎？確實，咱們大部分的查詢功能均可以經過數據庫查詢得到，若是查詢效率低下，還能夠經過建數據庫索引，優化SQL等方式進行提高效率，甚至經過引入緩存來加快數據的返回速度。若是數據量更大，就能夠分庫分表來分擔查詢壓力。

那爲何還要全文搜索引擎呢？咱們主要從如下幾個緣由分析：

數據類型 全文索引搜索支持非結構化數據的搜索，能夠更好地快速搜索大量存在的任何單詞或單詞組的非結構化文本。例如 Google，百度類的網站搜索，它們都是根據網頁中的關鍵字生成索引，咱們在搜索的時候輸入關鍵字，它們會將該關鍵字即索引匹配到的全部網頁返回；還有常見的項目中應用日誌的搜索等等。對於這些非結構化的數據文本，關係型數據庫搜索不是能很好的支持。
索引的維護 通常傳統數據庫，全文檢索都實現的很雞肋，由於通常也沒人用數據庫存文本字段。進行全文檢索須要掃描整個表，若是數據量大的話即便對SQL的語法優化，也收效甚微。創建了索引，可是維護起來也很麻煩，對於 insert 和 update 操做都會從新構建索引。

何時使用全文搜索引擎：

搜索的數據對象是大量的非結構化的文本數據。
文件記錄量達到數十萬或數百萬個甚至更多。
支持大量基於交互式文本的查詢。
需求很是靈活的全文搜索查詢。
對高度相關的搜索結果的有特殊需求，可是沒有可用的關係數據庫能夠知足。
對不一樣記錄類型、非文本數據操做或安全事務處理的需求相對較少的狀況。

Lucene，Solr， ElasticSearch ？

如今主流的搜索引擎大概就是：Lucene，Solr，ElasticSearch。

它們的索引創建都是根據倒排索引的方式生成索引，何謂倒排索引？

維基百科倒排索引（英語：Inverted index），也常被稱爲反向索引、置入檔案或反向檔案，是一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最經常使用的數據結構。

Lucene

Lucene是一個Java全文搜索引擎，徹底用Java編寫。Lucene不是一個完整的應用程序，而是一個代碼庫和API，能夠很容易地用於嚮應用程序添加搜索功能。

Lucene經過簡單的API提供強大的功能：

可擴展的高性能索引

在現代硬件上超過150GB /小時
小RAM要求 - 只有1MB堆
增量索引與批量索引同樣快
索引大小約爲索引文本大小的20-30％

強大，準確，高效的搜索算法

排名搜索 - 首先返回最佳結果
許多強大的查詢類型：短語查詢，通配符查詢，鄰近查詢，範圍查詢等
現場搜索（例如標題，做者，內容）
按任何字段排序
使用合併結果進行多索引搜索
容許同時更新和搜索
靈活的分面，突出顯示，鏈接和結果分組
快速，內存效率和錯誤容忍的建議
可插拔排名模型，包括矢量空間模型和Okapi BM25
可配置存儲引擎（編解碼器）

跨平臺解決方案

做爲Apache許可下的開源軟件提供，容許您在商業和開源程序中使用Lucene
100％-pure Java
可用的其餘編程語言中的實現是索引兼容的

Apache軟件基金會 在Apache軟件基金會提供的開源軟件項目的Apache社區的支持。

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

Solr

Apache Solr是一個基於名爲Lucene的Java庫構建的開源搜索平臺。它以用戶友好的方式提供Apache Lucene的搜索功能。做爲一個行業參與者近十年，它是一個成熟的產品，擁有強大而普遍的用戶社區。它提供分佈式索引，複製，負載平衡查詢以及自動故障轉移和恢復。若是它被正確部署而後管理得好，它就可以成爲一個高度可靠，可擴展且容錯的搜索引擎。不少互聯網巨頭，如Netflix，eBay，Instagram和亞馬遜（CloudSearch）都使用Solr，由於它可以索引和搜索多個站點。

主要功能列表包括：

全文搜索
突出
分面搜索
實時索引
動態羣集
數據庫集成
NoSQL功能和豐富的文檔處理（例如Word和PDF文件）

ElasticSearch

Elasticsearch是一個開源（Apache 2許可證），是一個基於Apache Lucene庫構建的RESTful搜索引擎。

Elasticsearch是在Solr以後幾年推出的。它提供了一個分佈式，多租戶能力的全文搜索引擎，具備HTTP Web界面（REST）和無架構JSON文檔。Elasticsearch的官方客戶端庫提供Java，Groovy，PHP，Ruby，Perl，Python，.NET和Javascript。

分佈式搜索引擎包括能夠劃分爲分片的索引，而且每一個分片能夠具備多個副本。每一個Elasticsearch節點均可以有一個或多個分片，其引擎也能夠充當協調器，將操做委派給正確的分片。

Elasticsearch可經過近實時搜索進行擴展。其主要功能之一是多租戶。

主要功能列表包括：

分佈式搜索
多租戶
分析搜索
分組和聚合

Elasticsearch vs. Solr的選擇

因爲Lucene的複雜性，通常不多會考慮它做爲搜索的第一選擇，排除一些公司須要自研搜索框架，底層須要依賴Lucene。因此這裏咱們重點分析 Elasticsearch 和 Solr。

Elasticsearch vs. Solr。哪個更好？他們有什麼不一樣？你應該使用哪個？

歷史比較

Apache Solr是一個成熟的項目，擁有龐大而活躍的開發和用戶社區，以及Apache品牌。Solr於2006年首次發佈到開源，長期以來一直佔據着搜索引擎領域，而且是任何須要搜索功能的人的首選引擎。它的成熟轉化爲豐富的功能，而不只僅是簡單的文本索引和搜索；如分面，分組，強大的過濾，可插入的文檔處理，可插入的搜索鏈組件，語言檢測等。

Solr 在搜索領域佔據了多年的主導地位。而後，在2010年左右，Elasticsearch成爲市場上的另外一種選擇。那時候，它遠沒有Solr那麼穩定，沒有Solr的功能深度，沒有思想分享，品牌等等。

Elasticsearch雖然很年輕，但它也本身的一些優點，Elasticsearch 創建在更現代的原則上，針對更現代的用例，而且是爲了更容易處理大型索引和高查詢率而構建的。此外，因爲它太年輕，沒有社區能夠合做，它能夠自由地向前推動，而不須要與其餘人（用戶或開發人員）達成任何共識或合做，向後兼容，或任何其餘更成熟的軟件一般必須處理。

所以，它在Solr以前就公開了一些很是受歡迎的功能(例如，接近實時搜索，英文：Near Real-Time Search)。從技術上講，NRT搜索的能力確實來自Lucene，它是 Solr 和 Elasticsearch 使用的基礎搜索庫。具備諷刺意味的是，由於 Elasticsearch 首先公開了NRT搜索，因此人們將NRT搜索與Elasticsearch 聯繫在一塊兒，儘管 Solr 和 Lucene 都是同一個 Apache 項目的一部分，所以，人們會首先指望 Solr 具備如此高要求的功能。

特徵差別比較

這兩個搜索引擎都是流行的，先進的的開源搜索引擎。它們都是圍繞核心底層搜索庫 - Lucene構建的 - 但它們又是不一樣的。像全部東西同樣，每一個都有其優勢和缺點，根據您的需求和指望，每一個均可能更好或更差。Solr和Elasticsearch都在快速發展，因此，話很少說，先來看下它們的差別清單：

特徵	Solr/SolrCloud	Elasticsearch
社區和開發者	Apache 軟件基金和社區支持	單一商業實體及其員工
節點發現	Apache Zookeeper，在大量項目中成熟且通過實戰測試	Zen內置於Elasticsearch自己，須要專用的主節點才能進行分裂腦保護
碎片放置	本質上是靜態，須要手動工做來遷移分片，從Solr 7開始 - Autoscaling API容許一些動態操做	動態，能夠根據羣集狀態按需移動分片
高速緩存	全局，每一個段更改無效	每段，更適合動態更改數據
分析引擎性能	很是適合精確計算的靜態數據	結果的準確性取決於數據放置
全文搜索功能	基於Lucene的語言分析，多建議，拼寫檢查，豐富的高亮顯示支持	基於Lucene的語言分析，單一建議API實現，高亮顯示從新計算
DevOps支持	還沒有徹底，但即將到來	很是好的API
非平面數據處理	嵌套文檔和父-子支持	嵌套和對象類型的天然支持容許幾乎無限的嵌套和父-子支持
查詢DSL	JSON（有限），XML（有限）或URL參數	JSON
索引/收集領導控制	領導者安置控制和領導者從新平衡甚至能夠節點上的負載	不可能
機器學習	內置 - 在流聚合之上，專一於邏輯迴歸和學習排名貢獻模塊	商業功能，專一於異常和異常值以及時間序列數據

這裏瞭解更多。

綜合比較

另外，咱們在從如下幾個方面來分析下：

近幾年的流行趨勢咱們查看一下這兩種產品的Google搜索趨勢。谷歌趨勢代表，與 Solr 相比，Elasticsearch具備很大的吸引力，但這並不意味着Apache Solr已經死亡。雖然有些人可能不這麼認爲，但Solr仍然是最受歡迎的搜索引擎之一，擁有強大的社區和開源支持。

安裝和配置與Solr相比，Elasticsearch易於安裝且很是輕巧。此外，您能夠在幾分鐘內安裝並運行Elasticsearch。可是，若是Elasticsearch管理不當，這種易於部署和使用可能會成爲一個問題。基於JSON的配置很簡單，但若是要爲文件中的每一個配置指定註釋，那麼它不適合您。總的來講，若是您的應用使用的是JSON，那麼Elasticsearch是一個更好的選擇。不然，請使用Solr，由於它的schema.xml和solrconfig.xml都有很好的文檔記錄。
社區 Solr擁有更大，更成熟的用戶，開發者和貢獻者社區。ES雖擁有的規模較小但活躍的用戶社區以及不斷增加的貢獻者社區。 Solr是真正的開源社區代碼。任何人均可覺得Solr作出貢獻，而且根據優勢選出新的Solr開發人員（也稱爲提交者）。Elasticsearch在技術上是開源的，但在精神上卻不那麼重要。任何人均可以看到來源，任何人均可以更改它並提供貢獻，但只有Elasticsearch的員工才能真正對Elasticsearch進行更改。 Solr貢獻者和提交者來自許多不一樣的組織，而Elasticsearch提交者來自單個公司。
成熟度 Solr更成熟，但ES增加迅速，我認爲它穩定。
文檔 Solr在這裏得分很高。它是一個很是有據可查的產品，具備清晰的示例和API用例場景。 Elasticsearch的文檔組織良好，但它缺少好的示例和清晰的配置說明。

總結

那麼，究竟是Solr仍是Elasticsearch？有時很難找到明確的答案。不管您選擇Solr仍是Elasticsearch，首先須要瞭解正確的用例和將來需求。總結他們的每一個屬性。

記住：

因爲易於使用，Elasticsearch在新開發者中更受歡迎。可是，若是您已經習慣了與Solr合做，請繼續使用它，由於遷移到Elasticsearch沒有特定的優點。
若是除了搜索文本以外還須要它來處理分析查詢，Elasticsearch是更好的選擇。
若是須要分佈式索引，則須要選擇Elasticsearch。對於須要良好可伸縮性和性能的雲和分佈式環境，Elasticsearch是更好的選擇。
二者都有良好的商業支持（諮詢，生產支持，整合等）
二者都有很好的操做工具，儘管Elasticsearch因其易於使用的API而更多地吸引了DevOps人羣，所以能夠圍繞它建立一個更加生動的工具生態系統。
Elasticsearch在開源日誌管理用例中佔據主導地位，許多組織在Elasticsearch中索引它們的日誌以使其可搜索。雖然Solr如今也能夠用於此目的，但它只是錯過了這一想法。
Solr仍然更加面向文本搜索。另外一方面，Elasticsearch 一般用於過濾和分組 - 分析查詢工做負載 - 而不必定是文本搜索。Elasticsearch 開發人員在 Lucene 和 Elasticsearch 級別上投入了大量精力使此類查詢更高效(下降內存佔用和CPU使用)。所以，對於不只須要進行文本搜索，並且須要複雜的搜索時間聚合的應用程序，Elasticsearch是一個更好的選擇。
Elasticsearch更容易上手，一個下載和一個命令就能夠啓動一切。Solr傳統上須要更多的工做和知識，但Solr最近在消除這一點上取得了巨大的進步，如今只需努力改變它的聲譽。
在性能方面，它們大體相同。我說「大體」，由於沒有人作過全面和無偏見的基準測試。對於95％的用例，任何一種選擇在性能方面都會很好，剩下的5％須要用它們的特定數據和特定的訪問模式來測試這兩種解決方案。
從操做上講，Elasticsearch使用起來比較簡單 - 它只有一個進程。Solr在其相似Elasticsearch的徹底分佈式部署模式SolrCloud中依賴於Apache ZooKeeper。ZooKeeper是超級成熟，超級普遍使用等等，但它仍然是另外一個活躍的部分。也就是說，若是您使用的是Hadoop，HBase，Spark，Kafka或其餘一些較新的分佈式軟件，您可能已經在組織的某個地方運行ZooKeeper。
雖然Elasticsearch內置了相似ZooKeeper的組件Xen，但ZooKeeper能夠更好地防止有時在Elasticsearch集羣中出現的可怕的裂腦問題。公平地說，Elasticsearch開發人員已經意識到這個問題，並致力於改進Elasticsearch的這個方面。
若是您喜歡監控和指標，那麼使用Elasticsearch，您將會進入天堂。這個東西比新年前夜在時代廣場能夠擠壓的人有更多的指標！Solr暴露了關鍵指標，但遠不及Elasticsearch那麼多。

總之，二者都是功能豐富的搜索引擎，只要設計和實現得當，它們或多或少都能提供相同的性能。本篇文章的整體內容大體以下圖，該圖由園友ReyCG精心繪製並提供。

參考：

我的公衆號：JaJian

歡迎長按下圖關注公衆號：JaJian！

按期爲你奉上分佈式，微服務等一線互聯網公司相關技術的講解和分析。

全文搜索引擎 ElasticSearch 仍是 Solr？