【CMU15-445 Part-12】Query Execution I

Part12-Query Execution I

Processing Models

Processing Model主要指的是明确如何去执行一个查询计划（top 2 bottom or bottom 2 top,operator之间的传递）。

Iterator Model

(volcano model/pipeline model);每个算子实现一个Next( )，父节点会调用子节点的next，然后子节点返回结果（下一个父节点需要处理的tuple）；

对一个tuple来说这种模型能让查询计划中尽可能多的使用它，一个operator处理完返回传入下一个继续用该tuple。

1. 遍历子节点next返回的每个tuple，进行projection操作。

pipeline model的原因是针对一个tuple进行了一系列的操作，并且在对一个tuple处理的时候，其他还可以进行去tuple等操作，更像是流水线。当我们将某些东西放到内存之后，在对下一条数据处理前要尽可能多的对该数据进行处理。

有些算子不适合流水线处理，pipeline breaker (joins,subqueries,order by)，在去做下个操作前，这些算子需要从子节点获取更多数据。iterator model再输出控制很简单（limit clauses)

Materialization Model

主要用在内存数据库。

调用Next的时候不想只返回一个tuple而是调用每个operator的时候就返回所有的tuples，不用逐个获取。假设需要limit 10，可以将查询信息向下传递来避免扫描很多tuples。返回的可以是一个单独的列或者一个materialized row

这里不同就是output返回的的all tuples。对OLTP wordload来说很好因为查询可以一次性获得少量或者一个tuple。对OLAP不好 因为数据量很大的时候在算子之间传递的代价就会很高

difference? one tuple passing in M model and iterator model?

Vectorized/Bactch Model

调用next的时候传递的是a batch的tuples而非单个tuple，重写next。每次调用Next返回的tuple size 取决于hardware，取决于速度多快，是不是循序IO。设定一个n，如果buffer size 足够一个batch就像上返回一堆tuple。对OLAP友好，因为OLAP主要对表中大部分数据进行长时间的一个扫描处理（数据仓库）

Plan Processing Direction

Approach #1 Top-to-Bottom

root开始 pull data from children，tuples

Approach #2 Bottom-to-Top

从叶子结点开始 向上推data，向上传递数据的时候得确保我们所正在处理的数据能够放在CPU cache and registers，对CPU友好但是对人难以解释。

Access Methods

叶子节点发生的事，通过access methods到DBMS表里面查找数据通过next进行传递。

三种基本方式：循序扫描sequential scan，索引扫描index scan以及multi-Index/”Bitmap” Scan

Sequential Scan

对1个table的每个page，取到bufferpool；迭代器遍历tuple，check是否符合。 DBMS一般会维护内部cursor来tracks last page/slot/tuple?

优化：prefectching（双缓冲）、buffer pool Bypass（用一个小buffer来对线程或者查询进行缓存 而不是去污染buffer pool 缓存）、

• Zone Maps

  提前计算关于page中某列的聚合信息 明确是否需要去访问这些page。即：Min、Max\AVG\SUM\COUNT… DBMS会首先检查zone map然后才会决定会不会访问该page。有些是把zone map存到page里面，所以实际还是访问了page。有些保存在单独的page里面，zone map block、Zone page保存了不同page的zone map，类似于元数据的东西可能放在内存中。维护zone map代价也很高 一般不会用在OLTP中，而是在OLAP，读多写少。

• Late Materialization

  对列式存储系统来说可以延迟将数据从一个oper 传播到下一个oper，只需要传递offset或者判断条件，具体数据很可能不需要的最后，因为列存最后组成tuple的话得拼接，代价大。下面的例子：filter以join算子不需要传递具体的数据因为对应的a，b列用不到，只需要最后去取c列。

  

• Heap clustering/Clustering Index 聚簇索引

  

Index Scan

索引扫描，DBMS选取一个合适的index来找到查询所需要的tuples。选哪个index取决于：

• 哪些属性上有index
• 哪些属性是索引需要的
• 属性的具体值，是否具有选择性能否查得更快
• 具体的判断条件
• unique index / non-unique index

以上是查询优化器要做的事情。

例子：在第一个场景中 要使用dept作为索引 只需要找到两个就可以了。第二个场景是99个人是CS的，就俩人小于30岁，用age作为索引，更有选择性

• Multi-Index Scan：
  1. 对于每个匹配的index 计算负荷的record ids
  2. 根据查询的判断条件combine这些sets，and or
  3. Retrieve the records

Bitmap Scan in PG，没饿过bit对应了每个record的位置，进而可以使用位操作and or出结果。

Index Scan Page Sorting

如果是非聚簇索引，如果输出结果并不是基于索引的id来进行排序，可能是其他的属性排序并且该属性上没有索引，沿着叶子节点扫描获取所有record id，根据page id排序。

DBMS 通常会先找到所有需要的 tuples，根据它们的 page id 来排序，完毕后再读取 tuples 数据，使得整个过程每个需要访问的 page 只会被访问一次。

order by,subquery,join,limit,min,max are all pipeline breakers;

Expression Evaluation

where子句表示为一个表达式树expression tree，该tree上所有节点代表了条件判断中不同类型的表达式，

• comparisons = < > ≠
• conjunction:And Disjunction OR
• Arithmetic Operators + - * /
• 常量
• tuple attribute references

select * from s where B.value = ? + 1;

Prepared Statement 声明查询模板，占位符运行时填入，类似于调用函数

需要关注execution context

优化where 1=1，JIT：just in time compilation。