前面講到了 NoSQL 數(shù)據(jù)庫的應用，在關系型數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫之外，還有一類非常重要的存儲中間件，那就是 文件索引。當你在電商網(wǎng)站搜索商品，或者在搜索引擎搜索資料時，都離不開基于文件索引的各種檢索框架的支持。

這一課時我們就一起來看下以 ElasticSearch 為代表的文件索引相關的知識。

ElasticSearch 簡介

在討論 ElasticSearch 之前，不得不提 Apache Lucene，因為 ElasticSearch 的廣泛應用離不開 Lucene 的支持。

Lucene 是一個開源的全文檢索引擎類庫，支持各種分詞以及搜索相關的實現(xiàn)，可以極大地簡化搜索開發(fā)的成本，但 Lucene 只是一個工具包，在實際項目中進行二次開發(fā)，你需要非常熟悉 Lucene 的實現(xiàn)機制以及 API 應用，這樣才能應用 Lucene 的各種特性。

現(xiàn)在有了 ElasticSearch，就可以直接使用基于 Lucene 的各種檢索功能，ElasticSearch 是一個基于 Lucene 的分布式全文檢索框架，在 Lucene 類庫的基礎上實現(xiàn)，可以避免直接基于 Lucene 開發(fā)，這一點和 Java 中 Netty 對 IO/NIO 的封裝有些類似。

ElasticSearch 開放了一系列的 RESTful API，基于這些 API，可以快捷地實現(xiàn)各種搜索功能。另外一方面，除了搜索相關的功能，ElasticSearch 還對分布式場景下的應用有特別好的支持，包括良好的擴展性，可以擴展到上百臺服務器的集群規(guī)模，以及近似實時分析的索引實現(xiàn)。這些特點，使得 ElasticSearch 在各類搜索場景、大數(shù)據(jù)分析等業(yè)務中廣泛應用。

ElasticSearch 應用

ElasticSearch 對搜索的支持非常好，但是和 NoSQL 數(shù)據(jù)庫一樣，對事務、一致性等的支持較低。

下面是一個實際開發(fā)中，常見的數(shù)據(jù)庫-索引-緩存系統(tǒng)架構圖：

可以看到，ElasticSearch 一般是作為持久性數(shù)據(jù)庫的輔助存儲，是和 SQL & NoSQL 數(shù)據(jù)庫一起使用，對外提供索引查詢功能。關系型數(shù)據(jù)庫保證數(shù)據(jù)更新的準確性，在關系型數(shù)據(jù)庫更新以后，通過 binlog 同步結合消息隊列分發(fā)的方式，來更新文件索引，提供一致性保證。

ELK stack

ElasticSearch 是由 Elastic 公司創(chuàng)建的，除了 ElasticSearch，Elastic 公司還有另外兩款產(chǎn)品，分別是 Logstash 及 Kibana 開源項目，這三個開源項目組合在一起稱為 ELK stack。

在 ELK 技術棧中，ElasticSearch 用于數(shù)據(jù)分析和檢索，Logstash 用于日志收集，Kibana 用于界面的展示，ELK 可以用于快速查詢數(shù)據(jù)并可視化分析，在日志處理、大數(shù)據(jù)等領域有非常廣泛的應用。我在一個項目中曾經(jīng)基于 ELK 部署過日志收集和告警系統(tǒng)，ELK 的文檔和各種問題手冊非常全面，可以說是開箱即用。

索引是如何建立的

ElasticSearch 存儲的單元是 索引，這一點區(qū)別于很多關系型數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫，比如關系型數(shù)據(jù)庫是按照關系表的形式組織數(shù)據(jù)，大部分 NoSQL 數(shù)據(jù)庫是 K-Value 的鍵值對方式。

ElasticSearch 存儲的基本單元是索引，那么索引是如何創(chuàng)建的呢？

ElasticSearch 索引的實現(xiàn)基于 Lucene，使用倒排索引的結構，倒排索引的引入，使得 ElasticSearch 可以非常高效地實現(xiàn)各種文件索引。倒排索引不光是在 ElasticSearch 等組件中應用，它還是百度等搜索引擎實現(xiàn)的底層技術之一。在搜索引擎中，索引的建立需要經(jīng)過網(wǎng)頁爬取、信息采集、分詞、索引創(chuàng)建的過程，不過在 ElasticSearch 內(nèi)部存儲的實現(xiàn)中，數(shù)據(jù)的寫入可以對比搜索引擎對網(wǎng)頁的抓取和信息采集的過程，只需要關注分詞和索引的創(chuàng)建。

分詞和索引

分詞是在索引建立中特別重要的一個環(huán)節(jié)，分詞的策略會直接影響索引結果。Lucene 提供了多種分詞器，分詞器是一個可插拔的組件，包括內(nèi)置的標準分詞器， 也可以引入對中文支持較好的 IKAnalyze 中文分詞器等。

下面我們通過一個例子來了解分詞的具體過程，假設我們在 ElasticSearch 中新增了兩個文檔，每個文檔包含如下內(nèi)容：

• 文檔1，Jerry and Tom are good friends.

• 文檔2，Good friends should help each other.

英文是有單詞的，單詞之間通過空格進行拆分，所以對英文的分詞相對容易，比如上面的內(nèi)容，可以直接對字符串按照空格拆分，得到分詞后的數(shù)組。

Jerry /? ?/ and /? ?/ Tom /? ?/ are /? ?/ good /? ?/ friends / .

Good /? ?/ friends /? ?/ should /? ?/ help /? ?/ each /? ?/ other / .

如果是中文，除了標點符號以外，一個整句是沒有分隔符的，處理起來就會復雜得多。一般來說，中文分詞用得比較多的策略是基于字典的最長字符串匹配方式，這種策略可以覆蓋大多數(shù)場景，不過還是有一小部分天然存在歧義的文檔是無法處理的。比如「學生會組織各種活動」，按照最長串匹配的方式，可以切分成“學生會/組織各種活動”，但實際要表達的可能是“學生/會/組織各種活動”。

現(xiàn)在有一個很火熱的學科叫作自然語言處理，研究的問題就包括如何消除語義分析中的各種歧義問題，感興趣的同學可以去了解下。

建立索引

索引存儲的結構是倒排索引，什么是倒排索引呢？倒排索引是相對于正排索引來說的，倒排索引描述了一個映射關系，包括文檔中分詞后的結果，以及分別包含這些單詞的文檔列表。

索引描述的其實就是關鍵詞和文檔的關系，正排索引就是“文檔—關鍵詞”的格式，倒排索引則相反，是“關鍵詞—文檔”的格式?？梢钥吹?，當需要使用關鍵詞進行檢索時，使用倒排索引才能實現(xiàn)快速檢索的目的。

針對上面的分詞示例，我們簡單起見，統(tǒng)一為小寫，把分詞之后的單詞組成一個不重復的分詞列表，為了更好地進行查找，可以按照字典序排序。

and,are,each,friends,good,help,jerry,other,should,tom

比如，其中“friends”在文檔 1 和文檔 2 中都出現(xiàn)了，“Tom”和“Jerry”只在文檔 1 中出現(xiàn)了 1 次，其他的單詞也進行同樣地處理，于是我們可以構建下面的倒排索引：

分詞文檔列表......friends文檔 1，文檔 2good文檔 1，文檔 2jerry文檔 1，tom文檔 1...以下省略

具體到數(shù)據(jù)結構的實現(xiàn)，可以通過實現(xiàn)一個字典樹，也就是 Trie 樹，對字典樹進行擴展，額外存儲對應的數(shù)據(jù)塊地址，定位到具體的數(shù)據(jù)位置。

對比 B+ 樹

MySQL InnoDB 引擎的索引實現(xiàn)是基于 B+ 樹，那么同樣是索引，倒排索引和 B+ 樹索引有哪些區(qū)別呢？

嚴格地說，這兩類索引是不能在一起比較的，B+ 樹描述的是索引的數(shù)據(jù)結構，而倒排索引是通過索引的組織形式來命名的。比如我們上面的例子中，倒排指的是關鍵詞和文檔列表的結構關系。

對于數(shù)據(jù)庫來說，索引的作用是提高數(shù)據(jù)查詢的性能，考慮到磁盤尋址的特性，選擇了 B+ 樹作為索引的實現(xiàn)結構，可以更好地實現(xiàn)通過主鍵以及通過區(qū)間范圍查找的要求。

對于倒排索引，則是對應具體的應用場景，我們在搜索中是通過一些關鍵詞，定位到具體的文檔。所以倒排索引實現(xiàn)的是根據(jù)關鍵詞，也就是分詞的結果，去查找文檔，或者不同的網(wǎng)頁。

總結

這一課時介紹了 ElasticSearch 存儲組件及其應用，日志分析的三大件之 ELK 技術棧，以及倒排索引是如何實現(xiàn)的。

雖然 ElasticSearch 技術可以實現(xiàn)高效的檢索，但是也帶來了相應的部署以及一致性維護成本，在一些小型項目中，還是會用數(shù)據(jù)庫模糊匹配的方式實現(xiàn)關鍵詞檢索。你可以思考一下，在你負責的項目中，是如何實現(xiàn)關鍵詞檢索的？歡迎留言分享。