Masoud Koleini, 合著者：Masoud Koleini和Paul Yang
August 18, 2021
介绍
Apache Cassandra是一个用于关键任务应用程序的开源分布式 NoSQL 数据库。Cassandra以其混合解决方案、安全性、高可扩展性和速度而闻名。它具有类似 SQL 的查询语言，称为 CQL（Cassandra 查询语言），熟悉传统 SQL 的人更容易使用。Cassandra 专门针对写入进行了优化，因此它为写入操作提供了高可扩展性和更低的延迟。
在本博客中，我们使用计算优化实例C6gd（AWS Graviton2）、C5d（英特尔 Skylake-SP 或 Cascade Lake）和C5ad（AMD EPYC 7002 系列）比较了在 AWS 云中运行的 Cassandra 的性能。所有实例类型都提供高网络带宽，并具有本地高速基于 NVMe 的 SSD 存储，可实现更快的磁盘 IO 操作。
基于 Arm Neoverse 的 AWS Graviton2 处理器
AWS Graviton2 处理器由 Amazon Web Services 使用 Arm Neoverse N1 内核定制构建，可为在 Amazon EC2 中运行的云工作负载提供最佳性价比。与类似的基于 x86 的实例相比，Graviton2 提供更好的性价比和更多的 NVMe 存储，从而允许用户以更低的价格运行他们的计算。Arm64 得到主要 Linux 发行版的支持，因此用户可以非常方便地将他们的应用程序迁移到 Graviton2 实例，以降低运营成本，同时提高性能。
今天，Graviton2 实例可用作通用 (M6g/M6gd/T4g)、计算优化 (C6g/C6gd/C6gn) 和内存优化 (R6g/R6gd/X2gd) 类型。用户可以根据他们计划运行的应用程序选择他们的实例类型，与类似的第 5 代 x86 实例相比，这将提供高达 40% 的性价比。
测试环境
基准测试针对 Cassandra 的单个实例运行。我们使用YCSB (Yahoo! Cloud Serving Benchmark)作为基准工具来报告 INSERT、UPDATE 和 RMW（读-修改-写）操作的指标。YCSB 在 AWS 中的一个单独实例上运行，但在与 Cassandra 相同的集群和置放群组中，以将延迟降至最低。
AWS 实例设置
Cassandra 实例和 YCSB 负载生成器都在 2xlarge R 系列实例上运行。实例 C6gd、C5d 和 C5ad 配备 8 个 vCPU、16 GiB 内存、NVMe SSD 存储和高达 10 Gbps 的网络带宽。所有实例都运行 Ubuntu 20.04 作为操作系统。
负载生成器设置
YCSB 工作负载分两个阶段执行，加载和事务。第一个阶段定义要插入数据库的数据，第二个阶段定义操作。工作负载的参数可以作为输入传递或在工作负载文件中定义。我们使用工作负载 F进行测试，它针对读取和读取-修改-写入操作的 50:50 比率对数据库进行基准测试。我们通过将“recordcount”和“operationcount”参数更改为 200K 来修改工作负载。对于每个测试的实例类型，我们使用相同的实例类型运行负载生成器设置（例如，为了测试 c6g.2xlarge，我们在 c6g.2xlarge 实例上运行负载生成器）。
Apache Cassandra 设置
对于这个基准测试，我们使用了 Cassandra 4.0-RC1（发布时的最新版本）并在 OpenJDK 11 上运行它。在 Cassandra 配置文件中，参数 data_file_directories 和 commitlog_directory 被更改为指向挂载的 NVMe 目录在实例上。此外， 在运行负载生成器之前，在 Cassandra 中创建了 所需的“usertable”。
性价比比较
我们将从我们发现的性价比总结开始，然后是下面的性能和延迟结果。
按需定价用于我们的性价比计算，使用测试时公布的按需定价。在所有测试的实例中，AWS Graviton2 的每小时成本最低。
以下图表显示了 Graviton2 与其他 x86 实例类型在发布时线程数分别为 1、8、16、32、64、96 和 120 的成本效益。左轴是 INSERT 和 RMW 操作的性价比，右轴是 Graviton2 与 x86 实例的改进百分比。
图 1 和图 2 显示，当用户将他们的 Cassandra 数据库迁移到基于 AWS Graviton2 的实例时，他们在 INSERT 和 RMW 操作上的每美元性能可以提高 15% 到 46%。
基准性能结果
YCSB 报告读取、更新和其他操作类型的延迟和吞吐量等指标。在本博客中，我们提供了有关 INSERT 和 RMW 工作负载的指标。YCSB 分两个阶段运行：
- 将数据加载到数据库中（收集的插入延迟/吞吐量）
- 运行工作负载（收集的读取/更新延迟/RMW 吞吐量）
对于每个阶段，我们都展示了 99% 的延迟和吞吐量图。Cassandra 在 OpenJDK11 上运行，每个图都比较了 AWS Graviton2 和 x86 实例上的测量结果，线程数分别为 1、8、16、32、64、96 和 120。
插入结果
下图显示了三种类型的实例和不同线程数的 INSERT 延迟（99%）和吞吐量。这些指标由 YCSB 在将数据加载到 Cassandra 中时收集。
下图显示了 Graviton2 对 x86 实例的 INSERT 操作的改进百分比。
如图 5 和图 6 所示，对于大多数线程数，与 C5d 相比，Graviton2 的插入延迟降低了 17%，吞吐量提高了 9.6%。与 C5ad 实例相比，Graviton2 的表现甚至更好，插入延迟降低了 37%，吞吐量提高了 30%。对于 x86 实例，吞吐量饱和发生在 32 个线程，而 Graviton2 继续扩展到 64 个线程。
RMW结果
下图显示了不同线程计数的 READ/UPDATE 延迟和 RMW 吞吐量的 RMW 结果。RMW 工作负载模拟用户从 Cassandra 读取数据并将修改后的值写回数据库的操作。
以下图表绘制了 Graviton2 对 x86 实例上的 READ-MODIFY-WRITE/READ 操作的改进：
与 INSERT 一样，AWS Graviton2 实例的性能与 x86 实例相似或更好，读取延迟最多可降低 60%。虽然对于某些线程数，C5d 吞吐量最多可提高 7.9%，但 Graviton2 的性能比 C5ad 高 30%。对于 RMW，所有经过测试的实例都在线程数约为 64 时遇到吞吐量饱和。
以下图表绘制了 Graviton2 对 x86 实例上的 READ-MODIFY-WRITE/UPDATE 延迟的改进：
在这里，我们看到与基于 x86 的实例相比，Graviton2 实例的更新延迟优势高达 42%。RMW-UPDATE 结果确实显示了 Graviton2 和 x86 之间的更多奇偶校验，基于 x86 的实例在某些线程数上显示出更低的延迟。
结论
我们的基准测试表明，对于大多数线程数，Cassandra 上的 INSERT 延迟在 c6gd (AWS Graviton2) 上较低；分别比 C5d（英特尔）和 C5ad（AMD）高出 17% 和 37%。基准测试还显示，对于 32 或更高的线程数，Graviton2 上的读取延迟比 x86 有所改善；高达 60%。Graviton2 的更新延迟改进高达 42%。
在 Graviton2 上运行的 Cassandra 的插入吞吐量始终高于 x86，线程数为 32 及以上（当 x86 上发生饱和时）。对于 RMW，C6gd 和 C5d 实例的吞吐量相似。但是，与 C5ad 实例相比，Cassandra 在 C6gd 上的 RMW 吞吐量最高可以超过 30%。
除了在用户将他们的 Cassandra 数据库迁移到 Graviton2 时体验到更高的性能之外，与等效的 x86 实例相比，他们还享受支付更低的小时费率。在 AWS Graviton2 上运行 Cassandra 时，对于不同线程数的 INSERT 和 RMW 操作，性价比优势从 15% 到 46% 不等。
AWS Graviton2 在广泛的工作负载中显示出显着的性能和性价比优势。其中包括H.264 视频编码、memcached、Elasticsearch等。许多组织发现，通过将工作负载迁移到 Graviton2，他们可以在短短几天内实现有意义的性能和成本收益。AWS 目前正在赞助Graviton 挑战赛，为通过将应用程序迁移到 Graviton2 来展示优势的团队提供折扣和奖品。比赛将于 8 月 31 日结束，但我们鼓励任何读者查看。
