PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 （翻译）

说完新技术下的新经济模式，下面咱们用Amazon Aurora 的Postgres 无服务的介绍来结束此篇文章。（跟上新形势，不做落后的人）

原文地址： https://jack-vanlightly.com/analyses/2023/11/15/neon-serverless-postgresql-asds-chapter-3

引言：

文章首先提到，将传统关系型数据库（如 MySQL）分解为独立的存储和计算组件，可以显著提升性能和可靠性。Amazon Aurora 就是一个很好的例子。Neon 采用了类似 Aurora 的架构，但在时间点查询模型等方面有所不同，这对存储层提出了不同的要求。

Amazon Aurora 简述：

Aurora 的核心思想是“数据库即日志”。它只复制预写日志（WAL），并将持久化存储（WAL 和数据页）从 MySQL 磁盘转移到一个单独的大规模多租户存储服务。通过只复制 WAL，即使复制因子更高（6 路复制），总复制字节数也更少。日志应用器（将 WAL 记录转换为数据页更改的组件）现在位于存储数据页的存储节点上。MySQL 数据库通过网络调用与存储服务通信，而不是文件系统调用。这种架构在弹性和持久性方面具有显著优势：

与存储服务的复制是同步的，并且跨可用区进行 6 路复制（4/6 写入仲裁），即使一个可用区和一个其他副本发生故障也不会丢失数据。 由于对存储服务的仲裁写入，磁盘故障不会导致数据库停机或故障转移。 大规模多租户降低了总拥有成本。 Neon：无服务器 Postgres

Neon 是一个基于类似 Amazon Aurora 架构的无服务器 Postgres 服务。它也将 Postgres 分解为分离的存储和计算层。其架构背后的动机有四个：

提供全球性价比最高的 Postgres 服务。 使用现代复制技术为 Postgres 提供高可用性和高持久性。 通过将无服务器消费模型引入 Postgres，简化开发人员的工作。 在保持 Postgres 大部分不变的情况下完成所有这些。 Neon 的目标是尽可能接近“Just Postgres”，同时获得分解式多租户架构的好处。

架构概述：

Neon 由无状态计算层和分解式存储层组成。Postgres 实例构成无状态计算层，存储层本身也是分解式的，由存储多个租户数据的存储节点组成。存储节点又分为用于预写日志（WAL 服务）和数据页（Page 服务）的水平可扩展服务。

每个 Postgres 数据库都是无状态的，因为其维护的任何状态对于持久性都不是必需的。

空闲的 Postgres 实例会在一段时间不活动后下线，并在收到新查询时再次启动。 Neon 对 Postgres 进行了一些修改，以拦截对 WAL 和数据文件的写入，并确保缓存驱逐不会导致本地磁盘写入。

时间点恢复、查询和分支：

Neon 的一个关键特性是支持时间点查询、时间点恢复和分支。这需要数据永不覆盖，并以一种高效的方式进行分层，以维护历史记录。日志序列号 (LSN) 是一个关键组件，它是一个单调递增的整数，分配给每个 WAL 记录，代表数据更改线性历史记录中的特定时间点。

分层数据存储模型由镜像文件和增量文件组成。每个镜像文件代表特定时间点 (LSN) 的页面范围内已物化的数据。WAL 记录（即增量）然后作为增量层文件分层在镜像文件之上。这些增量在最新的镜像文件上重放以生成新的镜像文件。给定 LSN 的读取首先找到等于或低于 LSN 的最高镜像文件，然后应用其上的所有 WAL 记录。

写入路径：

在传统的 Postgres 中，数据首先写入内部共享缓冲区，将更改应用于相关行的缓存 8kb 数据页。接下来，将增量写入 WAL 缓冲区。在写入提交之前，WAL Writer 从 WAL 缓冲区获取增量并将其持久化到 WAL 文件。共享缓冲区中的修改后的 8kb 数据页是“脏的”，因为它们尚未写入磁盘。

在 Neon 中，所有这些磁盘操作都不会发生；相反，这些操作会转换为网络 IO 请求，或者在缓存驱逐的情况下不进行任何操作。Postgres 数据库在本地维护的唯一表状态是它存储在其内部缓冲区中的内容。

Safekeepers：

Postgres 实例的 WAL 写入到三个 Safekeeper 节点的集群。每个 Postgres 数据库负责将 WAL 记录写入每个 Safekeeper，而不是写入一个领导者节点，然后该节点将这些记录复制到跟随者。

Neon 为其 WAL 服务选择了 Paxos 实现。每个 Postgres 数据库都是一个提议者（Proposer），每个 Safekeeper 都是一个接受者（Acceptor），Pageservers 是学习者（Learner）。在 Neon Postgres 数据库可以写入 WAL 记录之前，它必须由 Safekeepers 选举为领导者（杰出提议者）。一旦当选，它就可以自由地向 Safekeepers 写入（或提议）一系列 WAL 记录。一旦大多数 Safekeepers 确认了 WAL 记录，数据库就将该记录视为已提交。

Page 服务：

Page 服务是一组 Pageservers，目前一个数据库由一个 Pageserver 提供服务，一个 Pageserver 可以服务多个数据库。分片机制正在开发中，单个数据库可以分布在多个 Pageservers 上。

Pageservers 充当检查点角色。它们以 Paxos 学习者的身份了解已提交的 WAL 记录。WAL 记录在最新的镜像文件上重放，这些文件最终会上传到 S3。然后，Pageservers 与 Safekeepers 通信有关上次应用的 WAL 记录的索引，从而允许 Safekeepers 安全地进行垃圾回收。

读取路径：

读取首先会命中 Postgres 内存缓冲区中的本地缓存，只有在缓存未命中的情况下，才会向相关的 Pageserver 发送获取页面请求。Pageservers 也是缓存，实现了 LRU 缓存驱逐算法。如果在 Pageserver 上再次发生缓存未命中，它将从云存储（以层文件的形式）获取一个页面块。

Neon 支持读取副本，但与 Aurora 不同，数据库主实例不会将 WAL 记录流式传输到读取副本。相反，此责任转移到 Safekeepers。这也将读取副本置于 Paxos 学习者的角色，与 Pageservers 并列。

云对象存储：

Neon 利用廉价、持久的云对象存储。Neon 通过将其分解式存储服务作为前端的快速、容错缓存，将数据卸载到云存储，从而降低了存储成本。

多租户：

Neon 通过共享进程资源共享模型和逻辑隔离来实现多租户。

计算层： Neon 使用自己的虚拟化技术，将多个租户打包到共享计算实例上。每个 Postgres 数据库都在基于 QEMU 的 NeonVM 中运行，该 NeonVM 在 Kubernetes 中调度。每个租户数据库只有一个主 Postgres 数据库。扩展只能在一个维度上进行，即向上和向下。Neon 通过以下方式处理资源争用： 每个 Postgres 实例都在 NeonVM 的 cgroup 中运行。 vm-informant 进程接收来自 cgroup 的 memory.high 事件的通知。 vm-informant 进程然后向主机上运行的共享 autoscaler-agent 进程请求更多内存。 autoscaler-agent 与（修改后的）K8s 调度器协调，以获得分配更多资源给 VM 的批准。 Neon 使用 QEMU 的实时迁移功能将 VM 迁移到负载较轻的主机。 存储层： Neon 的分解式存储层通过共享进程资源共享模型和逻辑隔离来实现多租户。WAL 和 Page 服务可以部署在针对工作负载优化的硬件上。租户可以在 Safekeepers 和 Pageservers 之间转移。

冷启动：

冷启动是 Neon 架构中最棘手的问题之一。在计算层，这通过由可以快速承担租户身份的即用型 VM 组成的计算池来解决。然而，如果 Pageserver 没有托管服务初始请求所需的层文件，则第一个查询将体验到云对象存储的延迟成本。

结论：

Neon 是一个很好的案例研究，它展示了如何将传统的单租户、本地软件改造成云原生软件。它混合使用了常用技术，例如存储和计算分离、分布式预写日志和卸载到云对象存储，以及独特的技术，例如在计算层中使用虚拟化来实现弹性和移动性。Neon 也证明了为什么 Paxos 可能比更单一的 Raft 更适合某些需求。

总而言之，文章详细介绍了 Neon 的架构，并将其与 Aurora 进行了比较，强调了其在弹性、持久性和成本效益方面的优势，同时也指出了冷启动等潜在挑战。