ElasticSearch基本原理与介绍

1. Elastic Search
-基本原理与操作
量富征信 金服数据中心 李栓柱
2017-05

2. Agenda
• 基本原理与操作
– History
– 概念
– 节点启动
– 主节点选举
– 分片
– 写和读的过程
– 文档
– CURD操作
– 聚合
• 数据建模
– 存储原理
– 映射与类型
– 关系
– 练习
说在前面的:
本文主要偏结构化查询，对于全文搜索并未涉及
太多。如后续开发需要，再酌情进行相关培训。

3. History – Apache Lucene
– “Information retrieval software library”
– Free/open source
– Supported by Apache Foundation
– Created by Doug Cutting
– Written in 1999

4. History – Elastic Search
– You know, for Search”
– Also Free & Open Source
– Built on top of Lucene
– Created by Shay Banon @kimchy
– Versions
• First public release, v0.4 in February 2010
– A rewrite of earlier “Compass” project, now with scalability built-in
from the very core
• Now stable version at 0.20.6
• Beta branch at 0.90 (working towards 1.0 release)
– In Java, so inherently cross-platform

5. WHAT DOES IT ADD TO LUCENE?
– RESTfull Service
• JSON API over HTTP
• Want to use it from PHP?
– CURL Requests, as if you’d do requests to the Facebook Graph API.
– High Availability & Performance
• Clustering
– Long Term Persistency
• Write through to persistent storage system.

6. Installation
• wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.3.2.zip
• unzip elasticsearch-5.3.2.zip
• cd elasticsearch-5.3.2/
• /bin/elasticsearch –d
• http://localhost:9200

7. 插件安装1
• 中文分词: elasticsearch-plugin install analysis-smartcn
– reference:https://www.elastic.co/guide/en/elasticsearch/plugins/current/integra
tions.html
• phonetic: elasticsearch-plugin install analysis-phonetic
– reference:https://www.elastic.co/guide/en/elasticsearch/plugins/current/integra
tions.html
• Ingest Attachment(such as PPT, XLS, and PDF): elasticsearch-plugin install ingest-
attachment
– reference:https://www.elastic.co/guide/en/elasticsearch/plugins/current/integra
tions.html
• GeoIP: elasticsearch-plugin install ingest-geoip
– reference:https://www.elastic.co/guide/en/elasticsearch/plugins/current/integra
tions.html

8. 插件安装2
• HDFS: elasticsearch-plugin install repository-hdfs
– reference:https://www.elastic.co/guide/en/elasticsearch/plugins/current/integra
tions.html
• Hive/Spark/Storm integeration:
– reference:https://www.elastic.co/guide/en/elasticsearch/hadoop/current/install.
html
• 安全Search-guard
– Reference: http://floragunn.com/searchguard/

9. ElasticSearch 概念
• 节点
– 单个ES的服务实例称为节点(node)。
• 集群
– 当数据量或者查询压力超过单机负载时，需要多个节点来协同处理，多有这些节点组成
的系统成为集群(Cluster)
• 分片
– 集群允许系统存储的数据总量超过单机容量。为了满足这个需求，ES将数据散布到多个
物理Lucene索引上。这些Lucene索引成为分片(shard), 而散布这些分片的过程叫做分
片处理(sharding)
• 副本
– 索引的冗余备份，处理查询时可以把这些副本用作最初的主分片(primary shard)
• 网关
– 关于集群状态，索引设置的各种信息都会被搜集起来，并在网关(gateway)中被持久化

10. 集群

11. 节点启动1

12. 节点启动2

13. 节点启动3

14. 节点启动4

15. 节点启动5

16. 节点启动6

17. 节点启动7

18. 节点启动8

19. 节点启动9

20. 节点启动10

21. 节点启动11

22. 节点启动12 – 主节点Fault
Detection

23. 节点启动13 – 从节点Fault
Detection

24. 主节点选举
• 共识
 是分布式系统的一项基本挑战，要求系统中的所有进程/节点必
须对给定数据的值、状态达成共识。Raft,Paxos
 ElasticSearch的共识系统zen distory:
1. Ping: 执行节点使用ping来发现彼此
2. 单播(Unicast): 该模块包含一个主机名列表，用以控制哪些节
点需要ping通
 故障检测的原理是这样的，master节点会ping所有其他节点，
以检查他们是否还活着；然后所有节点再ping回去，告诉
master他们还活着。

25. 主节点选举 –脑裂
• 脑裂:
 在网络分区的情况下，一个
节点可以认为master已经死
了，然后选举自己为master,
这就导致了一个集群里面出
现多个master。这可能导致
数据丢失，也可能无法正确
合并数据。可以按照下面的
公式，根据有资格参加选取
的节点数，设置法定票数属
性的值，以避免脑裂的发生。
 distory.zen.minimum_mas
ter_nodes=int(# of master
of eligible nodes/2)+1

26. 什么是网络分区?
• 分布式通常假设网络是异步的，意味着网络可能会导致任意的重复、丢失、延迟或者乱序的
节点消息传递。在实际中，TCP状态机会保证节点消息传递的不丢失、不重复、时序。但是，
在socket级别上，节点接发消息会阻塞、超时等等。
• 检测到网络失败是困难的，因为我们唯一能得到其他节点状态的信息就是通过网络来得到，
延迟跟网络失败也无从区分。这里就会产生一个基本的网络分区问题：高延迟可以考虑作为
失败。当网络分区产生之后，我们没有渠道去了解其他节点到底发生了什么？
• 根据CAP理论，为了保证系统高可用性，一般系统会进入降噪模式，即利用备选节点保证系
统可用。之前的操作会丢失，即可能产生数据丢失。

27. 主节点选举 – Network Partition

28. 主节点选举

29. 主节点选举
• 根据备选主节点的列表来决定选举优先权
 备选节点的集群版本号最高
 其他备选节点
 备选节点ID顺序
• 发送选举join给这个新的节点，同时计票。
• 判定是否满足最小法定投票数distory.zen.minimum_master_nodes
• 选举完成后，所有节点移除失败主节点

30. 索引、分片、文档
• 索引实际上是指向一个或者多个物理分片的逻辑命名空间。
• 一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。一个分片是一个
Lucence的实例，以及它本身就是一个完整的搜索引擎。
• 我们的文档被存储和索引到分片内，ES直接与索引交互，而不是与分片交互。
• 一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分
片的数量决定着索引能够保存的最大数据量。
• 一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，
并且同时为搜索和返回文档等操作提供服务。

31. 主分片和副本分片
• 对于ES来说，分片及副本的分配将是提高可用性及快速搜索能力响应的核心设计。主分片和
副本分片都能处理查询请求，唯一的区别在于主分片才能处理索引请求。
• 索引的number_of_shards参数只对当前索引有效，而不是对整个集群有效，该参数定义了
当前索引的主分片数，而不是集群的所有主分片数。
• 副本对搜索的性能非常重要，同时用户也可在任何时候添加或者删除副本。额外的副本能给
你带来更大的容量，更高的吞吐能力及更强的故障恢复能力。
• 索引分片数量设置好之后，无法调整。如要调整，只能重建索引。

32. 如何规划分片数量
• 分配分片时主要考虑你的数据集的增长趋势，稍有富余是好的，过度分片会带来很多问题。
一个分片能够索引的最大文档数是Integer.MAX_VALUE-128
• 分片的成本:
– 每个分片本质上就是一个Lucene索引，因此会消耗响应的文件句柄，内存和CPU资源
– 每个搜索请求都会调度到索引的每个分片中，如果分片分散在不同的节点问题不大，在
同一个节点时，当分片开始竞争相同的硬件资源时，性能会逐步下降。
– ES默认使用td-idf来计算相关性，这些统计也会分配到各个分片上，如果大量的分片只
维护了很少的数据，将导致最终的文档相关性较差。
• ES推荐的最大JVM堆空间是30~32G, 分片最大则为30G，如果一个200G的索引，分配7到8
个分片。
• 在开始阶段，一个好的方案是根据你的节点数量按照1.5~3倍的方案来创建分片数量。
– 节点最大数 = 分片数*(副本数+1)

33. 分片恢复

34. 分片恢复 – 从主分片恢复

35. 写请求数据流(CUD
create,update,Delete)

36. 更新和删除操作(UD)
• 删除和更新都是写操作，但在elasticsearch中，文档是不可变的，因此不能被删除或改动以
展示其变更。
• 磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而
是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合
并时，在.del文件中被标记为删除的文档将不会被写入新段。
• 更新: 在新的文档被创建时，Elasticsearch会为该文档指定一个版本号。当执行更新时，旧
版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依
然能匹配查询，但是会在结果中被过滤掉。

37. 动态更新索引1
一个Lucene索引包含一个提交点
和三个段

38. 动态更新索引2
• 新的文档被搜集到内存索引缓存,并且追加到
Translog
• 不时的，缓存被提交:
– 一个新的段(倒排序索引)被持久化到磁盘
– 一个新的包含新段名字的提交点被写入磁盘
– 磁盘进行同步-所有在文件系统缓存中等待
写入的都刷新到磁盘，以确保它们被写入物
理文件。Translog不会被清空。
• 新的段被开启，让它包含的文档可以被搜索
• 内存缓存被清空，等待接收新的文档
• 每隔一段时间或者Translog大到了一定程度，索
引被刷新(flush)；一个新的translog被创建，并
且一个全量提交被执行。所有缓存被清空，创建
新的提交点，老的Translog被删除。

39. Lucene的段
• Lucene索引是由多个段组成，
段本身是一个功能齐全的倒排索
引。段是不可变的，允许
Lucene将新的文档增量地添加
到索引中，而不用从头重建索引。
对于每一个搜索请求而言，索引
中的所有段都会被搜索，并且每
个段会消耗CPU的时钟周、文件
句柄和内存。这意味着段的数量
越多，搜索性能会越低。
为了解决这个问题，Elasticsearch会合并小段到一个较
大的段（如上图所示），提交新的合并段到磁盘，并删
除那些旧的小段。
这会在后台自动执行而不中断索引或者搜索。由于段合
并会耗尽资源，影响搜索性能，Elasticsearch会节制合
并过程，为搜索提供足够的可用资源。

40. 段合并
上图所示:
1. 当索引的时候，刷新(Refresh)操作会创建新的段
并将段打开以供搜索使用。
2. 合并的进程选择一小部分大小相似的段，并且在
后台将它们合并到更大的段中。这并不会中断索
引和搜索。
下图所示:
1. 新的段被flush到了磁盘，系统写入一个包含新段
且排除旧的和较小的段的新提交点。
2. 新的段被打开用来搜素
3. 老的段被删除

41. 读操作: Read

42. 相关性得分 – 全文搜索
• 相关性是由搜索结果中Elasticsearch打给每个文档的得分决定的。
• 默认使用的排序算法是tf/idf(词频/逆文档频率)。
– 词频衡量了一个词项在文档中出现的次数 (频率越高 == 相关性越高)，
– 逆文档频率衡量了词项在全部索引中出现的频率，是一个索引中文档总数的百分比(频率
越高 == 相关性越低)。
– 最后的得分是tf-idf得分与其他因子比如(短语查询中的)词项接近度、(模糊查询中的)词
项相似度等的组合。

43. 空集群
• 一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相
同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群
中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
• 当一个节点被选举成为 主 节点时， 它将负责管理集群范围内的所有变更，例如增加、
删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等
操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任
何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节
点。
• 作为用户，我们可以将请求发送到 集群中的任何节点 ，包括主节点。 每个节点都知道
任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无
论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，
并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

44. 添加索引
• curl -k -u admin:admin -XPUT "https://localhost:9200/blogs" -d
"{"settings":{"number_of_shards":3,"number_of_replicas":1}}“
• 集群健康:
• Status:
• Green
• Yellow
• Red

45. 多节点集群
Nodes:2
Replication:1
Nodes:3
Replication:1
Nodes:3
Replication:2

46. 关闭一个节点
什么状态?

47. 数据Terminology
DB Elastic Search
DB Index
Table Type
Row Document
Column Filed
Schema Mapping
Index Everything is indexed
SQL Query DSL
Select * from table GET http://…
Update table SET … PUT http://

48. 文档元数据
• _index: 文档存放在哪里
 一个索引应该是因共同的特性被分组到一起的文档组合。例如，所有的产品存储在
products索引中,所有的销售交易存在索引sales中
 必须小写,不能下划线开头，不能包含逗号
• _type: 文档表示的对象类别
 数据可能在索引中只是松散的组织在一起，但是通常明确定义一些数据中的子分区是有
意义的，如products中会有很多不同的产品类别，如服务器、笔记本、台式机等
 这些文档共享一种相同的(或非常相似的)模式，相当于在索引中对数据进行逻辑分区，
不同的types的文档可能有不同的字段，但最好能非常相似。
 一个_type命名可以是大小写，不能下划线或者句号开头，不应该包含逗号，并且长度
限制在256字符
• _id: 文档唯一标识
 ID是一个字符串，当它和_index、_type组合就可以唯一确定ElasticSearch中的一个文
档。
 创建一个新的文档，可以提供自己的_id或者系统自动生成。

49. 文档操作
• GET: 获取文档
• POST:用来更新文档以及文档的部分更新
• PUT: 用来新建文档
• DELETE: 用来删除文档
• HEAD: 可以用来判断文档是否存在

50. 空搜索
• curl -k -u admin:admin -XGET "https://localhost:9200/_search?pretty"

51. 搜索-轻量
• GET _all/{index}/{type}/_search?q=查询字段：查询词+查询字段：查询词
• 了解即可，生产不使用
 拼接复杂，不利于调试和阅读
 查询字符串允许用户在索引的任意字段上执行可能较慢且重量级的查询，这可能会暴露
隐私信息，甚至拖垮集群。

52. 获取一个文档1
• 检索文档
– curl -XGET "localhost:9200/megacorp/employee/1?pretty“
• 获取索引下所有文档
– curl -XGET "localhost:9200/megacorp/employee/_search?pretty“
• 轻量查询
– curl -XGET
"localhost:9200/megacorp/employee/_search?q=last_name:Smith&pretty“
• DSL语言 - 查询表达式 – 全文搜索
– curl -XGET "localhost:9200/megacorp/employee/_search?pretty" -H "Content-Type:
application/json" -d "{"query" : {"match" : {"last_name" : "Smith"}}}“
• DSL语言 – 布尔查询
– curl -XGET "localhost:9200/megacorp/employee/_search?pretty" -H "Content-Type:
application/json" -d "{"query" : {"bool": {"must": {"match" : {"last_name" :
"smith" }},"filter": {"range" : {"age" : { "gt" : 30 } }} }}}"

53. 获取一个文档2
• DSL语言 – 结构化查询 – 过滤查询
– curl -XGET "localhost:9200/megacorp/employee/_search?pretty" -H "Content-
Type: application/json" -d"{"query" : {"constant_score" : {"filter" : {"term" :
{ "age" : 25}}}}}"
• 具体参考官方文档:
– https://www.elastic.co/guide/en/elasticsearch/reference/5.3/query-dsl.html
– https://www.elastic.co/guide/en/elasticsearch/reference/5.3/search-
aggregations.html

54. 更新一个文档
• 部分更新
– curl -XPOST "localhost:9200/megacorp/employee/1/_update?pretty" -H
"Content-Type: application/json" –d "{"doc" : {"last_name" :"New
Smith"}}“
– ES本身不删除数据，所以POST只能部分更新，本质上还是通过查询获得结果后和新的
内容合并新创建一个文档，原有文档标记为删除
• 查询批量更新 XPOST {index}/{type}/_update_by_query?conficts=true
– {“query”:{ “term”:{ “last_name”: “New new Smith”}}}
• 全部更新
– 使用XPUT 的创建命令，把文档放入即可覆盖旧有文档

55. 创建文档
• curl -XPUT "localhost:9200/megacorp/employee/1?pretty" -H "Content-Type:
application/json" -d
"{"first_name":"John","last_name":"Smith","age":25,"about":"I love to go
rock climing","interest":["sports","music"]}"

56. 删除文档
• curl -XDELETE "localhost:9200/megacorp?pretty“
• 删除整个索引

57. 判断文档是否存在
• CURL –i –XHEAD http://localost:9200/megacorp/employee/i
• 存在 200, 不存在404

58. 文档的批量操作
• 取回多个文档
– XGET {index}/{type}/_mget –d “{ "ids" : [ "2", "1" ] }”
• 批量操作
– curl -XPOST 'localhost:9200/_bulk?pretty' -H 'Content-Type: application/json' -d'
{ "delete": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "create": { "_index": "website", "_type": "blog", "_id": "123" }}
{ "title": "My first blog post" }
{ "index": { "_index": "website", "_type": "blog" }}
{ "title": "My second blog post" }
{ "update": { "_index": "website", "_type": "blog", "_id": "123", "_retry_on_conflict" :
3} }
{ "doc" : {"title" : "My updated blog post"} }
'

59. 处理冲突
• 并发控制:
 悲观并发控制:关系型数据库广泛应用，假定变更冲突
可能会发生，因此阻塞访问资源以防止冲突。一个典
型的例子是读取一行数据的时候先将其锁住，确保只
有放置锁的线程能够对数据进行修改。
 乐观并发控制：ES中使用的这种方法是假定冲突是不
可能发生的，并且不会阻塞正在尝试的操作。然而，
如果源数据在读写当中被修改，更新将会失败。应用
程序接下来将决定如何解决冲突。例如，可以重试更
新，使用新的数据、或者将相关情况报告给用户。
 _version, 更新的时候指定要更新的版本号，如
_version=1, 在更新的时候，如果有别的程序更新了，
_version=2，版本号增加。这个时候程序要更新的目
标版本和源的版本号不一致，产生冲突。

60. 主分片和副本分片

61. 新建、索引和删除文档
• 一致性
 默认情况，主分片需要规定数量，或大多数的分片(其中分片副本可以是主分片或者副本
分片)在写入操作时可用。
 Int((primary+number_of_replicas)/2)+1
 允许的一致性值是一个(只是主分片)或者”所有”(主分片和副本分片),或者默认的规定
数量或者大多数的副本分片。
 如本例子int((1+2)/2)+1=2, down一个节点仍然满足。如果副本为3,则
int((1+3)/2)+1=3,down一个节点，无法索引和删除任何文档。
• 超时
 没有足够的副本分片，ES会等待，希望更多的分片出现。默认情况下，最多等待一分钟，
使用timeout参数终止。

62. 取回一个文档
• 为了读取请求，协调节点在每次请求的时候选择不同的副本分片来达到负载均衡；通过
轮询所有的副本分片。

63. 局部更新文档
• 客户端向 Node 1 发送更新请求。
• 它将请求转发到主分片所在的 Node 3 。
• Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片
的文档。 如果文档已经被另一个进程修改，它会重试步骤 3 ，超
过 retry_on_conflict 次后放弃。
• 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的
副本分片，重新建立索引。 一旦所有副本分片都返回成功， Node 3 向协调节点也返回
成功，协调节点向客户端返回成功。

64. 使用mget取回多个文档

65. 使用bulk修改多个文档

66. 聚合查询 – 非结构化字段数据结构
• Fielddata – 正排索引
– 按照字段排序(Sort)
– 按照字段进行聚合(Aggregations)
– 过滤器
– Script排除中使用某些字段
• 以Segment进行构建，完全放入内存。一般ES的内
存占用最多的就是Fielddata
• Only support text field，默认是关闭的

67. 聚合查询 – 结构化字段数据结构
• Doc Value
– 与Fielddata类似，但是是持久化到磁盘上的。
– 本质上一个序列化的列式存储。
– 如右图所示，可以进行差值压缩，针对Terms
• 针对数字，会依次检测以下压缩模式
• 如果所有的数值各不相同(或缺失)，设置一个标记并记录这些值
• 如果这些值小于256，将使用一个简单的编码表
• 如果这些值大于257，检测是否存在一个最大公约数
• 如果没有存在最大公约数，从最小的数值开始，统一计算偏移量进行编码
– 比Fileddata慢上10% ~ 25%左右，但占用内存大大减少，其次预先写入磁盘，初始化
速度比Fielddata在内存要快。
– 支持大部分类型，在不需要分析的字段上默认会建立该结构，可以显式关闭。

68. 聚合查询 – 全局序数Global
Ordinals
• 全局序数是一个构建的基于Fielddata和doc value之上的数据结构，该数据结构维护
每个词的字典顺序(动态的，incremental numbering)
• 只支持text和keyword类型的字段
• Fieldata和doc value也有顺序，每个词也有一个唯一的序号，该序号是当前段的当前
字段的序号。全局序数则构建在Fielddata和doc value的段顺序上，建立段顺序和全
局序数之间的映射，全局序数在整个分片内是唯一的。(不跨分片)
• 全局序数用于排序和聚合，提升性能。词聚合在分片内依赖全局序数，然后，在最后合
并不同分片的结构阶段，把全局序数转换成实际的词。
• 每当出现一个新的段的时候，全局序数需要重建。

69. 聚合查询 – 基本概念
• 基本概念:
– 桶(Buckets):满足特定条件的文档的集合
• 可以理解为数据库中的分组概念
• 当聚合开始被执行，每个文档里面的值通过计算来决定符合那个桶的条件。如果匹
配到，文档将放入相应的桶并接着进行聚合操作。
• 桶也可以被嵌套在其他桶里面，提供层次化的或者有条件的划分方案。多层分组，
如浦东会被放入上海这个桶，上海会被放入中国这个桶。
– 指标(Metrics):对桶内的文档进行统计计算
• 可以理解为count()等SQL统计函数

70. Elastic Search
-数据建模
量富征信 金服数据中心 李栓柱
2017-05

71. 流程
集群和分片设计
确定集群节点
和配置
确定分片设计
逻辑建模
根据需求和场
景
根据数据情况
确定结构化、
全文、聚合
物理建模
创建Mapping
测试
常规测试
Explain和性能
测试
上线
故障恢复等
Runbook手册

72. 类别
• ElasticSearch中的数据大致分为两类:
 结构化
 非结构化
• 设计和搜索也分为:结构化搜索与全文搜索
• 同时需要考虑聚合查询相关的设计

73. 结构化搜索-原理
• 在结构化查询中，我们得到的结果总是非即否，要不存在于集合中，要么存在于集合之外。结构化查
询不关心文档的相关度和评分，它简单的对文档包括或者排除处理。
• 当进行精确值查询的时候，使用过滤器(filters)是最好的选择。使用过滤器的执行速度非常快，因为不
会计算相关度（直接跳过了整个评分阶段），并且很容易 被缓存。
• 内部过滤器的操作
– 查找匹配文档，在倒排序索引中直接匹配查询token，获取所有的文档posting list
– 创建文档包含查询词的roaring bitmap
– 迭代roaring bitmap
– 增量计数器进行计数
• ES能够缓存非评分查询从而获得更开的访问，ES会为每个索引跟踪保留查询使用的历史状态。
如果查询在最近的256次查询中会被引用到，那么它就会被缓存到内存中。低于10000个文
档(或者少于3%总索引数)的查询会被忽略。缓存满了，会根据LRU规则，最近最少使用的过
滤器会被剔除

74. 索引 – 关系型数据库索引

75. ElasticSearch倒排索引

76. ElasticSearch倒排索引-例子 – Posting list
ID Name Age Sex
1 Kate 24 Female
2 John 24 Male
3 Bill 29 Male
Term Posting List
Kate 1
John 2
Bill 3
Term Posting List
24 [1,2]
29 3
Term Posting List
Female 1
Male [2,3]

77. ElasticSearch倒排索引-例子-
Term Index
• 这棵树不会包含所有的term，它包含的是term的一些前缀。通过
term index可以快速地定位到term dictionary的某个offset，然
后从这个位置再往后顺序查找。
• 所以term index不需要存下所有的term，而仅仅是他们的一些前
缀与Term Dictionary的block之间的映射关系，再结合
FST(Finite State Transducers)的压缩技术，可以使term index
缓存到内存中。从term index查到对应的term dictionary的
block位置之后，再去磁盘上找term，大大减少了磁盘随机读的
次数。

78. ElasticSearch倒排索引-例子-
Term Index - FST
• 假设我们现在要将mop, moth, pop, star,
top(term index里的term前缀)映射到序号：
0，1，2，3，4，5(term dictionary的
block位置)。
• O表示状态，->表示状态变化的过程，上
面的字母和数字表示状态变化和权重。
• 将单词分成单个字母O和->表示出来，0权
重不显示。如果O后面出现分支，就标记权
重，最后整条路径上的权重加起来就是这
个单词对应的序号。

79. ElasticSearch倒排索引-例子-
Term Dictionary

80. ElasticSearch倒排索引-例子-
posting list差值压缩 Frame of
Reference
• Elasticsearch要求posting list是有序的(为了提高搜索的性能，再任性的要求也得满足)，这
样做的一个好处是方便压缩
• 差值压缩例子

81. ElasticSearch倒排索引-例子-
Roaring bitmaps
• 说到Roaring bitmaps，就必须先从bitmap说起。Bitmap是一种数据结构，假设有某个
posting list：
• [1,3,4,7,10]
• 对应的bitmap就是：
• [1,0,1,1,0,0,1,0,0,1]
• Bitmap的缺点是存储空间随着文档个数线性增长，Roaring bitmaps需要打破这个魔咒就一
定要用到某些指数特性：

82. ElasticSearch倒排索引-例子-
Roaring bitmaps
• 将posting list按照65535为界限分块，
比如第一块所包含的文档id范围在
0~65535之间，第二块的id范围是
65536~131071，以此类推。再用<
商，余数>的组合表示每一组id，这样
每组里的id范围都在0~65535内了，
剩下的就好办了，既然每组id不会变
得无限大，那么我们就可以通过最有
效的方式对这里的id存储。

83. ElasticSearch联合索引
• 上面说了半天都是单field索引，如果多个field索引的联合查询，倒排索引如何满足快速
查询的要求呢？
• 利用跳表(Skip list)的数据结构快速做“与”运算，或者
• 利用上面提到的bitset按位“与”

84. ElasticSearch联合索引
• 如果使用跳表，对最短的posting list中的每个id，
逐个在另外两个posting list中查找看是否存在，最
后得到交集的结果。
• 如果使用bitset，就很直观了，直接按位与，得到
的结果就是最后的交集。

85. 文档 – 关系型视图

86. 文档 – 文档视图
Book
Author
Publisher

87. 映射 Mapping
• Mapping is the process of defining how a document, and the fields it contains, are
stored and indexed.
• Mapping主要用于定义Index下面的Types
– Meta-fileds
– Fields or properties
• Settings to prevent mappings explosion
– index.mapping.total_fields.limit: the max number of fields in an index, default
1000
– index.mapping.depth.limit : default 20, inner objects
– index.mapping.nested_fields.limit : default 50

88. Mapping – Field datatypes
• 简单类型: String(ES 5之后不再使用，用text和keyword代替), Numeric(long, integer,
short, byte, double, float), date, boolean, binary, Range (integer_range, float_range,
long_range, double_range, date_range), Text(用于全文搜索)
• 复杂类型: Array, Object(object of single JSON Object), Nested(nested for arrays of
JOSN Objects)
• Geo地理: Geo-point(lat/lon points), Geo-shape(复杂类型如polygons)
• Keyword: A field to index structured content such as email addresses, hostnames,
status codes, zip codes or tags.
• 特别类型: IP (IPv4/IPv6), Completion (provide auto-complete suggestions), Token
count( count the number of tokens in a string), Mapper-murmur3 (compute hashes
of values at index-time and store them in the index), Attachment datatype,
Percolator datatype
• Multi-fields复合类型：it is often useful to index the same field in different ways for
different purposes.

89. Mapping – Meta-fields
• Identity meta-fields: _index, _uid, _type, _id
• Document source meta-fields: _source, _size
• Indexing meta-fields: _all, _field_names
• Routing meta-fields: _parent, _routing
• Other: _meta

90. Dynamic Mapping
• ES最重要的特性之一就是索引一个文档的时候，不需要创建映射就可以用，ES会自己帮
你创建默认的类型映射。
• 可以使用index templates去配置默认的自动映射关系等。
• 关掉: 配置索引 PUT {index}/_settings –d ‘{“index.mapper.dynamic”: false}’

91. 映射参数
• analyzer : 指定分析器
• normalizer : 正则器
• boost : 一般不使用，忽略; 权重
• coerce: 清除脏数据，例如，String的数字会被转为数字类型，单精度会被转为整型等
• copy_to: 用于创建自定义的_all 字段
• doc_values: 结构化搜索并且不需要排序和聚合运算可以关掉, 不支持text
• dynamic: filed级别关掉自动映射
• enabled: field级别，仅存储，不索引和搜索
• fielddata: text类型做聚合
• format: 格式
• ignore_above : Strings longer than the ignore_above setting will not be indexed or stored.
• ignore_malformed: Trying to index the wrong datatype into a field throws an exception by
default, and rejects the whole document. The ignore_malformed parameter, if set to true,
allows the exception to be ignored. The malformed field is not indexed, but other fields in the
document are processed normally.

92. 映射参数
• include_in_all : 跟_all有关
• index_options : 添加信息到倒排序索引
• index : 控制是否索引
• fields : It is often useful to index the same field in different ways for different purposes
• norms : 正则化参数
• null_value : 空值处理，默认的空值null是不索引的，不会出现在倒排序索引中，因此不能被搜索
• position_increment_gap
• properties: object/ nested’s sub fields called properties
• search_analyzer : 搜索分析器
• similarity : 相似度算法
• store: 额外指定类似_source的字段，用以接受返回结果
• term_vector: 词向量指定使用位置、位移等

93. 处理ＮＵＬＬ值
• Q: 如果一个字段没有值，那么如何将它存入倒排序索引中？
• A: 答案是什么都不存。简单的来说，根据上述对倒排序索引的原理的讲解，一个倒排序索引
只是一个token列表和与之相对应的文档信息，如果字段没有值，那么它也不可能被解析出
来任何token, 也就无法在倒排序索引结构中体现出来。
• Null, [], [null] 所有这些都是等价的。
• 处理方法：
– Exists或者missing关键字查询
– 在索引的时候, 利用null_value 参数指定特殊符号为空值，方便搜索

94. 映射: Text
• 数据存储在倒排序索引中
• 分析过程决定存储结构和查询词
• 存储设计很重要
• 支持查询:
 Partial Word Matches

95. 映射: Text
• 支持查询:N-Garm

96. 映射: Text –N-Garm Additional
Field
• Indexed Document stays the same
• Additional index field title.prefix
• Can be queried like any field
• 对存储有需求
• 对查询的性能影响比较大

97. ElasticSearch过程 – 分析 – 全文
索引
• 分析器由分词器(tokenizer)、过滤器(filter)和字符映射器组成(character mapper)
• 调用分词器之
前的文本预处
理操作
• 如HTML的去
标签
字符映
射器
•文本切割成词条
•词项在原始文本中
的位置
•词项的长度
•Tokenization
•Lowercasing
•Stemming
分词器
•0个或者多个
•小写过滤器
•ASCII过滤器
•同义词过滤器
•多语言词干还原
器
过滤器
•倒排序索引
•Term index
•Term dictionary
•Posting list及压缩
•聚合计算索引构建
索引

98. 映射: Text 结构化查询
• 在定义索引的时候，index:指定为not_analyzed

99. 映射: Numbers
• 树存储
• 250, 290, 400
• 精度越高，树高越高
• 低精度，term会比较多
• 一般默认配置
• 不需要分析器，一般用于结构化查询。

100. ElasticSearch过程 – 结构化搜索
• 无分析过程
•倒排序索引
•Term index
•Term dictionary
•Posting list及压缩
•聚合计算索引构建
索引

101. 映射 : Date
• 默认编码: ISO8601 format
• Joda Time开源包定义的日期格式
• 内部存储为long型
• 一般用于结构化查询，无分析过程

102. 映射 – Embedded Documents
• 本例子中
 Flat
 1:1 relationship
 对于1:N关系比较麻烦

103. 字段折叠1
• 需求：标题包含relatonships并且作者名包含John的博客，查询结果再按作者名分组。
• 需求分解:
– 标题和作者名需要可以进行全文搜索
– 作者同时可以进行聚合运算
• 思路1:
– 标题和作者都在做mapping的时候定义为text类型，并且被用英语分析器进行索引
– 其次作者字段打开fielddata以支持聚合运算
• 思路2:
– 标题和作者都在做mapping的时候定义为text类型，并且被用英语分析器进行索引
– 其次作者字段进行字段折叠，设定为keyword类型，利用doc value进行聚合计算

104. 字段折叠2

105. 处理结构化的关系型数据设计
• 背景：
– 不同于关系型数据库，使用ES，一般出于性能、弹性、近实时搜索、大数据量分析等目
的。
– 在构建ES数据模型的时候，免不了会涉及到关系型数据的问题，如OLAP运算等。但实
际上关系型数据库的ACID支持，JOIN等更擅长关系型数据的处理，但数据库本身的一
些设计对于全文搜索的支持弱，Join的开销贵，聚合分析等大IO场景都不适合，但这些
确是ES擅长的场景。
– ES是乐观锁，无ACID等控制，但纯面向读的快速索引，搜索，大数据量的节点间拓展
都是ES擅长的场景。

106. ES处理关系型数据
• 方式
– 应用端Join
– 反范式化
– 嵌套对象
– Parent/child关联
• 一般情况下最终的解决方案基本来自于这些方法或者这些方法的混合使用。

107. 应用端JOIN
先获取user_id
通过获取到的
user_id去查询该用
户的博客
该方案:
1. 数据是范式化的设计，Join是在客户端进行，需要搜索做额外的请求。
2. 缺点：如果叫John的用户很多，则获取blog的操作带来的搜索和结果都会很大
3. 比较适合过滤表entity比较少的情况。
4. 1:1, 1:N, N:N场景都可

108. 反范式化
• 一个请求即可完成
• 适合1:1, 1:N场景
• 缺点:
– Index的size会比较大
– 数据更新的时候，如用户的名称更改，则该索引下该用户的所有blog都需要更新。这个
代价和开销需要考量。
– 在OLAP的应用场景中，事实维度模型本身就是已经反范式化的了，事实表维度较多的时
候，在ES模型中嵌入的对象会比较多，索引的存储会相应的比较大。

109. 嵌套对象
Hidden separate document
1. 嵌套对象和根文档的join非常
快，接近同一个文档的查询速
度
2. 但这些嵌套对象是隐藏的，不
能直接访问，修改增加删除都
需要重新索引整个document
3. 适合1:N场景

110. Parent-Child Relationships
• 跟嵌套对象相比，Parent和Child是分开的文档，好处有:
– Parent可以直接被update, 无需重新索引childern
– Child可以被增加更新删除，不会影响parent和其他的child
– Child可以在搜索结果中被返回。
• ES维护了一个parent和child的映射(保存在doc values里面)，由于这个映射，查询时的join
的速度是比较快的，但必须满足parent和child在一个分片内。
• 不过因为 Parent-child 使用了 global ordinals 来加速 joins，不管使用了 in-memory
cache 或者 on-disk doc values, 当索引改变时 global ordinals 需要重新构建。shard的
parents越多，rebuild所花的时间就越多。刷新后的第一次 parent-child query or
aggregation之后，会触发global ordinals构建，这时可能触发一个比较明显的延时，可以
使用eager_global_ordinals来优化查询时间，把开销转移到 refresh time。
• 适合parent有很多child,即1:1和1:N。 很多parent和很少的child也是不适合的。

111. 练习
• 一个节点
• 创建可以进行聚合查询的某公司megacorp的employee文档
• 可以进行过滤查询，聚合以及特定字段的全文搜索

112. References
• ElasticSearch权威指南：
https://www.elastic.co/guide/cn/elasticsearch/guide/cn/index.html
• ElasticSearch官方文
档:https://www.elastic.co/guide/en/elasticsearch/reference/5.3/index.html
• ElasticSearch官方博客文章: https://www.elastic.co/blog