PostgreSQL 消息平台实践

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 标签PostgreSQL , 消息平台 , 数组 , in any array背景一个多渠道消息平台的数据库设计。业务规则1、消息发送给最终用户,一则消息可以发送给多个社交软件平台(因为一个用户可能使用多个软件平台(比如旺旺,WEB版旺旺,淘宝。

标签

PostgreSQL , 消息平台 , 数组 , in any array


背景

一个多渠道消息平台的数据库设计。

业务规则

1、消息发送给最终用户,一则消息可以发送给多个社交软件平台(因为一个用户可能使用多个软件平台(比如旺旺,WEB版旺旺,淘宝。。。))。

  • 使用数组存储 社交软件平台

2、一条消息在某社交软件平台已读,则该消息在其他社交软件平台也需要为已读。因为同一条消息,对一个人来说,当然是任意平台已读都认为是已读。

  • 使用一个状态字段,标识是否已读

3、消息按照类型展示,透视未读数(统计什么类型的消息用户读的多,什么类型的消息用户读的少),或者按人查询未读数(当用户登陆时,查询未读消息有多少条)

  • 聚合查询,或者按UID的简单查询

4、消息存在有效期(30天,大概6亿条消息),过期不管是否已读,均删除(当然也可以设计为未读则不删除,看需求)

业务特点&技术要求

1、写入操作:消息新增(比如消息每日增量2KW)、消息状态更新(有一定的已读比例)。

2、查询请求:(查询峰值QPS 5K左右)

  • 很容易满足

3、查询条件维度:(按社交软件平台、按消息类型、按状态获取消息列表、最近一条消息、统计未读数。。。。)。

4、新增社交软件平台:社交软件平台增加时需要易于扩展。

  • 使用数组存储社交软件平台,扩展性好,无需变更结构

设计

表结构

建表

create table tbl_msg (  
  mesgid int8 primary key,  -- 消息ID  
  uid int8,  -- 用户ID  
  msgtype int2,  -- 消息类型  
  plat int2[],  -- 发给了哪些 社交软件平台,数组类型  
  status boolean not null default false,  -- 阅读状态  
  content text,  -- 内容  
  crttime timestamp(0) not null,  -- 消息创建时间  
  modtime timestamp(0)  -- 消息状态修改时间  
);  

优化,可以按消息类型哈希分区。减少扫描量

《PostgreSQL 9.x, 10, 11 hash分区表 用法举例》

索引

按需创建索引。

create extension btree_gin;    

1、按社交软件平台查询、

create index idx_tbl_msg_1 on tbl_msg using gin (plat) where status=false;    
  
-- 查询社交平台,某个消息类型下,未读消息  
  
如果所有状态都想查询,则不需要 where status=false;  并把status放到索引字段里面

create index idx_tbl_msg_1 on tbl_msg using gin (plat,status);  

2、按消息类型、

create index idx_tbl_msg_2 on tbl_msg (uid, msgtype) where status=false;   

3、按状态获取消息列表、

create index idx_tbl_msg_3 on tbl_msg (status,uid,crttime);   

4、最近一条消息、

create index idx_tbl_msg_4 on tbl_msg (uid,crttime);   

查询SQL

1、按社交软件平台查询、

select count(*) from tbl_msg where plat @> array[?,?,...] and status=false;  

清理过期消息

单表的情况下,如何清理消息?

《在PostgreSQL中实现update | delete limit - CTID扫描实践 (高效阅后即焚)》

压测

1、每秒的写入量、更新量。10万行/s左右。

2、读取,简单SQL加分析SQL。 QPS 2万以上。

小结

用到的PostgreSQL数据库特性

1、数组类型,存储社交软件平台。

2、update,delete limit,删除过期数据

3、GIN索引,支持数组类型的高效过滤

4、分页(优化)

《论count与offset使用不当的罪名 和 分页的优化》

5、多核并行计算。数据库会根据SQL的成本、NODE自动规划是否使用并行计算,实时分析型的SQL请求非常有效。

《HTAP数据库 PostgreSQL 场景与性能测试之 23 - (OLAP) 并行计算》

6、丰富的索引接口

《PostgreSQL 9种索引的原理和应用场景》

《自动选择正确索引访问接口(btree,hash,gin,gist,sp-gist,brin,bitmap...)的方法》

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
3月前
|
存储 SQL Cloud Native
深入了解云原生数据库CockroachDB的概念与实践
作为一种全球领先的分布式SQL数据库,CockroachDB以其高可用性、强一致性和灵活性等特点备受关注。本文将深入探讨CockroachDB的概念、设计思想以及实践应用,并结合实例演示其在云原生环境下的优越表现。
|
3月前
|
Cloud Native 关系型数据库 大数据
CockroachDB:云原生数据库的新概念与实践
本文将介绍CockroachDB,一种先进的云原生数据库,它具备分布式、强一致性和高可用性等特点。我们将探讨CockroachDB的基本原理、架构设计以及在实际应用中的种种优势和挑战。
|
4月前
|
存储 关系型数据库 MySQL
存储成本最高降至原来的5%,PolarDB分布式冷数据归档的业务实践
国内某家兼具投资理财、文化旅游、票务为一体的大型综合型集团公司,2015年成立至今,由于业务高速发展,业务数据增长非常快,数据库系统屡次不堪重负。该公司数据库运维总监介绍,他们目前业务压力比较大的是票务和订单系统,他们的平台每天新增几千万的订单数据,订单的数据来自于各个终端,近几年每个月以300G的数据规模在高速增长,由于数据不断增加,数据库系统迄今为止迭代过了3次。
|
6月前
|
SQL 缓存 关系型数据库
PolarDB-X 混沌测试实践:如何衡量数据库索引选择能力
随着PolarDB分布式版的不断演进,功能不断完善,新的特性不断增多,整体架构扩大的同时带来了测试链路长,出现问题前难发现,出现问题后难排查等等问题。原有的测试框架已经难以支撑实际场景的复杂模拟测试。因此,我们实现了一个基于业务场景面向优化器索引选择的混沌查询实验室,本文之后简称为CEST(complex environment simulation test)。
|
7月前
|
存储 SQL 关系型数据库
AnalyticDB PostgreSQL构建一站式实时数仓实践
本文介绍通过 AnalyticDB PostgreSQL 版基于实时物化视图,构建流批一体的一站式实时数仓解决方案,实现一套系统、一份数据、一次写入,即可在数仓内完成实时数据源头导入到实时分析全流程。
1880 5
AnalyticDB PostgreSQL构建一站式实时数仓实践
|
8月前
|
分布式数据库 调度 数据库
直播预告 | PolarDB-X 备份恢复原理与实践
备份恢复是生产级数据库必不可少的功能,而PolarDB-X 作为一款分布式数据库,备份数据的全局一致也是最基本的要求。本期分享将介绍PolarDB-X 开源版备份恢复功能的背景与原理,以及如何使用 PolarDB-X Operator 实现备份调度。
直播预告 | PolarDB-X 备份恢复原理与实践
|
8月前
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
596 4
|
10月前
|
存储 SQL 运维
亿视电子基于PolarDB-X打造能源数字基座实践
本文整理自浙江亿视电子技术有限公司的技术总监韩毅在ScaleFlux × PolarDB 线下meetup中的分享。
|
11月前
|
存储 关系型数据库 API
|
11月前
|
存储 关系型数据库 Linux

相关产品

  • 云原生数据库 PolarDB