原文地址: https://www.elastic.co/guide/cn/elasticsearch/guide/current/kagillion-shards.html, 版权归 www.elastic.co 所有
英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/kagillion-shards.html
英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/kagillion-shards.html
请注意:
本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。
本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。
海量分片 (Kagillion Shards)edit
当新手们在了解过 分片预分配 之后做的第一件事就是对自己说:
我不知道这个索引将来会变得多大,并且过后我也不能更改索引的大小,所以为了保险起见,还是给它设为 1000 个分片吧… |
||
-- 一个新手的话 |
一千个分片——当真?在你买来 一千个节点 之前,你不觉得你可能需要再三思考你的数据模型然后将它们重新索引吗?
一个分片并不是没有代价的。记住:
- 一个分片的底层即为一个 Lucene 索引,会消耗一定文件句柄、内存、以及 CPU 周期。
- 每一个搜索请求都需要命中索引的每一个分片的副本,如果每一个分片都处于不同的节点还好, 但如果多个分片都需要在同一个节点上竞争相同的资源就有些糟糕了。
- 用于计算相关度的词项统计信息是基于分片的。如果有许多分片,但每一个分片中都只有很少的数据,会导致相关度变得很低。
稍微做一点预分配是好的。但大量分片(比如上千个分片)就有些糟糕。我们很难去定义多少个分片算是过多,这取决于它们的大小以及如何去使用它们。 一百个分片但很少使用也还好,两个分片但非常频繁地使用有可能就有点多了。 监控你的节点保证它们留有足够的空闲资源来处理一些异常的情景。
横向扩展应当分阶段进行。为下一阶段准备好足够的资源。 只有当你进入到下一个阶段,你才有时间思考需要作出哪些改变来达到这个阶段。