云端海量任务调度系统数据库设计 - 阿里云RDS PostgreSQL案例

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介:

标签

PostgreSQL , 任务调度系统 , 数据库设计 , schemaless


背景

任务调度系统中的任务状态管理,通常会用到数据库来存储任务调度的过程状态,控制任务的锁等。

《advisory lock 实现高并发非堵塞式 业务锁》

如果是小量任务,是挺好实现的,但是每小时处理几十亿或者几亿的任务,如何设计这样的任务状态管理数据库呢?

挑战

对于一个面向多个用户的任务调度平台(例如云端的任务调度平台,将面向所有租户使用)。

较大的挑战是任务数据的写入(海量),另一个是任务状态的更新(海量,每个任务至少被更新一次)。

云端海量任务调度数据库设计

pic

云端任务调度存在一些特性:

1、用户和用户之间的任务是没有关系的,单个用户的任务在调度时可能有依赖关系。

2、数据量庞大。

3、任务通常都有最终稳定状态,稳定后,对应的任务记录就不会变化了。

针对以上几个特点,采样PostgreSQL设计:

1、任务数据生成后写入任务处理表

2、任务处理表使用rotate设计(例如每小时一个rotate表),处理完的数据直接清除,不需要VACUUM。

3、分区方面,任务处理表采样用户级分区,在获取需要处理的任务时更加的精炼(减少冗余扫描)。

4、当任务达到最终状态时,从任务运行表删除,写入历史表。

5、早期的历史表,从RDS PG中删除,写入阿里云OSS,使用RDS PG OSS外部表接口可以访问到这些历史数据。

DEMO设计

1、初始任务表,用于存储用户生成的任务。

create table task_init (    -- 任务初始表  
  uid  int,        -- 用户id  
  ptid serial8,    -- 父任务id  
  tid serial,      -- 子任务ID    
  state int default 1,    -- 任务状态,1表示初始状态,-1表示正在处理, 0表示处理结束    
  retry int default -1,   -- 重试次数    
  info text,              -- 其他信息    
  ts timestamp            -- 时间     
);     
AI 代码解读

2、任务历史表,用于存储任务的最终状态。

create table task_hist (    -- 任务历史表  
  uid  int,   -- 用户id  
  ptid int8,  -- 父任务id  
  tid int,    -- 子任务ID    
  state int default 1,    -- 任务状态,1表示初始状态,-1表示正在处理, 0表示处理结束    
  retry int default -1,   -- 重试次数    
  info text,              -- 其他信息    
  ts timestamp      -- 时间      
);     
AI 代码解读

3、为了简化测试,按用户ID进行分区。(前面提到的rotate设计,多级分区设计,请参考本文末尾的文章)

do language plpgsql $$  
declare  
begin  
  for i in 1..1000 loop  
    execute 'create table task_init_'||i||' ( like task_init including all)';  
    execute 'create table task_hist_'||i||' ( like task_hist including all)';  
  end loop;  
end;  
$$;  
AI 代码解读

4、为了测试方便,使用schemaless的设计,将用户任务的初始数据生成写入放在PLPGSQL逻辑中。

create or replace function ins_task_init(  
  uid int,  
  info text,  
  ts timestamp  
)  returns void as $$  
declare  
  target name;  
begin  
  target := format('%I', 'task_init_'||uid);  
  execute format('insert into %I (uid,info,ts) values (%L,%L,%L)', target, uid,info,ts);  
end;  
$$ language plpgsql strict;  
AI 代码解读

5、运行任务,分为几个步骤。

5.1、从任务表读取任务。

5.2、用户执行任务。

5.3、反馈执行的结果,不成功的任务更新task_init表,对于执行成功(并结束)的任务,数据从task_init迁移到task_hist。

为了测试数据库的性能,我讲这三步的逻辑写到plpgsql里面。同时使用delete limit的特性,一次批量取出若干条任务。

这里使用CTID行号定位,达到最佳的性能。不仅免去了索引的使用,而且性能更佳。

这里使用了advisory lock,使得单个用户不会出现并行任务。(实际业务中,可以并行。)

这里没有测试更新状态,task_init还有少量更新(相比insert和delete,比例很少,可以忽略),比如任务失败的情况。

关闭task_init表的autovacuum,采用rotate的形式进行处理。

create or replace function run_task(  
  uid int,  
  batch int  
) returns void as $$  
declare  
  target1 name;  
  target2 name;  
begin  
  target1 := format('%I', 'task_init_'||uid);  
  target2 := format('%I', 'task_hist_'||uid);  
  execute format('with t1 as (select ctid from %I where pg_try_advisory_xact_lock(%L) limit %s) , t2 as (delete from %I where ctid = any (array(select ctid from t1)) returning *)  insert into %I select * from t2;', target1, uid, batch, target1, target2);  
end;  
$$ language plpgsql strict;  
AI 代码解读

6、测试分解动作。

写入初始任务  
  
postgres=# select ins_task_init(1,'test',now()::timestamp);  
 ins_task_init   
---------------  
   
(1 row)  
  
postgres=# select ins_task_init(1,'test',now()::timestamp);  
 ins_task_init   
---------------  
   
(1 row)  
  
运行任务  
  
postgres=# select run_task(1,100);  
 run_task   
----------  
   
(1 row)  
  
查看任务是否结束并迁移到历史表  
  
postgres=# select * from task_init_1;  
 uid | ptid | tid | state | retry | info | ts   
-----+------+-----+-------+-------+------+----  
(0 rows)  
  
postgres=# select * from task_hist_1;  
 uid | ptid | tid | state | retry | info |             ts               
-----+------+-----+-------+-------+------+----------------------------  
   1 |    1 |   1 |     1 |    -1 | test | 2017-07-20 15:26:32.739766  
   1 |    2 |   2 |     1 |    -1 | test | 2017-07-20 15:26:33.233469  
(2 rows)  
AI 代码解读

性能压测

1、生成任务的性能

vi ins.sql  
\set uid random(1,1000)  
select ins_task_init(:uid,'test',now()::timestamp);   
  
pgbench -M prepared -n -r -P 1 -f ./ins.sql -c 32 -j 32 -T 120  
query mode: prepared  
number of clients: 64  
number of threads: 64  
duration: 360 s  
number of transactions actually processed: 86074880  
latency average = 0.268 ms  
latency stddev = 0.295 ms  
tps = 239079.558174 (including connections establishing)  
tps = 239088.708200 (excluding connections establishing)  
script statistics:  
 - statement latencies in milliseconds:  
         0.001  \set uid random(1,1000)  
         0.267  select ins_task_init(:uid,'test',now()::timestamp);  
  
postgres=# select count(*) from task_init_1;  
 count   
-------  
 88861  
(1 row)  
  
postgres=# select count(*) from task_init_2;  
 count   
-------  
 88196  
(1 row)  
  
....  
  
postgres=# select count(*) from task_init_1000;  
 count   
-------  
 88468  
(1 row)  
AI 代码解读

2、运行任务的性能(一次批量取10000条任务)

vi run.sql  
\set uid random(1,1000)  
select run_task(:uid,10000);  
  
pgbench -M prepared -n -r -P 1 -f ./run.sql -c 32 -j 32 -T 120  
  
query mode: prepared  
number of clients: 32  
number of threads: 32  
duration: 120 s  
number of transactions actually processed: 3294  
latency average = 1171.228 ms  
latency stddev = 361.056 ms  
tps = 27.245606 (including connections establishing)  
tps = 27.247560 (excluding connections establishing)  
script statistics:  
 - statement latencies in milliseconds:  
         0.003  \set uid random(1,1000)  
      1171.225  select run_task(:uid,10000);  
  
postgres=# select count(*) from task_init_1000;  
 count   
-------  
 18468  
(1 row)  
  
postgres=# select count(*) from task_hist_1000;  
 count    
--------  
 224207  
(1 row)  
AI 代码解读

单独的测试数据

1、生成任务,23.9万条/s

2、消耗任务,27.2万条/s

生成与消耗任务同时运行的测试数据

1、生成任务,16.8万条/s

2、消耗任务,大于16.8万条/s

没有任何任务堆积。

小结

PostgreSQL在云端海量任务调度系统中,发挥了重要的作用。

单个PostgreSQL实例,已经可以处理每个小时 的任务生成,以及 的任务消耗。

任务调度系统比MQ更加复杂,类似MQ的超集,所以用户如果有MQ的需求,实际上使用RDS PostgreSQL也是可以的。性能指标比上面的测试更好。

参考

《advisory lock 实现高并发非堵塞式 业务锁》

《PostgreSQL schemaless 的实现(类mongodb collection)》

《行为、审计日志 (实时索引/实时搜索)建模 - 最佳实践 2》

《在PostgreSQL中实现update | delete limit》

《块级(ctid)扫描在IoT(物联网)极限写和消费读并存场景的应用》

《PostgreSQL 10.0 preview 功能增强 - 内置分区表》

《PostgreSQL 9.5+ 高效分区表实现 - pg_pathman》

《PostgreSQL 数据rotate用法介绍 - 按时间覆盖历史数据》

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
20663
分享
相关文章
阿里云PolarDB:引领云原生数据库创新发展
阿里云PolarDB引领云原生数据库创新,2024云栖大会将分享其最新发展及在游戏行业的应用。PolarDB凭借弹性、高可用性、多写技术等优势,支持全球80多个站点,服务1万多家企业。特别是针对游戏行业,PolarDB助力Funplus等公司实现高效运维、成本优化和业务扩展。通过云原生能力,PolarDB推动游戏业务的全球化部署与快速响应,提升用户体验并保障数据安全。未来,PolarDB将继续探索AI、多云管理等前沿技术,为用户提供更智能的数据基础设施。
瑶池数据库微课堂|PolarDB/RDS+ADB Zero-ETL:一种免费、易用、高效的数据同步方式
瑶池数据库微课堂介绍阿里云PolarDB/RDS与ADB的Zero-ETL功能,实现免费、易用、高效的数据同步。内容涵盖OLTP与OLAP的区别、传统ETL存在的问题及Zero-ETL的优势(零成本、高效同步),并演示了从RDS MySQL到AnalyticDB MySQL的具体操作步骤。未来将优化和迭代此功能,提供更好的用户体验。
1月17日|阿里云云谷园区,PolarDB V2.0技术沙龙,畅聊国产数据库
为了助力国产化项目顺利推进,阿里云邀请企业开发者和数据库负责人到云谷园区,与PolarDB V2.0技术专家面对面交流。扫描海报二维码报名,我们将根据信息为您申请入园。欢迎参与,共同探讨PolarDB的最新技术和应用!
体验领礼啦!体验自建数据库迁移到阿里云数据库RDS,领取桌面置物架!
「技术解决方案【Cloud Up 挑战赛】」上线!本方案介绍如何将自建数据库平滑迁移至云数据库RDS,解决业务增长带来的运维难题。通过使用RDS MySQL,您可获得稳定、可靠和安全的企业级数据库服务,专注于核心业务发展。完成任务即可领取桌面置物架,每个工作日限量50个,先到先得。
媒体声音|专访阿里云数据库周文超博士:AI就绪的智能数据平台设计思路
在生成式AI的浪潮中,数据的重要性日益凸显。大模型在实际业务场景的落地过程中,必须有海量数据的支撑:经过训练、推理和分析等一系列复杂的数据处理过程,才能最终产生业务价值。事实上,大模型本身就是数据处理后的产物,以数据驱动的决策与创新需要通过更智能的平台解决数据多模处理、实时分析等问题,这正是以阿里云为代表的企业推动 “Data+AI”融合战略的核心动因。
【深入了解MySQL】优化查询性能与数据库设计的深度总结
本文详细介绍了MySQL查询优化和数据库设计技巧,涵盖基础优化、高级技巧及性能监控。
64 0
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
63 3
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
81 3

相关产品

  • 云数据库 RDS
  • 云数据库 RDS PostgreSQL 版
  • 云数据库 RDS MySQL 版
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等