关于elasticsearch:ES之Lucene中的段文件

43次阅读

共计 2437 个字符,预计需要花费 7 分钟才能阅读完成。

简介

Elasticsearch 是基于 Lucene 实现的,Lucene 中引入了按段搜寻的概念,每一个段自身就是一个倒排索引。索引在 Lucene 中除示意所有段的汇合外,还减少了提交点(Commit point)的概念,一个列出了所有已知段的文件的形容如下图:一个 Lucene 索引蕴含一个提交点和三个段。

生成

新的文档首先被增加到内存索引缓存中(In-memory buffer)。

Elasticsearch 的主动刷新每隔 1s 进行一次,一个新的段被增加到提交点并清空内存索引缓存。

当一个查问被触发,所有已知的段按程序被查问。词项统计会对所有段的后果进行聚合,以保障每个词和每个文档的关联都被精确计算。

删除 & 更新

段是不可扭转的,所以既不能把文档从旧的段中移除,也不能批改旧的段来对文档进行更新。取而代之的是,每个提交点会蕴含一个 .del 文件,文件中会列出这些被删除文档的段信息。

当一个文档被“删除”时,它实际上只是在 .del 文件中被 标记删除 。一个被标记删除的文档依然能够被查问匹配到,但它会在最终后果被返回前 从后果集中移除

文档更新也是相似的操作形式:当一个文档被更新时,旧版本文档被标记删除,文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查问匹配到,但被删除的那个旧版本文档在后果集返回前就曾经被移除。

合并

主动刷新流程每秒会创立一个新的段,这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会耗费文件句柄、内存和 cpu 运行周期。更重要的是,每个搜寻申请都必须轮流查看每个段;所以段越多,搜寻也就越慢。

Elasticsearch 通过在后盾进行段合并来解决这个问题。小的段被合并到大的段,而后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中革除。被删除的文档(或被更新文档的旧版本)不会被拷贝到新的大段中。

启动段合并不须要用户做任何事。进行索引和搜寻时会主动进行。段合并的流程:

  1. 当索引的时候,刷新(refresh)操作会创立新的段并将段关上以供搜寻应用。
  2. 合并过程抉择一小部分大小类似的段,在后盾将它们合并到更大的段中且不会中断索引和搜寻。

两个已提交(存在于磁盘上)的段和一个未提交(存在于文件系统缓存中)的段合并到一个更大段,如图形容:

合并实现后,生成的大段(已排除被标记删除的文档)被关上用来搜寻,较小的段被删除,如图形容:

性能优化

段合并的计算量宏大,可能会吃掉大量磁盘 I/O。段合并可能要很长时间能力实现,尤其是比拟大的段,所以合并在 后盾定期操作。个别状况下段合并都不会有什么影响,因为大规模段合并的概率是很小的。

不过有时候合并会连累写入速率。如果这个真的产生了,Elasticsearch 会主动 限度索引申请到单个线程里。单线程能够缩小段文件的生成速度,防止出现数以百计的段在被合并之前就生成进去。如果 Elasticsearch 发现合并连累索引了,它会记录一个申明有 now throttling indexing 的 INFO 级别信息。

Elasticsearch 的默认设置在这块比拟激进:不心愿搜寻性能被后盾合并影响。不过有时候(尤其是 SSD,或者日志场景)限流阈值太低了。

这个限流阈值默认值是 20 MB/s,对机械磁盘应该是个不错的设置。如果应用的是 SSD,能够思考进步到 100–200 MB/s。测试验证对你的零碎哪个值适合:

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

如果在做批量导入,齐全不在意搜寻,能够彻底关掉合并限流。这样让索引速度跑到你磁盘容许的极限:

PUT /_cluster/settings
{
    "transient" : {"indices.store.throttle.type" : "none"}
}

设置限流类型为 none 彻底敞开合并限流。等实现了导入,须要改回 merge 从新关上限流。

通过批改 index.translog.flush_threshold_size 设置,从默认的 512 MB 到更大一些的值,比方 1 GB。这能够在一次清空触发的时候在事务日志里积攒出更大的段。

这样以来,清空的频率变低,大段合并的频率也变低(生成了更大的段也就意味着缩小了小段合并成大段的频率)。这样会有更少的磁盘 I/O 开销和更好的索引速率。当然,批改这个配置须要对应量级的 heap 内存用以积攒更大的缓冲空间,调整这个设置的时候须要关注这点。

optimize API

强制合并 API。会将一个分片强制合并到 max_num_segments 参数指定大小的段数目。这样做的用意是缩小段的数量(通常缩小到一个),来 晋升搜寻性能

值得注意的是,optimize API 不应该被用在一个沉闷的索引————一个更新频繁索引。后盾合并流程曾经能够很好地实现工作。optimizing 会妨碍这个过程。

在特定状况下,应用 optimize API 颇有好处。例如在日志这种用例下,每天、每周、每月的日志被存储在一个索引中。老的索引本质上是只读的;它们也并不太可能会发生变化

在这种状况下,应用 optimize 优化老的索引,将每一个分片合并为一个独自的段就很有用了;这样既能够节俭资源,也能够使搜寻更加疾速:

POST /logstash-2014-10/_optimize?max_num_segments=1 

示意合并索引中的每个分片为一个独自的段

最初须要理解下,应用 optimize API 触发段合并的操作 不会受到任何资源上的限度。这可能会消耗掉你节点上全副的 I / O 资源, 使其没有余裕来解决搜寻申请,从而有可能使集群失去响应。

如果想要对索引执行 optimize,最好先应用分片调配把索引移到一个平安的节点,再执行。

参考

https://www.elastic.co/guide/…
https://www.elastic.co/guide/…

正文完
 0