Mr Dk.

## 4.1 Row-based Storage (TiKV)

## 4.2 Column-based Storage (TiFlash)

## 5.1 Transactional Processing

## 5.2 Analytical Processing

## 5.3 Isolation and Coordination 为了避免 OLTP 和 OLAP 的资源冲突，TiKV 和 TiFlash 被部署到不同的服务器上。OLTP 负载主要访问 TiKV，OLAP 负载主要访问 TiFlash。 由于 TiKV 和 TiFlash 的数据可以被认为是一致的，因此 SQL 引擎中的查询优化器可以有以下选择： - TiKV row scan - TiKV...

 如果确定瓶颈不在某个类别中，那么该类别及其下属小类中的因素可以被忽略。 具体的分类标准由 PMU 得到的数据确定，比如顶层四大分类的区分方法： 

## Abstract 在一维的存储世界中模拟二维关系表的两种方式： - 按行存储：适合事务数据处理，因为业务通常只访问某几行 - 按列存储：适合分析型处理 本文经过分析得出，一个特别为列式存储设计的查询执行器对于获取性能来说至关重要。本文提出了 C-Store，分为存储层 + 执行层。提升性能的三个要点： 1. 执行层能够直接操作压缩后的列数据，提升 I/O 和 CPU 的效率；解决执行器扩展性的问题 2. 尽可能推迟各列被 join 成行的时机 3. invisible join

## Introduction 分析型应用的特点： - 不可预测：在事务型业务中，查询的模式基本是固定的（比如编码在应用程序中的 prepared statement）；而分析型业务比较自由 - 持续时间长：读取和计算的数据量大 - 面向读多于面向写：以只读查询为主，写入性能较差 - 聚焦于属性，而不是聚焦于实体：查询基本只会聚焦在某几个列上 几种构建列式存储的方法： - 对行存进行垂直分区，无需修改 DBMS 代码 - 修改物理存储层为列存，数据在进入执行层之前恢复为行存，无需修改执行器代码 - 修改物理存储层和执行层，充分针对列存场景进行优化：不同列的数据组成行元组的时机尽可能延迟，减少元组的构建开销 优化列式存储性能的更深层方法： - 压缩：列存有着更低的信息熵，压缩后可以节省 I/O；有些数据类型可以直接在压缩后的数据上操作；但执行器必须知道某一列是怎么压缩的，这可能会为执行器带来可扩展性的问题（一堆 if 语句）——本文试图解决这个问题，使得添加新的压缩算法不需要修改执行引擎代码 - 元组构造：大部分查询访问多于一个列，且大部分输出标准（ODBC...

## Column-Store Architecture Approaches and Challenges 三个等级的实现方式： - 行存模拟列存 - 列存 + 行存执行器 - 列存 + 列存执行器 使用行存来模拟列存的几种方案（性能都不好）： - 使用行存表来单独存储表的每一列，每个表包含两列： - ctid 用于把属于同一个行的各列数据串联起来 - 查询重写，使各个列表通过 ctid join - 列表中每个元组的开销过大 -...

## C-Store Architecture 每个表被表示为 **投影** 的集合，每个投影是一个表的子集，包含了表的所有行以及 **某几列**。每个投影中的各个列单独存放，但行顺序相同。表中的每个列至少会出现在一个投影中，一个列可以被存储在多个投影中（以不同的顺序）。 C-Store 中包含： - RS (Read-optimized Store) - WS (Write-optimized Store)：包含最近的写入和更新 由 Tuple Mover 周期性地把 WS 中的内容转移到 RS 中。 存储层上，投影中的每个列被存放在一个单独的文件中，被分为 64KB 大小的 block，每一个 block...