几张图看懂列式存储(转)

阅读目录数据库

1 为何要按列存储
2补充:数据压缩
3查询执行性能
add by zhj: 终于明白了什么是列式存储,什么是行式存储。这跟数据在存储介质中的存储结构有关,ide

列式存储是指,一列中的数据在存储介质中是连续存储的;行式存储是指一行中的数据在存储介质性能

中是连续存储的。简单的说,你能够把列式数据库认为是每一列都是一个表,这个表只有一列,如.net

果只在该列进行条件查询,速度就很快。翻译

那这两种不一样的存储方式对数据的CRUD有什么不一样的影响呢?看了一些文章,code

通常说的是下面两点orm

1。行数据库适用于读取出少行,多列的状况;列数据库相反,适用于读取出少数列,多数行的状况。blog

2。列数据库能够节省空间,若是某一行的某一列没有数据,那在列存储时,就能够不存储该列的值。排序

这比行数据库节省空间索引

我我的感受列数据库只适合对单个列进行条件查询,不适合对几个列的字段进行多条件组合查询,因

为每一列上的查询都是独立完成的,至关于每一列都是一个单独的数据库表,须要每一列的查询结果进行

join链接,join的条件是row_key相等,但每列的查询结果集可能很大。当咱们对一个列的数据进行切片,

存储在不一样的机器上时,通常是按主键进行排序,而后分片。额,有点乱。以HBase为例来讲吧,它每一

列的数、据其实都是按row-key排序的,这样的好处是,必定范围内row-key能够放在一台机器上,当咱们

用row-key进行查询时,能够很快就查到数据。HBase没有二级索引,若是我想用另外一列的字段作为查询条

件,那会全表扫描了。这样看来,貌似列数据库只有上面第2点的优点了

原文:http://blog.csdn.net/dc_726/article/details/41143175

最近看到一篇很好资料,里面三言两语配上几个图就把列式存储(Column-based Storage)讲明白了,牛啊!最喜欢的就是这种浅显易懂就把背景知识讲得明明白白,而不是长篇大论的讲概念。

回到顶部
1 为何要按列存储
列式存储(Columnar or column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来讲的。简单来讲二者的区别就是如何组织表(翻译很差,直接抄原文了):

Ø Row-based storage stores atable in a sequence of rows.

Ø Column-based storage storesa table in a sequence of columns.

下面来看一个例子:

从上图能够很清楚地看到,行式存储下一张表的数据都是放在一块儿的,但列式存储下都被分开保存了。因此它们就有了以下这些优缺点:

行式存储

列式存储

优势

Ø 数据被保存在一块儿

Ø INSERT/UPDATE容易

Ø 查询时只有涉及到的列会被读取

Ø 投影(projection)很高效

Ø 任何列都能做为索引

缺点

Ø 选择(Selection)时即便只涉及某几列,全部数据也都会被读取

Ø 选择完成时,被选择的列要从新组装

Ø INSERT/UPDATE比较麻烦

注:关系型数据库理论回顾 - 选择(Selection)和投影(Projection)

回到顶部
2补充:数据压缩
刚才其实跳过了资料里提到的另外一种技术:经过字典表压缩数据。为了方面后面的讲解,这部分也顺带提一下了。

下面中才是那张表原本的样子。通过字典表进行数据压缩后,表中的字符串才都变成数字了。正由于每一个字符串在字典表里只出现一次了,因此达到了压缩的目的(有点像规范化和非规范化Normalize和Denomalize)

回到顶部
3查询执行性能
下面就是最牛的图了,经过一条查询的执行过程说明列式存储(以及数据压缩)的优势:

关键步骤以下:

  1. 去字典表里找到字符串对应数字(只进行一次字符串比较)。

  2. 用数字去列表里匹配,匹配上的位置设为1。

  3. 把不一样列的匹配结果进行位运算获得符合全部条件的记录下标。

  4. 使用这个下标组装出最终的结果集。
相关文章
相关标签/搜索