PolarDB-X on OSS: 冷热数据分离存储

为什么需要冷热分离？

在数据库使用过程中，每天有大量的数据写入和更新。然而，通常只有时间邻近的，如一个月内，甚至一周内的数据才会被频繁更新和访问。而剩下的大量数据，都默默躺在磁盘的角落中，给存储空间带来了极大的浪费，也增加了数据库维护的成本。我们将前者中提到的频繁访问数据称为热数据，后者则称为冷数据。

通过对多位大型政企客户的走访和交流，我们感受到了开发者们对于冷热分离存储的迫切需求。何谓冷热分离？从字面意义上来理解，就是将热数据保留在高性能的存储设备中，用于应对日常频繁的写入与更新，满足用户对事务型数据处理的需要；冷数据则被迁移到低成本的存储设备里（这一过程也被称为“归档”），减轻热数据的维护压力，提供查询和局部订正的功能。

虽然不被频繁访问，冷数据却是十分具有价值的。它记录着用户的历史数据，例如电商的历史订单、银行系统的历史交易记录等。这些访问需求对个人用户来说是低频的，但放到整个电商用户群体，或是银行用户群体中，则是一份不小的workload。冷数据的分析处理能给用户带来很多商业上的 insight，帮助用户做出决策。因此还需要支持在线分析型数据处理的能力。跨越冷热数据的Join（连接）、Aggregation（聚合）是开发者们经常使用的分析手段。 因此，在PolarDB-X的冷热分离存储设计中，我们兼顾了高性能的点查和分析型查询，来满足不同用户对冷数据的访问需求。

为何选择OSS?

阿里云对外提供两类云存储服务：块存储与对象存储。其中块存储如ESSD等，是数据库事实上采取的存储方式，配备了RDMA网络服务和高性能SSD盘来提升访问性能；而对象存储如OSS，则利用低廉的HDD盘和标准网络，对外提供低成本、海量空间的存储服务。

PolarDB-X数据库原本的存储方式采用了Paxos三副本高可用集群，格式为InnoDB行存。在冷热分离存储架构中，我们将冷数据迁移到阿里云OSS对象存储中，并采用开源列存格式ORC。阿里云的OSS 对象存储服务本身保障了 12个9 的高可用性，因此我们采用了单副本的存储方式，这与 paxos 的三副本有所不同。

结合OSS单位存储的低成本，和ORC格式本身的压缩比，我们可以得到下列一组对比数据，来形成直观的感受：

	ORC 列存 on OSS	InnoDB 行存
存储单价	0.12 元/GB/月（本地冗余）0.15 元/GB/月（同城冗余）	0.72 元/GB/月（物理机 SSD）
副本数	1（底层多副本对用户透明）	3（Paxos 三副本）
压缩比	0.20x（实测 lineitem SF=100 占用空间 15.6GB）	1.55x（实测lineitem SF=50 占用空间 61GB）
最终单价	0.024 元/GB/月	1.12 元/GB/月

注：表中所用价格有时效性，具体以产品显示价格为准。

优势特性

TTL（time-to-live）

如何将冷数据从InnoDB行存中剥离出来？这是一个令很多开发者头疼的问题。如果使用delete from 语句 + where条件的形式来删除冷数据，很可能会因为扫描行数太多、数据太过分散，而造成锁表，影响整个数据库实例的访问；如果提前按照时间进行分区，再逐个将旧时间分区drop掉，则许多不适合按照时间分区的表将会束手无策。 针对用户反馈的这一实际问题，PolarDB-X 引入了TTL（time-to-live）这一新特性来帮助用户完成冷热数据剥离。用户无需手动维护，而是通过提前指定起始时间、分区大小和过期时间等信息，来完成数据的自动过期。我们在更底部的存储层将每张物理表做进一步的透明分区，数据按照最近的更新时间被集中到一起。 例如对于订单表t_orders，用户按照订单ID进行哈希分区。引入了TTL之后，每个分区被进一步透明划分。旧时间分区（图中的2022-01分区）的过期，如同撕掉便利贴一样，在不锁表、不手动分区的情况下完成冷热数据的剥离。

关于TTL的具体使用，可以参考官网文档：什么是TTL功能 ？

高性能查询

当冷数据从主库中剥离出来，归档至OSS存储服务后，我们就得到了一张以OSS为存储载体的归档表。它完全兼容MySQL数据类型和各种查询方式，在低成本、高可用的前提下，能带来与主表一致的使用体验。 为了满足不同用户对历史数据的查询需要，我们在设计上兼顾了点查和复杂分析型查询。对此我们进行了相应的测评。由于PolarDB-X on OSS 使用列存，在报表查询中有天然的优势，因此相比于PolarDB-X on MySQL 行存模式，TPC-H测试成绩有了大幅提升；1亿行数据量下的Sysbench点查测试也显示，归档表可以满足历史数据的查询要求。 在实现以上功能的过程中，最为关键的设计是文件系统、多级缓存、多级索引与查询裁剪。此外还包括列存索引选择、向量化计算、AGG加速等，我们都将在后续的文章中详细介绍。

TPC-H性能测试

规格：

• CPU：6 * 16C

• 内存：6 * 128GB

• SF = 100 （TPC-H 100GB）

总耗时约89s （PolarDB-X on MySQL 总耗时 150s）

Sysbench 性能测试

规格：

• 压测ECS：1 * 8C32G

• CN：6 * 16C128G

• Sysbench表行数： 1亿

• 并发数：100

sysbench性能测试数据如下：

查询类型	QPS	RT(95th percent) 单位：ms
主键点查	21762.46	6.79
主键范围查询	10769.62	167.44
二级索引点查	2760.82	55.82

一键迁移

完成了冷热数据剥离后，如何将数据快速归档到OSS上呢？我们基于MySQL标准语法，提供了非常简易便捷的方式，只需要执行一条建表语句：

 CREATE TABLE [oss_table_name] LIKE [innodb_table_name] 
 ENGINE = 'OSS' ARCHIVE_MODE = 'TTL'

执行后，OSS表将克隆InnoDB表的表结构，免去用户对归档表结构的设计；同时，冷数据归档表和源表被绑定起来，源表过期的数据将自动导入到归档表中。此后，用户可以像访问普通表一样，通过SQL来完成包括点查、范围查询、复杂分析型查询在内的各种数据访问。

手动强制过期

如果您想要更灵活的过期和归档操作，下列语句可以让您手动过期数据，并将过期数据导入至OSS中：

ALTER TABLE [innodb_table_name] EXPIRE LOCAL PARTITION [local_partition_name]

更多特性

任意时间点备份与闪回

在阿里云官方售卖的PolarDB-X 企业版中，支持了冷数据多副本备份与异地容灾。此外，PolarDB-X 将OSS归档表的版本控制与TSO结合起来，支持将整张表恢复到任意时间点之前的状态，也支持通过指定时间点来完成快照读。 您可以使用下列的闪回语句，让整张OSS归档表回到任意时间点之前的状态：

ALTER TABLE [oss_table_name] AS OF timestamp 'yyyy-mm-dd hh:mm:ss'

通过下列语句，指定时间点，完成在OSS归档表上的快照读：

SELECT xxx FROM [oss_table_name] AS OF timestamp '2022-01-01 01:02:03'

MySQL兼容性

PolarDB-X使用开源格式ORC来作为数据存储格式。ORC起源于Hive生态，其数据类型相比于MySQL有许多受限制的地方，例如不支持高精度的Decimal、不支持Collation、时间表示范围不够大、不支持Time类型等问题。因此，在ORC格式的基础上，想要提供MySQL风格的查询体验，还需要填补这一鸿沟。 为了给用户提供与MySQL一致的使用体验，我们精心设计了一套兼容MySQL的数据类型处理方案。包括time类型支持、基于collation的字符串查找、基于字节序的Decimal数值搜索等，构建起了从Hive生态到MySQL生态的桥梁。

开放性

我们将提供轻量级的ORC SDK。您可以通过ORC Connector 和catalog，将OSS上存储的ORC文件作为数据源，轻松地完成Spark、Flink、Presto等开源大数据产品的接入。 在开源版本中，您还可以使用其他存储设备或服务来存放归档表，只需在执行create table时，指定Engine参数的值，如Engine = 'S3' / Engine = 'local_disk' 等，将归档表存放在S3存储服务或本地磁盘上。

总结

PolarDB-X 冷热分离存储充分利用了OSS服务成本低、容量大的优良特性，将冷数据快速高效地从在线库中剥离出来，减轻了数据维护压力，降低了数据存储成本。同时，提供与MySQL兼容的访问方式，兼顾点查与分析型查询的性能，并支持大数据产品的接入。未来我们将在冷热数据分离这一赛道上不断前进。

文档来源：https://polardbx.com/realTimeInfoDetail?id=gKI0sDnYfx