ToB企服应用市场:ToB评测及商务社交产业平台

标题: 大数据-181 Elasticsearch - 原理分析索引文档存储段合并、存储文件详解 [打印本页]

作者: 嚴華 时间: 2024-10-27 08:51
标题: 大数据-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集群的数据存储目次中，根据我们之前设置好的服务