存储模型(行存/列存）对 TP 和 AP 业务的影响

 

 

基础的数据模型是以行和列组成的一张张表。通常行有一个唯一标识 Row Id，且存在有限个字段，字段就是列的值。行数可以达到非常大的量级，而列数通常是有限的。

行式存储就是，数据在存储介质（磁盘 or 内存）上的组织形式，是以行为单位的，即先放第一行所有的数据，再放下一行，这种方式比较符合人的直觉。列存就不一样了，它会把行的数据统统拆开，先存一列的数据，再存下一列。那这样的区别对于业务会有什么影响呢？

• 行存在 TP 场景 IO 次数少。比如这条 SQL：select col0, col1, col2, col3 from table where col0 = 100，只需要根据主键或者索引定位到这一行在什么地方，就可以用一次读 IO 返回所有需要的数据。列存就不行了，因为同一行的不同列的数据是分开存放的，就算你定位到了某一行的位置，这里还是需要 4 次读 IO 把相关的列数据读上来。
• 列存在 AP 场景读得快。看这条 SQL：select avg(col0), max(col1), col2 from table group by col2，它需要遍历全表数据来做聚合。这时候列存的优势就来了。因为对于一段列数据，它的类型是一样的，数据读上来之后不需要做拆列；并且如果这条 SQL 不涉及 col2，那么它是不用去读的。

当然这里只是简单的分析，在工程上，实际情况比这个复杂的多。在实际业务中，我们往往需要 TP 和 AP 的能力都需要。常见的做法是，分别用不同的数据库服务不同的负载。而纠结的是，TP 和 AP 的场景并不能完全割裂，有很多原因在推动 HTAP 数据库的出现和流行。

• 从 TP 数据库把数据导入 AP 数据库太痛苦了。要适配，要运维，中间件还要额外机器，有些对实时性、一致性要求高的分析需求还没法做。
• 很多时候会存在一个模糊地带，即你事先没办法严格区分它是哪种场景，或者业务开发者写的 SQL 在两边左右摇摆，DBA 头很大！

但是确实有一些尝试，试图调和行存和列存的矛盾，大概有几种类型：

• 实现一个新的数据结构，行存和列存的优点都有（缺点也大概率跑不掉），比如 Spanner PAX。
• 把数据放 RAM 或者 NVM，利用高性能硬件的的性能和随机访问的能力，硬抗行存或者列存的劣势，比如 Hana，MemDB 等。
• 对数据做一些假设，把不同部分数据使用不同的方案。感觉这个方案比较容易翻车 orz，毕竟假设很容易被打破。
• 既然各有优缺点，那别纠结了都安排上吧！一份数据有多个副本，副本可以选择行存或者列存。典型的如 TiDB。

 如上内容来自于：韦万