クエリの実行
クエリプランがオペレータによって構成され、オペレータの例は、一度データの片にオペレータと呼ば算出され、タスクは、そのような演算子インスタンスの一連のシーケンスを実行することです。
スケジュールデータベース
各クエリプランのデータベース・システムの場合は、いつ、どこで、どのようにそれを行うことを決定する必要があります。
→どのように多くのタスクを使用する必要がありますか？
→どのように多くのCPUコアを使用する必要がありますか？
→どのタスクがCPUコアで実行する必要がありますか？
→タスクがどこにその出力格納する必要がありますか？
オペレーティングシステム以外のデータベース・システムは、知っていることはありません。
今日はについて話されています。
- プロセスモデル
- データの配置
- スケジュールデータベース
プロセスモデル
プロセスモデルデータベース・システムは、マルチユーザの同時要求のアプリケーションをサポートすることができるシステム・アーキテクチャを定義します。労働者は、データベースのコンポーネント、最終顧客に代わって任務の実装であり、結果を返します。
1：プロセスワーカー
2：プロセスプール
3：スレッドワーカー
ワーカーのプロセス
各ワーカーは、独立したOSのプロセスである
→のOS依存のスケジューリングシステム
グローバル共有メモリデータ構造→。
→プロセスがクラッシュし、システム全体がクラッシュすることはありません。
→例：IBM DB2、Postgresのは、Oracle
プロセスプール
ワーカー・プロセス・プールには、任意のアイドル状態のプロセスを使用することができます。
→OSのシステムはまだスケジューリング、共有メモリに依存しています。
→不利なCPUのキャッシュの局所..
→例：IBM DB2、Postgresの（2015）
スレッドワーカー
具有多个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: 扼杀
→ 推迟对客户的答复，以增加请求之间的时间
→ 这假定了同步提交方案
一些思考
データベース管理システム洗練されたデザイン、意志の強い、独立したソフトウェアであるが、それは次のハードウェアを使用することが正しいことを確認する必要があります：
→データの場所は、この点で重要な側面です。
→同じシャードは、分散データベース内の単一ノード・データベース・システムのメモリ・ロケーションおよびトラッキングシステムを追跡しています。
オペレーティングシステムがあなたの人生を台無しにさせてはいけません。
参考リンクと文学：
【 -课程原文CMU 15から721 14-数据库调度スケジューリング
（https://15721.courses.cs.cmu.edu/spring2019/slides/14-scheduling.pdf）
- V.ライスら、Morsel-。駆動型並列処理：NUMA-Awareのクエリ評価の枠組みSIGMOD、2014年メニーコア時代、用
- I. Psaroudakis、ら、スケーリング最大同時メイン・メモリ列-ストアスキャン：適応NUMA対応データとタスクの配置に向けて、VLDB、2015（オプション）で
、高同時分析とトランザクションのメイン・メモリーワークロードのためのタスクスケジューリング、らI. Psaroudakis、ADMS、2013（オプション）で- 。
- 。らD. Porobic、ハードウェア諸島のOLTP 、VLDBで、2012（オプション）