PgSQL · 应用案例 · 传统分库分表(sharding)的缺陷与破解之法

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 背景随着互联网的发展,数据爆炸性的增长,数据库逐渐成为了很多业务的绊脚石,很多业务也哭着喊着要上分布式数据库。但是,传统的分库分表(sharding)带来的问题较多,得不偿失传统分库分表问题1、 扩容不方便(需要重分布数据)2、 分布键变更很麻烦3、 分布键选择(架构设计)需要谨慎,甚至很多sharding产品不支持多个分布键、或者不支持随机分布,导致业务不得不使用没有任何意义的自增序列来作为分布键。

背景

随着互联网的发展,数据爆炸性的增长,数据库逐渐成为了很多业务的绊脚石,很多业务也哭着喊着要上分布式数据库。

pic

但是,传统的分库分表(sharding)带来的问题较多,得不偿失

传统分库分表问题

1、 扩容不方便(需要重分布数据)

2、 分布键变更很麻烦

3、 分布键选择(架构设计)需要谨慎,甚至很多sharding产品不支持多个分布键、或者不支持随机分布,导致业务不得不使用没有任何意义的自增序列来作为分布键。

4、 无法支持复杂查询。跨库JOIN性能差,甚至只能按分布键JOIN,其他字段不支持JOIN。(因为这种产品架构数据节点之间是孤岛,数据需要在孤岛之间交互,需要通过上层的中间件节点,而这样的话,如果有跨库JOIN,就需要将数据收到中间件节点再JOIN,性能差是可想而知的,甚至打爆中间节点。)

5、 当需要写入、返回大量结果集时,可能把中间件打爆。可能性非常大。

6、 分布式事务性能差,甚至不支持分布式事务。

7、 由于各个数据节点各自为政,实际上这种模式带来的SQL限制多、功能缺失多

8、 SQL功能缺失,导致应用改造成本巨大,(实际上就是限制多)。

9、 全局一致性时间点恢复几乎不可实现,不同的数据节点处于不同的状态,没有一个全局统一的快照管理和恢复机制。

传统分库分表最大的问题实际上还是孤岛问题,导致了一系列的问题。

HybridDB for PG如何破解这些问题

pic

1、实时写入,通过直接写segment(可以做成对业务透明),实现了单机25万行/s的写入能力。通过扩展计算节点,可以扩展整个集群的写入能力。

2、批量导入,通过OSS_EXT,走OSS通道实时写入,我们测试过50台机器的机器,达到了100亿(5.5TB)数据,1251秒导入的性能。

3、全局一致性,HDB PG基于数据库的ACID标准设计,是一个整体,支持全局事务。支持全局一致性。

4、点查,点查能力,每个节点可以实现100万TPS。通过扩展计算节点,可以扩展整个集群的点查TPS能力。

5、复杂查询,核心是MASTER节点的分布式执行计划,MASTER节点收到用户请求后,生成分布式执行计划,并下发给计算节点并行执行。

6、大结果集查询,通过游标,实现大结果集的查询,分页,接收等。

7、UDF,用户可以使用java, python, plpgsql等语言,在HDB PG中实现业务逻辑,实现复杂的查询场景需求。

8、任意列JOIN,由于HDB PG数据节点直接可以重分布数据,不需要走MASTER节点,因此,不需要维表,就可以实现任意列的JOIN,GROUP BY,DISTINCT等。

9、任意distinct,同上。

10、任意group by,同上。

《HybridDB PostgreSQL “Sort、Group、distinct 聚合、JOIN” 不惧怕数据倾斜的黑科技和原理 - 多阶段聚合》

11、MASTER不承担计算,由于MASTER节点不承担计算,所以不会成为计算瓶颈,包括排序在内(MASTER节点采用MERGE SORT,几乎不耗费资源)。

12、机器学习,通过madlib插件,实现了数据库内部的机器学习。

相关资料

http://madlib.incubator.apache.org/

https://pypi.python.org/pypi/pymadlib/0.1.4

https://github.com/pivotalsoftware/PivotalR

https://cran.r-project.org/web/packages/PivotalR/PivotalR.pdf

https://cran.r-project.org/web/packages/PivotalR/vignettes/pivotalr.pdf

13、扩展功能:

资源隔离,通过资源队列,可以管理不同的用户资源使用情况。

HLL,是一个估值插件,可以存储估值数据。

行列混合存储,行列混合存储,支持压缩。

分布键,支持任意键作为分布键,同时支持随机分布,支持多列作为分布键。不需要强制分布键。

分区表,支持多级分区,范围分区,枚举分区。

空间数据,支持PostGIS,可以管理空间数据。

JSON,支持JSON数据类型。

数组,支持多值类型。

全文检索,支持全文检索类型。

正则表达式,支持正则表达式查询语法。

OSS,支持冷热分离存储。

总结

HybridDB for PostgreSQL属于MPP架构,解决了几类问题,实现了HTAP(OLTP和OLAP混合业务):

1、高并发小事务(实时写入、点查),

2、实时复杂大型计算,

3、批处理,

4、冷热数据分离,

5、资源隔离,

6、容量、功能扩展性,

容量水平扩展(支持两种扩容模式,一种原地扩容,一种跨集群扩容),功能(UDF,plpython, pljava, plpgsql,插件)。

7、机器学习。

HybridDB for PG 性能指标

50台机器的集群,一些性能指标如下:

通过增加机器,可以实现线性性能提升。

pic

pic

pic

参考

《HTAP数据库(OLTP+OLAP) - sharding 和 共享分布式存储 数据库架构 优缺点》

目录
相关文章
|
1月前
|
缓存 关系型数据库 MySQL
史上最全MySQL 大表优化方案(长文)
史上最全MySQL 大表优化方案(长文)
471 0
|
4月前
|
存储 SQL 弹性计算
|
SQL 设计模式 存储
本周推荐 | mysql中业务系统可借鉴的设计
推荐语:学习优秀的开源系统来优化我们业务的架构设计,这是我们作为业务开发的必修课,这篇文章从经典的mysql系统原理引申到业务系统设计思考,让人耳目一新,值得我们学习。 ——大淘宝技术工程师 默达
194 0
|
SQL 分布式计算 druid
2021 年数据库报告:PostgreSQL 成开发者首选 | Benchmark 测试陷“混战”
2021 年数据库报告:PostgreSQL 成开发者首选 | Benchmark 测试陷“混战”
220 0
2021 年数据库报告:PostgreSQL 成开发者首选 | Benchmark 测试陷“混战”
|
消息中间件 SQL 算法
MySQL千万数据方案调研,一不小心直接打挂我系统
大家好,我是Leo。 之前聊的RocketMQ暂时放放,目前正在调研一个千万数据的处理方案。 在准备测试数据的时候,执行了个 select 把我电脑内存打光了。然后OOM,黑屏,宕机。。
MySQL千万数据方案调研,一不小心直接打挂我系统
|
SQL 存储 缓存
MySQL 大表优化方案(长文)
单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候My
MySQL 大表优化方案(长文)
|
Cloud Native 数据库 C#
【大咖说*数据Cool谈——数据库寻路,开源有态度】
邀请嘉宾:PinCap联合创始人兼CTO-黄东旭、阿里云数据库产品事业部负责人-李飞飞 、华东师范大学副校长/资深数据库学者-周傲英 、InfoQ主编-王一鹏
116 0
【大咖说*数据Cool谈——数据库寻路,开源有态度】
|
Java 关系型数据库 MySQL
最牛逼的数据库性能测试工具,没有之一!
最牛逼的数据库性能测试工具,没有之一!
716 0
最牛逼的数据库性能测试工具,没有之一!
|
关系型数据库 MySQL 数据库
MySQL - 扩展性 1 概述:人多力量未必大
MySQL - 扩展性 1 概述:人多力量未必大我们应该接触过或者听说过数据库的性能瓶颈问题。对于一个单机应用而言,提升数据库性能的最快路径就是氪金 - 买更高性能的数据库服务器,只要钱到位,性能不是问题。
1231 0