小索引的 Elasticsearch 分片分配
Elasticsearch shard allocation for small indices
我有一个 elasticsearch 设置，其中包含 192 个活动索引，每个索引从几百 mb 到 5gb 不等。我读到，对于具有 1gb 索引的 logstash 用例，您应该只使用 1 个分片。我的设置的不同之处在于我将有更多的用户（估计最多 100 个）期望快速响应时间。我打算拥有 1 个副本以确保可靠性。
每个索引 1 个分片是否仍然适合我的用例？
看看这个博客：https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index。他对分片和分片大小有很多很好的建议。
但是，您真正应该问自己的问题是：改变有多容易？当涉及到大小调整和可扩展性时，答案通常是 "it depends" - 而真正的问题是：您可以多快重新配置？
这可能例如意味着您以某种方式设计您的应用程序，允许快速 re-spooling 数据进入新索引，您使用别名以便您实际上可以更改这些东西，您的数据所在的位置（不仅仅是在 Elastic 中，我希望）等
通过构建一个系统 - 从一开始 - 以便您可以快速重建索引使您能够试验大小 - 更重要的是 - 根据您的需要更改它们。
一句话：是的
创建多个主分片的需要源于隔离文档、极端计数（例如，当您处于数十亿文档量时）或提高写入吞吐量（在更多地方写入文档，从而减轻个人负担）。
在实践中，您希望根据您的用例进行分片，除非您是前两种情况之一（隔离或极端计数）。
- 你阅读量大吗？
- 你写字重吗？ （不太常见，但确实会发生）
如果您的阅读量很大，就像大多数用例一样，那么减少分片将通过限制请求大小（减少查看的地方）来帮助您。鉴于您的分片大小也相对较小（我认为 5 GB 以下的任何东西都相对较小），您可以轻松地拥有一个 primary 分片并且它应该有利于您通过这样做搜索性能。
共享相同映射但也很小 ("few hundred MBs") 的索引，如果您搜索它们，可能应该合并。如果它们是独立的，那么它真的没有什么区别，隔离听起来像是一种很好的做法，但代价是稍微膨胀你的集群状态（每个索引）。
我有一个 elasticsearch 设置，其中包含 192 个活动索引，每个索引从几百 mb 到 5gb 不等。我读到，对于具有 1gb 索引的 logstash 用例，您应该只使用 1 个分片。我的设置的不同之处在于我将有更多的用户（估计最多 100 个）期望快速响应时间。我打算拥有 1 个副本以确保可靠性。
每个索引 1 个分片是否仍然适合我的用例？
看看这个博客：https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index。他对分片和分片大小有很多很好的建议。
但是，您真正应该问自己的问题是：改变有多容易？当涉及到大小调整和可扩展性时，答案通常是 "it depends" - 而真正的问题是：您可以多快重新配置？
这可能例如意味着您以某种方式设计您的应用程序，允许快速 re-spooling 数据进入新索引，您使用别名以便您实际上可以更改这些东西，您的数据所在的位置（不仅仅是在 Elastic 中，我希望）等
通过构建一个系统 - 从一开始 - 以便您可以快速重建索引使您能够试验大小 - 更重要的是 - 根据您的需要更改它们。
一句话：是的
创建多个主分片的需要源于隔离文档、极端计数（例如，当您处于数十亿文档量时）或提高写入吞吐量（在更多地方写入文档，从而减轻个人负担）。
在实践中，您希望根据您的用例进行分片，除非您是前两种情况之一（隔离或极端计数）。
- 你阅读量大吗？
- 你写字重吗？ （不太常见，但确实会发生）
如果您的阅读量很大，就像大多数用例一样，那么减少分片将通过限制请求大小（减少查看的地方）来帮助您。鉴于您的分片大小也相对较小（我认为 5 GB 以下的任何东西都相对较小），您可以轻松地拥有一个 primary 分片并且它应该有利于您通过这样做搜索性能。
共享相同映射但也很小 ("few hundred MBs") 的索引，如果您搜索它们，可能应该合并。如果它们是独立的，那么它真的没有什么区别，隔离听起来像是一种很好的做法，但代价是稍微膨胀你的集群状态（每个索引）。