列式存储数据库
关系型数据库系统以二维表的形式呈现数据,比如下面的员工表
RowId | EmpId | Lastname | Firstname | Salary |
---|---|---|---|---|
001 | 10 | Smith | Joe | 40000 |
002 | 12 | Jones | Mary | 50000 |
003 | 11 | Johnson | Cathy | 44000 |
004 | 22 | Jones | Bob | 55000 |
上面的格式仅仅存在于理论和逻辑中,事实上存储设备要求数据序列化为某种形式。
我们知道对于硬盘来说,最昂贵的操作是查找。为了提高最终性能,所需要的相关数据应该以某种方式去存储从而使“查找”操作尽可能少。硬盘由一系列规定大小的块(block)组成, 通常足以容纳数据表的几行。通过把相关的行存储在块中,仅仅一定数量的块需要被读取从而最小化了查找的数量。
行式存储
传统的存储方案是按行序列化数据,如下所示
001:10,Smith,Joe,40000;002:12,Jones,Mary,50000;003:11,Johnson,Cathy,44000;004:22,Jones,Bob,55000;行式存储系统被设计为以很少的操作就可以返回整行或整条记录。当我们需要获取关于某个特定对象的信息的时候,比如某个用户的联系信息或某件商品信息,这种设计就相当适用。
但是行式存储不适用于对整个数据集的操作。比如,找出工资在40000到50000之间的记录,行式存储系统可能得找遍这个数据集才能找出匹配的所有记录。当数据量相当大时,这些记录存储于分散的不同的磁盘块中,这样相当多的磁盘操作就变得不可避免了。
为了提高这种类型操作的性能,大多数DBMS数据库系统使用索引技术。它把列的值存储在一起,同时与记录ID关联。如下所示
001:40000;002:50000;003:44000;004:55000;
我们可以看到,这里仅仅存储整个数据集的一部分,一般来说索引比整个主表要小很多。扫描小的数据集所需要的磁盘操作当然减少了。然而,当有新的数据写入数据库时,索引需要维护,这个对系统增加了额外的开销。
有些行式存储数据库被设计为完全运行于内存中,及内存数据库。这样的系统不依赖于磁盘操作,对于整个数据库的任何数据访问具有同等时间. (equal-time access) 这样的系统可能会很简单有效,然而它们管理的数据仅限于存储在内存中。
列式存储
列式存储系统将某一列的所有值序列化在一起,然后是另一列的所有值。对于我们的例表,数据存储结构如下
10:001,12:002,11:003,22:004;Smith:001,Jones:002,Johnson:003,Jones:004;Joe:001,Mary:002,Cathy:003,Bob:004;40000:001,
50000:002,44000:003,55000:004;
这样的结构看起来与行式存储中的索引结构看起来很像,对吧。是的,没错,看起来很接近。
只是,它们之间有显著的区别。行式存储中,主键是rowid(它关联到索引数据);列式存储中,主键是数据本身(关联回rowid),即“数据即索引”。对于常见的查询,如“所有名字叫Jones的人”,仅仅需要一个操作答案将被找到;另外,像一些聚合运算,基于这样的存储结构其性能能得以大幅提高。
Refer to: http://en.wikipedia.org/wiki/Column-oriented_DBMS