Shard大小官方推荐值为20-40GB, 具体原理呢？

Elasticsearch | 作者 jeffreyji | 发布于2018年12月12日 | 阅读数：5340

分享到：QQ空间新浪微博微信 QQ好友印象笔记有道云笔记

As titled, Shard大小超过40GB后，读写速度迅速下降，具体是什么原因导致呢？

2 个回复

medcl - 今晚打老虎。

赞同来自: ouyangchucai 、laoyang360 、su_san 、lbx6z

Lucene 底层没有这个大小的限制，20-40GB 的这个区间范围本身就比较大，经验值有时候就是拍脑袋，不一定都好使。

Elasticsearch 对数据的隔离和迁移是以分片为单位进行的，分片太大，会加大迁移成本。
一个分片就是一个 Lucene 的库，一个 Lucene 目录里面包含很多 Segment，每个 Segment 有文档数的上限，Segment 内部的文档 ID 目前使用的是 Java 的整型，也就是 2 的 31 次方，所以能够表示的总的文档数为Integer.MAX_VALUE - 128 = 2^31 - 128 = 2147483647 - 1 = 2,147,483,519，也就是21.4亿条。同样，如果你不 force merge 成一个 Segment，单个 shard 的文档数能超过这个数。
单个 Lucene 越大，索引会越大，查询的操作成本自然要越高，IO 压力越大，自然会影响查询体验。
具体一个分片多少数据合适，还是需要结合实际的业务数据和实际的查询来进行测试以进行评估。

ouyangchucai - Elasticsearch中文社区钉钉群号 : 21737292

单个分片（shard）是一个完整的Lucene索引，elastic工程师推荐单个分片大小10-40GB是经验值，这样集群的索引分片数不会过多、单个分片不会太大。单个分片如果太大（生产环境见过单个分片超过1TB），查询可能会出现超时，副本调整时可能多个分片同时写入一个节点，导致节点磁盘占满。单个分片如果太小，可能导致分片数过多（生产环境见过1个索引设置上千个分片），每个查询请求都要从多个分片获取查询结果、再合并结果取top N返回给客户端，检索响应时间会比较长。

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

Shard大小官方推荐值为20-40GB, 具体原理呢？

2 个回复

发起人

活动推荐

相关问题

问题状态

Shard大小官方推荐值为20-40GB, 具体原理呢？

与内容相关的链接

2 个回复

发起人

活动推荐

相关问题

问题状态