随着业务越来越看重数据的重要性，相信大家也做了很多
多维分析的需求，在调研技术选型时候，会发现很多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.会查询出来很多不需要的列
列存储
姓名 | 身份证号 | 检测机构 | 检测时间 | 结果 | 价格 |
|---|---|---|---|---|---|
| 彦祖 | 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 |
- 在列存储中，对于同样的核酸记录表，存储的物理结构如下：
列物理结构
- 在列式存储中，会把每一列存储到一起，如
姓名列，是把所有记录中的姓名这列的值使用连续空间存放到一起 - 而对于各个列之间，是没有必要使用连续空间存放到一起的，所以很多列式数据库都使用了分布式存储的方式，存储各个列
- 下面我们来分析下列存储的
数据压缩和查询执行流程
列存储的数据压缩
- 很多列式数据库都是通过
字典表的方式进行数据压缩 - 因为是把每一列存放到一起的，所以很容易通过对于每一列进行去重，来构建一个字典表，例如：
- 对于
姓名列，这列的所有数据如下：
彦祖|德华|路人甲|德华|彦祖
- 对这列值去重以后，构建一张
姓名列字典表，构建算法忽略，就使用自增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
id | 姓名列 |
|---|---|
| 1 | 彦祖 |
| 2 | 德华 |
| 3 | 路人甲 |
2.通过查询到彦祖的id，对于性名列进行对比，构建一个bitmap，把匹配的要的列的索引位设置为1，否则为0
姓名列
3.对于where 价格=20
和上面一样的操作，先查询价格字段表，20的id=2
id | 价格列 |
|---|---|
| 1 | 35 |
| 2 | 20 |
| 3 | 8 |
| 4 | 23 |
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，谢谢！
链接：https://www.jianshu.com/p/d1114dd4f77a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。