ElasticSearch 社区： 假设我有一位名叫 Twetter 的客户，他今天聘请我为一个 181 字的社交媒体网站建立他们的搜索能力。
假设我无法预测未来扩展所需的分片数量，并且存储大小已经达到数十 TB。
假设我不需要编辑任何被索引的文档。这仅用于搜索。
参考上图，似乎有一些文档指向“滚动索引”ref1ref2ref3，据此我可以创建一个单一索引（例如名为 tweets1 -> N 的索引） -飞。当一个索引填满时，我可以简单地添加一台带有新索引的新机器，并将其添加到同一个集群和别名中进行搜索。
这种架构在生产中是否有效？
这种“滚动索引”架构是否有任何长期影响，而不是在该估计范围内预测分片计数和扩展？
【问题讨论】：
标签： elasticsearch
elasticsearch 中的分片只是一个 lucene 索引。 elasticsearch 索引只是 lucene 索引（分片）的集合。鉴于此，在您的情况下进行容量规划，您只需要计算出您可以在一个索引中存储多少文档，并且仍然可以获得您想要的查询性能。
消耗资源的是底层 lucene 索引。根据您的文档在 lucene 索引中的索引方式，集群中的任何单个节点都可以处理有限数量的分片。您始终可以通过向集群添加更多节点来进行扩展。只需监控资源使用情况和查询响应时间即可知道何时添加更多节点。
创建名为tweet_1、tweet_2、tweet_3 等的索引是完全合理的。向前滚动而不用担心重新分片数据。它最终完成了同样的事情。只需使用 index alias 隐藏数字即可。
确定每个分片可以存储多少个文档以获得查询性能后，然后决定您希望每个索引拥有多少个分片，然后将这些数字相乘并将索引限制在代码中的该文档数。达到上限后，您只需滚动到新索引即可。这是我在代码中所做的，以确定将文档发送到哪个索引（我有顺序 ID）：
$index = 'file_' . (int)($fid / $docsPerIndex);
请注意，我使用的是index templates，因此它可以自动创建新索引，而无需在达到上限时手动翻转。
另一个考虑因素是您将执行什么类型的查询。随着数据的增长，您有两种扩展选项。
或
请记住，如果您有顺序或可预测的 id，则 elasticsearch 可以有效地执行基于 id 的查询，而无需实际查询整个集群。如果您让 ES 自动分配 id（假设您使用的是 ES >=1.4.0），它将已经使用可预测的 id（flake ids）。这也加快了索引速度。随机 id 会造成最坏的情况。
如果您的查询是基于时间的，那么它必须在此方案下为每个查询搜索整个索引集。对于基于时间的查询，您希望根据一段时间（例如，每天或每月根据您在该时间范围内收到的数据量）滚动索引，并将它们命名为 tweets_2015_01、tweets_2015_02 等。通过这样做，您可以根据请求的搜索时间范围缩小在查询时必须搜索的索引集。