MySQL 自动维护分区表的分区

一、需求

这是一个设备监控系统中用到的数据库。一个设备实时数据表,用于存储系统采集到的设备实时数据,如电压、电流、温度、功率等。数据采集和存储周期最快是一分钟,系统要求支持不低于10W台设备的监控,历史数据存储不低于10年。历史数据查询一般是以时间范围和设备Id作为查询条件,生成报表。

从需求上看,历史数据表的数据量将会是非常大的。没有别的办法,必须把历史数据表作分区,否则无法支撑那么大的数据量的查询。分区方案使用 range 分区,分区依据是设备时间。

经过测试,一个分区的数据量在1.2亿~1.3亿之间比较合适,太多时查询效率会有较为明显的下降,太少时查询效率没有太大的优势。

于是问题来了,一个分区中存储多大的数据量是最合适的,如何尽量地使每个分区中的数据量维护在这个合理的范围内?

二、方案选择

无论用什么方案,都应该支持使分区能够根据业务情况进行自动扩展。也就是说初始时,表的分区应该不大,但分区应该是随时间不断地增长的。如何进行分区的扩展,有两个方案。

1)固定周期性地扩展分区。即每过一段时间(一般是一个季度、半年、一年、或者几个月)创建一个新的分区。

这种方案中,思路简单,一般只要在MySQL中创建一个事件,通过调用存储过程,每天判断当前分区是否将要“到期”,如果到期,则创建新的分区。

但这种方案的不足之处在于,固定周期的分区无法使每个分区的数据量保持在一个合理范围内。系统刚上线时,由于设备数量少,这样一个分区的数据量会很少;而系统运维一段时间后,可能接入很多的设备,这样又会导致一个分区的数据量过大。

2)动态地扩展分区,当一个分区数据量达到一定量时,再创建新的分区。

这种方案比较灵活,基本能够确保每个分区的数据量保持在1.2亿~1.3亿这个合理范围之间。

本文详细描述这个方案的处理过程。

三、动态分区方案

1)首先确定表结构

Drop Table If Exists `DeviceData`;

Create Table `DeviceData` (

    `Id` Bigint Unsigned Not Null Auto_Increment Comment '主键',

    `DeviceId` Int Unsigned Not Null Comment '设备Id',

    `DeviceDateTime` Bigint Unsigned Not Null Comment '设备时间,以长整型表示,格式yyyyMMddHHmmss',

    `SignalId` Int Unsigned Not Null Comment '信号Id',

    `DataValue` Varchar(20) Not Null Comment '信号值',

    Primary Key(`Id`, `DeviceDateTime`)

) Partition By Range(DeviceDateTime / 1000000) (

    Partition pmax Values Less Than (maxvalue)

);

初始时,只有一个分区,所有数据在进行插入时,都会写到 pmax 分区中。当 pmax 分区中的数据量达到一个阈值时,再进行重组分区。

2)重组分区

我们可以直接使用重组分区命令把 pmax 分区拆分成为两个分区:

Alter Table `DeviceData` 

    Reorganize Partition pmax Into (

        Partition p20180101 Values Less Than (20180101), 

        Partition pmax Values Less Than (maxvalue)

    );

但是,当我们要进行重组分区时,pmax 分区中的数据量一定是非常大的,这条命令执行时间会非常非常非常……长,必然导致系统业务停顿,可能还会造成应用程序存储队列暴表而崩溃。

因此,直接重组分区的方案,否掉!

为了快速重组分区,可以借用一个临时表(是临时创建一个表,不是数据库概念中的临时表),使用交换分区的方式,把当前拥有上亿数据量的分区交换到临时表中,然后在正式数据表中进行拆分,由于这时正式数据表中的 pmax 分区没有数据,因此拆分数据会非常快,拆分完成后,再把临时表中的数据重新交换回来。用数据库脚本描述如下:

-- 创建临时表

Drop Table If Exists `TmpDeviceData`;

Create Table `TmpDeviceData` like `DeviceData`;

-- 用于交换的表不能是分区表,把它改为非分区表

Alter Table `TmpDeviceData` Remove Partitioning;

-- 把数据表和临时表锁住

Lock Table `DeviceData` Write, `TmpDeviceData` Write;

-- 把正式数据表中 pmax 分区交换到临时表,交换完成后,pmax 分区中将没有数据

Alter Table `DeviceData` Exchange Partition pmax With Table `TmpDeviceData`;

-- 把分区 pmax 拆分为两个分区

Alter Table `DeviceData` Reorganize Partition pmax Into (
    Partition p20180601 Values Less Than (20180601), 
    Partition pmax Values Less Than (Maxvalue)

);

-- 把数据从临时表中交换回来,交换回来的数据将存储到 p20180601 分区

Alter Table `DeviceData` Exchange Partition p20180601 With Table `TmpDeviceData` Without Validation;

-- 把表解锁

Unlock Tables;

以上方案在本人虚拟机上试验通过

另外,判断一个分区的数据量的办法有两个:

直接在分区中通过 Select Count(Id) From `DeviceData` 查询,但这样会对整个分区的数据进行一次计算,虽然很准确,但是占用数据库服务器的资源较多

还有一种办法是,在 information_schema.Partitions 表中,有个 Table_Rows 字段,它指示一个分区当前存储的数据行数,能够在0.01秒内得到结果。不过这个值是个估计值,会有大约3%的误差。但我们没必要计较那么精确,可以直接用它查询。

3)意外

按理说,到这里已经变得很简单了:

写个存储过程,判断一下 pmax 分区的数据量,如果达到一个阈值,则执行上面的脚本。当然分区的时间范围要使用系统当前时间(使用 Now函数取得),这可能要用到动态 sql 执行。然后再写个事件,每天调用这个存储过程。

但笔者在写存储过程时,系统有提示:

在存储过程中不允许出现锁表语句。委屈

在存储过程中不允许出现锁表语句。委屈

在存储过程中不允许出现锁表语句。委屈

4)意外的解决办法

没办法了,只能通过应用程序来传递 sql 了

我的系统是 CentOS + Java + MySQL

只写一个简单的 java 程序,通过java连接到数据库,然后动态执行上面的语句。然后在CentOS中利用 crontab 周期性地启动这个Java应用程序了。

Java程序会很长,这里就不帖代码了,基本上,是通过执行 

Select Table_Rows from information_schema.`PARTITIONS`

where TABLE_SCHEMA = database() and TABLE_NAME = 'DeviceData' and PARTITION_NAME = 'pmax';

得到分区中的数据量,当值大于1.2亿时,根据上面的脚本进行重新划分

Java程序编译成功后,通过linux的crontab命令加到crond服务中:

在命令行中执行 crontab -e,然后在编辑界面输入以下内容:

1 1 * * * java -cp $CLASSPATH:/home/zhimin/temp/crontab-java:/home/zhimin/temp/crontab-java/log4j-1.2.17.jar:/home/zhimin/temp/crontab-java/mysql-connector-java-5.1.25-bin.jar test.DataCheck

以上内容表示,在每天的1点1分执行后面的命令

有关crontab 的知识,网上搜索一大把,这里不再废话了。


©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值