传统分库分表(sharding)的缺陷与破解之法

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介:

标签

PostgreSQL , Greenplum , HybridDB for PostgreSQL , MPP , DIRECT-IO


背景

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

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 和 共享分布式存储 数据库架构 优缺点》

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
6月前
|
存储 缓存 负载均衡
数据库分库分表:提升系统性能的必由之路
数据库分库分表:提升系统性能的必由之路
188 1
|
3月前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
505 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
SQL 关系型数据库 MySQL
MySQL优化方案
MySQL优化方案
359 9
MySQL优化方案
|
7月前
|
算法 程序员
破解Paxos活性难题:分布式一致性的终极指南
Paxos算法是解决分布式系统一致性问题的关键,由Leslie Lamport提出。它涉及提议者、接受者和学习者三个角色,通过准备和接受两个阶段达成共识。然而,确保算法的活性,即在面对网络分区、竞争冲突和节点故障时仍能及时决策,是一个挑战。解决方法包括领导者选举、优化提案编号管理、使用超时机制和Fast Paxos等。实际案例中,通过领导者选举和超时机制,可以提高Paxos在应对网络延迟和冲突时的活性。
245 1
|
7月前
|
存储 关系型数据库 UED
✅到底有没有必要分库分表,如何考量的
是否需要分库分表取决于数据量、负载、增长速度、查询需求、扩展性、容错性和维护成本。当单表数据量接近2000万时,由于B+树结构,查询效率可能下降。B+树的高度和数据页限制了单表容量,通常保持在3-4层,以保证查询性能。以3层B+树、16KB数据页和1KB/行数据为例,可存约2000万条数据。权衡业务需求和技术因素,适时决定是否分表。
|
7月前
|
存储 缓存 负载均衡
数据库分库分表常见算法
数据库分库分表常见算法
|
存储 关系型数据库 MySQL
分库分表理论总结
分库分表理论总结
127 0
分库分表理论总结
|
SQL 关系型数据库 MySQL
软件测试|MySQL主键约束详解:保障数据完整性与性能优化
软件测试|MySQL主键约束详解:保障数据完整性与性能优化
|
SQL 存储 监控
大厂都在用的MySQL优化方案(上)
大厂都在用的MySQL优化方案
198 0
大厂都在用的MySQL优化方案(上)
|
SQL 关系型数据库 MySQL
大厂都在用的MySQL优化方案(下)
大厂都在用的MySQL优化方案
155 0
大厂都在用的MySQL优化方案(下)