Facebook 在2010年4月发表了一篇在Hadoop 里面实现列储存的论文: RCFile: A Fast and Space efficient Data Placement Structure in MapReduce based Warehouse Systems.
CSDN 上面有这篇文章的一部分翻译, 它当时提出这个设想其实就是想做一个列数据库，而实现列数据库的第一步就是实现列储存，本文主要介绍当时Hive 的RCFile 的实现环境与限制，下一代Hadoop的架构对新的RCFile 产生的影响以及将来可能出现的Hadoop 列数据库计算模型的一些相关问题.
RCFile 在实现的时候主要需要满足facebook 在以下4个方面的需求:
Fast data loading、
Fast query processing、
Highly efficient storage space utilization
Strong adaptivity to highly dynamic workload patterns
facebook 团队在参考设计的时候使用的是实验性质的C-store 数据库，而不是像另外一篇非常有名的Hadoop 与DBMS 争论的论文: A Comparison of Approaches to Large-Scale Data Analysis 中使用的是列数据库中非常好的Vertica 数据库做参考. 所以其在上面4点中并没有得到最好的设计，尤其是当时的Hadoop 架构上的限制非常的大，RCFile 的推出算是一种可以接受的能够实现的设计, 毕竟一个不算完美的设计可以慢慢修改，而一个设计非常优秀但是不能实现的设计等于空话.
阅读全文…
传统的行数据库使用的基本都是数据字典算法(Data Dictionary) 算法，或者叫标记化(tokenization)算法, 将Block 里面经常出现的相同值写在Block的头部，在实际储存值的地方用1,2,3,A,B 这种符号代替.这种算法将不同的列放在一起，所以出现相同值的概率非常低. 而行式数据库在每一列分开储存，可以针对每一列的特征使用不同的算法. 这篇文章就是介绍列数据库常用的压缩算法.
最早的列式数据库Sybase IQ 使用的是一种Decomposed 模型, 简单的将每一列分开，然后用rowid 来标记每一行的位置. 如下所示
| age |
rowid |
|
region |
|
|
customer |
|
|
| 18 |
1 |
|
region1 |
1 |
|
customer1 |
1 |
|
| 19 |
2 |
|
region1 |
2 |
|
customer6 |
2 |
|
| 29 |
3 |
|
region1 |
3 |
|
customer109 |
3 |
|
| 29 |
4 |
|
region6 |
4 |
|
customer28 |
4 |
|
| 31 |
5 |
|
region2 |
5 |
|
customer15 |
5 |
|
| 32 |
6 |
|
region6 |
6 |
|
customer16 |
6 |
|
| 18 |
7 |
|
region1 |
7 |
|
customer88 |
7 |
|
| 18 |
8 |
|
region3 |
8 |
|
customer27 |
8 |
|
后来的列式数据库基本上都不用rowid 来标记每一列的位置, 并且对于每一个Block 的数据一定是先计算那一列具有最高选择性（唯一值最少），然后依次以选择性来排序从而可以不使用rowid 标记行的位置.
而由于排序之后相同的值在一起的机会更大，所以压缩率也就比普通的简单列储存(也即上面介绍的Decompose模型) 的压缩率大很多倍.
阅读全文…
最早的商业列式数据库是在1995年发布的Sybase IQ , 但是一直到1999年左右才慢慢稳定到能够投入生产环境. 现在的大多数分析型数据库都是在2003-2005年从Postgresql 分支出来的. 其中尤其是Vertica 为代表的列数据库已经在大规模数据仓库环境中证明其特别为数据仓库环境设计的思路在一些领域具有竞争优势. 这篇文章解释介绍列式数据库的几大特点.
- 高效的储存空间利用率 传统的行式数据库由于每个列的长度不一，为了预防更新的时候不至于出现一行数据跳到另一个block 上去, 所以往往会预留一些空间. 而面向列的数据库由于一开始就完全为分析而存在，不需要考虑少量的更新问题，所以数据完全是密集储存的.
行式数据库为了表明行的id 往往会有一个伪列rowid 的存在. 列式数据库一般不会保存rowid.
列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率，普通的行式数据库一般压缩率在3：1 到5：1 左右，而列式数据库的压缩率一般在8：1到30：1 左右. (InfoBright 在特别应用可以达到40:1 , Vertica 在特别应用可以达到60:1 , 一般是这么高的压缩率都是网络流量相关的)
列式数据库由于其特殊的IO 模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(Sybase IQ 除外) . 这又额外的减少了数据储存的空间消耗.
列式数据库不需要物化视图,行式数据库为了减少IO 一般会有两种物化视图，常用列的不聚合物化视图和聚合的物化视图. 列式数据库本身列是分散储存所以不需要第一种，而由于其他特性使其极为适合做普通聚合操作.(另外一种物化视图是不能实时刷新的，比如排名函数,不规则连接connect by 等等，这部分列数据库不包括.)
阅读全文…