Apache Cassandra 在 Facebook 的应用

"\u003Cdiv\u003E\u003Cp\u003E谁说 Facebook 弃用 Cassandra？相反 Facebook 拥有全世界最大的单个 Cassandra 集群部署，而且他们对 Cassandra 做了很多性能优化，包括 Cassandra on RocksDB 以提升 Cassandra 的响应时间。\u003C\u002Fp\u003E\u003Cp\u003E在 Instagram （Instagram是Facebook公司旗下一款免费提供在线图片及视频分享的社交应用软件，于2010年10月发布。）上，我们拥有世界上最大的 Apache Cassandra 数据库部署。我们在 2012 年开始使用 Cassandra 取代 Redis ，在生产环境中支撑欺诈检测，Feed 和 Direct inbox 等产品。起初我们在 AWS 环境中运行了 Cassandra 集群，但是当 Instagram 架构发生变化时，我们将 Cassandra 集群迁移到Facebook 的基础架构中。我们对 Cassandra 的可靠性和可用性有了非常好的体验，但是在读取数据延迟方面我们觉得他需要改进。\u003C\u002Fp\u003E\u003Cp\u003E去年 Instagram 的 Cassandra 团队开始着手这个项目，以显着减少 Cassandra 的读取延迟，我们称之为 Rocksandra。 在这篇文章中，我将描述该项目的动机，我们克服的挑战以及内部和公共云环境中的性能指标。\u003C\u002Fp\u003E\u003Ch1\u003E动机\u003C\u002Fh1\u003E\u003Cp\u003E在 Instagram 上，我们大量使用 Apache Cassandra 作为通用键值存储服务。Instagram 的大多数 Cassandra 请求都是在线的，因此为了向数亿 Instagram 用户提供可靠且响应迅速的用户体验，我们有很高的 SLA 要求。\u003C\u002Fp\u003E\u003Cp\u003EInstagram 可靠性 SLA 保持为5-9s，这意味着在任何给定时间，请求失败率应小于0.001％。为了提高性能，我们主动监控不同 Cassandra 集群的吞吐量和延迟，尤其是 P99 读取延迟。\u003C\u002Fp\u003E\u003Cp\u003E下面的图显示了一个生产 Cassandra 集群的客户端延迟。蓝线是平均读取延迟（5ms），橙色线是 P99 读取延迟（在25ms到60ms的范围内）。\u003C\u002Fp\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp1.pstatp.com\u002Flarge\u002Fpgc-image\u002F354e4d1b605a4158a2499c50ca57433e\" img_width=\"1000\" img_height=\"634\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp1.pstatp.com\u002Flarge\u002Fpgc-image\u002F3d0b60605fb14205a20a0250e1ddd229\" img_width=\"1000\" img_height=\"634\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E经过调查，我们发现 JVM 垃圾收集器（GC）对延迟峰值做出了很大贡献。我们定义了一个称为 GC 停滞百分比的度量，用于衡量Cassandra 服务器执行 GC（Young Gen GC）并且无法响应客户端请求的时间百分比。结果显示我们生产 Cassandra 服务器上的 GC 停滞百分比。在最低请求流量时间窗口期间为1.25％，在高峰时段可能高达2.5％。\u003C\u002Fp\u003E\u003Cp\u003E这表明 Cassandra 服务器实例在垃圾收集上花费 2.5％ 的运行时间，而这段时间是不能服务客户端请求的。GC 开销显然对我们的 P99 延迟有很大影响，因此如果我们可以降低 GC 停顿百分比，我们将能够显着降低P99延迟。\u003C\u002Fp\u003E\u003Ch1\u003E解决办法\u003C\u002Fh1\u003E\u003Cp\u003EApache Cassandra 是一个分布式数据库，并用 Java 编写了基于 LSM 树的存储引擎。 我们发现存储引擎中的组件，如memtable，压缩，读\u002F写路径等，在 Java 堆中创建了很多对象，并为 JVM 产生了大量开销。为了减少来自存储引擎的GC影响，我们考虑了不同的方法，并最终决定开发C++存储引擎来替换现有的引擎。\u003C\u002Fp\u003E\u003Cp\u003E我们不想从头开始构建新的存储引擎，因此我们决定在 RocksDB 之上构建新的存储引擎。\u003C\u002Fp\u003E\u003Cp\u003ERocksDB 是一个开源的，高性能嵌入式键值数据库。它是用 C++ 编写的，并为 C++，C 和 Java 提供官方 API。RocksDB 针对性能进行了优化，尤其是在 SSD 等快速存储方面。它在业界广泛用作 MySQL，mongoDB 和其他流行数据库的存储引擎。\u003C\u002Fp\u003E\u003Ch1\u003E挑战\u003C\u002Fh1\u003E\u003Cp\u003E在 RocksDB 上实现新的存储引擎时，我们克服了三个主要挑战：\u003C\u002Fp\u003E\u003Cp\u003E第一个挑战是 Cassandra 还没有可插拔的存储引擎架构，这意味着现有的存储引擎与数据库中的其他组件耦合在一起。为了在大规模重构和快速迭代之间找到平衡点，我们定义了一个新的存储引擎 API，包括最常见的读\u002F写和流接口。这样我们就可以在 API 后面实现新的存储引擎，并将其注入 Cassandra 内部的相关代码路径。\u003C\u002Fp\u003E\u003Cp\u003E其次，Cassandra 支持丰富的数据类型和表模式，而 RocksDB 提供纯粹的键值接口。我们仔细定义了编码\u002F解码算法，使得我们使用 RocksDB 数据结构来构建 Cassandra 数据模型，并支持与原始 Cassandra 相同的查询语义。\u003C\u002Fp\u003E\u003Cp\u003E第三个挑战是关于 streaming。 Streaming 在 Cassandra 这样的分布式数据库是很重要组件。每当我们从 Cassandra 集群加入或删除节点时，Cassandra 都需要在不同节点之间传输数据以平衡集群中的负载。现有的 streaming 实现基于当前存储引擎的。因此，我们必须将它们彼此分离，创建一个抽象层，并使用 RocksDB API 重新实现 streaming 传输。对于高 streaming 吞吐量，我们现在首先将数据流式传输到临时 sst 文件，然后使用 RocksDB 提取文件 API 立即将它们批量加载到 RocksDB 实例中。\u003C\u002Fp\u003E\u003Ch1\u003E性能指标\u003C\u002Fh1\u003E\u003Cp\u003E经过大约一年的开发和测试，我们已经完成了第一个版本的实现，并成功将其推广到 Instagram 中的几个生产 Cassandra 集群。在我们的一个生产集群中，P99读取延迟从60ms降至20ms。 我们还观察到该集群上的GC停滞从2.5％下降到0.3％，这减少了10倍！\u003C\u002Fp\u003E\u003Cp\u003E我们还想验证 Rocksandra 在公共云环境中是否表现良好。我们在 AWS 环境中使用三个 i3.8 xlarge EC2 实例部署了一个 Cassandra 集群，每个实例具有 32 个核，244GB内存和 带有4个nvme闪存盘的raid0。\u003C\u002Fp\u003E\u003Cp\u003E我们使用 NDBench 作为基准测试，并使用这个框架中的默认表模式：\u003C\u002Fp\u003E\u003Cpre\u003ETABLE emp (\u003Cbr\u003E emp_uname text PRIMARY KEY,\u003Cbr\u003Eemp_dept text,\u003Cbr\u003Eemp_first text,\u003Cbr\u003Eemp_last text\u003Cbr\u003E )\u003Cbr\u003E\u003C\u002Fpre\u003E\u003Cp\u003E我们将 250M 6KB 行数据预先加载到数据库中（每个服务器在磁盘上存储大约500GB的数据）。我们在 NDBench 中配置了128个读客户端和128个写客户端。\u003C\u002Fp\u003E\u003Cp\u003E我们测试了不同的工作负载并测量了 avg\u002FP99\u002FP999 读\u002F写延迟。如我们所见，Rocksandra 提供了更低且一致的读\u002F写延迟。\u003C\u002Fp\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp3.pstatp.com\u002Flarge\u002Fpgc-image\u002F2dd45f83f780443892554395e2171751\" img_width=\"1000\" img_height=\"640\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp1.pstatp.com\u002Flarge\u002Fpgc-image\u002F9df2a6389bc3431280238d722e6f4bbd\" img_width=\"1000\" img_height=\"640\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Cp\u003E我们还测试了一个只读工作负载并观察到，在类似的P99读取延迟（2ms）下，Rocksandra 读取吞吐量提高了10倍（Rocksandra为300K\u002Fs，C * 3.0为 30K\u002Fs）。\u003C\u002Fp\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp3.pstatp.com\u002Flarge\u002Fpgc-image\u002F96f87c3d3d224acf8ea72fc1614e7e40\" img_width=\"1000\" img_height=\"503\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Cdiv class=\"pgc-img\"\u003E\u003Cimg src=\"http:\u002F\u002Fp1.pstatp.com\u002Flarge\u002Fpgc-image\u002F9c740d472f484d208b6a45acf4f3fb82\" img_width=\"1000\" img_height=\"537\" alt=\"Apache Cassandra 在 Facebook 的应用\" inline=\"0\"\u003E\u003Cp class=\"pgc-img-caption\"\u003E\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E\u003Ch1\u003E未来工作\u003C\u002Fh1\u003E\u003Cp\u003E我们开源了 Rocksandra 代码库和基准框架，您可以从Github下载（https:\u002F\u002Fgithub.com\u002FInstagram\u002Fcassandra\u002Ftree\u002Frocks_3.0），在您自己的环境中试用！\u003C\u002Fp\u003E\u003Cp\u003E下一步，我们正在积极开发更多 C 功能，如二级索引，修复等。我们还在开发一个 C 可插拔存储引擎架构，以便将我们的工作贡献给Apache Cassandra 社区。\u003C\u002Fp\u003E\u003Cp\u003E本文翻译自：https:\u002F\u002Finstagram-engineering.com\u002Fopen-sourcing-a-10x-reduction-in-apache-cassandra-tail-latency-d64f86b43589\u003C\u002Fp\u003E\u003Cp\u003E作者：明惠\u003C\u002Fp\u003E\u003C\u002Fdiv\u003E"

文章来源: https://www.toutiao.com/group/6688863468486918659/