列式数据库的特点.docxVIP

PAGE 1 PAGE 1 列式数据库的特点  本文介绍了列式数据库的几大特点，列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生，它跟行式数据库相比当然也有一些前提条件和优缺点。  最早的商业列式数据库是在1995年发布的SybaseIQ，但是一直到1999年左右才渐渐稳定到能够投入生产环境。现在的大多数分析型数据库都是在2003-2005年从Postgresql分支出来的。其中尤其是Vertica为代表的列数据库已经在大规模数据仓库环境中证明其特殊为数据仓库环境设计的思路在一些领域具有竞争优势。这篇文章解释介绍列式数据库的几大特点。  高效的储存空间利用率  传统的行式数据库由于每个列的长度不一，为了预防更新的时候不至于出现一行数据跳到另一个block上去，所以往往会预留一些空间。而面向列的数据库由于一开始就完全为分析而存在，不需要考虑少量的更新问题，所以数据完全是密集储存的。  行式数据库为了表明行的id往往会有一个伪列rowid的存在。列式数据库一般不会保存rowid。  列式数据库由于其针对不同列的数据特征而创造的不同算法使其往往有比行式数据库高的多的压缩率，平凡的行式数据库一般压缩率在3：1到5：1左右，而列式数据库的压缩率一般在8：1到30：1左右。(InfoBright在特殊应用可以达到40:1，Vertica在特殊应用可以达到60:1，一般是这么高的压缩率都是网络流量相关的)  列式数据库由于其特别的IO模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务(SybaseIQ除外)。这又额外的削减了数据储存的空间消耗。  列式数据库不需要物化视图，行式数据库为了削减IO一般会有两种物化视图，常用列的不聚合物化视图和聚合的物化视图。列式数据库本身列是分散储存所以不需要第一种，而由于其他特性使其极为适合做平凡聚合操作。(另外一种物化视图是不能实时刷新的，比如排名函数，不规则连接connectby等等，这部分列数据库不包括。)  不可见索引  列式数据库由于其数据的每一列都根据选择性进行排序，所以并不需要行式数据库里面的索引来削减IO和更快的查找值的分布状况。如下图所示:当数据库执行引擎进行where条件过滤的时候。只要它发觉任何一列的数据不满意特定条件，整个block的数据就都被丢弃。最终初步的过滤只会扫描可能满意条件的数据块。  (fromInfoBright:BlazingQueriesUsinganOpenSourceColumnarDatabaseforHighPerformanceAnalyticsandReporting)  另外在已经读取了可能的数据块之后，对于类似age65或job=‘Axx’的，列式数据库并不需要扫描完整个block，因为数据已经排序了。如果读到第一个age=66或者Job=‘Bxx’的时候就会停止扫描了。这相当与行式数据库索引里的范围扫描。  数据迭代(TupleIteration)  现在的多核CPU供应的L2缓存在短时间执行同一个函数许多次的时候能更好的利用CPU的二级缓存和多核并发的特性。而行式数据库由于其数据混在一起没法对一个数组进行同一个简洁函数的调用，所以其执行效率没有列式数据库高。  压缩算法  列式数据库由于其每一列都是分开储存的。所以很简单针对每一列的特征运用不同的压缩算法。常见的列式数据库压缩算法有RunLengthEncoding，DataDictionary，DeltaCompression，BitMapIndex，LZO，NullCompression等等。依据不同的特征进行的压缩效率从10W:1到10:1不等。而且数据越大其压缩效率的提升越为明显。  延迟物化  列式数据库由于其特别的执行引擎，在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算，直到最终需要输出完整的数据时。  (fromMcKnight:ColumnarDatabase:DataDoestheTwistandAnalyticsShout)  本文介绍了列式数据库的几大特点，列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生，它跟行式数据库相比当然也有一些前提条件和优缺点。  最早的商业列式数据库是在1995年发布的SybaseIQ，但是一直到1999年左右才渐渐稳定到能够投入生产环境。现在的大多数分析型数据库都是在2003-2005年从Postgresql分支出来的。其中尤其是Vertica为代表的列数据库已经在大规模数据仓库环境中证明其特殊为数据仓库环境设计的