1 基本概念

• cluster 类比成数据库
• index 类比成表
• document 类比成表中一行数据
• field 类比成表中字段，字段是包含数据的键值对

2 ES 是如何实现分布式的？

image.png

• 一个索引其实会被分片成多个shard放在不同机器上，每个shard只有索引的部分数据。
• 每个shard可有多个replica shard 放在其他机器。primary shard负责读写，写完后会同步到replica shard上。replica shard负责分担读请求，并防止其primary shard节点故障导致数据丢失。索引创建完成后，primary shard的数量就确定了不可更改，但replica shard的数量可以随时调整。
• cluster中有多个node, 会自动选举出一个node为master节点，负责维护索引元数据，负责集群中primary shard和replica shard的身份切换。

比如上图，index分成p0 p1 两个primary shard, 分别存储在node3 和 node 1上，他们的replica shard各自都有两份，比如p0的replica shard是r0, 在node1 和 node2 上。
cluster选举了node1作为master节点。

primary shard的默认数量是5，replica默认是1，也就是说默认5个primary shard，5个replica shard

3 ES写入数据的工作原理是什么？

image.png

插入、删除和索引都是写入操作。写入操作的主要过程如下：

1. 客户端请求到任意节点，比如node1
2. node1根据文档_id参数，hash计算出分片位置在node3节点的p0上，于是转发请求到p0
3. node3的p0分片执行写请求，完毕后转发给自己的两个分片r0。
4. 等待两个复制分片写入成功，node3报告写入成功给node1节点，node1节点再告诉客户端写入成功。

其中“执行写请求”的底层原理如下。

image.png

3.1 refresh

在ES中，buffer每隔1秒（或者满了），打开一个新segemnt并写入的过程，叫做refresh。

默认情况下，每个分片每秒自动刷新一次。这就是为什么说Elasticsearch是近实时的搜索了：
文档的改动在refresh之前，是搜索不出来的。

3.2 flush

在ES中，进行一次提交并删除事务日志的操作叫做 flush 。分片每30分钟，或事务日志过大，都会进行一次flush操作。

3.3 translog

为了数据安全es默认每隔5秒钟会把translog刷新(fsync)到磁盘中，也就是说最多会丢失5秒钟的数据，如果你对数据安全比较敏感，可以把这个间隔减小，但是会占用更多资源

flush和fsync的区别：

• flush是把内存中的数据(包括translog和segments)都刷到磁盘
• fsync只是把translog刷新到磁盘(确保数据不丢失)。

3.4 merge

通过每隔1秒自动刷新创建新的段，用不了多久段的数量就爆炸了。

每个段文件都会消费句柄、内存、cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。段越多，查询越慢。

ES通过后台merge段解决这个问题。小段被合并成大段，再合并成更大的段。

image.png

image.png

3.5 删除数据

如果删除，其实是把数据写到磁盘上的.del文件，然后在segemnt搜索到数据后，会在.del文件看是否有删除标记。

在merge后会物理删除。

4 ES搜索数据的工作原理是什么？

4.1 根据doc id 进行GET

• 协调节点根据id进行hash计算确认在哪个分片上
• 采用负载均衡的方式在primary shard和replica shard里查找数据

4.2 全文检索

image.png

1. 客户端发送请求到协调节点node3
2. node3向每个分片广播，比如图中广播给了r0和p1
3. 每个分片在本地执行搜索并且建立了匹配document的优先队列（priority queue），返回document的ID和它优先队列里的所有document的排序值给协调节点 Node 3 。
4. Node3 把这些值合并到自己的优先队列里产生全局排序结果。

5 在几十亿数据量级的场景下如何优化查询性能？

5.1 filesystem cache

es的数据是存在磁盘上，第1次读的时候如果没在操作系统的filesystem cache上找到，就会先去磁盘把数据放到filesystem cache里再返回给node。所以filesystem cache要足够大容纳尽可能多的index和segment file数据，这样就请求直接走内存，速度就快了。

另外，不必要的数据就别存在es里了，只把搜索用的字段数据放es。其他不用于检索的数据，可以放在hbase或者mysql数据库里。

走磁盘速度基本上都要上秒级，走内存基本上就是毫秒级了。

5.2 缓存预热

对于热点数据，每隔一段时间提前预热到filesystem cache里。

5.3 冷热分离

大量访问很少，频率很低的数据，单独写一个索引，热数据在另一个索引中。确保filesystem cache里的热数据不被频繁刷掉。

5.4 document 模型设计

es里复杂的关联语法join/nested等尽量别用，性能很低。写入es系统之前就完成关联，然后设计好document，添加一些field。

5.5 分页性能优化

es的分页性能比较差。es是分布式的，比如每页10条数据，你要查第100页的数据，实际上每个shard都会把自己的几千条数据发给协调节点，然后汇总，再从汇总结果查询到第100页的数据。

也就是说，翻页越深，各个shard拿到的数据越多，汇总的数据量也越多，性能越差。

1）不允许深度分页
2）使用es的scroll api , 游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 但是没法随意跳到任何一页