DBOS论文笔记

| 笔记 | 2005 | 6分钟 | 论文操作系统

不应仅基于单节点操作系统再配以独立的集群调度器、分布式文件系统和网络管理组件；而应以分布式事务型数据库管理系统（DBMS）作为可扩展集群操作系统的基础。

在第 2 节中，我们提出了基于**“万物皆表”**——将所有操作系统状态表示为关系表——的激进架构，利用现代数据库管理系统技术，将操作系统功能扩展至整个数据中心 [23, 33]。

架构

操作系统的资源管理问题已增长了多个数量级，如今本身就成为一个“大数据”问题

显而易见的解决方案是在下一代操作系统的内核中嵌入一个现代高性能的多节点事务型数据库管理系统（DBMS）。

Level 4 用户空间

最上层是传统的用户级任务，这些任务在隔离保护下运行，既彼此隔离，也与更低层级隔离，正如传统操作系统中一样。在 DBOS 中，我们主要面向分布式应用，例如并行分析、机器学习、网络搜索和移动应用后端——这些是当今最广泛使用的应用。为支持这些应用，我们鼓励采用无服务器（serverless）计算模型，用户将其任务分解为由子任务组成的有向图，每个子任务在短时间内运行。因此，子任务在指定的内存占用范围内产生、运行并销毁。鉴于此，我们并不计划支持当前系统中的复杂内存管理机制；只有在有足够可用内存满足其声明的占用时，子任务才能运行。

  • 在现有的无服务器平台（如 AWS Lambda、Azure Functions）里，每个函数实例往往相互隔离，运行在完全独立的容器或沙箱中。它们之间没有共享内存，也没有统一的进程表，需要借助外部存储（对象存储、分布式文件系统）来交换数据。

  • 在 DBOS 里，所有子任务的元数据（如任务 ID、所属用户、数据依赖、网络地址）、IPC 消息队列、资源状态（内存、CPU 利用率）等，统统以关系表的形式存储在同一个分布式事务数据库中。

    • 零外部存储依赖

      子任务之间交换数据，只需在数据库里进行一次插入和一次查询——同节点或跨节点均由数据库内核高效路由和缓存处理，无需独立的对象存储或文件系统跳板。

    • 事务一致性保障

      数据库事务保证了“写入中间结果”与“调度下游任务”这两步操作的原子性，消除了因网络抖动导致的丢失或重放风险。

所以相信DBOS能大幅简化分布式应用的开发。

Level 3 操作系统功能

第 4 级的应用由第 3 级的一组数据中心级操作系统服务支持，例如任务调度器、分布式文件系统、进程间通信（IPC）等。后文第 4 节将展示这些服务的高性能实现。

在 DBOS 中，所有操作系统服务均通过 SQL 结合用户自定义函数来实现。

为什么DBOS的实现能让分布式应用的开发更简单？

Level 2 数据库管理系统

我们之所以聚焦于 SQL DBMS，是为了利用高级查询语言所带来的强大分析能力；不过，若需要更底层的接口，也可以考虑将各类 No-SQL 数据库纳入 DBOS 风格的架构中。

Level 1 微内核服务

DBOS 三阶段

我们将分三个逐步增强的阶段来构建 DBOS 原型：从“稻草”（straw），到“木头”（wood），最后到“砖块”（brick）。

3.1 DBOS-straw

我们的第一个原型展示了在三项操作系统服务上可以实现合理的性能：任务调度、文件系统以及进程间通信（IPC）。构建 DBOS-straw 原型时，使用 Linux 作为第 1 级，采用关系型数据库（RDBMS）作为第 2 级，第 3 级的部分功能手工编写，第 4 级编写一些测试程序。有关这些服务的结果已在本文第 4 节中给出。我们期待此演示足以说服怀疑者相信该方案的可行性。此系统构建在 VoltDB 之上，VoltDB 提供了所需的高性能。

另外两阶段文中未实现。

调度

元数据表

  • Task(p_key, task_id, worker_id, …)：记录任务所属分区、ID、分配到的执行者、优先级等。
  • Worker(p_key, worker_id, unused_capacity)：记录每个分区中各执行者剩余可跑任务数。

三种示例调度器：调度逻辑均写在 SQL 存储过程内，修改几行即可变更策略

  1. FIFO 调度器：

    • 从目标分区随机选一空闲执行者（unused_capacity>0）
    • 容量–1 并插入 Task 行

  2. 局部性感知调度器：

    • 优先在任务“主目录”所在分区调度，若满载则在本地排队等待

  3. 最少负载调度器：

    • 在分区内选取 unused_capacity 最大的执行者，保证最优均衡
    • 仅需在 SQL 查询中加 ORDER BY unused_capacity DESC

具体代码里怎么实现的？到目前这个策略很好理解。但是SQL直接变成操作系统还是有点跨度太大了。

各位老师周二上午九点我们再开会讨论一下？主要明确现在的需求有没有问题或补充；黄老师麻烦重点看一下第六章界面设计，如果有不清晰的地方可以再讨论。

另外哈兔现在的后端数据库能不能给我看一下？方便我参考现在哈兔的用户管理结构。