• 什麼是全文搜尋
• 為什麼要用全文搜尋搜尋引擎
• Lucene，Solr，ElasticSearch ？
• Elasticsearch vs Solr 的選擇
• 總結

---

最近專案組安排了一個任務，專案中用到了基於 Solr 的全文搜尋，但是該 Solr 搜尋雲專案不穩定，經常查詢不出來資料，需要手動全量同步。

而且它還是其他團隊在維護，依賴性太強，導致 Solr 服務一齣問題，我們的專案也基本癱瘓，因為所有的依賴查詢都無結果資料了。

所以考慮開發一個適配層，如果 Solr 搜尋出問題，自動切換到新的搜尋 ES。其實可以透過 Solr 叢集或者服務容錯等設計來解決該問題。

但是先不考慮本身設計的合理性，領導需要開發，所以我開始踏上了搭建 ES 服務的道路，從零開始，因為之前完全沒接觸過 ES，所以透過本系列來記錄下自己的開發過程。

本篇文章的總體內容大致如下圖：

什麼是全文搜尋

什麼是全文搜尋引擎？百度百科中的定義：

全文搜尋引擎是目前廣泛應用的主流搜尋引擎。它的工作原理是計算機索引程式透過掃描文章中的每一個詞，對每一個詞建立一個索引，指明該詞在文章中出現的次數和位置，當使用者查詢時，檢索程式就根據事先建立的索引進行查詢，並將查詢的結果反饋給使用者的檢索方式。這個過程類似於透過字典中的檢索字表查字的過程。

從定義中我們已經可以大致瞭解全文檢索的思路了，為了更詳細的說明，我們先從生活中的資料說起。

我們生活中的資料總體分為兩種：

• 結構化資料：指具有固定格式或有限長度的資料，如資料庫，元資料等。
• 非結構化資料：非結構化資料又可稱為全文資料，指不定長或無固定格式的資料，如郵件，Word 檔案等。

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

根據兩種資料分類，搜尋也相應的分為兩種：結構化資料搜尋和非結構化資料搜尋。

對於結構化資料，我們一般都是可以透過關係型資料庫(MySQL，Oracle 等)的 table 的方式儲存和搜尋，也可以建立索引。

對於非結構化資料，也即對全文資料的搜尋主要有兩種方法：

• 順序掃描
• 全文檢索

順序掃描：透過文字名稱也可瞭解到它的大概搜尋方式，即按照順序掃描的方式查詢特定的關鍵字。

例如給你一張報紙，讓你找到該報紙中“RNG”的文字在哪些地方出現過。你肯定需要從頭到尾把報紙閱讀掃描一遍，然後標記出關鍵字在哪些版塊出現過以及它的出現位置。

這種方式無疑是最耗時的最低效的，如果報紙排版字型小，而且版塊較多甚至有多份報紙，等你掃描完你的眼睛也差不多了。

全文檢索：對非結構化資料順序掃描很慢，我們是否可以進行最佳化？把我們的非結構化資料想辦法弄得有一定結構不就行了嗎？

將非結構化資料中的一部分資訊提取出來，重新組織，使其變得有一定結構，然後對此有一定結構的資料進行搜尋，從而達到搜尋相對較快的目的。

這種方式就構成了全文檢索的基本思路。這部分從非結構化資料中提取出的然後重新組織的資訊，我們稱之索引。

還以讀報紙為例，我們想關註英雄聯盟 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。

所以這裡我們重點分析哪一個更好？它們有什麼不同？你應該使用哪一個？

歷史比較

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 都在快速發展，所以，話不多說，先來看下它們的差異清單：

瞭解更多：http://solr-vs-elasticsearch.com/

綜合比較

另外，我們再從以下幾個方面來分析下：

①近幾年的流行趨勢

我們檢視一下這兩種產品的 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 那麼多。

總之，兩者都是功能豐富的搜尋引擎，只要設計和實現得當，它們或多或少都能提供相同的效能。