深入ES分片

亦凉 2022-12-19 06:17 164阅读 0赞

### 文章目录 ###

*   *   *   *   *  （1）倒排索引不可变的好处？
                 *  （2）什么是per-segment search？
                 *  （3）为什么搜索是近实时的？
                 *  （4）ES怎样保证更新持久化，即使断电也不会丢失？

##### （1）倒排索引不可变的好处？ #####

1、不需要锁。如果从来不需要更新一个索引，就不必担心多个程序同时尝试修改。

2、一旦索引被读入文件系统的缓存，它就一直在那儿，因为不会改变。只要文件系统缓存有足够的空间，大部分的读会直接访问内存而不是磁盘。这有助于性能提升。

3、在索引的声明周期内，所有的其他缓存都可用。它们不需要在每次数据变化了都重建，因为数据不会变。

4、写入单个大的倒排索引，可以压缩数据，较少磁盘IO和需要缓存索引的内存大小。

##### （2）什么是per-segment search？ #####

如何在保持不可变好处的同时更新倒排索引。我们可以使用使用多个索引。不是重写整个倒排索引，而是增加额外的索引反映最近的变化。每个倒排索引都可以按顺序查询，从最老的开始，最后把结果聚合。

Elasticsearch底层依赖的Lucene，引入了per-segment search的概念。一个段(segment)是有完整功能的倒排索引，但是现在Lucene中的索引指的是段的集合，再加上提交点(commit point，包括所有段的文件)。新的文档，在被写入磁盘的段之前，首先写入内存区的索引缓存

注意：  
需要说明，Lucene索引是Elasticsearch中的分片，Elasticsearch中的索引是分片的集合。当Elasticsearch搜索索引时，它发送查询请求给该索引下的所有分片，然后过滤这些结果，聚合成全局的结果。

per-segment search工作流程  
1、新的文档首先被写入内存区的索引缓存  
2、准备提交内存区缓存Buffer  
3、内存缓存被提交到一个新的段中，新的段加到了提交点  
4、新的提交点写入磁盘，包括新段的名称，写入磁盘  
5、当前新段已经存在于磁盘中，新段被打开，它包含的文档可以被ES检索  
6、内存的缓存被清除，等待新的文档

图示：  
一个提交点和三个索引的Lucene  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center]  
内存缓存区有即将提交文档的Lucene索引  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 1]

提交后，新的段加到了提交点，缓存被清空

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 2]

##### （3）为什么搜索是近实时的？ #####

问题：  
因为per-segment search机制，索引和搜索一个文档之间是有延迟的。新的文档会在几分钟内可以搜索，但是这明显不满足实时的要求。而per-segment search这个环节中磁盘是瓶颈，提交一个新的段到磁盘需要fsync操作，确保段被物理的写入磁盘，即使电源失效也不会丢失数据。但是fsync是消耗很大的， 它不能在每个文档被索引的时候就触发。  
ES中存在着更轻量级的方式使得新的文档可以被搜索，在ES和磁盘之间构建了文件系统缓存。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 3]

位于Elasticsearch和磁盘间的是文件系统缓存。如前所说，在内存索引缓存中的文档被写入新的段，但是新的段首先写入文件系统缓存，这代价很低，之后会被同步到磁盘，这个代价很大。但是一旦一个文件被缓存，它也可以被打开和读取，就像其他文件一样。

Lucene允许新段写入打开，好让它们包括的文档可搜索，而不用执行一次全量提交。这是比提交更轻量的过程，可以经常操作，而不会影响性能。

在Elesticsearch中，这种写入打开一个新段的轻量级过程，叫做refresh。默认情况下，每个分片每秒自动刷新一次。这就是为什么说Elasticsearch是近实时的搜索了：文档的改动不会立即被搜索，但是会在一秒内可见。

这会困扰新用户：他们索引了个文档，尝试搜索它，但是搜不到。解决办法就是执行一次手动刷新，通过API:

POST /_refresh     --refresh所有索引
    POST /blogs/_refresh    --只refresh 索引blogs

虽然刷新比提交更轻量，但是它依然有消耗。人工刷新在测试写的时有用，但是不要在生产环境中每写一次就执行刷新，这会影响性能。相反，你的应用需要意识到ES近实时搜索的本质，并且容忍它。

不是所有的用户都需要每秒刷新一次。也许你使用ES索引百万日志文件，你更想要优化索引的速度，而不是进实时搜索。你可以通过修改配置项refresh\_interval减少刷新的频率：

PUT /my_logs
    { 
      "settings": { 
        "refresh_interval": "30s"  --每30s refresh一次
      }
    }

refresh\_interval可以在存在的索引上动态更新。你在创建大索引的时候可以关闭自动刷新，在要使用索引的时候再打开它。

PUT /my_logs/_settings
    {  "refresh_interval": -1 }      -- 禁用所有自动refresh
    PUT /my_logs/_settings
    {  "refresh_interval": "1s" } <2>     -- 每秒自动refresh

##### （4）ES怎样保证更新持久化，即使断电也不会丢失？ #####

ES增加了事务日志（translog），来记录每次操作。有了事务日志，过程现在如下：  
1、当一个文档被索引，它被加入到内存缓存，同时加到事务日志  
2、每秒分片都进行refsh（内存缓冲区的文档写入到段中，但没有fsync，段被打开，使得新的文档可以搜索、缓存被清除）  
3、经过一次refresh，缓存被清除，但事务日志没有  
4、随着更多的文档加入到缓存区，写入日志，这个过程会继续  
5、事务日志会记录增长的文档  
6、当日志到达某个阈值，新的日志会创建，会进行一次全提交：  
7、flush过后，段被全提交，事务日志清除

全提交过程如下  
1、内存缓存区的所有文档会写入到新段中。  
2、清除缓存  
3、一个提交点写入硬盘  
4、文件系统缓存通过fsync操作flush到硬盘  
5、事务日志被清除

事务日志记录了没有flush到硬盘的所有操作  
当故障重启后，ES会用最近一次提交点从硬盘恢复所有已知的段，并且从日志里恢复所有的操作。

事务日志还用来提供实时的CRUD操作。当你尝试用ID进行CRUD时，它在检索相关段内的文档前会首先检查日志最新的改动。这意味着ES可以实时地获取文档的最新版本。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 4]

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

flush API可用来进行一次手动flush：

POST /blogs/_flush    -- flush索引blogs
    POST /_flush?wait_for_ongoing    -- flush所有索引，等待操作结束再返回

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/b2406090bc3b43629668e61ec2b20760.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/49582a9666ab4a939a6d4db92f143858.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201105202723116.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20201105202738796.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20201105202834647.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L09jdG9wdXMyMQ==,size_16,color_FFFFFF,t_70#pic_center