读书笔记－ElasticSearch权威指南

ES是如何保证实时性的？

ES的每个示例都拥有一个luence，在luence中有一个段的概念，索引由一或多个段组成，每个段都是索引中可被单独检索的一部分。

当ES的flush事件触发时，新的数据会被ES作为一个新的段加入索引，于是新的数据就可以被检索到了。默认的flush间隔时1s。

那么问题来了，每次刷新都新增一个段，会不会造成查询的段过多，影响查找效率呢？

一般是不会的，ES会静默的对段进行合并，这个操作由于ES的资源控制，并不会影响到索引和查询操作。

那luence为什么要引入段的概念？

段是数据组织的单元，如果将所有的数据都直接保存在一个单元中，那么当有新数据加入的时候有两个选择：

1. 文件加锁，原地更新。有锁的开销，影响查询性能

2. 构建新索引，新索引替换旧索引。新增和修改开销巨大，实时性不能保证

于是，以段来组织索引是再正常不过的事情。

luence是如何应对删除或再索引操作的？

由于luence的数据是由段组织的，当有数据被删除时，只是将原内容标记为被删除，并没有真正的触发删除操作。

当有新内容时，是加入了一个新的段。更新操作也就自然而然的是先删除，再新增。

既然luence并没有操作原数据进行更新，那么依赖luence的ES是如何保证原子性的？

ES保证原子性的操作有两种，第一种为借用内置_version使用悲观锁的控制，这种适合总量固定的更新，比如库存。

另一种为冲突重试，这种适合对总量没有特别要求的更新，比如页面浏览量。

第一种如果_version落后于ES中数据的_version，会有异常抛出，可以反馈给业务。

第二种可以允许客户端指定重试次数，重试结束后返回异常。

ES提倡的索引切换方案是怎样的？

在ES中，允许给索引制定别名。所以鼓励的索引切换方案是利用alias。

比如实际索引名是raw0，在线上实际alias后的索引为ops。

现需要将raw0中索引的数据进行一定的变化，因此建了索引raw1.

在所以操作的时候，只需取消raw0的alias，加入raw1的alias即可。

由于上述操作开销很小，而且是原子性的，因此可以用来做索引切换。

ES多节点时，如何完成符合条件数据的汇总，会不会匹配数过多造成集群崩溃？

每个节点按相同的条件和限制进行查询，返回结果进行汇总。在分页的页面不大的情况下，不会崩溃。

举个栗子：

- 已知A、B、C三个数据节点和Client节点，要以id顺序取出所有数据中的前5个

- Client节点向三个基点分别发出查询：以id顺序取出所有数据中的前5个。

- Client将得到的所有文档按id顺序，取出前5个返回。

为什么Client节点要向每个数据节点都发出原始的查询请求呢？考虑下面的case：

1. A中的ID：[1, 2, 3, 4, 5]，B中的ID：[6, 7, 8, 9, 10]，C中的ID：[11, 12, 13, 14, 15]。此类情况（数据集中在少数的几个节点）必须向所有节点发送查询请求

2. A中的ID：[1]，B中的ID：[2]，C为空。此类情况（符合要求的条目不足）仍然需要向所有节点发送查询请求

归根结底，向所有节点发送查询消息的原因是不能保证在任意查询条件下，所有查询数据都按照相同的规则分布在所有节点中。

那么一次查询需要选出的文档数便可以确定了：选出的文档总数 ＝ 节点数 * 单个分页数

由此可以看出，在单个分页数不大的情况下，崩溃时比较困难的