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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。