Mr Dk.
验证开启 hardware prefetching 在虚拟机环境下是否会导致性能回退。这里的 prefetching 指的是从主存中预取指令和数据到 CPU cache 中。 Prefetching 主要被用于填补主存和 CPU 之间的速度差异。然而，当大量 prefetching 请求竞争有限的内存带宽和 cache 资源时，反而可能引起性能的回退。由于虚拟机环境中多个虚拟机可能共享 CPU 核心（以及 cache），传统的最佳实践是在虚拟机环境下关闭 hardware prefetching。 本文通过 OLTP 和 FileBench 两个场景的测试，说明只有在特定场景的组合下会发生性能回退。基于回退场景，提出了 VM 的 Virtual...
这是一篇深刻影响现代 DBMS 设计的论文。Volcano 严格来说不算一个 DBMS，而是一个查询执行系统，因为其中并没有用户友好的 UI、查询语言、类型系统、优化器、catalog 等。Volcano 完成了以下设计特性： 1. 模块化、可扩展设计 2. 不对数据模型作出任何假设，查询处理基于参数化的算子实现 3. 在基于单进程实现的算子上实现基于 shared memory 的并行化，并行处理与数据操纵无关 4. 使用 mechanism 来支持 policy 5. 实现了两个不对数据发生 manipulation 的 meta 算子
## Volcano System Design Volcano 包含两层： 1. 文件系统层：包含记录、文件、索引扫描操作，缓冲区管理 2. 查询处理层：查询处理模块，可以被组织为复杂的查询处理树  ### The File System 缓冲区管理器只提供 mechanism，比如保持页面、读写 disk page 等；而更高层的软件根据数据的敏感性、重要性、访问模式来决定如何使用这些 mechanism 的 policy。Volcano 中大量使用了这种 mechanism 和 policy 分离的设计策略，从而实现高度的模块化。 文件系统的扫描实现了两套接口。其中一套是标准的文件扫描接口：open、next、close、rewind，为了快速创建文件，还实现了 append。另外，扫描还支持可选的...
## Dynamic Query Evaluation Plans 查询优化器需要对系统中可用资源进行估算，最终查询计划的优劣性直接受估算准确性的影响。Volcano 提供了一个可以避免优化器不准的方法：动态查询计划选择。 在 Volcano 中，引入了一个也被实现为迭代器模式的 choose-plan 算子，它不会对数据有任何操作，所以是一个 meta 算子。该算子的 `open` 操作决定下属的哪一个子计划树应当被执行，并调用被选中子计划树的 `open`。该算子的 `open` 操作调用 support function 来决定使用哪个子计划，并传入 bindings 作为参数。`next` 和 `close` 就是简单地调用被选中子计划的 `next` 和 `close`。...
## Multiprocessor Query Evaluation 关系型查询处理系统中能够相对容易使用并行的主要原因： 1. 查询处理以表达式树流水线的形式表示，可以实现 **算子间并行（inter-operator parallelism）** 2. 每个算子内消费或产生的数据可以被分片为不相交的集合，从而实现 **算子内并行（intra-operator parallelism）** Volcano 的目标是不修改所有已有的单进程查询处理代码，所有的并行化问题都在一个提供标准迭代器接口的算子内解决，该算子在 Volcano 中被称为 exchange 算子。由于实现了标准的迭代器接口，因此这个算子可以被插入在计划树的任何位置上：  ### Vertical Parallelism 所谓垂直并行即进程间的流水化。Exchange 算子的第一个功能就是提供垂直并行能力。算子的 `open` 操作在共享内存中创建了一个叫做 port 的数据结构用于同步和数据交换，然后将创建一个新进程。子进程是父进程的完整拷贝，但是在 exchange...
## Grammar 在语法上，规则系统包含： - 规则名称 - 规则触发事件（或者可以被认为是时机，增/删/改/查） - 规则操作对象（看起来是一个查询 body，可以带过滤条件） - 规则动作 ``` DEFINE RULE rule-name [AS EXCEPTION TO rule-name] ON event TO object [[FROM clause] WHERE clause] THEN DO...
# Implementation 文中给出了两种实现规则系统的方法： 1. 在执行器内，处理每一条元组的时候，实现规则 2. 实现查询重写，在 Parser 和 Optimizer 之前实现这个模块 方法 1 于 1995 年在 Postgre95 出现前从 Berkeley Postgres 项目中移除（原因是？），方法 2 被实现并保留到了现在。其基本算法是替换规则中出现的 `CURRENT`、`NEW` 引用，并替换所有的元组使用和过滤条件。然后不断进行重写，直到没有更多规则可以被应用为止。 这也是目前 PostgreSQL 中 Query Rewriter...
# 2. Internal Sort: Avoiding and Speeding Comparisions ## 2.1 Comparision-Based Sorting versus Distrubtion Sort 传统的数据库排序都是由基于比较的排序算法实现的，比如快速排序或内部归并排序；而不是基于分布的排序算法，比如基数排序。然而，基于比较的排序一定会包含条件分支，这就导致了潜在的分支预测失败引发 CPU 的 stall。虽然现代 CPU 有着高效的分支预测硬件，但是数据库内排序的比较结果是不可预测的。这就让基于分布的排序算法有了吸引力。 虽然基于分布的排序算法有着更少的 CPU stall 和更少的 data cache 或 TLB miss，但暂未取代...
## 2.3 Order-Preserving Compression 对数据压缩，但保留数据间的大小顺序关系。效率没有无序压缩高，但优于完全不压缩。 ## 2.4 Cache-Optimized Techniques 现在处理器可以在一个时钟周期内执行多条指令，而一次 cache miss 可能会浪费几十个甚至上百个时钟周期。因此，使排序比较时的指令数量减少，不如减少 cache miss 的有效性更高。其中，减少代码尺寸相当重要，尤其是内层循环的比较操作。Key 的规范化使得原先复杂的比较操作的指令数量大大减少，直至能够完全放入 CPU cache。 数据 cache 和指令 cache 同样重要。通过将数据结构进行内存对齐，或者将数据移动变为指针移动，都可以减少数据 cache miss。
## Architecture ### OLTP 引擎 使用 ByteNDB，是一个计算与存储分离，一写多读共享存储的架构，类似 Aurora。  存储上分为 Page Store 和 Log Store，合并起来就是正确版本的数据。 ### HTAP 引擎  使用引擎分离、共享存储的架构设计。通过统一的 API，经过一个智能代理，把请求分流到 OLTP 或 OLAP 引擎上。这样可以避免 OLTP 和 OLAP 的互相干扰。OLTP 的...