Online analytical processing (OLAP) is a system for performing multi-dimensional analysis at high speeds on large volumes of data. Typically, this data is from adata warehouse, data mart or some other centralized data store. OLAP is ideal fordata mining, business intelligence and complex analytical calculations, as well as business reporting functions like financial analysis, budgeting and sales forecasting.
引用IBM博客上的一段话就是:
在线分析处理(OLAP)是一种用于对大量数据进行高速多维分析的系统。 通常,此数据来自数据仓库,数据集市或某些其他集中式数据存储。 OLAP是数据挖掘,商业智能和复杂分析计算以及诸如财务分析,预算和销售预测之类的业务报告功能的理想选择。所以OLAP重分析、重决策,数据量大因此需支持高吞吐;对数据多维度分析可能涉及复杂查询,需要能够对多维数据进行钻取、切片切块、旋转。
Online transactional processing (OLTP)enables the real-time execution of large numbers of database transactions by large numbers of people, typically over the Internet. OLTP systems are behind many of our everyday transactions, from ATMs to in-store purchases to hotel reservations. OLTP can also drive non-financial transactions, including password changes and text messages.
在线事务处理(OLTP)使大量人员通常通过Internet实时执行大量数据库事务。 例如 从ATM机到店内购买再到酒店预订,OLTP系统是我们日常交易的基础。 OLTP还可以推动非金融交易,包括密码更改和短信。所以OLTP要求支持事务查询、低延迟、数据实时性、可靠性要求高。
参考:https://www.ibm.com/cloud/blog/olap-vs-oltp
熟悉数据结构的同学都知道,BST平衡树(红黑树 & AVL树)数据查询速度快(logN),BST平衡树单个父节点的字节点数量小于等于2,高度为h的平衡树,节点数N最多为2^h-1。基于内存的的BST平衡树存储结构在高度不断增加时对插入查询性能影响不大,但是基于磁盘存储时,鉴于磁盘寻道时间成本,随着树高度增加,数据查询时间将层指数被放大。例如磁盘单次寻道时间为10ms,百万级别的数据耗时约 10 * 20ms = 0.2s,当数据上亿级别,耗时将扩大至2s。
-----------------------------支持多节点的B树数据结构衍生而出----------------------------
B树结构如下,草图勿怪,表明其意即可
参考维基百科,根据 Knuth 的定义,一个 m 阶的B树是一个有以下属性的树:
每一个内部节点的键将节点的子树分开。例如,如果一个内部节点有3个子节点(子树),那么它就必须有两个键: a1 和 a2 。左边子树的所有值都必须小于 a1 ,中间子树的所有值都必须在 a1 和a2 之间,右边子树的所有值都必须大于 a2 。
B树详细介绍可参考维基百科:https://zh.wikipedia.org/wiki/B%E6%A0%91
虽然多节点的B树降低了磁盘寻道的成本,但是B树结构在范围查询时存在劣势,这就衍生出B+树数据结构
----------------------支持多节点&范围查询的B+树数据结构衍生而出--------------------------
B树结构如下
该图是参考维基百科的,图示看出,叶子结点通过指针连接,这种存储结构大大利于顺序的范围查询;
B+树详细介绍可参考维基百科:https://zh.wikipedia.org/wiki/B%2B%E6%A0%91
为了引出LSM树,下面来说下磁盘的结构划分
磁盘扇区,磁盘块,磁盘页的区别:
扇区:磁盘的最小存储单位;
磁盘块:文件系统读写数据的最小单位;
页:内存的最小存储单位;
磁盘块和页的大小一般情况下为4KB,所以在B+树中一个节点的最大存储数据个数的总大小一般不能超过4KB,针对大规模写操作,B+树需要不停的分列合并以平衡其结构,且每次操作均会涉及磁盘寻道;所以基于B+树的MYSQL在数据量大时需要分库分表
基于B+树结构的存储具有很好的读性能和范围查询,确定是承载数量大时需要做其他策略(例如Mysql的分库分表)以适应业务需求,因此基于B+树的存储结构比较适用于OLTP应用场景;例如 MySQL 作为 OLTP 数据库不仅具备事务的处理能力,而且保证数据的持久化并且能够有一定的实时数据查询能力。
-----------------------支持高效批量写操作的LSM树数据结构衍生而出--------------------------
LSM树的结构如下所示,LSM存储结构主要分为两部分:基于存储的Memtable和基于磁盘的SSTable文件。
根据key值顺序存储<key,value>,基于内存的存储断电后会失效,通过WAL Log(Write-ahead logging,预写式日志)方式保障数据可靠性,机器故障时通过WAL恢复历史内存数据,当Memtable写满时,内存出现会Flush或Compation至磁盘;
当 MemTable达到一定大小后,会转化成Immutable MemTable。Immutable MemTable是将转MemTable变为SSTable的一种中间状态。写操作由新的MemTable处理,在转存过程中不阻塞数据更新操作。
有序<key, value>集合,是LSM树组在磁盘中的数据结构。为了加快SSTable的读取,可以通过建立key的索引以及布隆过滤器来加快key的查找。途中Level 0 空间占满后即触发Major Compaction,合并Level 0数据至Level 1,其他层同理。
多级顺序存储这会引发两个问题:
基于内存和基于磁盘均存储有序键值对,通过利用磁盘顺序写性能大大优于磁盘随机写性能来提高批量写,反之,顺序键值对存储结构一定程度上折损了读性能,尤其是存储在Level N中的数据;因此基于LSM树的数据库适用于写多读少的场景,例如OLAP应用场景。
从上图黄色线部分可以看出行存储就是依照现有的(RowID,Date/Time,Meterial,CustomerName,Quantity)数据协议整行存储,存储完RowID=1的所有数据后依次存储下一行,典型的Mysql,SQL SERVER 等均采用行存储格式。
从上图绿色部分可以看出列式存储按照某一列纵向存储,例如先存储途中RowID(1,2,3,4,5,6,7)在存储Date/Time(845,861......),列式存储的存在是针对对列进行操作(eg 对列聚类,求和等)可减少对全表的扫描。且列式存储同一列上的数据类型相同,便于压缩。
综上列存储的数据库更适合OLAP,行存储的数据库更适合OLTP
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。