DAOS 分布式异步对象存储|事务模型

DAOS API 支持分布式事务,允许将针对属于同一 Container 的对象的任何更新操作组合到单个 ACID 事务中。分布式一致性是通过基于多版本时间戳排序的无锁乐观并发控制机制提供的。DAOS 事务是可串行化的,可以在特定的基础上获取部分需要的数据集。

DAOS 版本控制机制允许创建持久的 Container 快照,该快照提供 Container 的实时分布一致性视图,该视图可用于构建生产者-消费者管道。

Epoch 和时间戳

每个 DAOS I/O 操作都有一个称为 epoch 的时间戳。epoch 是一个 64 位整数,它集成了逻辑和物理时钟(详见 HLC paper)。DAOS API 提供了辅助函数,用于将 epoch 转换为传统的 POSIX 时间(即 struct timespec,详见 clock_gettime(3))。

Container 快照

如下图所示,Container 的内容可以随时快照。

DAOS 分布式异步对象存储|事务模型

DAOS 快照非常轻量级,并且使用与创建快照的时间相关联的 epoch 进行标记。一旦创建成功,快照将一直保持可读性,直到它被显式销毁。在特定快照未被销毁前,Container 的内容可以回滚到该快照。

Container 快照功能支持本机生产者/消费者管道:

DAOS 分布式异步对象存储|事务模型

一旦成功写入数据集的一致版本,生产者 (Producer) 将生成一个快照。使用者 (Consumer) 的应用程序可以订阅 Container 快照事件,以便在生产者提交更新时可以处理新的更新。

快照的不变性保证了使用者可以看到一致的数据,即使生产者继续进行新的更新。生产者和消费者实际上都在 Container 的不同版本上操作,不需要任何串行化操作。一旦生产者生成了数据集的新版本,使用者就可以查询两个快照之间的差异,并且只处理增量修改。

分布式事务

与 POSIX 不同,DAOS API 不强制执行最坏情况下的并发控制机制来处理冲突的 I/O 操作。相反,各个 I/O 操作被标记为不同的 epoch,并按照 epoch 的顺序应用,而不管执行顺序如何。这个基准模型为不产生冲突的 I/O 工作负载的数据模型和应用程序提供了最大的可伸缩性和最高的性能。典型的例子是 MPI-IO 集合操作、POSIX 文件读/写操作和 HDF5 数据集读/写操作。

对于需要将冲突串行化的部分数据模型,DAOS 提供了基于多版本并发控制的分布式可串行化事务。当不同的用户进程要覆盖与 dkey/akey 关联的值时,通常需要该事务。例如 DAOS 上的 SQL 数据库,或者由非一致的客户端并发访问的一致的 POSIX 命名空间。

在同一操作的上下文中提交的所有 I/O 操作(包括读取)将使用相同的 epoch。DAOS 事务机制自动检测传统的读/写、写/读和写/写冲突,并中止其中一个冲突事务(事务在 -DER_RESTART 参数下提交失败)。然后,用户/应用程序必须重新启动失败的事务。

在目前的实现中,事务 API 具有以下限制,这些限制将在未来的 DAOS 版本中解决:

  • 不支持 Array API
  • 通过同一上下文环境执行的对象获取/列表和键值获取/列表操作所进行的事务对象更新和键值放入操作不可见。

相关信息

GitHub: https://github.com/storagezhang

Emai: debugzhang@163.com

华为云社区: https://bbs.huaweicloud.com/blogs/254178

DAOS: https://github.com/daos-stack/daos

本文翻译自 https://daos-stack.github.io/overview/transaction

上一篇:kafka高水位和Leader-Epoch


下一篇:学习笔记13:微调模型