作者：师天硕 | RisingWave Labs 内核开发工程师
RisingWave 是一款开源的分布式 SQL 数据库，专为流处理而设计，因其简化实时分析的强大能力而备受关注。然而，随着我们的用户开始构建更大、更复杂的应用程序，意外发现元数据存储 etcd 成为了性能瓶颈。在这篇文章中，我们将分享为什么决定用 Postgres 作为后台的元存储替换 etcd，其中面临的挑战，以及这种看似“老派”的方法如何为 RisingWave 解锁了新的可扩展性和开发者生产力。
1. 元数据存储的重要性
元数据存储 （Meta store）可以视作 RisingWave 集群的“大脑”。它负责存储关键的信息，确保整个系统的顺利运行。
RisingWave 遵循云原生设计，采用无状态组件，确保高可用性和可扩展性。持久化状态分为两个关键部分：
- 持久化数据存储：这是存储表数据、物化视图以及流处理操作状态的地方。它使用高效的 LSM 树格式 (Log-Structured Merge)，并存储在像 AWS S3这样的云对象存储服务中。
- 元数据存储：这里存储着关于数据和系统本身的所有信息。
元数据存储负责以下内容：
- 目录和用户信息：数据库、表、用户及其权限的详细信息。
- LSM 树元数据：关于持久化数据存储中数据结构和组织的信息。
- 流处理任务拓扑：所有活跃的流处理任务及其在计算节点上的分布图。
元数据服务器是 RisingWave 的核心组件，直接与元数据存储交互，管理如下一些关键功能：
- 元数据管理：创建、更新和删除 RisingWave 中的对象。
- 调度：动态分配资源并管理流处理任务在计算节点上的执行。
- 检查点管理：确保数据的持久性并支持从故障中恢复。
- LSM 树维护：通过调度和执行压缩任务来优化数据存储。
随着系统的扩展，元存储的性能变得至关重要，而我们最初选择的 etcd 开始显露出其局限性。
2. etcd 时代
最初，RisingWave 使用 etcd 作为元数据存储， 这是一种流行的分布式键值存储。使用初期，我们看重的是 etcd 的可靠性，高可用，并且支持事务。然而，随着RisingWave 的推广，用户开始部署更大、更复杂的集群，我们逐渐遇到了 etcd 的局限性。
2.1 开发瓶颈与缓存难题
etcd 简单的键值模型给我们的开发人员带来了显著挑战。对于复杂查询，例如检查流处理图中的循环依赖，开发人员需要在以下两种方案中做出选择：1）多次往返 etcd，导致性能下降；2）实现复杂的内存缓存来缓解性能问题，但这又引入了新问题，开发者需要保持缓存与 etcd 之间的一致性，这一过程对内存资源要求高, bug 也会增多。我们选择了第二种方案，因此不得不应对复杂性和可靠性带来的挑战。
2.2 云原生管理 etcd 的困难
在云环境中管理 etcd 变成了一项复杂的部署和管理任务。主要的云服务提供商没有提供托管的 etcd 服务，因此我们不得不自行部署和管理。etcd 主要为裸金属部署设计，而在云环境中，由于磁盘性能较慢，其性能往往受到限制。
2.3 etcd 存储的限制
etcd 的架构基于单个 Raft 组，没有 Sharding，这严重影响了其可扩展性。默认存储限制为 2 GB，推荐的最大值为 8 GB。这对我们来说是一个显著制约，因为 RisingWave 集群中的元数据量迅速增长。在某些情况下，磁盘空间不足时，我们甚至经历了部分提交事务导致的数据损坏。使用 Protobuf 编码处理元数据也使得调试和故障排查变得复杂。
3. 拥抱 SQL
为了克服 etcd 的局限性，我们做出了一个战略决策，将 RisingWave 的元数据存储后端转向基于 SQL 的方案，利用了强大的 OLTP 数据库系统：PostgreSQL。这一转变在简化开发流程、优化云端运维和提升可扩展性方面带来了多方面的优势。
3.1 解锁生产力
SQL 后端极大简化了开发过程。我们现在可以利用 SQL 的强大功能查询元数据，使得执行复杂操作变得更加容易。例如，检查流处理图中的循环依赖，以往在 etcd 中需要多次往返和复杂的缓存逻辑，现在只需使用 SQL 中的递归 CTE 即可完成。
SQL 数据库支持索引，能够快速检索元数据记录。SQL 数据库的强大查询和索引能力还消除了元数据服务器中复杂的内存缓存需求，简化了架构并减少了内存消耗。
3.2 简化云原生
采用 SQL 后端简化了我们的云端运维。我们现在可以利用像 AWS RDS、Azure PostgreSQL 数据库和 Google Cloud SQL 等托管的关系型数据库服务。这些服务经过高度优化，确保元数据存储能够应对大规模 RisingWave 部署的需求。这样大大减少了我们的运维负担，让工程师可以将精力更多地集中在新功能的开发，而非基础设施的管理。
3.3 拓展元数据存储
SQL 后端极大增强了 RisingWave 元数据存储的可扩展性和数据容量。现代关系型数据库能够处理 TB 级的数据，远远超出 etcd 的容量限制。这使得 RisingWave 可以支持更大、更复杂的部署，为我们提供了 10 倍的增长空间。SQL 后端还使得在多个 RisingWave 集群之间共享同一个数据库实例成为可能。
4. 挑战、取舍与经验
虽然转向 SQL 后端带来了诸多好处，但也带来了一些挑战和权衡。
4.1 挑战
首要挑战是如何确保现有 RisingWave 用户平稳迁移。因为用户仍在使用etcd，我们必须开发一款迁移工具，能够在不导致停机或数据丢失的情况下将元数据从 etcd 迁移到 SQL 后端。
4.2 取舍
需要权衡的是某些元数据操作的延迟相比 etcd 略有增加。etcd 作为一个内存型键值存储，对于简单的读写操作能够提供较低的延迟。然而我们发现对于大多数使用场景来说，SQL 后端的性能已经足够好，而且与 etcd 相比，管理 SQL 数据库带来的复杂性，使用托管服务后得到了大大缓解。
4.3 迁移过程
我们开发了迁移工具，帮助用户从 etcd 过渡到SQL后端。详细的迁移指南请参见从 etcd 迁移到 SQL 后端进行元数据管理。
4.4 收获
通过这次迁移，我们认识到选对工具非常关键，有时仍需要重新审视像 SQL 这样的成熟技术。另外，托管服务减轻了许多运营负担，也让扩展变得更简单。
5. 结论
自 2.1 版本起，RisingWave 正式用 Postgres 替换了 etcd 以存储元数据，这对 RisingWave 而言是一次颠覆性的变革，提升了系统的可扩展性、可靠性和易用性。通过拥抱 SQL 的强大与成熟，我们不仅克服了过去的局限性，还为一个更加开放友好的未来奠定了基础。我们期待看到用户基于这一增强平台创造出新的可能。
6. 关于 RisingWave
RisingWave 是一款开源的分布式流处理数据库，旨在帮助用户降低实时应用的开发成本。RisingWave 采用存算分离架构，提供 Postgres-style 使用体验，具备比 Flink 高出 10 倍的性能以及更低的成本。
👨🔬加入 RW 社区，欢迎关注公众号：RisingWave中文开源社区
🧑💻想要了解和探索 RisingWave，欢迎浏览我们的官网：risingwave.com/
🔧快速上手 RisingWave，欢迎体验入门教程：github.com/risingwave
💻深入理解使用 RisingWave，欢迎阅读用户文档：zh-cn.risingwave.com/docs
