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

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

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

medcl - 今晚打老虎。

赞同来自: ouyangchucai laoyang360

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

赞同来自:

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

要回复问题请先登录注册