京公网安备 11010802034615号
经营许可证编号:京B2-20210330
悉数那些“巨型”数据仓库
最早的商业列式数据库是在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'
的时候就会停止扫描了。这相当与行式数据库索引里的范围扫描。[page]
数据迭代 (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)[page]
在整个计算过程中, 无论过滤,投影,连接,聚合操作,列式数据库都不解压数据直到最后数据才还原原始数据值。这样做的好处有减少CPU 消耗,减少内存消耗,减少网络传输消耗,减少最后储存的需要。
列式数据库优缺点
列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生,它跟行式数据库相比当然也有一些前提条件和优缺点。
列式数据库优点:
极高的装载速度 (最高可以等于所有硬盘IO 的总和,基本是极限了)
适合大量的数据而不是小数据
实时加载数据仅限于增加(删除和更新需要解压缩Block 然后计算然后重新压缩储存)
高效的压缩率,不仅节省储存空间也节省计算内存和CPU.
非常适合做聚合操作。
缺点:
不适合扫描小量数据
不适合随机的更新
批量更新情况各异,有的优化的比较好的列式数据库(比如Vertica)表现比较好,有些没有针对更新的数据库表现比较差。
不适合做含有删除和更新的实时操作。
常见误区
一个常见的误区认为如果每次扫描较多行或者全列全表扫描的时候,行式数据库比列式数据库更有优势。事实上这只是行式数据库认识上的一个误区,即认为列式数据库的主要优势在于其列分开储存,而忽略了列式数据库上面提到的其他几大特征,这个才是列式数据库高性能的核心。
数据分析咨询请扫描二维码
若不方便扫码,搜微信号:CDAshujufenxi
一、问题:为什么 ID 会"断号" 很多刚接触 MySQL 的同学都会有一个困惑:表里的主键 ID 是自增的,删了中间几行数据之后,ID 变 ...
2026-10-22一、问题场景:为什么会重复 JOIN 同一个子查询 在写复杂 SQL 时,经常遇到这种需求:同一张表或同一个聚合子查询,要和主表关联 ...
2026-10-22人力资源专员是HR体系的执行入口。招聘信息发布、简历初筛、面试安排、考勤汇总、入离职手续、劳动合同与档案管理,大多由这个岗 ...
2026-10-22人力资源经理问“必学技巧”,真正要解决的不是知识清单不够长,而是时间有限、业务催得紧,学完却用不上。更有效的路径是:先用 ...
2026-10-22内容营销岗位的核心任务,不是“把文案写得更漂亮”,而是围绕目标受众,用持续的内容供给影响认知、推动转化并沉淀复购。它至少 ...
2026-10-22理财经理培训课程很多,难的是判断“先学什么、后学什么、学完能做什么”。与其按课程名称罗列,不如先看岗位任务:客户分层与维 ...
2026-10-22理财经理的知识结构,可以先用一句话概括:合规与产品知识决定“不出错”,客户经营与资产配置决定“够不够专业”,市场研判与数 ...
2026-10-22经济学背景做数据分析,优势不在工具,而在问题意识:供需如何相互作用、成本与收益如何权衡、变量之间是相关还是因果。真正的缺 ...
2026-10-22需要,但要把“需要”理解准确。经济学本身就在处理数据:GDP、物价、就业、企业营收、问卷调研,都是经济分析的原料。真正的区 ...
2026-10-22经济学分析能力不是单一技能,它至少由三层构成:把现实问题转成可检验假设的理论框架能力、用数据与统计方法验证假设的工具能力 ...
2026-10-22金融分析师的知识提升,先补的不是更多模型,而是让结论可复核的底层能力。按任务顺序,大致是四层:财务与业务理解、指标口径管 ...
2026-10-22金融分析师的“通用技能”,指换到不同机构、不同行业组仍用得上的底层能力,而非某家公司内部系统的操作经验。按任务拆,日常要 ...
2026-10-22先给结论:数据分析证书不是金融分析师的准入条件,招聘方也不会因为一张证书就直接判断你能做分析。要不要考,取决于你当前任务 ...
2026-10-22金融分析师的核心技能,不是“会看K线”或“会讲宏观”,而是能把一家公司、一个行业或一类资产,转化为可核查的数据判断与书面 ...
2026-10-22产品经理的知识提升,不是把需求文档、原型、SQL、数据分析、项目管理都学一遍,而是先对准目标岗位的真实任务,找出自己最缺的 ...
2026-10-22产品专员提升工作知识,最有效的方式不是先囤课程,而是围绕日常交付的四件事来补:需求调研与优先级判断、原型与PRD表达、竞品 ...
2026-10-22产品运营专员提升个人能力,常见误区是先把Excel、SQL、Python列成一张学习清单,然后从第一个工具开始学。更有效的做法是先回答 ...
2026-10-22产品运营的能力提升,最怕从“课程目录”出发:今天学增长模型,明天背SQL语法,学完却说不清自己负责的功能为什么激活率低。更 ...
2026-10-22产品经理的技能和影响力不是两条分开的赛道。技能决定你能不能把问题分析清楚、把方案设计对;影响力决定你的判断能否被团队接受 ...
2026-10-22产品经理要学的数据分析能力,不是“会写SQL”或“会用BI工具”这么简单。更准确地说,是围绕需求评估、功能迭代、指标监控、实 ...
2026-10-22