大数据-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或者更高。

1. PUT /_cluster/settings
2. {
3.   "persistent" : {
4.     "indices.store.throttle.max_bytes_per_sec" : "100mb"
5.   }
6. }

复制代码

用于控制归并线程的数目，推荐设置为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优化老的索引，将每一个分片合并为一个单独的段就很有用了，如许既可以节省资源，也可以搜索更加迅速：

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

复制代码

存储文件详解

信息检察

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

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

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

复制代码

执行效果如下图所示：

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

1. root@h121:/opt/servers/es/data/nodes/0# cd indices/
2. root@h121:/opt/servers/es/data/nodes/0/indices# ll
3. total 28
4. drwxrwxr-x 7 es_server es_server 4096 Aug 15 13:50 ./
5. drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 ../
6. drwxrwxr-x 4 es_server es_server 4096 Aug 15 11:50 GFUQVFGeR1OMxYpP84kADw/
7. drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 nP7CcjJqRGyTSRZFe-ws7Q/
8. drwxrwxr-x 3 es_server es_server 4096 Aug 15 13:50 pLcZj7mpQZ2sj489LCI8PA/
9. drwxrwxr-x 6 es_server es_server 4096 Aug 15 10:43 ppzCzxaxQAegLEM7C3W-ng/
10. drwxrwxr-x 4 es_server es_server 4096 Aug 15 10:14 wF9_Ay68Qhyx8X89TRNl0Q/
11. root@h121:/opt/servers/es/data/nodes/0/indices#

复制代码

对应的截图如下图所示：

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

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

1. cd ppzCzxaxQAegLEM7C3W-ng

复制代码

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

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

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

进入_state目次，检察当前目次下的内容，如下图所示：

1. cd _state

复制代码

执行效果如下图：

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

1. cd ..

复制代码

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

1. cd 0

复制代码

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

我们举行解释：

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

我们进入 index 数据目次：

1. cd index
2. ll

复制代码

可以检察到如下的内容：

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。