PolarDB · 引擎特性 · 历史库

数据库内核月报 - 2020 / 12

PolarDB · 引擎特性 · 历史库

历史数据归档的问题

大部分业务数据的读写特征,都是最新产生的数据会更频繁的被读取或者更新,而更久之前的数据(如1年之前的聊天记录,或者订单信息)则很少会被访问, 而随着业务运行时间的增加,数据库系统中会沉淀大量很少甚至不会被访问到的数据,这部分数据和最新产生的数据混合在一起会产生一系列问题:

针对此问题,一种做法做法是对历史数据做归档,将长期不使用的数据迁移至以文件形式存储的廉价存储设备上,比如阿里云OSS或者阿里云数据库DBS服务。然而实际业务系统中,历史数据并不完全是静态的,针对几个月甚至几年前的“旧”数据依旧存在实时的,低频的查询甚至更新需求,在阿里巴巴内部,类似淘宝/天猫的历史订单查询,企业级办公软件钉钉几年前的聊天信息查询,菜鸟海量物流的历史物流订单详情等。 为了解决历史数据的读取和更新问题,可以使用一个单独的数据库系统作为归档数据的存储目的地,称之为历史库. 业务对单独的历史库系统一般具有如下的诉求:

作为世界上使用最广泛的开源数据库系统,MySQL生态中一直缺乏一个好用的历史数据归档存储方案,既满足大容量低成本同时又具备一定的读写能力。虽然业界曾经推出过一些高压缩引擎如TokuDB, MyRocks等,但是受限于单物理机磁盘容量限制,存储的数据量有限。PolarDB历史库的推出即为满足这一需求。

PolarDB历史库产品

阿里云数据库团队将公司内部广泛使用的高压缩引擎X-Engine引擎与PolarDB相结合,使得PolarDB同时支持InnoDB引擎和X-Engine引擎,其中InnoDB引擎负责在线业务的高性能混合读写,X-Engine引擎负责归档数据的低频读写。

polardb_xengine_single_name


在PolarDB双引擎的架构上,我们推出了一款主要基于X-Engine引擎存储的数据库产品:PolarDB历史库。历史库单实例的存储空间上限为200TB,结合X-Engine引擎3~5倍的压缩能力,可提供近600TB~1PB的原始数据存储能力,能满足绝大部分客户的历史数据归档对存储容量的需求。

使用PolarDB 历史库(X-Engine)具有如下几个优势:

由于PolarDB 历史库提供了超大存储容量,它可以同时作为多个业务历史数据的汇聚地,以方便对所有历史数据进行集中存储和管理,用户可以在如下几个场景中使用历史库:

polardb_xengine_single_name

在线库和历史库之间的数据迁移,可以使用阿里云DTS或者DMS进行,其中DTS可以持续试试的将在线库的内容同步到历史库,而DMS则可以周期性的将在线数据批量导入到历史库。

PolarDB历史库技术架构

PolarDB历史库功能的推出依赖阿里巴巴数据团队之前在数据库和存储等方向上的创新和突破:

X-Engine存储引擎

PolarDB历史库通过引入X-Engine获得存储空间节省的优势,X-Engine引擎可以用如下几个关键点对其进行描述:

PolarDB双引擎

PolarDB的最初版本是基于InnoDB引擎设计的,其技术架构可以参见文章PolareDB产品架构,在InnoDB引擎上实现物理复制,并在此基础上支持一写多读已经非常具有技术挑战。X-Engine是一个完整独立的事务引擎,具有独立的REDO日志,磁盘数据管理,缓存管理,事务并发控制等模块,将X-Engine移植进PolarDB并实现双引擎的一写多读更具挑战。我们通过大量的工程创新将PolarDB带入双引擎时代:

除了涉及到X-Engine支持一写多读需要支持的功能改造之外,PolarDB X-Engine还有很多项工程改进,如针对历史库场景大表DDL的问题,除了部分支持instant DDL的schema变更操作,X-Engine也支持并行DDL功能,对那些需要copy表的DDL操作进行加速。

polardb_xengine_single_name

在PolarDB双引擎架构下,我们实现了在一套代码下支持两个事务引擎的一写多读,保证了PolarDB产品架构的简洁和一致用户体验。

历史库单计算节点架构

PolarDB集群版基于共享存储实现了一写多读,集群中有一个主节点(可读可写)和至少一个只读节点,但是在历史库场景下,用户一般需要巨大的存储容量,但由于读写量较小,RW节点的计算资源都无法利用完,更无须RO节点提供的读扩展能力。在RW和RO规格相同时,相当于浪费了一半的计算资源。

借助X-Engine引擎带来的数据压缩能力,可以降低客户的存储成本, 而在历史库当中我们使用单RW节点来提供服务,省去了RO节点的计算资源成本。当然去除了RO节点,在灾难场景,如RW节点异常Crash时,需要更长的崩溃恢复时间。但是依靠底层分布式存储提供的高可用能力,我们依然提供了99.95%的可用性。

在历史库这样一个低频读写的场景(很多时候数据为异步批量导入到历史库),用稍低一点的可用性换取成本节省,对很多用户是可以接受的。而对于那些对可用性要求比较高的客户,我们也即将在PolarDB集群版本中提供X-Engine引擎,在降低存储成本的同时,提供与标准版一样的可用性指标。

历史库单节点架构下,日常不提供RO节点, 在需要对节点进行运维操作,如进行节点升级需要重启时,通过部署临时的RO节点并升级为RW节点的方式,可以降低升级操作对客户读写的影响。

polardb_xengine_single_name

单节点时节点替换流程如上图所示,影响业务的时间为替换过程中HA将流量从原RW切换到新的RW的瞬间。