【架构师面试-存储-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：事务操作分析
行存储：锁一行数据
列存储：锁对应的列（范围大）
如果您觉得文章好看，欢迎点赞收藏加关注，一连三击呀，感谢！！☺☻
标签：存储,列式,行式,数据库,架构师,数据,10W 来源： https://blog.csdn.net/chongfa2008/article/details/121804236