C-Store: A Column-oriented DBMS Mike

这篇paper比较老，是列存比较基础的论文

几乎所有列存，或olap的论文都会引用这篇

行存面向写，支持OLTP

列存面向读，支持OLAP

基于磁盘的DBMS，瓶颈基本在磁盘IO，所有做的工作都是用多余的cpu来换取磁盘IO

总体的思路，压缩让需要存的数据更小，densepack，更多的数据一起存，这样会更紧凑？

本论文的创新点，如下

Hybrid架构

这个架构很有借鉴意义，因为一种结构很难同时满足TP和AP的需要

所以用两个系统，一个用于write-optimized，一个用于read-optimized，中间用一个tuple mover进行数据的同步

后续很多列存和ap系统都是用的这种架构

数据模型

这里提出的数据模型，比较有意思

Table只是一个逻辑概念，真正存储的是projections，

projection是columns的集合，并且projection之间是可以overlap的

这其实不就是把一张表，拆成多张表吗？或者可以认为是一种行存和列存的balance？类似Hbase的column family

降低了数据库管理的成本

可以对不同的projection不同的排序，当前不同排序的成本是很高的，需要多存一份数据

数据冗余可以用于数据恢复，因为一个colunm往往在不同的projections中存了多份

避免join，因为这个projection可以包含外表的字段，但是由于表拆的更小了，所以又增加了join的概率，双刃剑

数据压缩

在RS端，需要对数据进行压缩来降低磁盘IO

在WS端，就不需要加压缩了，因为本身数据在memory，而且WS只是cache实时数据，数据量不大

分成4种情况，

自身有序，大量重复，记录length

自身无序，大量重复，bitmap

自身有序，少量重复，记录delta

自身无序，少量重复，无解

并且对于数据value，可以再加上B-tree索引，因为RS是没有更新的，所以索引可以建的非常紧凑，不会有空洞，densepack

Snapshot Isolation

SI的核心问题，是在查询时间ET，我们要决定在WS和RS中哪些records是visible的？

SI，之所以是Snapshot，就是不能update in place，写不影响原来的读

所以update变成，一个insert和一个delete，这样如果我们记录下，insert和delete的时间，然后和ET比较，就可以判断这个record是否可见

这里决定以绝对时间来作为visible的判断，粒度太小，所以提出epoch

所以会保存insertion vector和deleted record vector，记录每个record的insert和delete的epoch

Epoch是什么，

对时间的划分

有个leader TA，会定期发送message，告诉大家可以epoch+1

然后大家会进入下一个epoch，并且等当前epoch的Transaction都结束后，reply到TA

TA收到所有的reply，就会把HWM设为改epoch，然后广播给大家，这样HWM以下的数据都是被读到的