数据库列存储:设计最佳压缩算法的捷径

数据库存储的方式能决定数据库运行的效率问题，数据库频道向您推荐《数据库性能优化与调试》专题。

其实列存储并不是什么新概念，早在1985年SIGMOD会议上就有文章” A decomposition storage model”对DSM(decomposition storage model)做了比较详细的介绍，而Sybase更在2004年左右就推出了列存储的Sybase IQ数据库系统(见200年VLDB文章” Sybase iq multiplex – designed for analytics”)，主要用于在线分析、数据挖掘等查询密集型应用。

列存储，缩写为DSM，相对于NSM(N-ary storage model)，其主要区别在于，DSM将所有记录中相同字段的数据聚合存储，而NSM将每条记录的所有字段的数据聚合存储，如下图所示：

列存储有什么优点？

就我目前比较肤浅的理解，列存储的主要优点有两个：

1) 每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，据C-Store, MonetDB的作者调查和分析，查询密集型应用的特点之一就是查询一般只关心少数几个字段，而相对应的，NSM中每次必须读取整条记录；

2) 既然是一个字段的数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。

列存储适合用在什么场合？

OLAP，数据仓库，数据挖掘等查询密集型应用。当然，列存储数据库并不是说完全不能进行更新操作，其实它们的更新操作性能并不是很差，一般也够用，但是一方面不如自己的查询性能，另外一方面也不如Oracle这种专门搞OLTP的数据库，所以一般就不提这个。

列存储不适合用在什么场合？

相对来说，不适合用在OLTP，或者更新操作，尤其是插入、删除操作频繁的场合。

为啥上世纪80年代就出现的概念现在又重新炒起来了呢？

2005年VLDB有篇文章(“One Size Fits All – An Idea Whose Time Has Come and Gone”)，就是那个老牛M. Stonebraker写的，明确指出，时代变了，指望一个数据库产品就统一天下的日子已经一去不复还了。于是，这个老牛在2005年左右做了C-Store，一个列存储的数据库原型系统，在VLDB, SIGMOD等***国际会议上灌了几桶水后，拉了一伙人出去开了个公司叫Vertica，将其商业化，专注于数据仓库、在线分析等市场，最近貌似还挺红火的；顺便说一下，为了贯彻上面的思想，这个老牛在同一时期又做了H-Store，一个主内存数据库原型系统，没怎么灌水就又招呼了一帮人开了个公司叫VoltDB，将其商业化，专注于联机事务处理，但是近况貌似不怎么样，可能是跟Oracle老大大直接冲突了吧。

联想到M. Stonebraker在上世纪70年代带头开展关系数据库管理系统的实现工作，做出来了Ingres，其中灌水无数，从这个原型系统基础上产生了很多商业数据库软件，包括 Sybase、Microsoft SQL Server、NonStop SQL、Informix 等，而所谓的***进的开源数据库系统PostgreSQL也是Ingres的一个后继分支。

原文标题：说说列存储技术

链接：http://www.cnblogs.com/happyy/archive/2010/04/26/1721481.html

【编辑推荐】