行存储
我们常用的关系型数据库mysql，oracle等都是基于行存储，以最常用的mysql数据库 innodb引擎为例,见下图
多个连续的行记录，组成一个data page（大小16k），然后按照B+树的结构进行组织存储。
这种存储模式适用于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的分析性能要求的存储结构呢?答案是肯定的。
行列混合存储
阿里的AnalyticDB就是采用行列混合存储的产品
如图所示，AnalyticDB将30720条记录定义为一个block，数据在block中的某一列，是按列存储的。同一block的不同列，又是连续存储的。在行列混存的模式下
- 多列写入 ，列存模式的随机写变成顺序写
- OLTP明细查询，select 多列由列存的随机读，变成了block内的顺序读
- OLAP多维分析，将随机读变成顺序读
基于行列混合存储的特性，配合倒排索引，bitmap索引，范围索引，预排序、各种的Cache机制、读写分离等。AnalyticDB做到了既满足大批量高性能写入、又满足千亿量级数据实时分析毫秒级别响应，很适合大数据量实时写入，实时分析的场景。
最后：阿里B2B广告团队招人，java，数据工程，数据挖掘，base可选北京杭州。有意者丢简历过来
hengyi.wzw@alibaba-inc.com
