Chapter 2
第2章
Elasticsearch基础知识

2.1 搜索引擎基础知识

Elasticsearch功能的核心是搜索引擎，学习搜索引擎的基础知识对于加深Elasticsearch核心概念的理解大有裨益。

在20世纪90年代初期，互联网刚开始普及，个人建站还比较困难，网站主要由公司或精通技术的爱好者托管。当时还没有搜索引擎之类的产品，网站影响力是通过口口相传的方式建立起来的。

在1990年前后，第一个搜索引擎工具出现了，随后几年出现了许多商业引擎，包括Excite、AltaVista和Yahoo！。而后，网页和用户的数量逐渐增长到无法再通过集中列表来管理的程度。Google于1998年应运而生，推出了PageRank算法，并一举改变了搜索引擎的格局，在搜索引擎领域长久地遥遥领先于竞争对手。

现如今，搜索引擎已然成为大多数人日常生活的一部分，人们已经离不开它。

2.1.1 搜索引擎的目标

如下3个核心目标是构建和优化搜索引擎的的基本框架，不仅适用于Google、Bing、百度等大型搜索引擎，也适用于实际业务中的Elasticsearch应用。

1）全面性：无论是商业化的搜索引擎，还是由Elasticsearch构建的搜索引擎，全面的信息覆盖都是至关重要的。这既体现在商业搜索引擎的爬虫技术优化上，也体现在Elasticsearch搜索引擎的基础数据源的完整性上。它与大数据的定义——对所有数据进行分析处理，而非单纯依赖随机分析法（抽样调查）——有着天然的契合。毫无疑问，数据的多样性和完整性会极大增强基于全量数据的检索、聚合、统计、分析的价值。

2）速度：搜索引擎应能在海量数据中迅速有效地检索信息。这需要我们借助索引、缓存等技术来优化搜索引擎的检索速度。

3）准确性：搜索引擎的任务是返回用户最想获取的结果，以提升用户体验。这要求我们在设计和优化搜索引擎时追求结果的精确性、满足用户的具体需求。

2.1.2 搜索引擎的核心要求

搜索引擎的目的是帮助用户以极小的时间成本从海量的数据中找出最相关的结果。糟糕的搜索引擎往往会“答非所问”，用户可能连续翻了许多页依然找不到期望的结果。这一方面会浪费用户宝贵的时间，另一方面会令用户有挫败感。而出色的搜索引擎在召回数据的第一页甚至第一条就是最相关的结果，让用户“得来全不费工夫”。

问题来了，搜索引擎要满足哪些核心的要求，才能达到用户的预期、增强用户体验，且提高用户的满意度呢？

（1）识别用户真正的需求

通过用户输入的简短几个字符，识别出用户真正期望的搜索结果，获取用户隐藏在字符后面的真正需求，这是搜索引擎首先要解决的非常重要的问题。

（2）匹配用户需求

搜索本质上是一个信息匹配的过程，即从海量数据里找到匹配用户需求的内容。从实现的角度看，搜索引擎的核心工作是判断内容和用户查询关键词的相关度，相关度高的结果数据应当优先被召回。

（3）找到可信数据

对于在互联网上发布的信息是否可信，没有明确的判定标准。但可以将数据来源的可靠性、内容的准确性和一致性作为可信赖的判定依据。例如，同样是被召回的数据，来自人民网、新华网等权威媒体的结果的可信度极高，而来自普通自媒体、小型网站的结果的可信度则大打折扣甚至不可信，因此实战层面建议将权威媒体赋予更高的权重，以提高可信赖性。

2.1.3 检索质量的评价指标

点击搜索按钮之后，召回的结果是否达到用户的预期呢？一般我们从召回率、精准率两个指标来衡量检索质量。

（1）召回率

召回率是指在一次返回的搜索结果中与搜索关键词相关的文档占所有相关文档的比例。召回率的本质是衡量检索结果的查全率，评价检索系统是否把该召回的文档都召回了。

（2）精准率

精准率也叫精确率，可以定义为本次搜索结果中相关文档所占的比例。精准率的本质是衡量检索结果的查准率。当数据规模非常大时，用户更加关注的是排在前面的检索结果是否相关，是否达到搜索预期。所以，相较于召回率，大数据业务场景的用户更关注精准率。

如图2-1所示，N、M、K、L代表不同类型的数据。横轴表示数据是否在搜索结果中。纵轴则表示数据是否与搜索关键词相关。

至此，N、M、K、L的含义如下。

1）N代表该数据在搜索结果中，且相关。

2）M代表该数据在搜索结果中，但不相关。

3）K代表该数据不在搜索结果中，但相关。

4）L代表该数据不在搜索结果中，也不相关。

再来看召回率、精准率的计算公式。

召回率=N/（N+K）

K值越小，召回率越高。也就是说，未被召回的相关数据越少，召回率越高。极端情况K=0，所有相关数据都被完整召回了，召回率为1。

精准率=N/（N+M）

M值越小，精准率越高。也就是说，搜索结果中不相关数据越少，精准率越高。

2.1.4 倒排索引

面对海量数据时，倒排索引扮演了关键角色，它以卓越的性能为我们快速定位包含用户查询关键词的相关内容。为更好地理解倒排索引，我们首先需要明确其定义：在一个文档集合中，每个文档都可视为一个词语的集合，倒排索引则是将词语映射到包含这个词语的文档的数据结构。这与普通索引（即将文档映射到其包含的词语）正好相反，而倒排索引正因其特性，成为了快速实现全文搜索的理想选择。

图2-2展示了一本C语言图书末页的索引结构。这种结构揭示了核心关键词与页码之间的对应关系。这种关系模式可以视为倒排索引的实际例证。在此结构中，我们可以根据关键词快速找到包含这个关键词的内容的页码。这与倒排索引在接收关键词输入后能够迅速定位包含该关键词的文档的性质是一致的。借由这种类比，我们可以更为直观地理解倒排索引在数据查询中的关键作用。

倒排索引主要由两部分组成：单词词典，即每个文档进行分词后的词项在去重后组成的集合；倒排文件是倒排列表持久化存储的结果，通常保存在磁盘等存储设备上。倒排列表记录了词项所在文档的文档列表、单词频率等信息。

我们以4个文档为例，如表2-1所示。这4个文档的倒排索引如表2-2所示。

docid代表文档ID，TF代表词频。以词项“chatgpt”为例，其对应的倒排索引（1:1）中前面的1代表文档ID，说明文档1中包含“chatgpt”词项；后面的1代表词频，说明“chatgpt”词项在文档1里出现了1次。

实际的倒排列表存储的信息要比表2-2复杂，还会包括词项在文档中出现的位置等信息，以方便实现复杂检索。

有了倒排列表，当检索“chatgpt”时，就无须对逐个文档进行扫描，而可以借助倒排索引锁定ID为1、2、3、4的文档，实现以O（1）的时间复杂度快速召回数据，达到快速响应的目的。

2.1.5 全文检索

数据索引化指的是数据在写入搜索引擎（本书中主要指Elasticsearch）的过程中，扫描文档中的每一个词项，结合分词器和词典对必要的词项建立倒排索引，同时指明该词项在文章中出现的次数和位置。

全文检索的前提是待检索的数据已经索引化，当用户查询时能根据建立的倒排索引进行查找。衡量全文检索系统的关键指标是全面、准确和快速。

全文检索的特点如下。

❑只处理文本，不处理语义。

❑结果列表有相关度排序。

❑支持高亮显示结果数据。

❑原始的文本被切分为单个单词、短语或特殊标记后进行存储。

❑给定词与它的变体（如近义词）会被折叠为一个词，如electrification和ectric、mice和mouse、“土豆”和“马铃薯”、“西红柿”和“番茄”等，每组词均被视为同一个词。

2.2 Elasticsearch的核心概念

如前所述，Elasticsearch是目前最流行的、能够方便地实现各种类型数据的检索和分析的开源搜索引擎。Elasticsearch具有高度可扩展性，可以轻松管理PB级数据。熟悉Elasticsearch常用术语及概念是使用它的重要前提。

下面我们讲解Elasticsearch的几个核心概念。

来看“集群”“节点”“索引”“分片”等一系列概念。它们的关系如图2-3所示，对外提供服务的是整个集群，一个集群可以由多个节点组成，不同的节点根据用途不同会划分成不同的角色，每个节点的数据会划分出多个索引，一个索引对应多个分片数据。

我们可以对比MySQL来理解Elasticsearch，如表2-3所示。左侧是MySQL的基本概念，右侧是Elasticsearch对应的相似概念的定义。借由这种对比，我们可以更直观地看出Elasticsearch与传统数据库之间的关系及差异。

2.2.1 集群

Elasticsearch集群是一组Elasticsearch节点的集合。节点根据用途不同会划分出不同的角色，且节点之间相互通信。Elasticsearch集群常用于处理大规模数据集，目的是实现容错和高可用。Elasticsearch集群需要一个唯一标识的集群名称来防止不必要的节点加入。集群大小从单个节点到数千个节点不等，具体大小取决于实际业务场景。

2.2.2 节点

节点是指一个Elasticsearch实例，更确切地说，它是一个Elasticsearch进程。节点可以部署到物理机或者虚拟机上。每当Elasticsearch启动时，节点就会开始运行。每个节点都有唯一标识的名称，在部署多节点集群环境的时候我们要注意不要写错节点名称。

2.2.3 索引

索引是Elasticsearch中用于存储和管理相关数据的逻辑容器。索引可以看作数据库中的一个表，它包含了一组具有相似结构的文档。在Elasticsearch中，数据以JSON格式的文档存储在索引内。每个索引具有唯一的名称，以便在执行搜索、更新和删除操作时进行引用。索引的名称可以由用户自定义，但必须全部小写。总之，索引是Elasticsearch中用于组织、存储和检索数据的一个核心概念。通过将数据划分为不同的索引，用户可以更有效地管理和查询相关数据。

2.2.4 分片

在了解分片是什么之前，让我们谈谈为什么需要分片。假设你有一个包含超大规模文档的索引，有总计1TB的数据。当前集群中有两个节点，每个节点有512GB的空间可用于存储数据。显然，整个索引无法存储在任何一个节点上，因此有必要以某种方式拆分索引的数据，否则会导致数据存储不完整。在这种情况下，索引的大小超过了单个节点的硬件限制，分片就派上用场了。分片通过将索引分成更小的部分来解决这个问题。

因此，分片将包含索引数据的一个子集，并且其本身具有完整的功能和独立性，可以将分片近似看作“独立索引”。单节点集群环境中，当索引被分片时，该索引中的给定文档将仅存储在其中一个分片中。如图2-3中的分片1～4、副本1～4均为分片。

当处理涉及多个数据分片的查询时，Elasticsearch会将查询请求分发到各个相关的分片，并将它们的结果集进行聚合。对于使用Elasticsearch的应用程序来说，它无须了解底层数据的分片结构或处理这种复杂性，因为整个查询和结果集合的过程对于应用程序（进而对于用户）来说是完全“透明”的。这种设计带来了极高的便利性，允许应用程序更专注于数据处理和用户交互，而不需要关心底层数据存储和检索的细节。

所以说，一个分片本质就是一个Lucene索引。

2.2.5 副本

生产环境下，硬件随时可能发生故障。为了保证集群的容错性和高可用性、提高查询的吞吐率，Elasticsearch提供了复制数据的特性。分片可以被复制，被复制的分片称为“主分片”，如图2-3中的主分片1～4；主分片的复制版本称为“副本分片”或简称为“副本”，如图2-3中的副本1～4。

创建索引时需要指定主分片，且主分片数一经指定就不支持动态更新了。而副本同样需要在创建索引时指定，每个分片可以有0或多个副本，副本数支持动态更新。

当某主分片所在的数据节点不可用时，会导致主分片丢失现象，若短时间内不对此采取补救措施，集群会将该分片对应的副本提升为新的主分片。

2.2.6 文档

关系型数据库将数据以行或元组为单位存储在数据库表中，而Elasticsearch将数据以文档为单位存储在索引中。

作为Elasticsearch的基本存储单元，文档是指存储在Elasticsearch索引中的JSON对象。文档中的数据由键值对构成。键是字段的名称，值是不同数据类型的字段。不同的数据类型包含但不限于字符串类型、数字类型、布尔类型、对象类型等。

以某航空类索引为例，如下。

2.2.7 字段

字段是Elasticsearch中最小的单个数据单元，类似于关系型数据库表中的字段。一般实战项目前期的设计环节都是根据业务需求拆分、定义字段，并且敲定字段类型。在上面航空类索引的示例中，“FlightNum”是字段，其含义为“航班号”，字段类型为keyword。

与关系型数据库不同的是，Elasticsearch的一个字段可以设定两种或两种以上的数据类型，通过定义multi-field来灵活地满足复杂的业务需求。

2.2.8 映射

不少初学者对映射（Mapping）这个概念会感觉不好理解。映射类似于关系型数据库中的Schema，可以近似地理解为“表结构”。

映射的定义如下所示。

我们拿到一个业务需求后，往往会将业务细分会几个索引。每个索引都需要一个相对固定的表结构，包含但不限于字段名称、字段类型、是否需要分词、是否需要索引、是否需要存储、是否需要多字段类型等。这些都是设计映射时要考虑的问题。

2.2.9 分词

前面我们讲过了倒排索引，倒排索引的本质是使用户以O（1）的时间复杂度快速召回结果数据。而分词则是构建倒排索引的重要一环。

在英文文本中，空格就是切分语句或短语的“屏障”。但中文文本中则没有了这道“屏障”，于是分词就变得就不那么简单，需要由专门的分词算法构建的分词器来实现。

举例来说（该例子中选择IK分词器的ik_smart粗粒度分词器）。对于中文新闻标题“阿根廷击败法国夺得世界杯冠军梅西创多项纪录”，分词的结果如下。

阿根廷 击败 法国 夺得 世界杯 冠军 梅 西 创 多项 纪录

2.3 本章小结

首先，本章围绕搜索引擎的话题展开讲解，具体从搜索引擎的目标、搜索引擎要满足的3个核心要求、检索质量的评价指标、倒排索引、全文检索这5个方面阐述了搜索引擎的基础知识。

我们掌握了这些基础知识，对后面更进一步学习Elasticsearch也会有所帮助。

搜索引擎基础知识小结如图2-4所示。

其次，本章讲解了Elasticsearch的核心概念，如图2-5所示。