【架构师面试-存储-1】-行式存储与列式存储

1：OLTP与OLAP 

当今的数据处理大致可分为两大类

1：联机事务处理 OLTP (on-line transaction processing)

OLTP 是传统关系型数据库的主要应用，用来执行一些基本的、日常的事务处理， 比如数据库记录的增、删、改、查等等

不适合海量数据处理

ACID

串行化【单线程】：事务之间相互影响，要么锁住，(写锁)

2：联机分析处理 OLAP (On-Line Analytical Processing)

OLAP 是分布式数据库的主要应用，它对实时性要求不高，但处理的数据量大，通常应用于复杂的动态报表系统上。

2：行式存储与列式存储

行式存储法(Row-based)：数据一行行存储

传统的关系型数据库，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based)

在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的， 一行中的数据在存储介质中以连续存储形式存在。

列式存储(Column-based)：数据一列列存储

列式是相对于行式存储来说的，新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。

在基于列式存储的数据库中， 数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。

ElasticSearch、MongoDB、Solr、Splunk...

Redis(K/V)、

ps：MongoDB，属于文档存储，存储一个JSON(BSON)文档、或者一个文本（二进制）文档

类似：elasticserach，solr，oss……

也被称为NoSql

3：行式存储 适用场景

适合随机的增删改查操作;

需要在行中选取所有属性的查询操作;

需要频繁插入或更新的操作，其操作与索引和行的大小更为相关。

行式存储实操中，我们会发现行式数据库在读取数据时存在一个固有的“缺陷”。这个"缺陷"是什么？不擅长在海量数据中找数据。

4：列式存储 适用场景：

低延迟：查询过程中，可针对各列的运算并发执行，最后在内存中聚合完整记录集，最大可能降低查询响应时间;

查找数据高效：无需维护索引，查询过程中能够尽量减少无关IO，避免全表扫描

节省空间：因为各列独立存储，且数据类型已知，可以针对该列的数据类型、数据量大小等因素动态选择压缩算法，以提高物理存储利用率；如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值，这将比行式存储更节省空间。

当然，跟行数据库一样，列式存储也有不太适用的场景，这个场景是什么？

数据需要频繁更新的交易场景，表中列属性较少的小量数据库场景，不适合做含有删除和更新的实时操作

5：行存储 vs 列存储【读、写、删】

1：读取数据分析

假设：

从2^30行中取出1列数据 100001 ~ 200000行的name, status列

行存储读取成本分析：

场景：读取10W行数据的2列

先取行，再取列：从连续的空间取出10w行，从10w行结果集合中取出name和status列

1行平均10KB：10W行=10W * 10kb = ≈ 1G数据

Buffer如何是4M，将进行256次读取

10W过滤操作

列存储读取成本分析：

场景：读取10W行数据的2列

先取列，再取行：从2列中取出10w条

1列的一个条目平均20Byte，10W行的两列=20 byte * 10W ≈ 2M

Buffer如何是4M，将进行1次读取

不需要更多的过滤操作

2：更新一行多个值分析

行存储：一行数据

列存储：多列数据（次数多）

3：添加一行数据分析

行存储：一行数据

列存储：多列数据（次数多）

4：事务操作分析

行存储：锁一行数据

列存储：锁对应的列（范围大）

如果您觉得文章好看，欢迎点赞收藏加关注，一连三击呀，感谢！！☺☻