加個(gè)“星標”，不忘簽到哦
來(lái)源：http://t.cn/Ebgm7sn
最近項目組安排了一個(gè)任務(wù)，項目中用到了全文搜索，基于全文搜索 Solr，但是該 Solr 搜索云項目不穩定，經(jīng)常查詢(xún)不出來(lái)數據，需要手動(dòng)全量同步，而且是其他團隊在維護，依賴(lài)性太強，導致 Solr 服務(wù)一出問(wèn)題，我們的項目也基本癱瘓，因為所有的依賴(lài)查詢(xún)都無(wú)結果數據了。所以考慮開(kāi)發(fā)一個(gè)適配層，如果 Solr 搜索出問(wèn)題，自動(dòng)切換到新的搜索--ES。
其實(shí)可以通過(guò) Solr 集群或者服務(wù)容錯等設計來(lái)解決該問(wèn)題。但是先不考慮本身設計的合理性，領(lǐng)導需要開(kāi)發(fā)，所以我開(kāi)始踏上了搭建 ES 服務(wù)的道路，從零開(kāi)始，因為之前完全沒(méi)接觸過(guò) ES，所以通過(guò)本系列來(lái)記錄下自己的開(kāi)發(fā)過(guò)程。
1. 什么是全文搜索
什么是全文搜索引擎？
百度百科中的定義：全文搜索引擎是目前廣泛應用的主流搜索引擎。它的工作原理是計算機索引程序通過(guò)掃描文章中的每一個(gè)詞，對每一個(gè)詞建立一個(gè)索引，指明該詞在文章中出現的次數和位置，當用戶(hù)查詢(xún)時(shí)，檢索程序就根據事先建立的索引進(jìn)行查找，并將查找的結果反饋給用戶(hù)的檢索方式。這個(gè)過(guò)程類(lèi)似于通過(guò)字典中的檢索字表查字的過(guò)程。
從定義中我們已經(jīng)可以大致了解全文檢索的思路了，為了更詳細的說(shuō)明，我們先從生活中的數據說(shuō)起。
我們生活中的數據總體分為兩種：結構化數據 和 非結構化數據。
結構化數據： 指具有固定格式或有限長(cháng)度的數據，如數據庫，元數據等。
非結構化數據： 非結構化數據又可稱(chēng)為全文數據，指不定長(cháng)或無(wú)固定格式的數據，如郵件，word文檔等。
當然有的地方還會(huì )有第三種：半結構化數據，如XML，HTML等，當根據需要可按結構化數據來(lái)處理，也可抽取出純文本按非結構化數據來(lái)處理。
根據兩種數據分類(lèi)，搜索也相應的分為兩種：結構化數據搜索和非結構化數據搜索。
對于結構化數據，我們一般都是可以通過(guò)關(guān)系型數據庫(mysql，oracle等)的 table 的方式存儲和搜索，也可以建立索引。對于非結構化數據，也即對全文數據的搜索主要有兩種方法：順序掃描法，全文檢索。
順序掃描：通過(guò)文字名稱(chēng)也可了解到它的大概搜索方式，即按照順序掃描的方式查詢(xún)特定的關(guān)鍵字。例如給你一張報紙，讓你找到該報紙中“RNG”的文字在哪些地方出現過(guò)。你肯定需要從頭到尾把報紙閱讀掃描一遍然后標記出關(guān)鍵字在哪些版塊出現過(guò)以及它的出現位置。
這種方式無(wú)疑是最耗時(shí)的最低效的，如果報紙排版字體小，而且版塊較多甚至有多份報紙，等你掃描完你的眼睛也差不多了。
全文搜索：對非結構化數據順序掃描很慢，我們是否可以進(jìn)行優(yōu)化？把我們的非結構化數據想辦法弄得有一定結構不就行了嗎？將非結構化數據中的一部分信息提取出來(lái)，重新組織，使其變得有一定結構，然后對此有一定結構的數據進(jìn)行搜索，從而達到搜索相對較快的目的。這種方式就構成了全文檢索的基本思路。這部分從非結構化數據中提取出的然后重新組織的信息，我們稱(chēng)之索引。
還以讀報紙為例，我們想關(guān)注最近英雄聯(lián)盟S8全球總決賽的新聞，假如都是 RNG 的粉絲，如何快速找到 RNG 新聞的報紙和版塊呢？全文搜索的方式就是，將所有報紙中所有版塊中關(guān)鍵字進(jìn)行提取，如'EDG'，'RNG'，'FW'，'戰隊'，'英雄聯(lián)盟'等。然后對這些關(guān)鍵字建立索引，通過(guò)索引我們就可以對應到該關(guān)鍵詞出現的報紙和版塊。注意區別目錄搜索引擎。
2. 為什么要用全文搜索搜索引擎
之前，有同事問(wèn)我，為什么要用搜索引擎？我們的所有數據在數據庫里面都有，而且 Oracle、SQL Server 等數據庫里也能提供查詢(xún)檢索或者聚類(lèi)分析功能，直接通過(guò)數據庫查詢(xún)不就可以了嗎？確實(shí)，我們大部分的查詢(xún)功能都可以通過(guò)數據庫查詢(xún)獲得，如果查詢(xún)效率低下，還可以通過(guò)建數據庫索引，優(yōu)化SQL等方式進(jìn)行提升效率，甚至通過(guò)引入緩存來(lái)加快數據的返回速度。如果數據量更大，就可以分庫分表來(lái)分擔查詢(xún)壓力。
那為什么還要全文搜索引擎呢？我們主要從以下幾個(gè)原因分析：
數據類(lèi)型 全文索引搜索支持非結構化數據的搜索，可以更好地快速搜索大量存在的任何單詞或單詞組的非結構化文本。 例如 Google，百度類(lèi)的網(wǎng)站搜索，它們都是根據網(wǎng)頁(yè)中的關(guān)鍵字生成索引，我們在搜索的時(shí)候輸入關(guān)鍵字，它們會(huì )將該關(guān)鍵字即索引匹配到的所有網(wǎng)頁(yè)返回；還有常見(jiàn)的項目中應用日志的搜索等等。對于這些非結構化的數據文本，關(guān)系型數據庫搜索不是能很好的支持。
索引的維護 一般傳統數據庫，全文檢索都實(shí)現的很雞肋，因為一般也沒(méi)人用數據庫存文本字段。進(jìn)行全文檢索需要掃描整個(gè)表，如果數據量大的話(huà)即使對SQL的語(yǔ)法優(yōu)化，也收效甚微。建立了索引，但是維護起來(lái)也很麻煩，對于 insert 和 update 操作都會(huì )重新構建索引。
什么時(shí)候使用全文搜索引擎：
搜索的數據對象是大量的非結構化的文本數據。
文件記錄量達到數十萬(wàn)或數百萬(wàn)個(gè)甚至更多。
支持大量基于交互式文本的查詢(xún)。
需求非常靈活的全文搜索查詢(xún)。
對高度相關(guān)的搜索結果的有特殊需求，但是沒(méi)有可用的關(guān)系數據庫可以滿(mǎn)足。
對不同記錄類(lèi)型、非文本數據操作或安全事務(wù)處理的需求相對較少的情況。
3. Lucene，Solr， ElasticSearch ？
現在主流的搜索引擎大概就是：Lucene，Solr，ElasticSearch。
它們的索引建立都是根據倒排索引的方式生成索引，何謂倒排索引？
維基百科倒排索引（英語(yǔ)：Inverted index），也常被稱(chēng)為反向索引、置入檔案或反向檔案，是一種索引方法，被用來(lái)存儲在全文搜索下某個(gè)單詞在一個(gè)文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最常用的數據結構。
3-1 Lucene
Lucene是一個(gè)Java全文搜索引擎，完全用Java編寫(xiě)。Lucene不是一個(gè)完整的應用程序，而是一個(gè)代碼庫和API，可以很容易地用于向應用程序添加搜索功能。
Lucene通過(guò)簡(jiǎn)單的API提供強大的功能：
可擴展的高性能索引
在現代硬件上超過(guò)150GB /小時(shí)
小RAM要求 - 只有1MB堆
增量索引與批量索引一樣快
索引大小約為索引文本大小的20-30％
強大，準確，高效的搜索算法
排名搜索 - 首先返回最佳結果
許多強大的查詢(xún)類(lèi)型：短語(yǔ)查詢(xún)，通配符查詢(xún)，鄰近查詢(xún)，范圍查詢(xún)等
現場(chǎng)搜索（例如標題，作者，內容）
按任何字段排序
使用合并結果進(jìn)行多索引搜索
允許同時(shí)更新和搜索
靈活的分面，突出顯示，連接和結果分組
快速，內存效率和錯誤容忍的建議
可插拔排名模型，包括矢量空間模型和Okapi BM25
可配置存儲引擎（編解碼器）
跨平臺解決方案
作為Apache許可下的開(kāi)源軟件提供 ，允許您在商業(yè)和開(kāi)源程序中使用Lucene
100％-pure Java
可用的其他編程語(yǔ)言中的實(shí)現是索引兼容的
Apache軟件基金會(huì )在A(yíng)pache軟件基金會(huì )提供的開(kāi)源軟件項目的Apache社區的支持。
但是Lucene只是一個(gè)框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的學(xué)習了解，才能明白它是如何運行的，熟練運用Lucene確實(shí)非常復雜。
3-2 Solr
Apache Solr是一個(gè)基于名為L(cháng)ucene的Java庫構建的開(kāi)源搜索平臺。它以用戶(hù)友好的方式提供Apache Lucene的搜索功能。作為一個(gè)行業(yè)參與者近十年，它是一個(gè)成熟的產(chǎn)品，擁有強大而廣泛的用戶(hù)社區。它提供分布式索引，復制，負載平衡查詢(xún)以及自動(dòng)故障轉移和恢復。如果它被正確部署然后管理得好，它就能夠成為一個(gè)高度可靠，可擴展且容錯的搜索引擎。很多互聯(lián)網(wǎng)巨頭，如Netflix，eBay，Instagram和亞馬遜（CloudSearch）都使用Solr，因為它能夠索引和搜索多個(gè)站點(diǎn)。
主要功能列表包括：
全文搜索
突出
分面搜索
實(shí)時(shí)索引
動(dòng)態(tài)群集
數據庫集成
NoSQL功能和豐富的文檔處理（例如Word和PDF文件）
3-3 ElasticSearch
Elasticsearch是一個(gè)開(kāi)源（Apache 2許可證），是一個(gè)基于A(yíng)pache Lucene庫構建的RESTful搜索引擎。
Elasticsearch是在Solr之后幾年推出的。它提供了一個(gè)分布式，多租戶(hù)能力的全文搜索引擎，具有HTTP Web界面（REST）和無(wú)架構JSON文檔。Elasticsearch的官方客戶(hù)端庫提供Java，Groovy，PHP，Ruby，Perl，Python，.NET和Javascript。
分布式搜索引擎包括可以劃分為分片的索引，并且每個(gè)分片可以具有多個(gè)副本。每個(gè)Elasticsearch節點(diǎn)都可以有一個(gè)或多個(gè)分片，其引擎也可以充當協(xié)調器，將操作委派給正確的分片。
Elasticsearch可通過(guò)近實(shí)時(shí)搜索進(jìn)行擴展。其主要功能之一是多租戶(hù)。
主要功能列表包括：
分布式搜索
多租戶(hù)
分析搜索
分組和聚合
4 Elasticsearch vs. Solr的選擇
由于Lucene的復雜性，一般很少會(huì )考慮它作為搜索的第一選擇，排除一些公司需要自研搜索框架，底層需要依賴(lài)Lucene。所以這里我們重點(diǎn)分析 Elasticsearch 和 Solr。
Elasticsearch vs. Solr。哪一個(gè)更好？他們有什么不同？你應該使用哪一個(gè)？
4-1 歷史比較
Apache Solr是一個(gè)成熟的項目，擁有龐大而活躍的開(kāi)發(fā)和用戶(hù)社區，以及Apache品牌。Solr于2006年首次發(fā)布到開(kāi)源，長(cháng)期以來(lái)一直占據著(zhù)搜索引擎領(lǐng)域，并且是任何需要搜索功能的人的首選引擎。它的成熟轉化為豐富的功能，而不僅僅是簡(jiǎn)單的文本索引和搜索； 如分面，分組，強大的過(guò)濾，可插入的文檔處理，可插入的搜索鏈組件，語(yǔ)言檢測等。
Solr 在搜索領(lǐng)域占據了多年的主導地位。然后，在2010年左右，Elasticsearch成為市場(chǎng)上的另一種選擇。那時(shí)候，它遠沒(méi)有Solr那么穩定，沒(méi)有Solr的功能深度，沒(méi)有思想分享，品牌等等。
Elasticsearch雖然很年輕，但它也自己的一些優(yōu)勢，Elasticsearch 建立在更現代的原則上，針對更現代的用例，并且是為了更容易處理大型索引和高查詢(xún)率而構建的。此外，由于它太年輕，沒(méi)有社區可以合作，它可以自由地向前推進(jìn)，而不需要與其他人（用戶(hù)或開(kāi)發(fā)人員）達成任何共識或合作，向后兼容，或任何其他更成熟的軟件通常必須處理。
因此，它在Solr之前就公開(kāi)了一些非常受歡迎的功能(例如，接近實(shí)時(shí)搜索，英文：Near Real-Time Search)。從技術(shù)上講，NRT搜索的能力確實(shí)來(lái)自L(fǎng)ucene，它是 Solr 和 Elasticsearch 使用的基礎搜索庫。具有諷刺意味的是，因為 Elasticsearch 首先公開(kāi)了NRT搜索，所以人們將NRT搜索與Elasticsearch 聯(lián)系在一起，盡管 Solr 和 Lucene 都是同一個(gè) Apache 項目的一部分，因此，人們會(huì )首先期望 Solr 具有如此高要求的功能。
4-2 特征差異比較
這兩個(gè)搜索引擎都是流行的，先進(jìn)的的開(kāi)源搜索引擎。它們都是圍繞核心底層搜索庫 - Lucene構建的 - 但它們又是不同的。像所有東西一樣，每個(gè)都有其優(yōu)點(diǎn)和缺點(diǎn)，根據您的需求和期望，每個(gè)都可能更好或更差。Solr和Elasticsearch都在快速發(fā)展，所以，話(huà)不多說(shuō)，先來(lái)看下它們的差異清單：
特征Solr/SolrCloudElasticsearch
社區和開(kāi)發(fā)者Apache 軟件基金和社區支持單一商業(yè)實(shí)體及其員工
節點(diǎn)發(fā)現Apache Zookeeper，在大量項目中成熟且經(jīng)過(guò)實(shí)戰測試Zen內置于Elasticsearch本身，需要專(zhuān)用的主節點(diǎn)才能進(jìn)行分裂腦保護
碎片放置本質(zhì)上是靜態(tài)，需要手動(dòng)工作來(lái)遷移分片，從Solr 7開(kāi)始 - Autoscaling API允許一些動(dòng)態(tài)操作動(dòng)態(tài)，可以根據群集狀態(tài)按需移動(dòng)分片
高速緩存全局，每個(gè)段更改無(wú)效每段，更適合動(dòng)態(tài)更改數據
分析引擎性能非常適合精確計算的靜態(tài)數據結果的準確性取決于數據放置
全文搜索功能基于Lucene的語(yǔ)言分析，多建議，拼寫(xiě)檢查，豐富的高亮顯示支持基于Lucene的語(yǔ)言分析，單一建議API實(shí)現，高亮顯示重新計算
DevOps支持尚未完全，但即將到來(lái)非常好的API
非平面數據處理嵌套文檔和父-子支持嵌套和對象類(lèi)型的自然支持允許幾乎無(wú)限的嵌套和父-子支持
查詢(xún)DSLJSON（有限），XML（有限）或URL參數JSON
索引/收集領(lǐng)導控制領(lǐng)導者安置控制和領(lǐng)導者重新平衡甚至可以節點(diǎn)上的負載不可能
機器學(xué)習內置 - 在流聚合之上，專(zhuān)注于邏輯回歸和學(xué)習排名貢獻模塊商業(yè)功能，專(zhuān)注于異常和異常值以及時(shí)間序列數據
4-3 綜合比較
另外，我們在從以下幾個(gè)方面來(lái)分析下：
近幾年的流行趨勢 我們查看一下這兩種產(chǎn)品的Google搜索趨勢。谷歌趨勢表明，與 Solr 相比，Elasticsearch具有很大的吸引力，但這并不意味著(zhù)Apache Solr已經(jīng)死亡。雖然有些人可能不這么認為，但Solr仍然是最受歡迎的搜索引擎之一，擁有強大的社區和開(kāi)源支持。
安裝和配置 與Solr相比，Elasticsearch易于安裝且非常輕巧。此外，您可以在幾分鐘內安裝并運行Elasticsearch。 但是，如果Elasticsearch管理不當，這種易于部署和使用可能會(huì )成為一個(gè)問(wèn)題?；贘SON的配置很簡(jiǎn)單，但如果要為文件中的每個(gè)配置指定注釋?zhuān)敲此贿m合您。 總的來(lái)說(shuō)，如果您的應用使用的是JSON，那么Elasticsearch是一個(gè)更好的選擇。否則，請使用Solr，因為它的schema.xml和solrconfig.xml都有很好的文檔記錄。
社區 Solr擁有更大，更成熟的用戶(hù)，開(kāi)發(fā)者和貢獻者社區。ES雖擁有的規模較小但活躍的用戶(hù)社區以及不斷增長(cháng)的貢獻者社區。 Solr是真正的開(kāi)源社區代碼。任何人都可以為Solr做出貢獻，并且根據優(yōu)點(diǎn)選出新的Solr開(kāi)發(fā)人員（也稱(chēng)為提交者）。Elasticsearch在技術(shù)上是開(kāi)源的，但在精神上卻不那么重要。任何人都可以看到來(lái)源，任何人都可以更改它并提供貢獻，但只有Elasticsearch的員工才能真正對Elasticsearch進(jìn)行更改。 Solr貢獻者和提交者來(lái)自許多不同的組織，而Elasticsearch提交者來(lái)自單個(gè)公司。
成熟度 Solr更成熟，但ES增長(cháng)迅速，我認為它穩定。
文檔 Solr在這里得分很高。它是一個(gè)非常有據可查的產(chǎn)品，具有清晰的示例和API用例場(chǎng)景。 Elasticsearch的文檔組織良好，但它缺乏好的示例和清晰的配置說(shuō)明。
5. 總結
那么，到底是Solr還是Elasticsearch？有時(shí)很難找到明確的答案。無(wú)論您選擇Solr還是Elasticsearch，首先需要了解正確的用例和未來(lái)需求?？偨Y他們的每個(gè)屬性。
記?。?div style="height:15px;">
由于易于使用，Elasticsearch在新開(kāi)發(fā)者中更受歡迎。但是，如果您已經(jīng)習慣了與Solr合作，請繼續使用它，因為遷移到Elasticsearch沒(méi)有特定的優(yōu)勢。
兩者都有很好的操作工具，盡管Elasticsearch因其易于使用的API而更多地吸引了DevOps人群，因此可以圍繞它創(chuàng )建一個(gè)更加生動(dòng)的工具生態(tài)系統。
Elasticsearch在開(kāi)源日志管理用例中占據主導地位，許多組織在Elasticsearch中索引它們的日志以使其可搜索。雖然Solr現在也可以用于此目的，但它只是錯過(guò)了這一想法。
Solr仍然更加面向文本搜索。另一方面，Elasticsearch 通常用于過(guò)濾和分組 - 分析查詢(xún)工作負載 - 而不一定是文本搜索。Elasticsearch 開(kāi)發(fā)人員在 Lucene 和 Elasticsearch 級別上投入了大量精力使此類(lèi)查詢(xún)更高效(降低內存占用和CPU使用)。因此，對于不僅需要進(jìn)行文本搜索，而且需要復雜的搜索時(shí)間聚合的應用程序，Elasticsearch是一個(gè)更好的選擇。
Elasticsearch更容易上手，一個(gè)下載和一個(gè)命令就可以啟動(dòng)一切。Solr傳統上需要更多的工作和知識，但Solr最近在消除這一點(diǎn)上取得了巨大的進(jìn)步，現在只需努力改變它的聲譽(yù)。
在性能方面，它們大致相同。我說(shuō)“大致”，因為沒(méi)有人做過(guò)全面和無(wú)偏見(jiàn)的基準測試。對于95％的用例，任何一種選擇在性能方面都會(huì )很好，剩下的5％需要用它們的特定數據和特定的訪(fǎng)問(wèn)模式來(lái)測試這兩種解決方案。
從操作上講，Elasticsearch使用起來(lái)比較簡(jiǎn)單 - 它只有一個(gè)進(jìn)程。Solr在其類(lèi)似Elasticsearch的完全分布式部署模式SolrCloud中依賴(lài)于A(yíng)pache ZooKeeper。ZooKeeper是超級成熟，超級廣泛使用等等，但它仍然是另一個(gè)活躍的部分。也就是說(shuō)，如果您使用的是Hadoop，HBase，Spark，Kafka或其他一些較新的分布式軟件，您可能已經(jīng)在組織的某個(gè)地方運行ZooKeeper。
雖然Elasticsearch內置了類(lèi)似ZooKeeper的組件Xen，但ZooKeeper可以更好地防止有時(shí)在Elasticsearch集群中出現的可怕的裂腦問(wèn)題。公平地說(shuō)，Elasticsearch開(kāi)發(fā)人員已經(jīng)意識到這個(gè)問(wèn)題，并致力于改進(jìn)Elasticsearch的這個(gè)方面。
如果您喜歡監控和指標，那么使用Elasticsearch，您將會(huì )進(jìn)入天堂。這個(gè)東西比新年前夜在時(shí)代廣場(chǎng)可以擠壓的人有更多的指標！Solr暴露了關(guān)鍵指標，但遠不及Elasticsearch那么多。
總之，兩者都是功能豐富的搜索引擎，只要設計和實(shí)現得當，它們或多或少都能提供相同的性能。本篇文章的總體內容大致如下圖，該圖由園友ReyCG精心繪制并提供。
