如何评价 Google 在2022年推出的 AlloyDB 全托管式 PostgreSQL 数据库?
来源：https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage 导读：在Google I/O 2022[2] 大会上，Google Cloud 发布了兼容 PostgreSQL 标准的云原生数据库 AlloyDB（注：Alloy 意为合金），速度号称是 Amazon 的同类产品（Aurora？）的两倍，这个口号，对老用户来说，应该不足以让其迁移，但对于新用户来说，确有一些吸引力。 由于笔者主要做存储，下面基于谷歌这篇介绍 AlloyDB 存储层博文[3]，剖析下 AlloyDB 存储层架构，看看其设计有何亮色。 作者：木鸟杂记https://www.qtmuniao.com/2022/05/15/google-alloydb-storage转载请注明出处 在整体上，AlloyDB 分为 Database 层和存储层。其中，DB 层用以兼容 PostgreSQL 协议，解析 SQL 语句，转化为读写请求，发送给存储层。对于存储层，又可以细分为三层： 即，AlloyDB 将其存储层进一步拆分为两个存储层和一个计算层，以拆解复杂度： 存储层本质上是要提供 block 的读写服务， AlloyDB 拆出 log storage 层负责写、block storage 层负责读。基于日志服务物化实现存储层，在分布式数据库领域，算是一个经典（甚至老旧）架构，但如何将其高效组合，还是比较考验工程能力。 基于日志服务的另一个好处是，可以对同一份数据使用不同的方式进行物化，以支持不同的工作负载（workload），比如将数据按需物化为针对 TP 和 AP 优化的数据格式，即，支持 HTAP。 写入请求（如 SQL insert），由客户端向主实例发起，在经过 DB 层解析后，变为一组 WAL Records 发到存储层。在 WAL 同步写入成功后，事务提交成功返回。之后，LPS 会将日志异步的物化为 Block。 原文没有展开，但如何对日志进行分段和容错、如何多地部署、如何管理日志生命周期，也是很关键的设计点。 读取请求（如 SQL query），由客户端向任何实例发起，在 DB 层解析后，如果命中该 DB 层中的缓存（Buffer Cache），则直接返回；如果请求所需数据缓存不够，则可以去更大的、类似二级缓存的 Ultra-fast Cache 中去捞，如命中，则仍可不访问存储层。 如 Ultra-fast Cache 中仍然缺少所需 block，则会带上 block id 和 LSN，向存储层发送 block 读取请求： 在存储层中，LPS 负责 block 的读写，每个 LPS 都维护了 Buffer Cache，这个术语比较有意思： 在此处，两者合二为一，LPS 在日志重放（log apply）时，首先写入自己的 Buffer Cache，此时 Buffer Cache 充当 buffer，以批量刷入 block storage 中；LPS 在将 Buffer Cache 刷到 block storage 前，如收到 block 读取请求，并命中 Buffer Cache，可直接返回，此时，Buffer Cache 充当 cache。 当然，LPS 需要对 Buffer Cache 维护类似脏表之类的数据结构，以追踪每个 block 的生命周期和下刷失效时机。 为了应对变化的负载，LPS 实例数量被设计为可伸缩的：即调整 LPS 和 block shard 的映射关系。在进一步解释如何伸缩前，先梳理下 block、shard 和 LPS实例 的概念以及联系： 一组 block 集合为一个 shard，一个 shard 最多为一个 LPS实例 所处理，但一个 LPS实例 可同时处理多个 shards。 以餐厅来类比，block 可理解为客人，shard 可理解为餐桌，LPS 实例可理解为服务员： 这种动态调节，可完全自动化，无需用户感知和干预。又因 LPS 没有状态（Buffer Cache 不算状态，想想为什么），因此可以快速伸缩。 为了容忍区域性故障，AlloyDB  会将每个 block 分片的多个副本放到不同区域（zone）中。 文中提到两个概念，region 和 zone，没有去求证，但猜测 region 指物理区域，zone 指逻辑区域。当某个 zone 发生故障时，在同一 region 新拉起一个 zone，并进行数据恢复： 正常情况下，每个 zone 可以独立的进行服务，没有特别多的跨 zone 流量。 此外，AlloyDB 还支持逻辑上（比如某个 database）的手动和自动备份，以防止用户误删数据。 AlloyDB 的存储层基于日志服务进行实现，分为两层存储 log storage、block storage 和一层计算 LFS。基于 LSN 来控制并发，动态伸缩 LFS 以应对负载。 你对这种设计有什么看法？欢迎留言讨论。 [1] 任何想法都欢迎来提 issue: https://github.com/DistSysCorp/ArticleListWeekly/issues [2] Google I/O 大会 2022: https://io.google/2022/ [3] alloydb for postgresql intelligent scalable storage: https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage   我是青藤木鸟，一个喜欢摄影的分布式系统程序员。如果你觉得文章还不错，欢迎关注我的公众号：“木鸟杂记”，比心~