gpt4 book ai didi

在多个索引上同时以恒定速率将数据推送到 Elasticsearch 时出现性能问题

转载 作者:行者123 更新时间:2023-11-29 02:55:14 26 4
gpt4 key购买 nike

我们在 elasticsearch 上遇到了一些性能问题或异常,特别是在我们当前正在构建的系统上。

要求:我们需要为我们的多个客户捕获数据,他们将近乎实时地查询和报告他们。收到的所有文件格式相同,属性相同,并且采用平面结构(所有字段都是主要类型,没有嵌套对象)。我们希望将每个客户的信息彼此分开。

接收和查询数据的频率:我们以每秒 200 到 700 个文档的波动速率接收每个客户的数据——峰值出现在一天的中午。查询将主要是每个客户大约 1200 万份文档的聚合——直方图/百分位数以显示随时间变化的模式,以及偶尔的原始文档检索以找出特定时间点发生的事情。我们的目标是以不同的文档插入速率为 50 到 100 个客户提供服务 - 最小的可以是 20 文档/秒,最大的可以在几分钟内达到 1000 文档/秒的峰值。

我们如何存储数据:每个客户每天有一个索引。例如,如果我们有 5 个客户,那么整个星期共有 35 个索引。我们每天打破它的原因是因为它主要是最近的两个被查询,偶尔剩下的其他人。我们也这样做,以便我们可以独立于客户删除旧索引(有些可能希望保留 7 天,有些 14 天的数据)

我们如何插入:我们每秒发送 10 到 2000 个数据。一份原始文档大约有 900 字节。

环境AWS C3-Large – 3 个节点出于测试目的,所有索引均使用 10 个分片和 2 个副本创建Elasticsearch 1.3.2 和 1.4.1

我们注意到的:

如果我仅将数据推送到一个索引,当插入速率约为每秒 100 个文档时,对于插入的每个批处理,响应时间从 80 到 100 毫秒开始。我提高它,在插入速率接近每批 1 秒之前我可以达到 1600,当我将它增加到接近 1700 时,由于并发插入,它会在某个时候撞墙,时间将螺旋上升到 4或 5 秒。也就是说,如果我降低插入率,Elasticsearch 会很好地恢复。 CPU 使用率随着速率的增加而增加。

如果我同时推送 2 个索引,总共可以达到 1100 个,CPU 占用率高达 93%,大约每秒 900 个文档。如果我同时推送 3 个索引,总共可以达到 150 个,CPU 占用率上升到 95% 到 97%。我试了很多次。有趣的是,当时的响应时间约为 109 毫秒。我可以将负载增加到 900,响应时间仍然在 400 到 600 左右,但 CPU 保持运行状态。

问题:

看看我们上面的要求和发现,设计是否方便所要求的?我可以做哪些测试来了解更多信息?是否有任何我需要检查(和更改)的设置?

最佳答案

我在 AWS 上托管了数千个 Elasticsearch 集群 https://bonsai.io在过去的几年里,进行了很多听起来像这样的容量规划对话。

首先,我觉得你们这里有一个非常好的集群设计和测试平台。我的第一直觉是,您正在合理地接近 c3.large 实例的限制,并且希望尽快升级到 c3.xlarge(或更大)。

如果您的租户相对较少,则每个租户每天的指数可能是合理的。您可以考虑每天为所有租户创建一个索引,使用过滤器将搜索重点放在特定租户上。除非丢弃旧数据可以明显节省成本,否则过滤器也应该足以强制执行数据保留窗口。

按租户划分索引的主要好处是可以在不同的 Elasticsearch 集群之间移动您的租户。如果您有一些租户的使用量比其他租户大得多,这可能会有所帮助。或者降低 Elasticsearch 集群状态管理成为所有租户单点故障的可能性。

需要牢记的其他一些事项可能有助于解释您所看到的性能差异。

这里最重要的是,索引是难以置信的 CPU 瓶颈。这是有道理的,因为 Elasticsearch 和 Lucene 从根本上说只是非常奇特的字符串解析器,而您正在发送成堆的字符串。 (堆是这里合法的度量单位,对吧?)您的主要瓶颈将是 CPU 内核的数量和速度。

为了在编制索引时充分利用 CPU 资源,您应该考虑正在使用的主分片数量。我建议从三个主分片开始,以便在集群中的三个节点之间平均分配 CPU 负载。

对于生产,您几乎肯定会使用更大的服务器。目标是使您的峰值索引需求的总 CPU 负载最终低于 50%,因此您有一些额外的开销来处理您的搜索。聚合也相当耗费 CPU。额外的性能开销也有助于优雅地处理任何其他不可预见的情况。

您提到同时推送到多个索引。当批量更新到 Elasticsearch 时,我会避免并发,支持使用批量 API 进行批量更新。您可以使用集群级 /_bulk 端点为多个索引批量加载文档。让 Elasticsearch 在内部管理并发性,而不会增加解析更多 HTTP 连接的开销。

这只是对性能基准测试主题的快速介绍。 Elasticsearch 文档有一篇关于 Hardware 的好文章这也可以帮助您规划集群大小。

关于在多个索引上同时以恒定速率将数据推送到 Elasticsearch 时出现性能问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27989068/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com