我被要求通过“外推”我们拥有的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在内部做的事情远不止是访问每个文档,计算分数或聚合,然后进入下一个,下一个,最终返回结果。它使用许多工具来帮助限制它必须做的工作量,这使得可靠地预测性能变得非常困难。我的十亿个文档可能会与你的表现非常不同,即使它们的大小大致相同。
我能建议的最佳选择是尝试模拟虚假数据--也许使用在线生成器,或者根据有限的数据集中的统计数据按程序创建一些数据--并用它来测试性能。它可能并不完美,但它会给予你一个比这里任何人都现实得多的答案。