亚马逊AWS官方博客
通过 Amazon OpenSearch Service 上的 AWS Graviton2 实例提高性能
Amazon OpenSearch Service(Amazon Elasticsearch Service 的下一代产品)是 AWS 为 OpenSearch 提供的一项完全托管式服务。它是一个开源搜索和分析套件,用于广泛的使用场景,例如实时应用程序监控、日志分析和网站搜索。
在运行 OpenSearch Service 域时,您可以从适合工作负载的主节点和数据节点的各种实例中进行选择:通用、计算优化、内存优化或存储优化。随着每一代新产品的发布,Amazon OpenSearch Service 带来了更好的性价比。
Amazon OpenSearch Service 现在支持 AWS Graviton2 实例:通用型(m6G)、计算优化型(c6g)、内存优化型(r6g)和带附加磁盘的内存优化型(R6gD)。与当前一代基于英特尔处理器的相应实例(M5、C5、R5)相比,这些实例的索引吞吐量提高了 38%,索引延迟减少了 50%,查询性能提高了 40%(取决于实例系列和大小)。
AWS Graviton2 实例系列包括几项新的性能优化,例如每个内核的缓存更大、比同类 x86 实例更高的 Amazon Elastic Block Store(Amazon EBS)吞吐量、完全加密的 RAM 等。您可以通过立即预置或迁移 OpenSearch Service 实例,轻松从这些优化中受益。
与基于英特尔的第五代实例相比的性能分析
我们使用 AWS Graviton2 实例对第五代基于英特尔的实例进行了测试,并衡量了性能改进。我们的设置包括两个六节点域、三个专用主节点和三个数据节点,运行 Elasticsearch 7.10。对于基于英特尔的设置,我们将 c5.xlarge 用于主节点,将 r5.xlarge 用于数据节点。同样,在基于 AWS Graviton2 的设置中,我们将 c6g.xlarge 用于主节点,将 r6g.xlarge 用于数据节点。两个域都启用了三个可用区并启用了 VPC,每个节点都具有高级安全性和连接了 512 GB 的 EBS 卷。每个索引有六个分片和一个副本。
数据集包含 2,000 个具有平面文档结构的文档。每个文档有 20 个字段:1 个日期字段、16 个文本字段、1 个浮点型字段和 2 个长整型字段。使用随机样本动态生成文档,所以语料库是无限的。
对于摄入,我们使用了负载生成主机,其中每个批次请求都有 4 MB 的有效负载(每个请求大约有 2,048 个文档)和 9 个客户端。
我们将一个查询生成主机与一个客户端一起使用。我们混合运行了低延迟查询(大约 10 毫秒)、中等延迟查询(100 毫秒)和高延迟查询(1,000 毫秒):
- 低延迟查询 – 这些是全部匹配查询。
- 中等延迟查询 – 这些是多重匹配查询或基于一个随机选择关键字的筛选条件的查询。在日期直方图中聚合结果并按降序摄入时间戳排序。
- 高延迟查询 – 这些是多重匹配查询或基于五个随机选择关键字的筛选条件的查询。使用两种聚合对结果进行聚合:在基于摄入时间戳且间隔为 3 小时的日期直方图,以及基于摄入时间戳且间隔为 1 分钟的日期直方图中聚合。
我们运行了 60 分钟的试机时间,然后是 3 小时的 90/10 摄入,以便查询混合了 20% 低延迟、50% 中等延迟和 30% 高延迟查询的工作负载。发送到集群的负载量完全相同。
图表和结果
当以相同的吞吐量摄入文档时,与基于英特尔的域相比,AWS Graviton2 域的延迟要低得多,如下图所示。即使延迟为 p99,AWS Graviton2 域的延迟也始终低于基于英特尔的域的 p50 延迟。此外,AWS Graviton2 延迟比基于英特尔的实例更加一致,可提供更可预测的用户体验。
当以相同的吞吐量查询文档时,AWS Graviton2 域的性能优于基于英特尔的实例。AWS Graviton2 的 p50 延迟优于英特尔实例的 p50 延迟。
同样,AWS Graviton2 的 p99 延迟也好于基于英特尔的实例。请注意,在下图中,随着时间的推移,由于语料库规模增长,导致延迟增加。
结论
正如我们的性能分析所示,与基于第五代英特尔处理器的实例相比,基于 AWS Graviton2 的全新实例始终能提供更好的性能。试试这些新实例,将它们的表现告诉我们!
与往常一样,我们非常欢迎大家向我们提供反馈。