大数据-181 Elasticsearch - 原理剖析 索引文档存储段合并、存储文件详解

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

• Hadoop（已更完）
• HDFS（已更完）
• MapReduce（已更完）
• Hive（已更完）
• Flume（已更完）
• Sqoop（已更完）
• Zookeeper（已更完）
• HBase（已更完）
• Redis （已更完）
• Kafka（已更完）
• Spark（已更完）
• Flink（已更完）
• ClickHouse（已更完）
• Kudu（已更完）
• Druid（已更完）
• Kylin（已更完）
• Elasticsearch（正在更新…）

章节内容

上节我们完成了如下的内容：

• Elasticsearch 索引写入 原理剖析
• Elasticsearch 近实时搜索 原理剖析

索引文档存储段合并

段合并机制

由于自动刷新流程每秒创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦，每一个段都会消耗文件句柄、内存、CPU运行周期。更重要的是，每个搜索请求必须轮流检查每个段，所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题，小的段合并到大的段，然后这些大的段被合并到更大的段，段合并的时候会将那些旧的已删除文档从文件系统中清除，被删除的文档（或被更新文档的旧版本）不会拷贝到新的大段中。
启动段合并在进行索引和搜索时会自动进行，这个流程像在下图中提到的一样工作：

• 第一步：当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用
• 第二步：合并进程选择一小部分大小相似的段，并且在后台将他们合并到更大的段中，这并不会中断索引和搜索。

两个提交了的段和一个未提交的段正在合并到一个更大的段：

第三步：合并完成时的活动：

• 新的段被刷新（flush）到了磁盘，写入一个包含新段且排除旧的和较小的段的新提交点
• 新的段被打开用来搜索
• 老的段被删除 一旦合并结束，老的段被删除

合并大的段需要消耗大量的 I/O和CPU资源，如果任其发展会影响搜索性能，Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好的执行。
默认情况下，归并线程的限速配置：indices.store.throttle.max_bytes_per_sec是20MB。
对于写入量较大，磁盘转速较高，甚至使用SSD盘的服务器来说，这个限速是明显过低的。对于 ELK Stack应用，建议可以适当调大到100MB或者更高。

PUT/_cluster/settings
{"persistent":{"indices.store.throttle.max_bytes_per_sec":"100mb"}}

用于控制归并线程的数目，推荐设置为CPU核心数的一半，如果觉得自己磁盘性能跟不上，可以降低配置，免得IO性能瓶颈。（index.merge.scheduler.max_thread_count）

归并策略

归并策略 policy
归并线程是按照一定的运行策略来挑选Segment进行归并的，主要有以下的几条：

• index.merge.policy.floor_segement 默认2MB，小于这个大小的Segment，优先被并归
• index.merge.policy.max_merge_at_once 默认一次最多归并10个 Segment
• index.merge.policy.max_merge_at_once_explicit 默认optimize 时一次最多归并30个Segment
• index.merge.policy.max_merged_segment 默认5GB，大于这个大小的Segment，不用参与归并，optimize除外。

Optimize API

Optimize API大可看做强制合并API，它将一个分片强制合并到max_num_segments参数指定大小的段数目，这样做的意图是减少段的数量（通常减少到一个），来提升性能。在特定情况下，使用OptimizeAPI颇有益处。
例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。老的索引实质上是只读的，它们也并不太可能发生变化，在这种情况下，使用Optimize优化老的索引，将每一个分片合并为一个单独的段就很有用了，这样既可以节省资源，也可以搜索更加迅速：

POST /Logstash-2024-08/_optimize?max_num_segments=1

存储文件详解

信息查看

通过 ES-Head 插件可以查看到一个索引分片的信息，图中一个绿色的方块就代表一个分片Shard。
ES使用Lucene来处理Shard级别的索引和查询，因此数据目录中的文件由Elasticsearch和Lucene共同编写。
Lucene负责编写和维护Lucene索引文件，而Elasticsearch在Lucene之上编写与功能相关的元数据，例如字段映射，索引设置和其他集群元数据，用户和支持功能由Elasticsearch提供。

存储目录

我们登录到服务器上，进入到ES集群的数据存储目录中，根据我们之前配置好的服务

cd /opt/servers/es/data/nodes/0

执行结果如下图所示：

我们进入 indices 目录，这个目录下的数据有：

root@h121:/opt/servers/es/data/nodes/0# cd indices/
root@h121:/opt/servers/es/data/nodes/0/indices# ll
total 28
drwxrwxr-x 7 es_server es_server 4096 Aug 1513:50 ./
drwxrwxr-x 4 es_server es_server 4096 Aug 1510:14 ../
drwxrwxr-x 4 es_server es_server 4096 Aug 1511:50 GFUQVFGeR1OMxYpP84kADw/
drwxrwxr-x 4 es_server es_server 4096 Aug 1510:14 nP7CcjJqRGyTSRZFe-ws7Q/
drwxrwxr-x 3 es_server es_server 4096 Aug 1513:50 pLcZj7mpQZ2sj489LCI8PA/
drwxrwxr-x 6 es_server es_server 4096 Aug 1510:43 ppzCzxaxQAegLEM7C3W-ng/
drwxrwxr-x 4 es_server es_server 4096 Aug 1510:14 wF9_Ay68Qhyx8X89TRNl0Q/
root@h121:/opt/servers/es/data/nodes/0/indices# 

对应的截图如下图所示：

如何找到它们的对应关系呢？
可以在ES-Head中，点击索引的Info => IndexStatus => 弹窗中有一个 UUID，这个就是我们需要的值，对应的关系如下图所示：

我们需要的是进入这个目录：（你的和我的不一样）：

cd ppzCzxaxQAegLEM7C3W-ng

目录当中的内容如下图所示：

我们对上述的内容进行解释：

• 0、1、3 是标识 shard编号
• _state 存储了索引状态，包括setting，mapping等文件

进入_state目录，查看当前目录下的内容，如下图所示：

cd _state

执行结果如下图：

我们回到上一级，回到刚才的数字编号目录（0、1、3文件夹）

cd..

执行结果如下，有0、1、3，我们随便进入一个

cd0

我们进入文件夹之后，可以看到下面有这些内容：

我们进行解释：

• index ES的数据目录
• _state 当前shard的信息，比如是主、副分片等信息
• translog保证数据写入的安全事务日志数据

我们进入 index 数据目录：

cd index
ll

可以查看到如下的内容：

我们对当中的文件内容进行解释：