CMU 15-721 14-数据库调度 Scheduling

2019-09-14 1959

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 查询执行查询计划是由运算符组成的，而运算符实例就是操作符运算在一段数据上的一次调用，任务就是一系列这样的操作符实例的执行序列。数据库调度对于每一个查询计划，数据库系统需要决定什么时候，在什么地方，怎么样去执行。

查询执行

查询计划是由运算符组成的，而运算符实例就是操作符运算在一段数据上的一次调用，任务就是一系列这样的操作符实例的执行序列。

数据库调度

对于每一个查询计划，数据库系统需要决定什么时候，在什么地方，怎么样去执行。
→ 应该使用多少个任务？
→ 应该使用多少个CPU核？
→ 任务应该在哪个CPU核上执行？
→ 任务应该将它的输出存储到哪里？
数据库系统永远要比操作系统知道这些。

今天我们来讲一下：

进程模型
数据放置
数据库调度

进程模型

数据库系统中的进程模型定义了一个系统架构，可以支撑多用户应用的并发请求。Worker是数据库的一个组件，负责代表客户端执行任务并返回结果。

1: 一个进程一个Worker
2: 进程池
3: 一个线程一个Worker

一个进程一个Worker

每一个Worker就是一个独立的OS进程
→ 依赖于OS系统调度
→ 对全局数据结构使用共享内存。
→ 进程崩溃不会让整个系统崩溃。
→ 例子: IBM DB2, Postgres, Oracle

进程池

一个Worker可以使用任意进程池中空闲的进程。
→ 仍然依赖于OS系统调度和共享内存。
→ 不利于 CPU 缓存的局部性..
→ 例子: IBM DB2, Postgres (2015)

一个线程一个Worker

具有多个Worker线程的单个进程。
→ DBMS必须管理自己的调度。
→ 选择使用调度线程。
→ 线程崩溃可能会让整个系统崩溃。
→ 例子: IBM DB2, MSSQL, MySQL, Oracle (2014)

进程模型PROCESS MODELS

用多线程架构有下面几个好处:
→ 很少的上下文切换的开销
→ 不用管理共享内存

观察

不管DBMS使用什么Worker的分配策略或任务分配策略，Worker对本地数据的操作都是非常重要的。DBMS的调度程序必须知道其底层硬件的内存配置。
→ Uniform vs. Non-Uniform Memory Access

UNIFORM MEMORY ACCESS

NON-UNIFORM MEMORY ACCESS

数据放置

数据库系统可以为数据库划分内存分区，并将每个分区分配给CPU。通过控制和跟踪分区的位置，它可以调度操作符在最近的CPU核的Worker上执行。

内存分配

当DBMS调用malloc时会发生什么？
→ 假设分配器没有可以释放的内存块。
实际上，几乎什么都没有：
→ 分配器将扩展进程数据段。
→ 但是这个新的虚拟内存并没有立即得到实际的物理内存。
→ 操作系统只在有页错误时分配物理内存。

内存分配位置

现在在发生页面错误之后，操作系统在哪里分配NUMA系统中的物理内存？

1: Interleaving

→ 在CPU之间统一分配的内存。
2: First-Touch

→ 在访问导致页面错误的内存位置的线程的CPU上。

数据放置OLTP

数据放置OLAP

分区vs放置

使用分区方案根据某些策略对数据库进行拆分。
→ 轮询 Round-robin
→ 属性范围 Attribute Ranges
→ 哈希 Hashing
→ 部分/完全复制 Partial/Full Replication
一个放置方案告诉DBMS将这些分区放在哪里。
→ 轮询 Round-robin
→ 跨核交错 Interleave across cores

数据库调度

静态数据库调度

数据库系统在生成执行计划时决定使用多少个线程来执行查询，在执行过程中不可以改变。
→ 最简单的方法是使用与核数相同的任务数

碎屑驱动（MORSEL-DRIVEN）调度

任务的动态调度，这些任务运行在被称为“碎屑”的水平分区上，这些分区分布在各个核上。
→ 一个worker一个CPU核
→ 基于Pull的任务分配
→ 循环的数据放置
支持并行的，NUMA感知的操作符实现。

HYPER架构

没有单独的调度线程，线程使用单个任务队列对每个查询计划执行协作调度。
→ 每个Worker都试图选择本地碎屑上执行的任务。
→ 如果没有本地任务，worker才会从全局队列拉去下一个任务。

HYPER数据分区

HYPER执行的例子

按照任务队列，任务A1/A2/A3先执行

如果由于filter导致数据分布不均，A3并未执行成功，那么B1/B2可以分配到前两个CPU核及他们的本地内存中，继续执行创建hash

如果B1此时执行完毕，A3/B2仍然在执行，那B3被分配到第一个CPU核，但是需要跨本地内存读取B3的数据分布

因为一个CPU核一个Worker，他们必须采取偷窃的方式，否则空闲的就会等待那些仍然在执行的任务。用一个lock-free的哈希表去维护全局队列。

SAP HANA NUMA感知的调度

基于多Worker的Pull方式的调度被组织成分组或者池。
→ 每个CPU可以有多个分组
→ 每个组可以有个软和硬优先级的队列
使用一个单独的watchdog线程检查各组是否饱和，并可以重新动态分配任务。

SAP HANA线程组

每个线程组可以有软和硬优先级的任务队列
→ 线程可以去偷窃其他组软队列的任务
每个组有四个不同的线程池：
→ Working: 正在执行一个任务
→ Inactive: 被latch阻塞在内核中
→ Free: 睡眠一会, 然后被唤醒去看是否有新的任务执行
→ Parked: 和Free一样，但是不能自己唤醒自己