http://www.penglixun.com/tech/database/column-oriented_dbms_analyse.html
列式数据库的简单分析
二 3rd, 2010 | Posted by P.Linux | Filed under 数据库 发表评论 | Trackback
本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/database/column-oriented_dbms_analyse.html
这些天看数据仓库的内容，发现一个新内容——列式存储。曾经有想过把数据库行列转置作成索引，不过没有深想，没想到列式数据库已经开始发展起来了
。
首先看下WIKI上对列式数据库的解释
：列式数据库是以列相关存储架构进行数据存储的数据库，主要适合与批量数据处理和即席查询。相对应的是行式数据库，数据以行相关的存储体系架构进行空间分配，主要适合与小批量的数据处理，常用于联机事务型数据处理
。
数据库以行、列的二维表的形式存储数据，但是却以一维字符串的方式存储
，例如以下的一个表：
EmpId Lastname Firstname Salary
1 Smith Joe 40000
2 Jones Mary 50000
3 Johnson Cathy 44000
这个简单的表包括员工代码(EmpId), 姓名字段(Lastname and Firstname)及工资(Salary).
这个表存储在电脑的内存(RAM)和存储(硬盘)中。虽然内存和硬盘在机制上不同，电脑的操作系统是以同样的方式存储的。数据库必须把这个二维表存储在一系列一维的“字节”中，又操作系统写到内存或硬盘中。
行式数据库把一行中的数据值串在一起存储起来，然后再存储下一行的数据，以此类推。
1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000;
列式数据库把一列中的数据值串在一起存储起来，然后再存储下一列的数据，以此类推。
1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000;
这是一个简化的说法。
昨天装了下两个基于MySQL的数据仓库，infindb和infobright，看了文档发现它们都是列式数据库
，把40多M的数据导入infobright，没想到数据文件只有1M多，压缩比令我惊讶！
然后测试了下选择某一列，在列上做计算，都比MyISAM和InnoDB要快
，看了一些原理文档，就自己模拟了一下，写了个程序测试。
从内存中读取效率很高，但是从磁盘中读取（假设行式数据库的索引在内存中）比行式数据库要慢（开始在Twitter上说比行式快是程序写错了），不过我觉得还是我设计上的问题，至少Infobright就比MyISAM/InnoDB快，列式应该也有其特殊的索引机制和缓存机制，例如每列分开存在不同的文件，这样文件指针转移会更快
。
2010-02-04补充：采用了多个文件指针后，列式存储明显加速，如果给每个列一个文件指针，效率会非常高，也可以肯定，如果每个列单独存储一个文件，效率还会提高
。现在文件中列式表读取效率降低了4/5，接近行式表了。继续优化还能提高。
代码请展开：...
(略)
2010-02-04测试结果：
======生成数据======
+—–静态数据—–+
分配空间中……
空间分配完毕!
分配空间耗时: 0ms
生成数据中……
数据生成完毕!
生成数据耗时: 4180ms
正在将数据写入文件……
数据写入完毕!
写入数据耗时: 2480ms
静态行式存储耗费空间: 495M
静态列式存储耗费空间: 259M
+—–动态数据—–+
=====内存存取测试=====
+—-静态表测试中—-+
*行式存储*
正在测试内存中读取行式静态表……
内存中行式静态表读取测试完毕!
读取耗时:10 ms
正在测试内存中列式静态表读取……
内存中列式静态存储表读取测试完毕!
读取耗时:0 ms
*列式存储*
正在测试磁盘中读取行式静态表……
磁盘中行式静态表读取测试完毕!
读取耗时:190 ms
正在测试磁盘中列式静态表读取……
磁盘中列式静态存储表读取测试完毕!
读取耗时:210 ms
共匹配:69650 行
All OK!
http://www.douban.com/note/62372165/
列式数据库之infobright
2010-03-06 23:21:51
年前听过Sybase中国区副总裁的关于列式数据库的讲座
之后就一直被列式数据库强大的性能吸引。最近邂逅了infobright
，列式数据库的学习展开了。
Sysbase可以说是列式数据库的先驱，Sysbase IQ 15 就是Sybase 目前最新的列式数据库。
它具有强大的功能，包括数据的快速加载、超高速的分析性能、强大的业务智能分析、领先的数据建模能力等等。
infobright是一个基于MySQL的数据仓库系统，共工的不周山的blog上有挺详细的介绍
。同样是列式数据库，但是infobright和Sybase IQ系列还是有很大的不同
。infobright采用的Knowledge Grid来组织数据，infobright内部是没有索引，就这点就节省了不少的空间。
而Sybase IQ系列还是使用了索引，而这些索引我个人的理解就是位图索引的改进版。白皮书上说，infobright的数据压缩比可以是10：1到40：1
，个人拿庞大的日志数据库做了个小小实验，感觉压缩也没那么夸张。如果依据位图索引的思想，每列数据的相似度越高就会具有越高的压缩比。infobright应该也是满足这一点的，但是具体Knowledge Grid内部如何实现还不清楚，有待继续考究。
infobright的优点有很多，简单列举如下：
Infobright的优点：
（1）高压缩比率
（2）快速响应复杂的分析查询语句
（3）随着数据库的逐渐增大，查询和装载性能基本保持稳定
（4）没有特殊的数据仓库模型（比如星状模型、雪花模型）要求
（5）无需要物化视图、复杂的数据分区策略、索引
（6）实施和管理简单，需要极少的管理
（7）和众多的BI套件相容，比如Pentaho、Cognos、Jaspersoft。
infobright有两个版本ICE和IEE，目前ICE的版本是3.3.1，支持64位Linux和32位windows。ICE不支持DML
，也就是不支持insert、update等操作。
至于infobright的应用待改天认真写。感谢豆友Once的帮助，以后还会认真请教他。待下次有机会再去豆瓣希望能够和他好好聊一聊。
http://blog.csdn.net/BU_BetterYou/archive/2008/05/14/2445964.aspx
列式数据库专栏——曾经 ... 当今关系型数据库体系结构的起源
收藏
列式数据库专栏
一个由多名专家撰稿的关于数据库技术和创新的博客。
曾经 ... 当今关系型数据库体系结构的起源
当今关系型数据库管理系统很大程度上是基于二十世纪 80 年代的设计理念而构建的。相对于今天的系统而言，那个时候的计算机价格不菲，而且速度很慢。最大程度上减少昂贵的 CPU 周期 – 而不考虑 I/O 吞吐 – 是早期关系型数据库管理系统 (DBMS) 设计的驱动力。
市场追逐的有利卖点是事务处理以及与之相配的简单决策支持，只要能够访问有限的属性（维度）集，用户往往就感到满意了。
事务处理通过主键或其它键来检索行，并在这些行上执行适当的插入、更新和删除操作。可以通过索引或散列进行直接访问，其提供的快速访问只占用小部分处理能力，还具有足够的并发性。在大多数系统中，平均起来每个表有一到两个散列或索引。
这减轻了在执行删除和插入操作时必须维护大量结构的压力－会占用相当大的处理器周期的操作。
吸取 IBM 的经验教训
在 IBM 早期开发 DB2 的时候，我们的重点是最大限度地减少用于事务处理占用的处理器周期，并与我们的硬件同行一起合作优化了比较相关的几个部分
。相对于前一代非关系型数据库管理系统（IMS、IDMS、DATACOM 等等）而言，DB2 的成本增加了两到三倍以上，主要是由处理器消耗产生。很多人容易忽略的事实是，在 DB2 上开发和部署应用程序，比在现有的数据库管理系统上要明显快得多
。
尽管关系型的指令只是想检索应用程序真正需要的一行中的某些属性，但应用程序倾向于检索整行（所有属性）。应用程序拥有标准的表格映射，它们是由应用程序代码中的数据字典生成的。编写SELECT *并添加谓词比在复杂应用中确定是否与其它部分共享检索行要简单得多。将行的属性从存储缓冲区移到应用程序的空间将占用很多处理能力，并且在分布式系统中占用还会加大，因为首先需要将数据从存储缓冲区移到网络空间，然后再移到应用程序空间
。优化这种烦琐活动以及其它许多在处理器通道、高速缓存优化和指令集中的活动，会使得用于事务的处理器消耗有明显改观。搜索只是一个较小的活动；要想获得成功，必须关注混合行处理、序列化、扩展性和可用性等各方面。
到了 80 年代中期，DB2 的价格与现在的数据库管理系统不相上下。
这些系统已扩展到处理更大范围的商务智能问题，这就要求访问非预期属性的数据并通过函数来分析这些过滤的数据。
设法提高查询速度
为了提高在关系型系统中的查询速度，我们的重点放在改进并行全表扫描、更智能化的索引技术，以及对压缩对象的压缩搜索。
在数据库中增加了很多功能来减少处理器周期，并利用物化视图进行预计算。但是，维护大量的索引和物化视图无论是在时间（处理）还是空间（存储）方面成本都很高。虽然这种方法在可预见的访问情况下是非常有效的，但无法满足真正随机访问的应用，在这种情况下全表扫描是唯一的解决方法。
在二十世纪 80 年代，数据库的行很小（实际上，模型是 80 列穿孔卡片，平均每条记录有 20 个字段），而且实体（表）的数量也很小（100 个算是很大了）。当时通常是双向和三向连接。而今天，每个表的属性数量都能达到数百个，更有甚者达到数千个。数据库中的表的数量已经上升到了数千个。六路和七路连接司空见惯；十路和十二路连接也屡见不鲜。只有跟踪了 SAP 模式的发展的人，才能见证到这种变化。
因为涉及到的查询参数（属性）和关系的数量，查询已显得更为复杂。
列式体系结构强调属性和关系
要解决这些问题，设计逆向数据库非常有必要，因为其重点强调属性列表和实体间的关系
。这正是列式数据库能够做到的。其余是决定成功与否的细节：压缩效率；连接链表；用时间戳标记的数据元素以提供历史记录详细信息，还包括减轻加载和更新操作的压力；添加所有关系型的功能等等
。
一个简单的事实是，这种类型的数据库能根本满足当今商业智能的关键需求
；即，查询包含大量属性和关系的集合，并在其上使用业务函数
。
原文：Once upon a time ... the origins of today's relational database architectures 曾经 ... 当今关系型数据库体系结构的起源下载
From:http://hi.baidu.com/zeorliu/blog/item/97d08e2314c89948ad34de4d.html
