存算分离架构软肋｜云盘性能不行

存算分离数据库软肋 | 云盘性能不行, 咋办?

PlanetScale 发布PG云服务benchmark, 把自家的RDS性能捧上了天, 把AWS、google、Neon等云服务厂商的RDS踩在脚下摩擦. 详见:

《PlanetScale发布Postgres云服务, 吊打主流云厂商“胜之不武”》

但是他们的测试方法有注水, 很快引起了公愤! 并且他们只字未提本地盘的问题以及云盘的好处。只是把自己的产品捧得高高的，详见:

海外PG厂商互殴｜PlanetScale “作弊”测试引公愤

其实 PlanetScale 的策略无外乎就是用本地SSD去吊打云盘, 最后得出他们的PG性能更好的结论.

那Aurora、Neon、PolarDB等存算分离架构的云原生PG就被人捏到软肋了? 从此一蹶不振软趴趴了么?

当然不是, 我相信阿里云会第一个表示不同意。PolarDB云盘IO一样能打，什么软肋，你试试就知道有多硬！

那么除了阿里云PolarDB采用的RDMA、CXL等软硬一体解决之道之外, 其他云数据库厂商咋办呢?

这篇文章就来好好聊一聊。

还记不记得SSD刚刚推出市场时, 贵得要死, 简直比黄金还贵.

但是数据库是IO大户, 该用还的用啊, 为了在性能和存储空间上取得平衡, 当时就有好多解决方案.

例如开源项目flashcache就是把SSD当成二级缓存, 能同时提升文件系统的读写性能. 参考文章( https://github.com/digoal/blog ):

• 《flashcache usage guide》
• 《PostgreSQL IOPS performance tuning by flashcache》

zfs文件系统的L2ARC, 参考文章:

• 《ZFS ARC & L2ARC zfs-$ver/module/zfs/arc.c》

Oracle ExtraData 一体机也有类似的功能.

如今的存算分离架构, 也出现了类似的解决方案.

下面翻译一篇来自Neon的文章: “Neon 如何使用 LFC（本地文件缓存）来保持快速读取”

https://neon.com/blog/separation-of-storage-and-compute-perf

存储和计算分离无需牺牲性能, Neon 如何使用 LFC（本地文件缓存）来保持快速读取

现代 OLTP 数据库系统（例如 Neon 和 AWS Aurora）将存储和计算分离。这种架构的主要优势在于弹性和“无服务器”特性。存储量似乎“无底洞”，而计算量则可以随着负载的增加和减少而弹性扩缩。用户无需承诺一定数量的存储或计算量，只需按使用量付费。

Neon 计算运行 Postgres，存储是专为云定制的 Postgres 页面多租户键值存储。您可以点击此处了解更多关于 Neon 架构的信息。

传统上，这种分离的缺点是它会导致从计算到存储的额外网络传输(跳数增加, 延迟增加, 带宽降低)，从而导致缓冲池未命中时的延迟更高。在本篇博文中，我们将讨论 Neon 的本地文件缓存组件 (LFC) 如何让我们兼顾两者的优势：存储和计算架构分离的弹性，以及与在本地磁盘上运行 Postgres 相同的延迟和吞吐量。

要获取 Postgres 性能的基准，您可以自行或通过数据库即服务 (DaaS) 供应商将其放入具有本地固定大小 NVMe 存储的虚拟机中。以下是 Planetscale 的最新基准测试结果。

具有单层本地 NVMe 存储的固定大小 VM 的缺点是：

• 当你在设置时选择的固定大小磁盘不够用时，情况可能会发生改变。你必须提前规划，迁移到新的实例大小，这需要手动操作，而且价格也会大幅上涨。
• 即使您选择最大的可用磁盘，您的数据库大小也仅限于云中可用的本地磁盘的大小。
• 由于您需要选择一个足够大的驱动器来容纳您的数据库和一些增长，因此您总是需要支付比您使用的更多的存储空间。
• 您的实例的大小是根据您的峰值吞吐量确定的，因此在其余时间，您支付的计算费用将超过您实际使用的计算费用。

这些限制就是为什么像 Neon 这样的弹性系统如此受欢迎的原因：只需为您使用的存储空间付费，永远不会超出其容量，并根据使用情况自动扩展计算规模。

但是，您是否需要为了弹性而牺牲性能？答案是否定的，因为引入了由 NVMe 存储支持的本地文件缓存 (LFC)。如果 LFC 足够大，与数据库工作集匹配，Neon 的性能与在具有 NVMe 存储的虚拟机中超额配置的 Postgres 相同。

两全其美

Neon 计算节点拥有本地文件缓存(LFC)，这是传统 Postgres 共享缓冲区与 Neon 存储之间的一个额外缓存层。共享缓冲区作为 LFC 之上的一个小型热缓存保留。

LFC 是 Neon Autoscaling 的关键组件，因为它可以调整大小，而 Postgres 共享缓冲区的大小是固定的（尽管我们正在努力使其未来可以调整大小）。LFC 利用 Linux 页面缓存提供类似 RAM 的延迟，但延迟会随着 LFC 大小的增加而溢出到磁盘。

默认情况下，LFC 的大小与计算节点上的物理 RAM 大小大致相同，以提供类似 RAM 的延迟（LFC 中的页面位于 Linux 页面缓存中），同时保持比共享缓冲区更高的灵活性。但是，对于受益于 Postgres 和存储后端之间的大型 NVMe 缓存的工作负载，我们可以轻松配置更大的 LFC 并将其溢出到磁盘。

如果我们配置一个与数据库大小相同的 LFC（例如，对于类似 TPCC 的基准测试，为 500GB），那么我们就可以兼具两全其美的优势：存储保持弹性并与计算分离，但本地 SSD 上也有数据库的热本地缓存。

这些大缓存配置已在neon.com上作为私人预览版向部分客户提供一段时间，但直到最近才作为 Databricks Lakebase 发布的一部分向公众开放。我们目前正在努力整合 Lakebase 和neon.com的功能，以便在所有地区提供无缝体验。

关于基准的简要说明

下面我们列出了一些基于竞争对手planetscale最近使用的类似 TPCC 的基准测试的汇总数据。需要注意的是，该基准测试的原始作者 Percona并不建议以这种方式使用，但我们将使用这些数据来演示 LFC 在这种特定情况下的影响。

Percona 在 README 中用于比较读/写性能的基准测试内容如下：

这不是 TPCC 工作负载的实现。它“类似 TPCC”，仅使用 TPCC 规范中的查询和模式。它不遵循所需的“键控时间”，并且作为固定数据集上的闭环争用基准测试，而不是随仓库数量扩展的开环基准测试。它也不遵循其他多项 TPCC 规范要求。请勿使用 sysbench-tpcc 生成 TPC-C 结果来比较不同供应商，或者请附上类似的 TPCC 类特性免责声明。

因此，我们使用这个基准并不是因为它是标准或代表现实世界的使用情况，而是因为另一个供应商用它来评估 Neon，我们想展示这些数字在不同的配置下是什么样子。

Neon说这话还真是严谨啊!

结果

那么，当我们启用更大的 Neon 本地文件缓存时，情况会有什么不同？

pic

图 1：Neon 8CU + Large LFC（红色）与 Neon 8CU 基线（蓝色）的比较。QPS 越高越好，延迟越低越好。

我们重新测试了类似 Percona TPCC 的基准测试，以确认基于本地磁盘的解决方案将失去其优势的预期：

第三方测试的近似值

如您所见，Neon 实现了大致相同的 QPS，而所需的高性能本地 NVMe 数量仅为本地磁盘解决方案的一半 - 因为我们的系统可以配置为任意缓存大小，所以我们的用户不必承担从固定磁盘大小菜单中购买“下一个大小”的成本。

那么，我们是否为了实现更低的本地磁盘读取延迟而放弃了弹性？并非如此！缓存的大小是灵活的，它不必与数据库总大小匹配。EC2 上 500GB 的 Postgres 数据库无法使用 500GB 的驱动器，您需要先计算数据库大小，然后再计算下一个可用的磁盘大小。但 Neon 有一个选择：我们可以根据工作集而不是整个数据库来调整 LFC 的大小 —— 在后续测试中，我们还测试了 180GB 的 LFC 而不是 500GB，峰值 QPS 仅损失约 10%（180GB 的大小来自对工作集大小的智能运行时估算）。

你怎么看? 欢迎留言讨论!

你是喜欢本地Nvme盘 还是 云盘呢？理由是什么？