大数据-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 15 13:50 ./
drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 ../
drwxrwxr-x 4 es_server es_server 4096 Aug 15 11:50 GFUQVFGeR1OMxYpP84kADw/
drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 nP7CcjJqRGyTSRZFe-ws7Q/
drwxrwxr-x 3 es_server es_server 4096 Aug 15 13:50 pLcZj7mpQZ2sj489LCI8PA/
drwxrwxr-x 6 es_server es_server 4096 Aug 15 10:43 ppzCzxaxQAegLEM7C3W-ng/
drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 wF9_Ay68Qhyx8X89TRNl0Q/
root@h121:/opt/servers/es/data/nodes/0/indices#