形形色色的数据库

形形色色的数据库

——一文读懂 OLTP 和 OLAP

1

为什么会有这么多类型的数据库?

因为满足不了用户使用数据的全部需求。

数据使用说起来很简单,概括起来就是「读、写」二字,但实际操作中,无比复杂。

数据业务在大的方向上有两类,分别是交易型业务和分析型业务。

你可能见过这两个词:OLTP 和 OLAP,基本上就是对应这两种情况。

数据库为满足业务需求,也分为两大类:交易型数据库和分析型数据库。

交易型数据库是什么?

交易型数据库用于业务系统数据的增、删、改、查。又称为操作型数据库、事务型数据库。

业务系统就是我们平常所能接触到的各种功能系统,如企业经营过程中使用的各种管理系统,包括设计、研发、制造、销售、人力、财务的各种系统;个人生活娱乐、工作中用到的各种应用,如电商、微博、微信等。都可以看成业务系统。

这些系统,需要把我们提交的信息实时保存下来,也需要把保存好的数据展示出来,按用户各种查询条件过滤数据,还可接受用户的修改、删除。

通常,完整的一段信息会被分开存储,如一篇文章,分成标题、正文、作者等部分,按固定的结构存储,这就叫「结构化存储」。这种存储方式,有很多优点,因为粒度细、结构规整,想局部、全部地读写数据都很方便,效率非常高。

交易型业务,有两个字非常重要,即「实时」。数据要实时地成功写入,快速地读取。想想看,发生了一笔充值或消费的操作,数据却没有被实时地记录,后果非常严重。

哪种数据库用来支持交易型业务?

适用于以上场景的数据库,主要是大家所熟知的关系型数据库,如 MySQL、Oracle、SQL Server、PostgreSQL 等。

它们共同特点是一个库里会有多张表,相当于一个 Excel 文件中有多个 Sheet 页。每张表会存储相同业务和结构的数据,如商品表,只存储和商品有关的信息,有商品名称、商品规格、商品描述……订单表,只存储和订单相关的信息,订单号、订单金额、下单时间……每张表有多个列(字段)存储这些数据,同 Excel 文件的列一样。

这些数据库,有的是商业公司开发的,有的是开源的。一般来说,商业数据库,会支持更多的特性,性能、稳定性也更高,有好的服务保障。关键行业应用的数据库,如银行,用的都是商业数据库。

开源数据库应对一般的使用场景也没有问题,还可以按需调优和改造。很多国产关系型数据库就是基于开源关系型数据库改造而来。

关系型数据库除了上述几种,还有一类轻量的产品,以 SQLite 为代表,非常适合手机等移动设备应用本地存储。

只有关系型数据库就够了吗?

关系型数据库太「规范」了,事先需要有大量的结构设计(即建模)工作,到用的时候需要知道结构才能取出所需要的数据。读写的速度也不行,因为它最终要存储在硬盘上,如果数据从内存中读取,速度可以保障,但丢失风险高。

我们的目的是用数据,可不想耗费精力在它的结构上,通过结构化对数据进行使用,只是一种方法和手段而已,并不是一定得把数据结构化后才能用。况且,有时候结构本身是数据的一部分,拆成行、列的存储形式用起来反而不方便。

有些数据,非常适合用 JSON 的结构存储,如下图。再把这种 JSON 文档存储在不同的「单元格」中,这种存储方式和上面关系型数据库的原理有本质的差别。实际上这种方式就是 NoSQL 数据库的一种类型,叫做文档数据库。代表产品是 MongoDB。用户可以事先不关注数据库结构,只需关注文档内部的结构,每个文档的内部结构都可以不同,这样一来更贴合人类「自然」的使用。

NoSQL 除了文档型数据库,还有键值型数据库、列式数据库、图数据库、时序数据库等。各自典型的代表有 Redis、HBase、Neo4j、InfluxDB 等。

NoSQL 数据库为什么也有这么多种类型?

简单来说,有两个原因,一是数据本身的特点;二是出于使用场景的需要。

一种新技术或新产品的出现,一定是为解决某个具体的痛点。

比如 Redis 是基于内存的键值数据库,键值这种存储结构,类似于查字典,查询速度非常快,数据又是在内存读取,比硬盘快很多倍。它的应用场景在于较稳定不变的数据的高频读取,不必每次都从关系型数据库中查询,所有一般应用在数据缓存的场景中。

时序数据,即按照固定频率不断生成的周期性数据,一般物联网设备、日志数据等都会呈现时序特征,这类数据有非常显著的特点,比如说插入频率较为稳定,不会像天猫双十一活动非常高的并发写入,写入的数据几乎不被更新,不会像订单数据那样进行状态更新,也很少会删除单条数据,一般是对过期数据批量化删除。时序数据偶尔丢失几条,不会对整体业务造成太大的影响。它们的某些维度,可以合并存入,降低存储成本,如某台设备的 ID、IP 地址、甚至是地区,可以是类似「合并单元格」的存储方式,这实际上就是时序数据的压缩技术,可以有效节省存储空间。针对以上特点进行优化设计,就产生了专门的时序数据库。

图数据库,和图片、图像完全没有关系。它擅长实体关系的存储和表达,如社交关系、投资关系等,关系型数据库也能做到,多个实体可以通过主外键来建立关联,多对多的关系需要产生一张中间表来关联,如果存在大量的这种数据,关系型数据库就会耗费大量的存储资源,关联查询和递归查询效率也会比较低。即使是同一实体,如果关系穿透路径较长时,有时也会低到不可用的地步。图数据库利用节点和边的结构,比较完美地解决了上述问题。

从 NoSQL 这里,就有了向分析型数据库过渡的倾向,这一点在列式数据库上有明显的体现。列式数据库典型的代表是 HBase,顾名思义,在物理存储上,列式数据库按列存储数据,最大的优势是获取「局部数据」更快,在数据统计分析的场景下,我们通常是按列进行操作,比如对价格一列进行求总和、平均值、最大值、最小值等(术语上称为「聚合查询」,是分析的基础),这一列数据物理上存储在一个区域,一次就可以读取,而如果是按行存储,需要读取每一行,才能从每一行数据中找到「价格」那个单元格,这就是它最大的优势,所以数据分析业务,即 OLAP,列式数据库有很高的性能。

这种列式存储的结构,也非常有利于分布式存储。天然适合大数据。2

分析型数据库有什么特点?

简单地说,分析型数据库,是面向分析的,而不是面向记录数据和更新数据(这是交易型数据库做的事情)。

分析就是通过对数据进行有逻辑的计算,得出新的数据,新的数据可以印证一定的假设。想要做好数据分析,要求分析型数据库有以下特点:

首先,它需要存储大量静态的数据,基于尽可能多的数据,才最有可能还原真实情况。其次,需要能很快地取出计算所需的数据,这对于快速得到计算结果至关重要。最后,取出的数据可以很快地得到聚合的结果。

上面已经说到,列式数据库在前两点上已经支持的不错了。

换个角度来说,分析就是尽可能多角度地看待某项定量数据。多角度,就是「维度」,定量数据,就是「度量」,分析的核心内容,围绕的就是这两个关键词。

而这两个关键词的背后,就是离散数据和连续数据,两者之间相互转化的主要手段,就是聚合查询。所以最后一点,能快速得到聚合的结果,也是分析型数据库的着力点之一。由此诞生了很多 OLAP 的引擎。我们耳熟能详的有:Hive、Presto、Impala、Clickhouse、Greenplum、Doris、Druid、TiDB。

这些大数据开源工具,很难严格地界定它们是数据库,还是 OLAP 引擎,还是交互式查询(即席查询)引擎,正是由于上面提到的最后一个要求。它们通过各种技术原理和方法,实现能够快速地进行维度构建、关联、转换和度量的计算,最终达到快速获得分析结果。

另一方面,分析型数据库还得考虑易用性,对于我们来说,目前最好用的分析方法还是属 SQL 语句(尽管对普通人还是很难)。对于存得多和取数快,偏偏是 NoSQL 的长项,如何让分析型数据库良好兼容 SQL,也是分析型数据库核心要面对的问题。

以上是「关耳爷」微信公众号的小输出,请笑纳。