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

Question

我们在 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 保持运行状态。

问题:

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

Answer 1

我在 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 的好文章这也可以帮助您规划集群大小。