这篇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以下的数据都是被读到的
