我被要求通过“外推”我们拥有的10 M文档的实际索引来估计1B文档的虚构ES索引的查询吞吐量下降。
保持事情非常简单-假设一个3节点Elasticsearch集群，其中一个索引包含1000万个静态文档（没有进一步插入或删除文档）。平均查询性能为每秒100个查询。
现在，使用相同的集群，您有一个包含10亿个静态文档的索引（假设所有文档的大小都差不多）。如果所有事情都假设是线性的，那么您将看到每秒1个查询，因为1B是100 x10 M。但我忍不住想它不可能是那样的直线b/当然，搜索100个文档的索引不会比查询1000个文档慢10倍......所以也许答案是它在某种程度上真的是对数的？
这里的任何指导都将是非常有帮助的，因为在这一点上，我所知道要做的就是把我们目前的QPS率乘以100，这将使我们的QPS率处于非常糟糕的位置。
1条答案
按热度按时间kyxcudwk1#
我已经与Elasticsearch合作了足够长的时间，能够真正，真正，深刻地理解这个问题的来源，但是你会一次又一次地偶然发现的答案是真实的：你只需要试一下就知道了。
事实上，您是对的。几乎可以肯定，您在处理更多文档时的实际性能不会呈线性增长。实际上，查询性能取决于许多因素，包括（但肯定不限于）：
1.查询开销，它在不同的文档数量上或多或少保持不变（或者 * 最多 * 随着您访问的索引数量而变化）。
1.在索引布局中，假设你的十亿个文档没有线性缩放的 unique 术语数，实际的索引不会随着每个额外的文档而在大小和复杂性上缩放。
1.缓存，很明显，它在各种其他变量下的行为都不同。
Elasticsearch在内部做的事情远不止是访问每个文档，计算分数或聚合，然后进入下一个，下一个，最终返回结果。它使用许多工具来帮助限制它必须做的工作量，这使得可靠地预测性能变得非常困难。我的十亿个文档可能会与你的表现非常不同，即使它们的大小大致相同。
我能建议的最佳选择是尝试模拟虚假数据--也许使用在线生成器，或者根据有限的数据集中的统计数据按程序创建一些数据--并用它来测试性能。它可能并不完美，但它会给予你一个比这里任何人都现实得多的答案。