用了Elasticsearch，一口气上5T

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

Elasticsearch | 作者 fanmo3yuan | 发布于2018年04月09日 | 阅读数：5401
分享到：QQ空间新浪微博微信QQ好友印象笔记有道云笔记
通过 _cat/segment API 可以获取shard的segment信息，虽然说segment个数越少越好，但是在日常读写情况下，很难真正做到很少的segment，那么如何判断索引的segment是否合理呢？通过小segment的比例可以吗
2018-04-09 添加评论

没有找到相关结果

    已邀请:

    rochy - rochy_he

    赞同来自: su_san

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

    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个数多少个干嘛呢？哈哈哈哈……不知其他大佬有何建议？
    2019-03-13 0 0
    分享

    fanmo3yuan

    赞同来自:

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

    zqc0512 - andy zhou

    赞同来自:

    一般情况下是越少越好的。关键是不是土豪 家里有矿没有，不想搞就多上机器，多搞SSD
    2019-03-14 0 1
    分享

    PythonLee - 90后IT男

    赞同来自:

    考虑多少个干嘛,考虑下单个segment的大小,如果太大太小都会影响性能.
    2019-03-14 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    Copyright © 2024 · CC BY-NC-SA 3.0

    本站服务器及带宽由 提供赞助