随着业务越来越看重数据的重要性，相信大家也做了很多多维分析的需求，在调研技术选型时候，会发现很多olap，如druid、clickhouse、starRocks都是列式存储数据库，今天我们来通过对比行存储简单说下列存储

举个栗子来说下列存储和行存储

要过年回家了，今天做了核酸检测，我们就以存储核酸检测为业务场景

栗子

核酸检测表

• 就以应用页面为主，存储核酸记录需要存储以下几个字段
• 姓名、身份证号、检测机构、检测时间、结果、价格

行存储

• 在行存储下（如mysql等），大家都比较熟悉，就不多说了，每条记录都是表中的每一行，表存储如下
  | 姓名 | 身份证号 | 检测机构 | 检测时间 | 结果 | 价格 |
  |-----|-----|--|----------|-----|-----|
  | 彦祖 | 123512387 | 北京 | 2021-12-24 12:12:45 | 阴性 |35|
  | 德华 | 213124157 | 上海 | 2021-12-22 12:12:45 | 阴性 |20|
  | 路人甲 | 213123145 | 河南 | 2021-12-21 12:12:45 | 阴性 | 8 |
  | 德华 | 213124157 | 广州 | 2021-12-29 12:12:45 | 阴性 | 23|
  | 彦祖 | 123512387 | 上海 | 2021-12-30 12:12:45 | 阴性 | 20|

• 因为数据都是按行方式存储，所以在物理存储中，会以连续空间来存储数据，物理存储中，这些数据存储方式如下：

  
  
  行存储物理结构

行存储优点分析

• 在这样的物理结构下，因为是连续空间，所以插入一条数据只需要追加到当前数据之后即可，很方便
• 对于按记录查询也很方便，例如：我们要查询彦祖的所有核酸记录，页面应用的话应该是通过彦祖的身份证号
• 对应的sql如下：

select * from 核酸记录表 where 身份证号='彦祖的身份证号'

• 这个sql的执行流程比较清晰

1.先从索引查询出来彦祖的记录存储的物理地址
2.在通过物理地址去表的物理存储中查询对应地址中的数据

• 这样就可以快速得到彦祖的核酸记录

行存储缺点分析

• 这时候，业务方提了一个需求，他要统计彦祖做核酸总共花了多少钱
• 对于这个需求，sql实现也很简单，通过对价格列sum就可以实现，sql如下：

select sum(价格) from 核酸记录表 where 身份证号='彦祖的身份证号'

• 这个sql的执行流程也比较清晰

1.先从索引查询出来彦祖的记录存储的物理地址
2.在通过物理地址去表的物理存储中查询对应地址中的数据
3.拿到所有数据时候，在通过对于价格列sun聚合得到结果

• 分析下，因为行存储使用的是连续空间，即使需求里面只需要select sum(价格)，但是读取物理存储时候，还是读取出来了所有的字段

行存储优缺点总结

• 通过上面的分析，总结一下行存储的优缺点
• 优点：

1.连续空间对于插入/更新很方便
2.对于记录查询很方便

• 缺点

1.会查询出来很多不需要的列

列存储

• 在列存储中，对于同样的核酸记录表，存储的物理结构如下：

列物理结构

• 在列式存储中，会把每一列存储到一起，如姓名列，是把所有记录中的姓名这列的值使用连续空间存放到一起
• 而对于各个列之间，是没有必要使用连续空间存放到一起的，所以很多列式数据库都使用了分布式存储的方式，存储各个列
• 下面我们来分析下列存储的数据压缩和查询执行流程

列存储的数据压缩

• 很多列式数据库都是通过字典表的方式进行数据压缩
• 因为是把每一列存放到一起的，所以很容易通过对于每一列进行去重，来构建一个字典表，例如：
• 对于姓名列，这列的所有数据如下：

彦祖|德华|路人甲|德华|彦祖

• 对这列值去重以后，构建一张姓名列字典表，构建算法忽略，就使用自增id的方式,如下：
  | id | 姓名列 |
  |-----|-----|
  |1| 彦祖 |
  |2| 德华 |
  |3| 路人甲 |
• 这样构建字典表，对于列存储的物理存储结构，就可以执行存储字典表中的id,而不用存储具体的值，有了字典表以后姓名列存储如下：

1|2|3|2|1

• 同样对于价格列，这列的所有数据如下：

35|20|8|23|20

• 对这列值去重以后，构建一张价格列字典表，构建算法忽略，就使用自增id的方式,如下：
  | id | 价格列 |
  |-----|-----|
  |1| 35 |
  |2| 20 |
  |3| 8 |
  |4|23|

• 有了字典表以后价格列存储如下：

1|2|3|4|2

• 这样通过一些数据压缩算法等，可以对数据存储进行压缩

列存储的查询执行过程

• 有字典表以后，我们来看下，列存储一般是如何进行查询的
• 业务需求查询彦祖，20块钱做的核酸记录：

select * from 核酸记录表 where 姓名=彦祖 and 价格=20

• 对于该sql，执行过程如下：

1.对于where 姓名=彦祖
首先查询姓名字典表，查询到彦祖的id=1

2.通过查询到彦祖的id，对于性名列进行对比，构建一个bitmap，把匹配的要的列的索引位设置为1，否则为0

姓名列

3.对于where 价格=20
和上面一样的操作，先查询价格字段表，20的id=2

4.通过查询到价格20的id，对于价格列进行对比，构建一个bitmap，把匹配的要的列的索引位设置为1，否则为0

价格列

5.对于两个where条件的结果bitmap做与运算，bitmap中，位为1的索引就是要查询数据的所有列的索引,如该栗子中，两个结果bitmap与运算后的结果是00001，所以所有列的第5个值，拼接起来就是我们要查询的数据

与运算

6.所以我们把所有列的第五个值拿出来组装后就是我们需要的数据

列存储优点分析

• 上面讲了列存储的数据压缩,在数据压缩上列存储有一定的优势
• 每一列都可以天然做索引，不需要额外的数据结构来对各个列构建索引，所以不用在意每一列的数据类型，都可以做索引
• 对于统计彦祖做核酸总共花了多少钱这种需求

select sum(价格) from 核酸记录表 where 身份证号='彦祖的身份证号'

• 因为列是分开存储的，按照上面讲的查询流程，其实最后我们得到的结果bitmap，拿到位=1的索引后，我们不需要查询所有的列，只需要拿着索引去价格列中获取相应位置的值，然后在进行sum聚合

列存储缺点分析

• 因为各个列是分开存储的，所以在插入、更新时，需要对于每一个列进行操作，没有行存储连续空间那么方便
• 还是看上面说的查询过程，每次查询过后，都需要对查询到的需要的列进行一个数据组装

列存储优缺点总结

• 通过上面的分析，总结一下列存储的优缺点
• 优点：

1.数据压缩比较有优势
2.任何列都可以做索引
3.查询时只有涉及到的列会被读取

• 缺点

1.每次查询时，都需要对查询到的列进行数据重新组装
2.插入/更新操作比较困难

列式存储数据库就说到这里，欢迎大家来交流，指出文中一些说错的地方，让我加深认识，愿大家没有bug，谢谢！