对列式数据库的一点总结和展望

6年半以前，我回到中国，重新加入我近19年前离开的公司：Sybase中国，负责在中国地区推动列式数据库产品Sybase IQ。从去年开始角色有些转换，从列式数据库转而关注SAP的数据库战略，同时关注在“极端OLTP”场景下的数据库技术发展方向。现在似乎是一个回顾一下列式数据库这个技术过去近10年来的发展过程，并展望一下未来的发展方向的时候了。

     2006年前后，一般企业的数据规模大约在100GB级别，个别大企业开始尝试挖掘TB级数据中的价值，也开始体会TB级数据管理及分析的挑战了。列式数据库在几乎低调、甚至沉寂了近10年之后开始被一些前瞻性客户关注了。

      归根溯源，列式数据库可以追溯到1994年，Sybase公司收购了一家名为ExpressWay Technologies的公司，其主要产品是帮助传统数据库做报表加速的工具，原理就是把行式数据库的数据以列式的方式存储下来。这个技术在1996年被正式推出为产品Sybase IQ，并延续到了现在。我们来看看为什么这样一个从行式到列式的转变可以提高报表的速度吧：

首先，行式数据库顾名思义，存储格式是按照‘行’的方式把一行各个字段的数据存在一起，一行一行连续存储的。这样的话，对把一条数据的信息写到数据库中；或者对一条数据中的某些字段进行修改；或者删除整条数据一类的OLTP操作来说既直观也高效。但是，在行式数据库上做一些报表、分析的时候，大家又发现这种存储格式使用效率不高，因为大部分统计分析场景，例如：统计各省份的销售额和利润同比变化；按照部门统计业绩完成情况等等，都是在其中某些字段上的操作，行式数据库不分情况一律按照页面读取数据的方式，在只分析销售额和利润的时候，把每一份合同的其他信息，如客户名称，签约时间，客户经理等等也统统都读了进来，浪费了大量宝贵的I/O。

数据库界给出的第一个改进办法就是“索引”，就像字典前面的目录一样，做到快速定位。但是随着分析场景变得越来越复杂、变化越来越多，DBA们发现索引通常只能为一部分查询、分析起到帮助的作用，如果想为一个企业级的BI系统中所有的查询、分析场景做优化，无论是从组合的角度，还是从开销的角度，都几乎是不可能的，因为大量的索引所带来的存储空间的浪费以及为维护这些索引所带来的时间的浪费都会以指数级别增长。

 

而列式数据库的思路原理并不复杂，把行式数据全部拆开，按照列的方式重新组合存储，一列的所有行的数据存放在一起；按照列内数据的特征值（通常像时间、部门代码、销售地区等维度字段的特征值并不多，几个到几百个很常见）进行高效编码，并且在实际存储中以编码形式存储，这样就带来了大比例的压缩。

带来的好处是：原来只分析销售额的查询就只访问销售额字段，即使是所有历史时期的数据，也不存在读多余的无关数据的问题。

真正的列式数据库具有的创新性在于所有字段都是索引的，甚至可以认为索引和数据是统一的，这样一来，企业数据分析中最困难的随机查询，反而变成了列式数据库的长项，经常出现在这些复杂、多表关联、历史数据分析的场景中比传统的行式数据库快成百上千倍的情况。

列式数据库在数据仓库、数据集市、企业商务智能（BI）等领域已经发挥了越来越多的作用，在全球数以千计的企业中支撑着大量的大数据分析场景的应用，最大的可公开的数据仓库压缩后的数据量达几百TB，约合传统行式数据库内几PB的总量。各家数据库厂商都已经以不同的形式在接受列式存储技术，推出不同风格、不同类型的列式存储的产品，例如最新的微软SQL Server 2012中的Columnstore Index就是一个很好的例子，可选择地定义个别列式存储的索引。

未来会怎样呢？这里说一点个人的观点：

 

1. 一项技术从产生到兴盛需要一段时间，列式数据库目前应该仍处于高速发展期，在未来的1-3年间应该还会出现更多的用户接受列式数据库对分析类场景的优势，更大量地采用
2. 更多的ISV会重点投入开发基于列式数据库的分析类应用，充分享受列式数据库的优势
3. 列式数据库的宗旨在于丰富而高效的索引，会有更多的索引出现，为不同的分析场景提供高效的服务，例如：全文检索、图像分析等等。
4. 更长期的范畴：技术产品通常会有分久必合，合久必分的情况，在另一个高度上把行式数据库和列式数据库以某种智能的方式组合在一起也是一种可以预见，并且已经见到类似SAP HANA这样的尝试已经显露出一些初期的势头

让我们积极加入到列式数据库技术的学习、研究、使用及发展的浪潮中，在数据库这个既传统而又不断出新的领域中捕获各自的机会，贡献各自的才智吧