前言
最近項(xiàng)目組安排了一個任務(wù)铲汪，項(xiàng)目中用到了基于 Solr 的全文搜索，但是該 Solr 搜索云項(xiàng)目不穩(wěn)定罐柳，經(jīng)常查詢不出來數(shù)據(jù)掌腰，需要手動全量同步。
而且它還是其他團(tuán)隊(duì)在維護(hù)张吉，依賴性太強(qiáng)齿梁，導(dǎo)致 Solr 服務(wù)一出問題，我們的項(xiàng)目也基本癱瘓，因?yàn)樗械囊蕾嚥樵兌紵o結(jié)果數(shù)據(jù)了勺择。
所以考慮開發(fā)一個適配層创南，如果 Solr 搜索出問題，自動切換到新的搜索 ES酵幕。其實(shí)可以通過 Solr 集群或者服務(wù)容錯等設(shè)計(jì)來解決該問題扰藕。
但是先不考慮本身設(shè)計(jì)的合理性，領(lǐng)導(dǎo)需要開發(fā)芳撒，所以我開始踏上了搭建 ES 服務(wù)的道路邓深，從零開始，因?yàn)橹巴耆珱]接觸過 ES笔刹，所以通過本系列來記錄下自己的開發(fā)過程芥备。
本篇文章的總體內(nèi)容大致如下圖：
由 ReyCG 精心繪制并提供
什么是全文搜索引擎？
百度百科中的定義：
全文搜索引擎是目前廣泛應(yīng)用的主流搜索引擎舌菜。它的工作原理是計(jì)算機(jī)索引程序通過掃描文章中的每一個詞萌壳，對每一個詞建立一個索引，指明該詞在文章中出現(xiàn)的次數(shù)和位置日月，當(dāng)用戶查詢時袱瓮，檢索程序就根據(jù)事先建立的索引進(jìn)行查找，并將查找的結(jié)果反饋給用戶的檢索方式爱咬。這個過程類似于通過字典中的檢索字表查字的過程尺借。
從定義中我們已經(jīng)可以大致了解全文檢索的思路了，為了更詳細(xì)的說明精拟，我們先從生活中的數(shù)據(jù)說起燎斩。
我們生活中的數(shù)據(jù)總體分為兩種：
結(jié)構(gòu)化數(shù)據(jù)：指具有固定格式或有限長度的數(shù)據(jù)，如數(shù)據(jù)庫蜂绎，元數(shù)據(jù)等栅表。
非結(jié)構(gòu)化數(shù)據(jù)：非結(jié)構(gòu)化數(shù)據(jù)又可稱為全文數(shù)據(jù)，指不定長或無固定格式的數(shù)據(jù)师枣，如郵件怪瓶，Word 文檔等。
當(dāng)然有的地方還會有第三種：半結(jié)構(gòu)化數(shù)據(jù)践美，如 XML洗贰，HTML 等，當(dāng)根據(jù)需要可按結(jié)構(gòu)化數(shù)據(jù)來處理拨脉，也可抽取出純文本按非結(jié)構(gòu)化數(shù)據(jù)來處理哆姻。
根據(jù)兩種數(shù)據(jù)分類，搜索也相應(yīng)的分為兩種：結(jié)構(gòu)化數(shù)據(jù)搜索和非結(jié)構(gòu)化數(shù)據(jù)搜索玫膀。
對于結(jié)構(gòu)化數(shù)據(jù)矛缨，我們一般都是可以通過關(guān)系型數(shù)據(jù)庫(MySQL，Oracle 等)的 table 的方式存儲和搜索，也可以建立索引箕昭。
對于非結(jié)構(gòu)化數(shù)據(jù)灵妨，也即對全文數(shù)據(jù)的搜索主要有兩種方法：
順序掃描
全文檢索
順序掃描：通過文字名稱也可了解到它的大概搜索方式，即按照順序掃描的方式查詢特定的關(guān)鍵字落竹。
例如給你一張報(bào)紙泌霍，讓你找到該報(bào)紙中“RNG”的文字在哪些地方出現(xiàn)過。你肯定需要從頭到尾把報(bào)紙閱讀掃描一遍述召，然后標(biāo)記出關(guān)鍵字在哪些版塊出現(xiàn)過以及它的出現(xiàn)位置朱转。
這種方式無疑是最耗時的最低效的，如果報(bào)紙排版字體小积暖，而且版塊較多甚至有多份報(bào)紙藤为，等你掃描完你的眼睛也差不多了。
全文檢索：對非結(jié)構(gòu)化數(shù)據(jù)順序掃描很慢夺刑，我們是否可以進(jìn)行優(yōu)化缅疟？把我們的非結(jié)構(gòu)化數(shù)據(jù)想辦法弄得有一定結(jié)構(gòu)不就行了嗎？
將非結(jié)構(gòu)化數(shù)據(jù)中的一部分信息提取出來遍愿，重新組織存淫，使其變得有一定結(jié)構(gòu)，然后對此有一定結(jié)構(gòu)的數(shù)據(jù)進(jìn)行搜索沼填，從而達(dá)到搜索相對較快的目的桅咆。
這種方式就構(gòu)成了全文檢索的基本思路。這部分從非結(jié)構(gòu)化數(shù)據(jù)中提取出的然后重新組織的信息倾哺，我們稱之索引轧邪。
還以讀報(bào)紙為例刽脖，我們想關(guān)注英雄聯(lián)盟 S8 全球總決賽的新聞羞海，假如都是 RNG 的粉絲，如何快速找到 RNG 新聞的報(bào)紙和版塊呢曲管？
全文檢索的方式就是却邓，將所有報(bào)紙中所有版塊中關(guān)鍵字進(jìn)行提取，如"EDG"院水，"RNG"腊徙，"FW"，"戰(zhàn)隊(duì)"檬某，"英雄聯(lián)盟"等撬腾。
然后對這些關(guān)鍵字建立索引，通過索引我們就可以對應(yīng)到該關(guān)鍵詞出現(xiàn)的報(bào)紙和版塊恢恼。注意區(qū)別目錄搜索引擎民傻。
為什么要用全文搜索搜索引擎
之前，有同事問我，為什么要用搜索引擎漓踢？我們的所有數(shù)據(jù)在數(shù)據(jù)庫里面都有牵署，而且 Oracle、SQL Server 等數(shù)據(jù)庫里也能提供查詢檢索或者聚類分析功能喧半，直接通過數(shù)據(jù)庫查詢不就可以了嗎奴迅？
確實(shí)，我們大部分的查詢功能都可以通過數(shù)據(jù)庫查詢獲得挺据，如果查詢效率低下取具，還可以通過建數(shù)據(jù)庫索引，優(yōu)化 SQL 等方式提升效率扁耐，甚至通過引入緩存來加快數(shù)據(jù)的返回速度者填。
如果數(shù)據(jù)量更大，就可以分庫分表來分擔(dān)查詢壓力做葵。那為什么還要全文搜索引擎呢占哟？我們主要從以下幾個原因分析：
數(shù)據(jù)類型
全文索引搜索支持非結(jié)構(gòu)化數(shù)據(jù)的搜索，可以更好地快速搜索大量存在的任何單詞或單詞組的非結(jié)構(gòu)化文本酿矢。
例如 Google榨乎，百度類的網(wǎng)站搜索，它們都是根據(jù)網(wǎng)頁中的關(guān)鍵字生成索引瘫筐，我們在搜索的時候輸入關(guān)鍵字蜜暑，它們會將該關(guān)鍵字即索引匹配到的所有網(wǎng)頁返回；還有常見的項(xiàng)目中應(yīng)用日志的搜索等等策肝。
對于這些非結(jié)構(gòu)化的數(shù)據(jù)文本肛捍，關(guān)系型數(shù)據(jù)庫搜索不是能很好的支持。
索引的維護(hù)
一般傳統(tǒng)數(shù)據(jù)庫之众，全文檢索都實(shí)現(xiàn)的很雞肋拙毫，因?yàn)橐话阋矝]人用數(shù)據(jù)庫存文本字段。
進(jìn)行全文檢索需要掃描整個表棺禾，如果數(shù)據(jù)量大的話即使對 SQL 的語法優(yōu)化缀蹄，也收效甚微。
建立了索引膘婶，但是維護(hù)起來也很麻煩缺前，對于 insert 和 update 操作都會重新構(gòu)建索引。
什么時候使用全文搜索引擎：
搜索的數(shù)據(jù)對象是大量的非結(jié)構(gòu)化的文本數(shù)據(jù)悬襟。
文件記錄量達(dá)到數(shù)十萬或數(shù)百萬個甚至更多衅码。
支持大量基于交互式文本的查詢。
需要非常靈活的全文搜索查詢脊岳。
對高度相關(guān)的搜索結(jié)果有特殊需求逝段，但是沒有可用的關(guān)系數(shù)據(jù)庫可以滿足筛璧。
對不同記錄類型、非文本數(shù)據(jù)操作或安全事務(wù)處理的需求相對較少的情況惹恃。
Lucene夭谤，Solr，ElasticSearch 巫糙？
現(xiàn)在主流的搜索引擎大概就是：Lucene朗儒，Solr，ElasticSearch参淹。
它們的索引建立都是根據(jù)倒排索引的方式生成索引醉锄，何謂倒排索引？
維基百科：倒排索引（英語：Inverted index）浙值，也常被稱為反向索引恳不、置入檔案或反向檔案，是一種索引方法开呐，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射烟勋。它是文檔檢索系統(tǒng)中最常用的數(shù)據(jù)結(jié)構(gòu)。
Lucene
Lucene 是一個 Java 全文搜索引擎筐付，完全用 Java 編寫卵惦。Lucene 不是一個完整的應(yīng)用程序，而是一個代碼庫和 API瓦戚，可以很容易地用于向應(yīng)用程序添加搜索功能沮尿。Lucene 通過簡單的 API 提供強(qiáng)大的功能：
可擴(kuò)展的高性能索引：
在現(xiàn)代硬件上超過 150GB /小時。
小 RAM 要求较解，只有 1MB 堆畜疾。
增量索引與批量索引一樣快。
索引大小約為索引文本大小的 20-30％印衔。
強(qiáng)大啡捶，準(zhǔn)確，高效的搜索算法：
排名搜索：首先返回最佳結(jié)果当编。
許多強(qiáng)大的查詢類型：短語查詢届慈，通配符查詢徒溪，鄰近查詢忿偷，范圍查詢等。
現(xiàn)場搜索（例如標(biāo)題臊泌，作者鲤桥，內(nèi)容）。
按任何字段排序渠概。
使用合并結(jié)果進(jìn)行多索引搜索茶凳。
允許同時更新和搜索嫂拴。
靈活的分面，突出顯示贮喧，連接和結(jié)果分組筒狠。
快速，內(nèi)存效率和錯誤容忍的建議箱沦。
可插拔排名模型辩恼，包括矢量空間模型和 Okapi BM25。
可配置存儲引擎（編解碼器）谓形。
跨平臺解決方案：
作為 Apache 許可下的開源軟件提供 灶伊，允許您在商業(yè)和開源程序中使用 Lucene。
100％-pure Java寒跳。
可用的其他編程語言中的實(shí)現(xiàn)是索引兼容的聘萨。
Apache 軟件基金會：
獲得 Apache 軟件基金會提供的開源軟件項(xiàng)目的 Apache 社區(qū)的支持。
但是 Lucene 只是一個框架童太，要充分利用它的功能米辐，需要使用 Java，并且在程序中集成 Lucene书释。需要很多的學(xué)習(xí)了解儡循，才能明白它是如何運(yùn)行的，熟練運(yùn)用 Lucene 確實(shí)非常復(fù)雜征冷。
Solr
Apache Solr 是一個基于名為 Lucene 的 Java 庫構(gòu)建的開源搜索平臺择膝。它以用戶友好的方式提供 Apache Lucene 的搜索功能。
作為一個行業(yè)參與者已近十年检激，它是一個成熟的產(chǎn)品肴捉，擁有強(qiáng)大而廣泛的用戶社區(qū)。
它提供分布式索引叔收，復(fù)制齿穗，負(fù)載平衡查詢以及自動故障轉(zhuǎn)移和恢復(fù)。如果它被正確部署然后管理得好饺律，它就能夠成為一個高度可靠窃页，可擴(kuò)展且容錯的搜索引擎。
很多互聯(lián)網(wǎng)巨頭复濒，如 Netflix脖卖，eBay，Instagram 和亞馬遜（CloudSearch）都使用 Solr巧颈，因?yàn)樗軌蛩饕退阉鞫鄠€站點(diǎn)畦木。
主要功能列表包括：
全文搜索
突出
分面搜索
實(shí)時索引
動態(tài)群集
數(shù)據(jù)庫集成
NoSQL 功能和豐富的文檔處理（例如 Word 和 PDF 文件）
ElasticSearch
Elasticsearch 是一個開源（Apache 2 許可證），基于 Apache Lucene 庫構(gòu)建的 RESTful 搜索引擎砸泛。
Elasticsearch 是在 Solr 之后幾年推出的十籍。它提供了一個分布式蛆封，多租戶能力的全文搜索引擎，具有 HTTP Web 界面（REST）和無架構(gòu) JSON 文檔勾栗。
Elasticsearch 的官方客戶端庫提供 Java惨篱，Groovy，PHP围俘，Ruby妒蛇，Perl，Python楷拳，.NET 和 Javascript绣夺。
分布式搜索引擎包括可以劃分為分片的索引，并且每個分片可以具有多個副本欢揖。
每個 Elasticsearch 節(jié)點(diǎn)都可以有一個或多個分片陶耍，其引擎也可以充當(dāng)協(xié)調(diào)器，將操作委派給正確的分片她混。
Elasticsearch 可通過近實(shí)時搜索進(jìn)行擴(kuò)展。其主要功能之一是多租戶坤按。主要功能列表包括：
分布式搜索
多租戶
分析搜索
分組和聚合
Elasticsearch vs Solr 的選擇
由于 Lucene 的復(fù)雜性，一般很少會考慮它作為搜索的第一選擇臭脓，排除一些公司需要自研搜索框架，底層需要依賴 Lucene来累。
所以這里我們重點(diǎn)分析哪一個更好？它們有什么不同嘹锁？你應(yīng)該使用哪一個葫录？
歷史比較
Apache Solr 是一個成熟的項(xiàng)目领猾，擁有龐大而活躍的開發(fā)和用戶社區(qū)，以及 Apache 品牌摔竿。
Solr 于 2006 年首次發(fā)布到開源，長期以來一直占據(jù)著搜索引擎領(lǐng)域但金，并且是任何需要搜索功能的人的首選引擎。
它的成熟轉(zhuǎn)化為豐富的功能冷溃，而不僅僅是簡單的文本索引和搜索； 如分面梦裂，分組似枕，強(qiáng)大的過濾，可插入的文檔處理年柠，可插入的搜索鏈組件凿歼，語言檢測等。
Solr 在搜索領(lǐng)域占據(jù)了多年的主導(dǎo)地位冗恨。然后答憔，在 2010 年左右，Elasticsearch 成為市場上的另一種選擇掀抹。
那時候虐拓，它遠(yuǎn)沒有 Solr 那么穩(wěn)定，沒有 Solr 的功能深度傲武，沒有思想分享蓉驹，品牌等等。
Elasticsearch 雖然很年輕揪利，但它也自己的一些優(yōu)勢态兴，Elasticsearch 建立在更現(xiàn)代的原則上，針對更現(xiàn)代的用例疟位，并且是為了更容易處理大型索引和高查詢率而構(gòu)建的瞻润。
此外，由于它太年輕甜刻，沒有社區(qū)可以合作敢订，它可以自由地向前推進(jìn)，而不需要與其他人（用戶或開發(fā)人員）達(dá)成任何共識或合作罢吃，向后兼容楚午，或任何其他更成熟的軟件通常必須處理。
因此尿招，它在 Solr 之前就公開了一些非常受歡迎的功能(例如矾柜，接近實(shí)時搜索，英文：Near Real-Time Search)就谜。
從技術(shù)上講怪蔑，NRT 搜索的能力確實(shí)來自 Lucene，它是 Solr 和 Elasticsearch 使用的基礎(chǔ)搜索庫丧荐。
具有諷刺意味的是缆瓣，因?yàn)?Elasticsearch 首先公開了 NRT 搜索，所以人們將 NRT 搜索與 Elasticsearch 聯(lián)系在一起弓坞。
盡管 Solr 和 Lucene 都是同一個 Apache 項(xiàng)目的一部分，但是戚扳，人們會首先期望 Solr 具有如此高要求的功能帽借。
特征差異比較
這兩個搜索引擎都是流行的砍艾，先進(jìn)的的開源搜索引擎脆荷。它們都是圍繞核心底層搜索庫 Lucene 構(gòu)建的简烘，但它們又是不同的定枷。
像所有東西一樣欠窒，每個都有其優(yōu)點(diǎn)和缺點(diǎn)岖妄，根據(jù)您的需求和期望荐虐，每個都可能更好或更差。
Solr 和 Elasticsearch 都在快速發(fā)展腕铸，所以狠裹，話不多說涛菠，先來看下它們的差異清單：
了解更多：http://solr-vs-elasticsearch.com/
綜合比較
另外礁叔，我們再從以下幾個方面來分析下：
①近幾年的流行趨勢
我們查看一下這兩種產(chǎn)品的 Google 搜索趨勢言疗。谷歌趨勢表明噪奄，與 Solr 相比勤篮，Elasticsearch 具有很大的吸引力碰缔，但這并不意味著 Apache Solr 已經(jīng)死亡戳护。
雖然有些人可能不這么認(rèn)為腌且，但 Solr 仍然是最受歡迎的搜索引擎之一铺董，擁有強(qiáng)大的社區(qū)和開源支持。
②安裝和配置
與 Solr 相比，Elasticsearch 易于安裝且非常輕巧重付。此外确垫，您可以在幾分鐘內(nèi)安裝并運(yùn)行 Elasticsearch。
但是恨豁，如果 Elasticsearch 管理不當(dāng)橘蜜，這種易于部署和使用可能會成為一個問題计福。
基于 JSON 的配置很簡單象颖，但如果要為文件中的每個配置指定注釋说订，那么它不適合您。
總的來說钙姊，如果您的應(yīng)用使用的是 JSON煞额，那么 Elasticsearch 是一個更好的選擇膊毁。
否則婚温，請使用 Solr缭召，因?yàn)樗?schema.xml 和 solrconfig.xml 都有很好的文檔記錄逆日。
③社區(qū)
Solr 擁有更大室抽，更成熟的用戶坪圾，開發(fā)者和貢獻(xiàn)者社區(qū)。ES 雖擁有的規(guī)模較小但活躍的用戶社區(qū)以及不斷增長的貢獻(xiàn)者社區(qū)漓概。
Solr 是真正的開源社區(qū)代表胃珍。任何人都可以為 Solr 做出貢獻(xiàn)，并且根據(jù)優(yōu)點(diǎn)選出新的 Solr 開發(fā)人員（也稱為提交者）吩蔑。
Elasticsearch 在技術(shù)上是開源的烛芬，但在精神上卻不那么重要赘娄。任何人都可以看到來源擅憔，任何人都可以更改它并提供貢獻(xiàn)檐晕，但只有 Elasticsearch 的員工才能真正對 Elasticsearch 進(jìn)行更改辟灰。
Solr 貢獻(xiàn)者和提交者來自許多不同的組織芥喇，而 Elasticsearch 提交者來自單個公司继控。
④成熟度
Solr 更成熟武通，但 ES 增長迅速珊搀，我認(rèn)為它穩(wěn)定境析。
⑤文檔
Solr 在這里得分很高劳淆。它是一個非常有據(jù)可查的產(chǎn)品，具有清晰的示例和 API 用例場景括勺。
Elasticsearch 的文檔組織良好朝刊，但它缺乏好的示例和清晰的配置說明。
總結(jié)
那么冯挎，到底是選擇 Solr 還是 Elasticsearch咙鞍？有時很難找到明確的答案续滋。無論您選擇 Solr 還是 Elasticsearch疲酌，首先需要了解正確的用例和未來需求朗恳，總結(jié)它們的每個屬性。
記住下面這些要點(diǎn)：
由于易于使用油航，Elasticsearch 在新開發(fā)者中更受歡迎谊囚。但是执赡，如果您已經(jīng)習(xí)慣了與 Solr 合作搀玖，請繼續(xù)使用它灌诅，因?yàn)檫w移到 Elasticsearch 沒有特定的優(yōu)勢。
如果除了搜索文本之外還需要它來處理分析查詢即舌，Elasticsearch 是更好的選擇顽聂。
如果需要分布式索引肥惭，則需要選擇 Elasticsearch蜜葱。對于需要良好可伸縮性和性能的云和分布式環(huán)境牵囤，Elasticsearch 是更好的選擇揭鳞。
兩者都有良好的商業(yè)支持（咨詢野崇，生產(chǎn)支持乓梨，整合等）径荔。
兩者都有很好的操作工具，盡管 Elasticsearch 因其易于使用的 API 而更多地吸引了 DevOps 人群，因此可以圍繞它創(chuàng)建一個更加生動的工具生態(tài)系統(tǒng)鹦马。
Elasticsearch 在開源日志管理用例中占據(jù)主導(dǎo)地位荸频，許多組織在 Elasticsearch 中索引它們的日志以使其可搜索客冈。雖然 Solr 現(xiàn)在也可以用于此目的场仲，但它只是錯過了這一想法渠缕。
Solr 仍然更加面向文本搜索。另一方面馍忽，Elasticsearch 通常用于過濾和分組，分析查詢工作負(fù)載坝冕，而不一定是文本搜索徽诲。Elasticsearch 開發(fā)人員在 Lucene 和 Elasticsearch 級別上投入了大量精力使此類查詢更高效(降低內(nèi)存占用和 CPU 使用)谎替。因此钱贯，對于不僅需要進(jìn)行文本搜索秩命，而且需要復(fù)雜的搜索時間聚合的應(yīng)用程序褒傅，Elasticsearch 是一個更好的選擇殿托。
Elasticsearch 更容易上手，一個下載和一個命令就可以啟動一切旋廷。Solr 傳統(tǒng)上需要更多的工作和知識礼搁，但 Solr 最近在消除這一點(diǎn)上取得了巨大的進(jìn)步馒吴，現(xiàn)在只需努力改變它的聲譽(yù)。
在性能方面豪治，它們大致相同鬼吵。我說“大致”，因?yàn)闆]有人做過全面和無偏見的基準(zhǔn)測試决摧。對于 95％ 的用例，任何一種選擇在性能方面都會很好矾麻，剩下的 5％ 需要用它們的特定數(shù)據(jù)和特定的訪問模式來測試這兩種解決方案芭梯。
從操作上講甩牺，Elasticsearch 使用起來比較簡單累奈，它只有一個進(jìn)程澎媒。Solr 在其類似 Elasticsearch 的完全分布式部署模式 SolrCloud 中依賴于 Apache ZooKeeper戒努，ZooKeeper 是超級成熟柏卤，超級廣泛使用等等缘缚，但它仍然是另一個活躍的部分桥滨。也就是說齐媒，如果您使用的是 Hadoop喻括，HBase贫奠，Spark，Kafka 或其他一些較新的分布式軟件脖律，您可能已經(jīng)在組織的某個地方運(yùn)行 ZooKeeper小泉。
雖然 Elasticsearch 內(nèi)置了類似 ZooKeeper 的組件 Xen微姊，但 ZooKeeper 可以更好地防止有時在 Elasticsearch 集群中出現(xiàn)的可怕的裂腦問題兢交。公平地說魁淳，Elasticsearch 開發(fā)人員已經(jīng)意識到這個問題界逛，并致力于改進(jìn) Elasticsearch 的這個方面息拜。
如果您喜歡監(jiān)控和指標(biāo)少欺，那么使用 Elasticsearch赞别，您將會進(jìn)入天堂仿滔。這個東西比新年前夜在時代廣場可以擠壓的人有更多的指標(biāo)崎页！Solr 暴露了關(guān)鍵指標(biāo)飒焦，但遠(yuǎn)不及 Elasticsearch 那么多翁巍。
