由于第三章的内容比较多,这里我们拆分成两篇读书笔记来记录。上一章我们聊了聊如何数据库是如何实现存储和检索的,今天这篇我们继续来看看OLTP与OLAP存储引擎的区别与联系。
联机事务处理过程(On-Line Transaction Processing)也就是我们通常称之的OLTP。 联机分析处理过程(On-Line Analysis Processing)则被称为OLAP。
在文中,作者列出了两类处理过程的区别,我们来一一梳理一下:
SQL语言它适用于OLTP类型的查询以及OLAP类型查询。但是将两者类型的应用混杂与同一个数据库,会大大提升DBA的运维难度,同时数据库也没办法因地制宜的更好来设计优化不同的应用。
OLTP系统通常解决的是应用程序高可用性和低延迟的读写请求,往往是业务运行的关键所在。DBA也并不愿意让数据分析师在OLTP数据库上运行特殊的解析查询,因为这些查询通常需要扫描数据集的大部分,这会损害并发执行事务的性能。 所以随着海量数据不断增长,越来越多的公司选择将OLAP应用运行在一个单独的数据库来分析。这个单独的数据库称为数据仓库。
数据仓库,是一个独立的数据库,主要负责分析查询数据,而不会影响OLTP操作。数据仓库中包含公司在各种OLTP系统的数据的只读副本。数据从OLTP数据库中提取(周期性的进行数据转储或持续不断的更新),将提取的数据的结构转为易于分析的结构,然后加载到数据仓库。这样过程称为提取–变换–加载(Extract-Transform-Load)
ETL在数据仓库与数据库之间的交互
使用一个单独的数据仓库,而不是查询OLTP数据库直接分析。是因为数据仓库可以根据访问的特点优化查询。上一篇讨论的存储索引结构,通常都适用于OLTP数据库,但不适用于OLAP系统。接下来我们来看看适用于OLAP系统的存储索引结构。
在典型的数据仓库中,表的结构通常非常宽。事实表通常有超过一百列,有时设置为几百列。而通常数据仓库的查询只访问一次4或5列的查询。
大多数的OLTP数据库,存储是面向行的:一行之中的所有值会连续存放。 但是,当一个OLAP的存储查询需要少数的列时(每行由100多个列组成),需要将数据从磁盘加载到内存中,并解析它们,并过滤掉那些不符合所需条件的列。这会造成很多不必要的查询消耗。
按列而不是按行存储关系数据
压缩的位图索引存储单列。
在列存储中,存储行的顺序并不重要。最简单的就是将它们按照插入的顺序排序,因为插入一个新行只意味着追加到每个列文件中。但是,选择逻辑顺序,可以带来几点好处。 (1) 排序之后的列是有序的,更有利于定位查询数据。(如:按照时间排序,查询某个时间段内产生的数据) (2) 它有助于压缩列。如果主排序列没有许多不同的值,那么在排序之后,它将有许多重复的序列。简单的编码压缩之后,就可以极大的降低存储开销。
注意,对每个列进行独立排序是没有意义的,因为我们将不再知道列中属于哪一行。可以新建一个索引来指向对应的行。有序又要求高效,所以排序列的存储通常都是通过上文提及的SSTable格式在内存之中灵活处理。
数据仓库另一个常用的优化方式是:物化视图。如前所述,数据仓库查询通常涉及聚合函数,如SQL中的计数、总和、平均值、最小值或最大值。如果相同的聚合被许多不同的查询使用,那么每次都对原始数据进行处理是十分浪费的。为什么不缓存查询中经常使用的一些计数或总数呢?
在关系型的数据模型中,它通常被定义为标准(虚拟)视图:一个表一样的对象,其内容是一些查询的结果。虚拟视图只是编写查询的快捷方式。当您从虚拟视图中读取时,SQL引擎将它展开为视图的底层查询,然后处理展开的查询。而物化视图是将实际的查询结果写入磁盘,不需要额外的计算过程。但是当底层数据发生变化时,物化视图需要更新,因为它是一个非规范化的数据复制。(类似于触发器的工作原理)。所以物化视图是不常用于OLTP数据库,而在数据仓库进行ETL时进行更新。
通过表的两个维度,来聚合数据
物化视图的好处是:某些查询变得非常快因为他们已经被预先计算。 但物化视图的缺点是:查询原始数据的灵活性不足。 例如,没有办法计算哪种销售成本超过100美元的商品的比例。因此,大多数数据仓库尽量保留尽可能多的原始数据,并且只使用物化视图作为对某些常用查询的性能提升。
梳理了OLAP与数据仓库的联系,同时总结了几种在数据仓库种子常用的存储结构与对应的优化方式。接下来,我们进入下一章来看看编码在存储之中的意义。>由于第三章的内容比较多,这里我们拆分成两篇读书笔记来记录。上一章我们聊了聊如何数据库是如何实现存储和检索的,今天这篇我们继续来看看OLTP与OLAP存储引擎的区别与联系。