最早的商业列式数据库是在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 等等，这部分列数据库不包括。）

　　不可见索引

　　列式数据库由于其数据的每一列都按照选择性进行排序，所以并不需要行式数据库里面的索引来减少IO 和更快的查找值的分布情况。如下图所示： 当数据库执行引擎进行where 条件过滤的时候。只要它发现任何一列的数据不满足特定条件，整个block 的数据就都被丢弃。最后初步的过滤只会扫描可能满足条件的数据块。

　　（from InfoBright ： Blazing Queries Using an Open Source Columnar Database for High Performance Analytics and Reporting ）

　　另外在已经读取了可能的数据块之后，对于类似age < 65 或 job = ‘Axx’ 的，列式数据库并不需要扫描完整个block，因为数据已经排序了。如果读到第一个age=66 或者 Job = ‘Bxx’ 的时候就会停止扫描了。这相当与行式数据库索引里的范围扫描。