如何判断一个shard的segment是否合理?

Elasticsearch | 作者 fanmo3yuan | 发布于2018年04月09日 | 阅读数:772

通过 _cat/segment API 可以获取shard的segment信息,虽然说segment个数越少越好,但是在日常读写情况下,很难真正做到很少的segment,那么如何判断索引的segment是否合理呢?通过小segment的比例可以吗
已邀请:

hapjin

赞同来自:

我也对这个问题很感兴趣。
我有一个user_v1索引如下:3.4亿个文档,56GB(不包括副本)
user_v1.png

统计了一下user_v1的Segment个数是:404个。分布如下:
docments.png

横坐标是每个Segment中包含的文档个数,注意单位是10^7。纵坐标是Segment个数。可见,大部分Segment只包含了少量的文档(估计 340个左右的Segment包含的文档个数少于1W个吧)
 
索引配置:refresh interval 是默认值1s
 
后来想了下这个问题:什么叫做合理?
如果index操作没有瓶颈,search操作的响应时间也符合业务要求,那就是合理了……管它Segment个数多少个干嘛呢?哈哈哈哈……不知其他大佬有何建议?

rochy - rochy_he@tw

赞同来自:

segment 数量与查询的效率关系还是很紧密的,
通常而言如果不影响查询,那么无需特别关心 segment 数量
 
如果说索引已经停止数据写入或者删除,
那么可以执行一次 force merge 来使得小的 segment 能够合并为大的 segment 提高查询效率
 
持续写入的索引,ES 也会根据 segment 数量来对小的 segment 进行合并,只是此时会影响查询和写入效率而已
 

fanmo3yuan

赞同来自:

segment的合理性是很难明确定义的,还是那句话in depends,业务上可以满足性能,机器资源够用,那么就是合理的。不过,segment的大小,多少确实会影响es的性能和资源。
在有持续写入的情况下,一方面segment过小产生较多的merge时,会影响到写入性能,这时通常需要调整segment的参数,降低merge的频次;另一方面,较多的segment会减少单个segment的大小,Lucene reload文件的成本会降低。
在高并发查询的时候,通常会试图降低segment个数,如果是机械硬盘,segment少会减少寻道成本,降低IO压力,ssd的话可能影响并不会这么大。过多的segment同样会消耗内存,句柄等其他资源,总体上来说,查询场景下减少segment个数是正确的

zqc0512 - andy zhou

赞同来自:

一般情况下是越少越好的。关键是不是土豪 家里有矿没有,不想搞就多上机器,多搞SSD

PythonLee - 90后IT男

赞同来自:

考虑多少个干嘛,考虑下单个segment的大小,如果太大太小都会影响性能.

要回复问题请先登录注册