ElasticSearch 基本原理之全文检索

一、开篇几个问题

1.大规模数据如何检索？

当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑：

1）用什么数据库好？(MySQL、sybase、Oracle、达梦、神通、MongoDB、Hbase…)

MySQL：通过分库分表可以存海量数据，但是做数据检索效率是达不到毫秒级别，并且数据检索只能支持模糊查询，不支持全文检索、分词检索

以上数据库都可以做海量数据存储，但都不适合做检索的工作。

2）如何解决单点故障；(lvs、F5、A10、Zookeeper、MQ)

集群，要考虑故障转移的问题，就需要借助lvs、F5、A10、Zookeeper来维护配置

MQ，可以做大量数据的缓存队列，例如滴滴，后台存储了大量的数据，数据实时不停的产生，每天产生400T的数据，这么大量的数据必须要有一个缓存队列进行缓存，然后再写入到库里

3）如何保证数据安全性；(热备、冷备、异地多活)

保证数据不会丢失，做备份

4）如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)

分库分表后的检索问题

5）如何解决统计分析问题；(离线、近实时)

以上数据库做数据统计分析都要自己实现

思考如果自己设计可以从哪些方面考虑：

2.传统数据库的应对解决方案？

对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈：

解决要点：

1）通过主从备份解决数据安全性问题；

2）通过数据库代理中间件心跳监测，解决单点故障问题；

3）通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果

4）通过分表分库解决读写效率问题

1.数据库并不适合做海量数据的检索，通常项目实践中不会让并发请求最终落在数据库上，数据库中每个sql本身都代表了锁，因此性能并不是太高，尤其面对海量数据，并发量高的情况

2.同时数据库只能做模糊查询的检索，并不能做全文分词检索

3.非关系型数据库的解决方案？

对于Nosql数据库，以redis为例，其它原理类似， 解决要点：

1）通过副本备份保证数据安全性；

2）通过节点竞选机制解决单点问题；

3）先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

Redis做全文检索是不可能的，本身就是key-value数据结构

并且服务器内存是有限制的，不能无限制存储数据

4.完全把数据放入内存怎么样？

完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：

1PB=1024T=1048576G

节点数=1048576/96=10922个

实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。

全部放在内存速度问题是解决了，但成本问题上来了。

为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法：

1、磁盘存储顺序存储；

2、将数据和索引分离；

3、压缩数据；

4、热点数据放内存

5、多线程

以上5个特点就是ElasticSearch的特点（ElasticSearch对堆内存的要求比较高，一个节点最高占用30G）

二、全文检索技术

1.什么是全文检索？

什么叫做全文检索呢？这要从我们生活中的数据说起。

我们生活中的数据总体分为两种：结构化数据和非结构化数据。

• 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。
• 非结构化数据：指不定长或无固定格式的数据，如 互联网数据、邮件，word文档等。

对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快，那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？这就是全文检索的基本思路，也就是将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引 。

非结构化数据又一种叫法叫全文数据。

按照数据的分类，搜索也分为两种：

• 对结构化数据的搜索： 如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。
• 对非结构化数据的搜索： 如用Google和百度可以搜索大量内容数据。

对非结构化数据也即全文数据的搜索主要有两种方法：顺序扫描法和反向索引法。

• 顺序扫描法：所谓顺序扫描法，就是顺序扫描每个文档内容，看看是否有要搜索的关键字，实现查找文档的功能，也就是根据文档找词。
• 反向索引法：所谓反向索引，就是提前将搜索的关键字建成索引，然后再根据索引查找文档，也就是根据词找文档。

这种先建立

索引

，再对索引进行

搜索

文档的过程就叫

全文检索(Full-text Search)

。

数据库只能做精确匹配，不能分词搜索，并且效率低。

2.全文检索场景

• 搜索引擎（对算法、数据结构要求较高）
• 站内搜索（直接使用ElasticSearch基本可以满足）
• 系统文件搜索

3.全文检索相关技术

1. Lucene：如果使用该技术实现，需要对Lucene的API和底层原理非常了解，而且需要编写大量的Java代码。
2. Solr：使用java实现的一个web应用，可以使用rest方式的http请求，进行远程API的调用。
3. ElasticSearch(ES)：可以使用rest方式的http请求，进行远程API的调用。

Solr和ElasticSearch底层都是基于Lucene

4.Solr和ES的比较

ElasticSearch vs Solr 检索速度

• 当单纯的对已有数据（静态数据，不会发生变化的数据）进行搜索时，Solr更快。

  

• 当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。

  

• 随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

  

• 大型互联网公司，实际生产环境测试，将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。

  

总结：

• 二者安装都很简单；
• Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
• Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
• Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能都由第三方插件提供；
• Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于Elasticsearch。

最终的结论：

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

三、全文检索的流程分析

1.什么是索引

  有人可能会说，对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快（由于结构化数据有一定的结构可以采取一定的搜索算法加快速度），那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？

  这种想法很天然，却构成了全文检索的基本思路，也即将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。

  这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引

  这种说法比较抽象，举几个例子就很容易明白，比如字典，字典的拼音表和部首检字表就相当于字典的索引，对每一个字的解释都是非结构化的，如果字典没有拼音表和部首检字表，在茫茫辞海中找一个字只能顺序扫描。然而字的某些信息可以提取出来进行结构化处理，比如读音，就比较结构化，分声母和韵母，分别只有几种可以 一一列举，于是将读音拿出来按一定的顺序排列，每一项读音都指向此字的详细解释的页数。我们搜索时按结构化的拼音搜到读音，然后按其指向的页数，便可找到 我们的非结构化数据——也即对字的解释

2.流程总览

索引库创建过程

索引库搜索过程

全文检索的流程分为两大流程：索引创建、搜索索引

• 索引创建：将现实世界中所有的结构化和非结构化数据提取信息，创建索引的过程。
• 搜索索引：就是得到用户的查询请求，搜索创建的索引，然后返回结果的过程。

要想搞清楚全文检索，必须要搞清楚下面三个问题：

• 1.索引库里面究竟存些什么？(Index)
• 2.如何创建索引？(Indexing)
• 3.如何对索引进行搜索？(Search)

3.创建索引流程

3.1原始内容

原始内容是指要索引和搜索的内容。

原始内容包括互联网上的网页、数据库中的数据、磁盘上的文件等。

3.2获得文档

也就是采集数据，从互联网上、数据库、文件系统中等获取需要搜索的原始信息，这个过程就是信息采集。

采集数据的目的是为了将原始内容存储到Document对象中。

如何采集数据？

1. 对于互联网上网页，可以使用工具将网页抓取到本地生成html文件。
2. 数据库中的数据，可以直接连接数据库读取表中的数据。
3. 文件系统中的某个文件，可以通过I/O操作读取文件的内容。

在Internet上采集信息的软件通常称为爬虫或蜘蛛，也称为网络机器人，爬虫访问互联网上的每一个网页，将获取到的网页内容存储起来。

3.3创建文档对象

创建文档的目的是统一数据格式（Document），方便文档分析。

说明：

1.一个Document文档中包括多个域(Field)，域(Field)中存储内容。

2.这里我们可以将数据库中一条记录当成一个Document，一列当成一个Field

3.4分析文档(重点)

分析文档主要是对Field域进行分析，分析文档的目的是为了索引。

说明：分析文档主要通过分词组件(Tokenizer)和语言处理组件(Linguistic Processor)完成

3.4.1分词组件

分词组件工作流程（此过程称之为Tokenize）

1. 将Field域中的内容进行分词（不同语言有不同的分词规则）
2. 去除标点符号。
3. 去除停用词（stop word）。

经过分词（Tokenize）之后得到的结果成为

词元（Token）

。

所谓停用词(Stop word)就是一种语言中最普通的一些单词，由于没有特别的意义，因而大多数情况下不能成为搜索的关键词，因而创建索引时，这种词会被去掉而减少索引的大小。

英语中停词(Stop word)如：“the”,“a”，“this”等。

对于每一种语言的分词组件(Tokenizer)，都有一个停词(stop word)集合。

示例(Document1的Field域和Document2的Field域是同名的)：

• Document1的Field域：

  Students should be allowed to go out with their friends, but not allowed to drink beer.

• Document2的Field域：

  My friend Jerry went to school to see his students but found them drunk which is not allowed.

• 在我们的例子中，便得到以下词元(Token)：

  “Students”，“allowed”，“go”，“their”，“friends”，“allowed”，“drink”，“beer”，“My”，“friend”，“Jerry”，“went”，“school”，“see”，“his”，“students”，“found”，“them”，“drunk”，“allowed”。

将得到的词元(Token)传给语言处理组件(Linguistic Processor)

3.4.2语言处理组件

语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些同语言相关的处理。

对于英语，语言处理组件(Linguistic Processor)一般做以下几点：

• 1.变为小写(Lowercase)。
• 2.将单词缩减为词根形式，如“cars”到“car”等。这种操作称为：stemming。
• 3.将单词转变为词根形式，如“drove”到“drive”等。这种操作称为：lemmatization。

语言处理组件(linguistic processor)的结果称为词(Term)。

Term是索引库的最小单位。

• 在我们的例子中，经过语言处理，得到的词(Term)如下：

  “student”，“allow”，“go”，“their”，“friend”，“allow”，“drink”，“beer”，“my”，“friend”，“jerry”，“go”，“school”，“see”，“his”，“student”，“find”，“them”，“drink”，“allow”。

  也正是因为有语言处理的步骤，才能使搜索drove，而drive也能被搜索出来。

3.5索引创建

索引的目的是为了搜索。

说明：将得到的词(Term)传给索引组件(Indexer)，索引组件(Indexer)主要做以下几件事情：

3.5.1创建Term字典

在我们的例子中字典如下：

3.5.2排序Term字典

对字典按字母顺序进行排序

3.5.3合并Term字典

合并相同的词(Term)成为文档倒排(Posting List)链表

在此表中，有几个定义：

• Document Frequency 即文档频次，表示总共有多少文件包含此词(Term)。
• Frequency 即词频率，表示此文件中包含了几个此词(Term)。

到此为止，索引已经创建好了。

最终的索引结构是一种倒排索引结构也叫反向索引结构，包括索引和文档两部分，索引即词汇表，它的规模较小，而文档集合较大。

倒排索引结构是根据内容（词汇）找文档，如下图：

3.6创建索引流程总结

分词及检索的详细的流程：

上图详细演示了一下： 创建索引的过程 （此过程为

英文环境

下的索引库构建过程，中文有一定差异）

4.搜索索引流程

4.1查询语句

4.2执行搜索

4.2.1第一步：对查询语句进行词法分析、语法分析及语言处理。

1、词法分析

如上述例子中，经过词法分析，得到单词有lucene，learned，hadoop, 关键字有AND, NOT。

注意：关键字必须大写，否则就作为普通单词处理。

2、语法分析

如果发现查询语句不满足语法规则，则会报错。如lucene NOT AND learned，则会出错。

如上述例子，lucene AND learned NOT hadoop形成的语法树如下：

3、语言处理

如learned变成learn等。

经过第二步，我们得到一棵经过语言处理的语法树。

4.2.2第二步：搜索索引，得到符号语法树的文档。

1、 首先，在反向索引表中，分别找出包含lucene，learn，hadoop的文档链表。

2、 其次，对包含lucene，learn的链表进行合并操作，得到既包含lucene又包含learn的文档链表。

3、 然后，将此链表与hadoop的文档链表进行差操作，去除包含hadoop的文档，从而得到既包含lucene又包含learn而且不包含hadoop的文档链表。

4、 此文档链表就是我们要找的文档。

4.2.3第三步：根据得到的文档和查询语句的相关性，对结果进行排序。

相关度自然打分（权重越高分越高）：

• tf越高、权重越高（tf代表该词在文档中出现的频率）
• df越高、权重越低（df代表包含该词的文档的数量）

人为影响分数：

• 设置Boost值（加权值）

5.Lucene相关度排序

5.1什么是相关度排序

相关度排序是查询结果按照与查询关键字的相关性进行排序，越相关的越靠前。比如搜索“Lucene”关键字，与该关键字最相关的文章应该排在前边。

5.2相关度打分

Lucene对查询关键字和索引文档的相关度进行打分，得分高的就排在前边。

如何打分呢？Lucene是在用户进行检索时实时根据搜索的关键字计算出来的，分两步：

1. 计算出词（Term）的权重
2. 根据词的权重值，计算文档相关度得分。

什么是词的权重？

通过索引部分的学习，明确索引的最小单位是一个Term(索引词典中的一个词)。搜索也是从索引域中查询Term，再根据Term找到文档。Term对文档的重要性称为权重，影响Term权重有两个因素：

• Term Frequency (tf)：

  指此Term在此文档中出现了多少次。tf 越大说明越重要。

  词(Term)在文档中出现的次数越多，说明此词(Term)对该文档越重要，如“Lucene”这个词，在文档中出现的次数很多，说明该文档主要就是讲Lucene技术的。

• Document Frequency (df)：

  指有多少文档包含此Term。df 越大说明越不重要。

  比如，在一篇英语文档中，this出现的次数更多，就说明越重要吗？不是的，有越多的文档包含此词(Term), 说明此词(Term)太普通，不足以区分这些文档，因而重要性越低。

5.3.设置boost值影响相关度排序

boost是一个加权值（默认加权值为1.0f），它可以影响权重的计算。在索引时对某个文档中的field设置加权值，设置越高，在搜索时匹配到这个文档就可能排在前边。

6.Lucene的Field域

6.1Field属性

Field是文档中的域，包括Field名和Field值两部分，一个文档可以包括多个Field，Document只是Field的一个承载体，Field值即为要索引的内容，也是要搜索的内容。

属性	可选值
是否分词(tokenized)	* 是：作分词处理，即将Field值进行分词，分词的目的是为了索引。 比如：商品名称、商品描述等，这些内容用户要输入关键字搜索，由于搜索的内容格式大、内容多需要分词后将语汇单元建立索引 * 否：不作分词处理 比如：商品id、订单号、身份证号等
是否索引(indexed)	* 是：进行索引。将Field分词后的词或整个Field值进行索引，存储到索引域，索引的目的是为了搜索。 比如：商品名称、商品描述分析后进行索引，订单号、身份证号不用分词但也要索引，这些将来都要作为查询条件。 * 否：不索引。 比如：图片路径、文件路径等，不用作为查询条件的不用索引
是否存储(stored)	* 是：将Field值存储在文档域中，存储在文档域中的Field才可以从Document中获取。 比如：商品名称、订单号，凡是将来要从Document中获取的Field都要存储。 * 否：不存储Field值 比如：商品描述，内容较大不用存储。如果要向用户展示商品描述可以从系统的关系数据库中获取。

6.2Field常用类型

下边列出了开发中常用 的Filed类型，注意Field的属性，根据需求选择：

Field类	数据类型	Analyzed 是否分词	Indexed 是否索引	Stored 是否存储	说明
StringField(FieldName, FieldValue,Store.YES))	字符串	N	Y	Y或N	这个Field用来构建一个字符串Field，但是不会进行分词，会将整个串存储在索引中，比如(订单号,身份证号等) 是否存储在文档中用Store.YES或Store.NO决定
LongField(FieldName, FieldValue,Store.YES)	Long型	Y	Y	Y或N	这个Field用来构建一个Long数字型Field，进行分词和索引，比如(价格) 是否存储在文档中用Store.YES或Store.NO决定
StoredField(FieldName, FieldValue)	重载方法，支持多种类型	N	N	Y	这个Field用来构建不同类型Field 不分析，不索引，但要Field存储在文档中
TextField(FieldName, FieldValue, Store.NO) 或 TextField(FieldName, reader)	字符串 或 流	Y	Y	Y或N	如果是一个Reader, lucene猜测内容比较多,会采用Unstored的策略.

6.3Field设计

Field域如何设计，取决于需求，比如搜索条件有哪些？显示结果有哪些？

字段	设计
商品id	是否分词：不用分词，因为不会根据商品id来搜索商品 是否索引：不索引，因为不需要根据商品ID进行搜索 是否存储：要存储，因为查询结果页面需要使用id这个值。
商品名称	是否分词：要分词，因为要根据商品名称的关键词搜索。 是否索引：要索引。 是否存储：要存储。
商品价格	是否分词：要分词，lucene对数字型的值只要有搜索需求的都要分词和索引，因为lucene对数字型的内容要特殊分词处理，需要分词和索引。 是否索引：要索引 是否存储：要存储
商品图片地址	是否分词：不分词 是否索引：不索引 是否存储：要存储
商品描述	是否分词：要分词 是否索引：要索引 是否存储：因为商品描述内容量大，不在查询结果页面直接显示，不存储。

常见问题：

不存储是指不在lucene的索引域中记录，目的是为了节省lucene的索引文件空间。

如果要在详情页面显示描述，解决方案：

从lucene中取出商品的id，根据商品的id查询关系数据库（MySQL）中item表得到描述信息。