1 搜索引擎

1.1 簡介

全文搜索引擎是目前廣泛應(yīng)用的主流搜索引擎。它的工作原理是計(jì)算機(jī)索引程序通過掃描文章中的每一個詞嵌牺，對每一個詞建立一個索引，指明該詞在文章中出現(xiàn)的次數(shù)和位置髓梅，當(dāng)用戶查詢時绎签，檢索程序就根據(jù)事先建立的索引進(jìn)行查找，并將查找的結(jié)果反饋給用戶的檢索方式诡必。這個過程類似于通過字典中的檢索字表查字的過程搔扁。

1.2 結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(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ū)別目錄搜索引擎

1.3 倒排索引

如何理解倒排索引呢殴胧？ 假如現(xiàn)有三份數(shù)據(jù)文檔佩迟，文檔的內(nèi)容如下分別是：

Java is the best programming language.
PHP is the best programming language.
Javascript is the best programming language.

為了創(chuàng)建倒排索引，我們通過分詞器將每個文檔的內(nèi)容域拆分成單獨(dú)的詞（我們稱它為詞條或 Term）报强，創(chuàng)建一個包含所有不重復(fù)詞條的排序列表，然后列出每個詞條出現(xiàn)在哪個文檔秉溉。

結(jié)果如下所示

這種結(jié)構(gòu)由文檔中所有不重復(fù)詞的列表構(gòu)成碗誉，對于其中每個詞都有一個文檔列表與之關(guān)聯(lián)诗充。
這種 由屬性值來確定記錄的位置的結(jié)構(gòu)就是倒排索引。帶有倒排索引的文件我們稱為倒排文件

我們將上面的內(nèi)容轉(zhuǎn)換為圖的形式來說明倒排索引的結(jié)構(gòu)信息蝴蜓，如下圖所示：

image.png

其中主要有如下幾個核心術(shù)語需要理解：

• 詞條（Term）： 索引里面最小的存儲和查詢單元俺猿，對于英文來說是一個單詞，對于中文來說一般指分詞后的一個詞诵冒。
• 詞典（Term Dictionary）： 或字典，是詞條 Term 的集合汽馋。搜索引擎的通常索引單位是單詞圈盔，單詞詞典是由文檔集合中出現(xiàn)過的所有單詞構(gòu)成的字符串集合，單詞詞典內(nèi)每條索引項(xiàng)記載單詞本身的一些信息以及指向倒排列表的指針驱敲。
• 倒排表（Post list）：一個文檔通常由多個詞組成，倒排表記錄的是某個詞在哪些文檔里出現(xiàn)過以及出現(xiàn)的位置众眨。每條記錄稱為一個倒排項(xiàng)（Posting）。倒排表記錄的不僅是文檔編號沿腰，還存儲了詞頻等信息。
• 倒排文件（Inverted File）： 所有單詞的倒排列表往往順序地存儲在磁盤的某個文件里颂龙，這個文件被稱之為倒排文件掸冤，倒排文件是存儲倒排索引的物理文件

詞典和倒排表是 Lucene 中很重要的兩種數(shù)據(jù)結(jié)構(gòu)，是實(shí)現(xiàn)快速檢索的重要基石稿湿。詞典和倒排文件是分兩部分存儲的，詞典在內(nèi)存中而倒排文件存儲在磁盤上

1.4 使用全文搜索引擎條件

什么時候使用全文搜索引擎：

• 搜索的數(shù)據(jù)對象是大量的非結(jié)構(gòu)化的文本數(shù)據(jù)饺藤。
• 文件記錄量達(dá)到數(shù)十萬或數(shù)百萬個甚至更多流礁。
• 支持大量基于交互式文本的查詢神帅。
• 需要非常靈活的全文搜索查詢。
• 對高度相關(guān)的搜索結(jié)果有特殊需求找御，但是沒有可用的關(guān)系數(shù)據(jù)庫可以滿足。
• 對不同記錄類型霎桅、非文本數(shù)據(jù)操作或安全事務(wù)處理的需求相對較少的情況

2 Lucene讨永，Solr，ElasticSearch

現(xiàn)在主流的搜索引擎大概就是：Lucene卿闹，Solr，ElasticSearch锻霎。
它們的索引建立都是根據(jù)倒排索引的方式生成索引
倒排索引（英語：Inverted index），也常被稱為反向索引雇寇、置入檔案或反向檔案，是一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射嫩海。它是文檔檢索系統(tǒng)中最常用的數(shù)據(jù)結(jié)構(gòu)

2.1 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ù)雜

2.2 Solr

Apache Solr是一個基于名為 Lucene 的 Java 庫構(gòu)建的開源搜索平臺逗旁。它以用戶友好的方式提供 Apache Lucene 的搜索功能。它是一個成熟的產(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 文件）

2.3 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ò)展。其主要功能之一是多租戶我磁。主要功能列表包括：

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

2.4 區(qū)別和選擇

2.4.1 如何選擇

由于 Lucene 的復(fù)雜性，一般很少會考慮它作為搜索的第一選擇夺艰，排除一些公司需要自研搜索框架，底層需要依賴 Lucene减牺。
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ǔ)搜索庫脆炎。

盡管 Solr 和 Lucene 都是同一個 Apache 項(xiàng)目的一部分，但是袱蚓，人們會首先期望 Solr 具有如此高要求的功能。

2.4.2 區(qū)別

這兩個搜索引擎都是流行的喇潘，先進(jìn)的的開源搜索引擎。它們都是圍繞核心底層搜索庫 Lucene 構(gòu)建的颖低，但它們又是不同的。
像所有東西一樣忱屑，每個都有其優(yōu)點(diǎn)和缺點(diǎn)，根據(jù)需求和期望莺戒，每個都可能更好或更差。

Solr 和 Elasticsearch 都在快速發(fā)展瘪校，所以，話不多說阱扬，先來看下它們的差異清單：

image.png

2.4.2.1 流行趨勢

我們查看一下這兩種產(chǎn)品的 Google 搜索趨勢伸辟。谷歌趨勢表明，與 Solr 相比自娩，Elasticsearch 具有很大的吸引力，但這并不意味著 Apache Solr 已經(jīng)死亡忙迁。

雖然有些人可能不這么認(rèn)為，但 Solr 仍然是最受歡迎的搜索引擎之一姊扔，擁有強(qiáng)大的社區(qū)和開源支持。

image.png

2.4.2.2 安裝和配置

與 Solr 相比佛南，Elasticsearch 易于安裝且非常輕巧。此外嗅回，可以在幾分鐘內(nèi)安裝并運(yùn)行 Elasticsearch。
但是绵载，如果 Elasticsearch 管理不當(dāng)苛白，這種易于部署和使用可能會成為一個問題。

基于 JSON 的配置很簡單购裙，但如果要為文件中的每個配置指定注釋，那么它不適合躏率。
總的來說民鼓，如果的應(yīng)用使用的是 JSON私股，那么 Elasticsearch 是一個更好的選擇。
否則倡鲸，請使用 Solr黄娘，因?yàn)樗?schema.xml 和 solrconfig.xml 都有很好的文檔記錄。

2.4.2.3 社區(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 提交者來自單個公司浆劲。

2.4.4.4 成熟度

Solr 更成熟，但 ES 增長迅速牌借，穩(wěn)定

2.4.4.5 文檔

Solr 在這里得分很高。它是一個非常有據(jù)可查的產(chǎn)品膨报，具有清晰的示例和 API 用例場景适荣。
Elasticsearch 的文檔組織良好院领，但它缺乏好的示例和清晰的配置說明。

2.4.3 總結(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)步
• 在性能方面，它們大致相同千所。說“大致”，因?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)入天堂。Solr 暴露了關(guān)鍵指標(biāo)栈拖，但遠(yuǎn)不及 Elasticsearch 那么多。

總之涩哟，兩者都是功能豐富的搜索引擎盼玄，只要設(shè)計(jì)和實(shí)現(xiàn)得當(dāng)潜腻，它們或多或少都能提供相同的性

轉(zhuǎn)載于：https://mp.weixin.qq.com/s/_u4b-BFRhP1SDFCN8pJihQ