查询执行

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

数据库调度

对于每一个查询计划，数据库系统需要决定什么时候，在什么地方，怎么样去执行。
→ 应该使用多少个任务？
→ 应该使用多少个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一样，但是不能自己唤醒自己

可以根据任务是CPU还是内存瓶颈来动态调整thread pinning，发现worker偷窃并不适合具有较多套接字的系统。使用线程分组允许内核执行其他任务，而不仅仅是查询。

观察

如果请求到达数据库系统的速度快于其执行速度，那么系统就会超载。
操作系统在这里帮不了我们：
→ CPU瓶颈: 啥也不做
→ Memory瓶颈: 内存溢出 OOM
数据库系统最简单的处理方式就是：崩溃

流程控制

• 2: 接收控制

  → 如果系统确认没有资源去执行新的请求，直接中止新的请求

• 1: 扼杀

  → 推迟对客户的答复，以增加请求之间的时间

→ 这假定了同步提交方案

一些思考

数据库管理系统是一个设计精妙，意志坚强的独立的一件软件，但是它需要确保它使用下列硬件是正确的：
→ 数据位置是这方面的一个重要方面。
→ 跟踪单节点数据库系统中的内存位置与在分布式数据库系统中跟踪Shard是相同的。
不要让操作系统毁了你的人生。

参考链接和文献：

[- 课程原文CMU 15-721 14-数据库调度 scheduling
](https://15721.courses.cs.cmu.edu/spring2019/slides/14-scheduling.pdf)
- V. Leis, et al., Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age, in SIGMOD, 2014
- I. Psaroudakis, et al., Scaling Up Concurrent Main-Memory Column-Store Scans: Towards Adaptive NUMA-aware Data and Task Placement, in VLDB, 2015 (Optional)
- I. Psaroudakis, et al., Task Scheduling for Highly Concurrent Analytical and Transactional Main-Memory Workloads, in ADMS, 2013 (Optional)
- D. Porobic, et al., OLTP on Hardware Islands, in VLDB, 2012 (Optional)