数据库存储引擎创新:PolarDB X-Engine历史库产品

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: 作为世界上使用最广泛的开源数据库系统,MySQL生态中一直缺乏一个好用的历史数据归档存储方案,既满足大容量低成本同时又具备一定的读写能力。虽然业界曾经推出过一些高压缩引擎如TokuDB,MyRocks等,但是受限于单物理机磁盘容量限制,存储的数据量有限。PolarDB历史库的推出即为满足这一需求。

撰稿:PolarDB新型存储引擎团队




历史数据归档的问题


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


  • 历史数据和最新的数据存储在一个数据数据库系统中,导致磁盘空间不足。
  • 大量数据共享数据库内存缓存空间,磁盘IOPS等,导致性能问题。
  • 数据量太大导致数据备份时间过长甚至失败,而且备份出来的数据存放也是一个问题。


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


  • 具有非常巨大的容量,业务可以放心持续将线上数据保存到历史库中,而不用担心容量问题。
  • 支持和在线数据库系统一样的访问接口,如都是MySQL协议等,业务可以和在线业务相同的接口访问历史库。
  • 必须具有低廉的成本,如使用压缩减少数据所占磁盘空间,廉价存储介质等,确保可以使用较大的代价保存海量的数据。
  • 具备一定的读写能力,满足低频的读写需求。


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




PolarDB历史库产品


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


1.png


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


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


  • 超大的容量,200TB的存储空间加上X-Engine数据压缩能力,可提供超500TB以上的原始数据存储容量,同时容量按需付费,不用预先为未来的数据增长预备存储空间。
  • PolarDB历史库与官方MySQL的协议一致,相比于将历史数据备份到HBase等NoSQL产品,业务应用程序不用修改代码即可同时访问在线库和历史库。
  • 借助PolarDB底层共享存储提供的快速备份能力,再大的实例也可以实现对数据的快速备份,备份数据上传到OSS等廉价存储设备,确保数据永不丢失。


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


  • 将PolarDB 历史库作为线下自建数据库实例的冷数据存储地,线下自建数据库服务包括且不限于MySQL/Postgre/Sql Server等关系数据库。
  • 将PolarDB历史库作为阿里云RDS MySQL或者PolarDB MySQL数据库服务的归档存储地,将较少访问到的历史数据迁移到PolarDB X-Engine中存储,释放在线实例的空间以降低成本并提升性能。
  • 直接将PolarDB 历史库作为大容量关系数据库使用,以满足一些写入数据量巨大,但读频次较低的业务的需求(如系统监控日志等)。


2.png


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




PolarDB历史库技术架构


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


  • 阿里巴巴自研的基于LSM-tree架构的存储引擎X-Engine提供了强大的数据压缩能力,满足了归档数据库对低存储成本的要求。
  • PolarDB借助于共享分布式存储服务,实现了存储容量在线平滑扩容,同时计算节点和存储节点之间采用高速网络互联,并通过RDMA协议进行数据传输,使I/O性能不再成为瓶颈。集成到PolarDB的X-Engine引擎同样获得了这些技术优势。下面我们分别讲解X-Engine引擎的基础特点,以及如何将X-Engine与PolarDB相结合以提供一个有竞争力的历史库技术方案。


6.png


X-Engine存储引擎


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


  • X-Engine使用了LSM-Tree的分层架构,最近写入的热点数据和历史写入冷数据分开索引,同时创新性的使用事务流水线技术,把事务处理的几个阶段并行起来,极大提升了写入吞吐。
  • 分层存储底层的数据是大部分时候为静态只读,在数据页中所有记录采用前缀编码,同时每个数据页中的数据都是紧凑排列不会留空洞,最后底层数据都会默认进行压缩,因此相比原始数据可获得数倍的空间压缩。
  • X-Engine对传统LSM-tree性能影响比较大的Compaction过程做了大量优化,如拆分数据存储粒度,利用数据更新热点较为集中的特征,尽可能在合并过程中复用数据。精细化控制LSM的形状,减少I/O和计算代价,有效缓解了合并过程中的空间增大。X-Engine本身的实现非常复杂,远非几句话可描述,本篇不对其展开详细讲述


3.png


X-Engine在阿里巴巴集团内部就作为一个自研引擎集成到AliSQL之中,也集成到公有云RDS MySQL当中,作为归档引擎售卖,而现在我们将其集成到了PolarDB当中。


融合InnoDB/X-Engine引擎


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


  • 合并X-Engine的事务WAL日志流和InnoDB的REDO日志流,实现了一套日志流和传输通道同时服务于InnoDB引擎和X-Engine引擎,管控逻辑以及与共享存储的交互逻辑无需做任何改变,同时未来新增其他引擎时也可以复用发这套架构。
  • 将X-Engine的IO模块对接到PolarDB InnoDB所使用的用户态文件系统PFS上,如此实现InnoDB与X-Engine共享同一个分布式块设备. 同时依靠底层分布式存储实现了快速备份。
  • 在X-Engine中实现了基于WAL日志的物理复制功能,并且一步到位的引入并行WAL回放机制,实现了RW节点与RO节点之间毫秒级别的复制延迟。在此基础之上,我们实现了在RO上提供支持事务一致性读的能力。


7.png


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


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




PolarDB X-Engine普惠版


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


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


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


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


5.png


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




PolarDB X-Engine的性能


在PolarDB内核多年的技术积累以及PolarStore提供的极致性能基础上,PolarDB X-Engine在提供极低存储成本的同时,也保证了足够的性能满足业务的诉求。下面我们展示PolarDB 历史库的性能数据。


  • PolarDB X-Engine各规格的纯写性能


8.png


  • PolarDB X-Engine各规格的只读性能


9.png


  • PolarDB X-Engine混合读写性能


10.png


相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
目录
相关文章
|
3月前
|
关系型数据库 MySQL 分布式数据库
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶,邀请好友完成更有机会获得​小米Watch S3、小米体重称​等诸多好礼!
零基础教你用云数据库PolarDB搭建企业网站,完成就送桌面收纳桶!
|
12天前
|
NoSQL 关系型数据库 分布式数据库
基于PolarDB的图分析:通过DTS将其它数据库的数据表同步到PolarDB的图
本文介绍了使用DTS任务将数据从MySQL等数据源实时同步到PolarDB-PG的图数据库中的步骤.
|
15天前
|
SQL 关系型数据库 分布式数据库
夺冠在即 | PolarDB数据库创新设计赛(天池杯)决赛答辩通知
2024年全国大学生计算机系统能力大赛PolarDB数据库创新设计赛(天池杯)于8月21日启动,吸引了200多所高校近千支队伍参赛。经过激烈角逐,60支队伍晋级决赛第一阶段,36支队伍脱颖而出进入现场答辩,将于12月29日在武汉大学争夺最终奖项。决赛要求选手基于PolarDB-PG开源代码部署集群并优化TPCH查询性能。完赛率超90%,成绩表现出明显梯度,前20名均在500秒内完成。评委来自学术界和工业界,确保评选公正。预祝选手们取得优异成绩!
|
30天前
|
Cloud Native 关系型数据库 分布式数据库
PolarDB 分布式版 V2.0,安全可靠的集中分布式一体化数据库管理软件
阿里云PolarDB数据库管理软件(分布式版)V2.0 ,安全可靠的集中分布式一体化数据库管理软件。
|
12天前
|
NoSQL 关系型数据库 分布式数据库
PolarDB图数据库快速入门
图数据库(Graph Database)专门存储图数据,适合处理社交网络、知识图谱等复杂关系。它使用图查询语言(如Cypher、Gremlin)进行操作。PolarDB兼容OpenCypher语法,支持创建、查询、更新和删除图数据,包括模式匹配、过滤、MERGE避免重复、可视化工具等功能,简化了图数据的管理和应用。
|
2月前
|
关系型数据库 分布式数据库 数据库
锦鲤附体 | PolarDB数据库创新设计赛,好礼不停!
锦鲤附体 | PolarDB数据库创新设计赛,好礼不停!
|
16天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
42 3
|
16天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
45 3
|
16天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
59 2

相关产品

  • 云原生分布式数据库 PolarDB-X
  • 云原生数据库 PolarDB
  • 下一篇
    开通oss服务