在 IaaS 中保存预写日志 (WAL) 的最佳方法（容错、低成本）？

Question

我正在为“云原生” DBMS 开展一个绿地项目，“云原生”意味着它所做的保证（例如 ACID）将取决于某些支持 IaaS 服务（例如对象存储、托管消息队列等）的存在。目标是减少 DBMS 的代码库大小和操作开销，适用于您已经在 IaaS 环境中运行的情况。

任何 DBMS 都需要的一个功能是预写日志 (WAL)，用于在崩溃后重放状态。实现 WAL 的简单、“云无关”方式是将其作为 DBMS 守护进程管理的磁盘文件。在云设置中，这隐式转换为 WAL 日志驻留在本地连接的“临时”磁盘中，或驻留在通过 iSCSI 等方式连接到 VM 的虚拟机管理程序的 SAN（例如 EBS、GCE PD）卷中。（并且，由于 WAL 用于崩溃恢复，我们可以忽略临时磁盘选项；如果崩溃是因为实例失败，磁盘将消失！）

WAL 具有特定的语义：

• WAL 由一个进程/作业拥有；没有其他任何东西可以读取或写入它（即，它可以被视为由其所有者永久“独占锁定”）

• 唯一的写入是附加（这可能会被转换为环形缓冲区文件中的覆盖，但这是一个实现细节）

• 没有混合的读/写流量；WAL 只打开仅有的阅读或打开仅有的用于书写，会话期间不会发生切换

• 读取会话很少见（仅适用于崩溃恢复），并且始终从第一个可用（即非垃圾收集）段开始流式读取整个 WAL

• WAL 的作者可以承认确保 WAL 中直到给定检查点的所有内容都已提交到其最终目的地。这可以允许将检查点之前的所有内容标记为垃圾收集或覆盖

鉴于这些语义，我想知道是否存在其他 IaaS 基础设施组件，比 SAN 卷更适合处理 WAL 写入和崩溃恢复流量。

我所说的“更适合”是指以下考虑因素的组合：

1. 可以使用流协议与该基础组件进行通信，该协议比 iSCSI 等块存储协议更紧密地匹配 WAL 语义，从而减少实例的开销；

2. 鉴于 WAL 在崩溃恢复中的重要性，它损坏的可能性比在单个 SAN 卷上要小；

3. 该解决方案将使每 GB 写入 WAL 数据的成本低于 SAN 卷的成本。

（我可能无法同时拥有这三种情况，但三种情况中有两种就很好了。）

---

两类基础组件似乎为此而努力但实际上并非如此的是持久的消息队列服务（AWS SQS；Google Cloud Pub/Sub）和对象存储（S3、GCS）。

这两种服务类型都允许快速写入小消息/对象，然后持久保存/复制它们；但这两种服务类型都不会持久保存仅被部分写入，而且对于这种用例来说，它们的成本也太高了，甚至与 SAN 磁盘相比也是如此。WAL 每天可以有多个 TB 的数据流过，而对象存储和消息队列本质上都有每次检查点写入的成本，这使得 WAL 可能成为最多在其中存储昂贵的东西。

Answer 1

正如您所提到的 GCP，要走的路是使用 Pub/Sub 并将日志存储在 GCS 中。

GCS 可能比 S3 更便宜，这取决于将数据存储在 GCS（操作）中后访问的频率。

当您在 Cloud Storage 中执行操作时，会产生操作费用。操作是对 Cloud Storage 中的存储桶和对象进行更改或检索相关信息的操作。

操作分为三类：A 类、B 类和免费。计费标准为每 10,000 次操作。参见官方文档更多细节

有关定价和解决方案的更多详细信息，您应该联系 GCP 销售人员通过此表格，您无需成为客户即可收到估价