最早的商业列式数据库是在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’ 的时候就会停止扫描了。这相当与行式数据库索引里的范围扫描。
数据迭代 （Tuple Iteration）
现在的多核CPU 提供的L2 缓存在短时间执行同一个函数很多次的时候能更好的利用CPU 的二级缓存和多核并发的特性。而行式数据库由于其数据混在一起没法对一个数组进行同一个简单函数的调用，所以其执行效率没有列式数据库高。
压缩算法
列式数据库由于其每一列都是分开储存的。所以很容易针对每一列的特征运用不同的压缩算法。常见的列式数据库压缩算法有Run Length Encoding ， Data Dictionary ， Delta Compression ， BitMap Index ， LZO ， Null Compression 等等。根据不同的特征进行的压缩效率从10W:1 到10:1 不等。而且数据越大其压缩效率的提升越为明显。
延迟物化
列式数据库由于其特殊的执行引擎，在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算，直到最后需要输出完整的数据时。
（from McKnight : Columnar Database : Data Does the Twist and Analytics Shout）
传统的行式数据库运算， 在运算的一开始就解压缩所有数据，然后执行后面的过滤，投影，连接，聚合操作
而列式数据库的执行计划却是这样的。
（from McKnight : Columnar Database : Data Does the Twist and Analytics Shout）
在整个计算过程中， 无论过滤，投影，连接，聚合操作，列式数据库都不解压数据直到最后数据才还原原始数据值。这样做的好处有减少CPU 消耗，减少内存消耗，减少网络传输消耗，减少最后储存的需要。
列式数据库优缺点
列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生，它跟行式数据库相比当然也有一些前提条件和优缺点。
列式数据库优点：
- 极高的装载速度 （最高可以等于所有硬盘IO 的总和，基本是极限了）
- 适合大量的数据而不是小数据
- 实时加载数据仅限于增加（删除和更新需要解压缩Block 然后计算然后重新压缩储存）
- 高效的压缩率，不仅节省储存空间也节省计算内存和CPU。
- 非常适合做聚合操作。
缺点：
- 不适合扫描小量数据
- 不适合随机的更新
- 批量更新情况各异，有的优化的比较好的列式数据库（比如Vertica）表现比较好，有些没有针对更新的数据库表现比较差。
- 不适合做含有删除和更新的实时操作。
常见误区
一个常见的误区认为如果每次扫描较多行或者全列全表扫描的时候，行式数据库比列式数据库更有优势。事实上这只是行式数据库认识上的一个误区，即认为列式数据库的主要优势在于其列分开储存，而忽略了列式数据库上面提到的其他几大特征，这个才是列式数据库高性能的核心。