秒杀 Redis 的 KVS 数据库上云了！伯克利重磅开源 Anna 1.0

天下武功，唯快不破。今年 3 月份，伯克利 RISE 实验室推出了最新的键值存储数据库 Anna，提供了惊人的存取速度、超强的伸缩性和史无前例的一致性保证。Anna 论文也被评为"Best of ICDE 2018"，其加长版即将应邀发表在 IEEE TKDE 期刊上。Anna 一经推出即在业界引发热烈讨论（AI 前线报道回顾 https://mp.weixin.qq.com/s/3WmGpZkEuSz-ox_2CPCsqg "> 伯克利推出世界最快的 KVS 数据库 Anna：秒杀 Redis 和 Cassandra）。不少读者关心它何时开源、后续有什么新的进展。今天，AI 前线给大家带来了 Anna 的最新消息，过去这半年里，伯克利 RISE 实验室对 Anna 的设计进行了重大变更，新版本的 Anna 能够更好地在云端扩展。实验表明，无论是在性能还是成本效益方面，Anna 都表现突出，它明显优于 AWS ElastiCache 的 memcached 以及较早之前的 Masstree，也比 AWS DynamoDB 更具成本优势。与此同时，Anna 所有源码也正式登陆 Github，开放给所有开发者。

背景

在之前的一篇博文中，我们介绍了 Anna 系统，它使用了一个核心对应一个线程的无共享线程架构，通过避免线程间的协调来实现闪电般的速度。Anna 还使用晶格组合来实现多样的无协调一致性级别。第一个版本的 Anna 吊打现有的内存 KV 存储系统：它的性能优于 Masstree 700 倍，优于 TBB 800 倍。你可以重温之前的博文（ https://databeta.wordpress.com/2018/03/09/anna-kvs/ ） ，或者阅读完整的论文（ http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf ）。我们将第一个 Anna 版本称为“Anna v0”。在这篇文章中，我们介绍如何将这个最快的 KV 存储系统变得极具成本效益和适应性。

现如今，公共基础设施云用户可选择的存储系统真是太多了。AWS 提供两种对象存储服务（S3 和 Glacier）和两种文件系统服务（ EBS 和 EFS），另外还有七种不同的数据库服务，从关系数据库到 NoSQL 键值存储。真是花样繁多，令人眼花缭乱，用户自然会问，哪个服务才适合他们。最直接（然而并不乐观）的答案是，把它们全都用起来就对了。

这些存储服务都提供了非常有限的成本与性能之间的权衡。例如，AWS ElastiCache 速度很快，但很贵，而 AWS Glacier 虽然便宜，但速度较慢。因此，用户门面对一个窘境：他们必须要么放弃节约成本的目标，大规模部署高性能存储集群，要么放弃性能，利用低成本的系统例如 DynamoDB 或者 S3。

更糟糕的是，大多数实际应用展现出偏斜的数据访问模式。频繁被访问的数据是“热”数据，其他则为“冷”数据，而这些服务要么是专门为“热数据”而设计，要么专门为“冷数据”而设计。因此，不想在性能或成本上妥协的用户必须手动将这些解决方案拼凑在一起，跟踪服务间的数据和请求，以及管理不同的 API，并做出一致性保证。

更糟糕的是，高性能的云存储产品不具备弹性：向集群添加资源或从集群中移除资源都需要人工干预。这意味着云开发者们设计并实现自定义解决方案来监控工作负载变化、修改资源分配以及在存储引擎之间移动数据。

这是非常糟糕的。应用程序开发人员不断被迫重新发明轮子，而不是把精力放在他们最关心的指标上：性能和成本。我们想要改变这种现状。

Anna v1

我们借助 Anna v0 这个内存存储引擎来解决上述的云存储问题。我们的目标是将最快的 Anna 同时发展成为最具适应性和成本效益的 KV 存储系统。我们向 Anna 中添加了 3 个关键的机制：垂直分层、水平弹性和选择性复制。

Anna v1 的核心组件是监控系统和策略引擎，可实现工作负载的响应性和适应性。为了满足用户定义的性能目标（ 请求延迟）和成本，监控服务对工作负载变化进行监控和调整。存储服务器会收集请求和数据的统计信息。监视系统定期搜索和处理这些数据，策略引擎基于这些统计信息执行上述的三个操作。操作的触发规则很简单：

• 弹性：为了让系统适应变化的工作负载，系统需要能够根据工作量自动扩展和收缩。当一个层达到计算或存储容量最大值时添加节点，当某个节点明显得不到未充分利用时将其移除。

• 选择性复制：在实际工作环境下，访问量很大的 key 需要被广泛的复制到多个节点和 CPU 核从而提高性能。Anna v0 启用了 key 的多主复制，但在复制所有 key 时提供了一个固定的复制因子。正如读者们想象的，这是一个成本很大的设计。在 Anna v1 中，监控服务仅选择性的复制访问次数高的“热”key 而不复制“冷”key，从而减小存储成本。

• 升级和降级：与传统的内存层次结构中一样，热数据应该保存在更快的存储介质中提高访问效率，冷数据应该保存在较慢的存储介质中节约成本。我们的监测服务会根据数据的热度变化自动将它们移至合适的存储介质。

为了实现这些机制，我们不得不对 Anna 的设计做出两个重大变更。首先，我们让存储引擎支持多种存储介质——目前是内存和闪存。与传统的存储层次结构类似，这些存储层的成本与性能权衡是不一样的。我们还实现了一个路由服务，它将用户请求发送到目标层的服务器上。无论数据存储在什么地方，都可以为用户提供统一的 API。这些层都从第一版 Anna 继承了同等丰富的一致性模型，因此开发者可以灵活挑选并自定义合适的一致性模型。

我们的实验表明，无论是在性能还是成本效益方面，Anna 都达到了令人印象深刻的水平。在同一成本下，Anna 提供优于 AWS ElastiCache8 倍的吞吐量和优于 DynamoDB 355 倍的吞吐量。Anna 还能够通过添加节点和恰到好处的数据复制来应对工作负载的变化：

这篇文章只提供了Anna 的设计概述，如果你有兴趣了解更多，可以在这里（ https://arxiv.org/pdf/1809.00089.pdf ）和这里（ https://github.com/fluent-project/fluent/tree/master/kvs ）找到完整的论文和代码。这个项目的进展让我们很满意，我们也很乐意收到你的反馈。后续，我们会有更多的计划，将 Anna 的高性能和灵活性拓展到其他的系统中，敬请关注！

查看英文原文： https://rise.cs.berkeley.edu/blog/going-fast-and-cheap-how-we-made-anna-autoscale/

感谢蔡芳芳对本文的审校。