全文搜索引擎到底選ElasticSearch還是Solr ？
最近項目組安排了一個任務，項目中用到了基于 Solr 的全文搜索，但是該 Solr 搜索云項目不穩定，經常查詢不出來數據，需要手動全量同步。
而且它還是其他團隊在維護，依賴性太強，導致 Solr 服務一出問題，我們的項目也基本癱瘓，因為所有的依賴查詢都無結果數據了。
所以考慮開發一個適配層，如果 Solr 搜索出問題，自動切換到新的搜索 ES。其實可以通過 Solr 集群或者服務容錯等設計來解決該問題。
但是先不考慮本身設計的合理性，領導需要開發，所以我開始踏上了搭建 ES 服務的道路，從零開始，因為之前完全沒接觸過 ES，所以通過本系列來記錄下自己的開發過程。
本篇文章的總體內容大致如下圖：
圖片
由 ReyCG 精心繪制并提供
什么是全文搜索
什么是全文搜索引擎？百度百科中的定義：
全文搜索引擎是目前廣泛應用的主流搜索引擎。它的工作原理是計算機索引程序通過掃描文章中的每一個詞，對每一個詞建立一個索引，指明該詞在文章中出現的次數和位置，當用戶查詢時，檢索程序就根據事先建立的索引進行查找，并將查找的結果反饋給用戶的檢索方式。這個過程類似于通過字典中的檢索字表查字的過程。
從定義中我們已經可以大致了解全文檢索的思路了，為了更詳細的說明，我們先從生活中的數據說起。
我們生活中的數據總體分為兩種：
- 結構化數據：指具有固定格式或有限長度的數據，如數據庫，元數據等。
- 非結構化數據：非結構化數據又可稱為全文數據，指不定長或無固定格式的數據，如郵件，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 那么多。
總之，兩者都是功能豐富的搜索引擎，只要設計和實現得當，它們或多或少都能提供相同的性能。
