数据库列存储:设计最佳压缩算法的捷径
数据库存储的方式能决定数据库运行的效率问题，51CTO数据库频道向您推荐《数据库性能优化与调试》专题。
其实列存储并不是什么新概念，早在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
【编辑推荐】
- Oracle存储过程的编写经验总结
- 存储结构之Oracle逻辑存储结构
- 新一代数据存储架构面面观
- SQL Server存储过程命名标准
- 使用脚本加速DB2存储过程的开发