行存储

我们常用的关系型数据库mysql，oracle等都是基于行存储，以最常用的mysql数据库 innodb引擎为例,见下图

行存储

多个连续的行记录，组成一个data page（大小16k），然后按照B+树的结构进行组织存储。

image.png
这种存储模式适用于OLTP的业务场景

一行记录的所有列连续存储，一次IO可以实现整行读取或者写入，实现数据库的ACID特性就比较简单。
OLTP常见的业务场景，点查询，点更新等
select c1,c2,c3 from table where id =xxx;
update table set c1=xxx,c2=xxx where id = xxx;
由于B+树的逻辑结构，千万级别数据量最少3次IO可返回结果。

列存储

随着数据量的膨胀（亿数量级）以及在线分析业务OLAP的发展，基于行存储的mysql等关系型数据库就开始力不从心了，基于列存储的数据库产品就开始登场。

列存

如图，数据按列进行存储。
行存和列存在以下关键点上有极大差异

IO放大问题
OLAP大多是对某一列或几列数据的一个聚合分析，比如找出年龄在18-30岁之间的人的userid ，如果是传统的行存储模式，即使在年龄上有索引，那么在回表查询的时候，也会不得不将符合条件记录的所有列（userid之外的姓名，性别...）都读出来。这就会造成IO放大，当数据量在亿级别的时候，这就很影响性能了，列存储就规避了这一点。
数据压缩问题
同一列的数据，数据类型一致，列存的模式下就适合数据压缩，不同的列可以采用不同的压缩算法，压缩存储就会带来IO性能的提升。
事务ACID问题
行存储，一条记录一次IO写入，那么保证事务特性就很简单。
列存储，一条记录拆分成多次IO进行列写入，那么就比较难实验事务特性。

这样的差异造成，OLAP场景很适合采用列存储，但是反过来，在OLTP场景，列存储又无能为力了。比如对某一条记录的写入或者修改，行存储一次IO搞定，可以保证数据的完整性，但是列存储就要将一条行记录的写入拆成多次的列记录写入，这就带来了写入IO的性能问题。

基于以上行存和列存的特性，在实际业务中，我们的OLTP系统一般是采用基于行存的数据库产品，像mysql oracle等，然后将业务数据离线导入到基于列存的产品，进行后续的分析，这种模式的实时性是很差的，一般用于分析T-1的离线数据，如果有需求要实时分析在业务系统中实时产生的数据，这种模式就无法满足了，那么有没有既能满足OLTP的写入性能要求，又能满足OLAP的分析性能要求的存储结构呢?答案是肯定的。