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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 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数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
8月前
|
Java 中间件 数据库连接
分库分表的4种方案
分库分表的4种方案
245 0
|
2月前
|
存储 关系型数据库 UED
✅到底有没有必要分库分表,如何考量的
是否需要分库分表取决于数据量、负载、增长速度、查询需求、扩展性、容错性和维护成本。当单表数据量接近2000万时,由于B+树结构,查询效率可能下降。B+树的高度和数据页限制了单表容量,通常保持在3-4层,以保证查询性能。以3层B+树、16KB数据页和1KB/行数据为例,可存约2000万条数据。权衡业务需求和技术因素,适时决定是否分表。
|
4月前
|
SQL 缓存 数据库
后端开发中的数据库优化策略——提高性能和可靠性
在后端开发中,数据库是至关重要的一环。如何优化数据库,提高系统性能和可靠性,一直是后端开发者需要面对的问题。本文将介绍几个常用的数据库优化策略,包括数据结构设计、索引优化、SQL语句优化、缓存优化等方面,希望对后端开发者有所帮助。
32 2
|
9月前
|
弹性计算 Java 关系型数据库
分库分表比较推荐的方案
ShardingSphere 绝对可以说是当前分库分表的首选!ShardingSphere 的功能完善,除了支持读写分离和分库分表,还提供分布式事务、数据库治理等功能。另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁
126 0
|
6月前
|
存储 关系型数据库 MySQL
太强了!三种方案优化 2000w 数据大表!
太强了!三种方案优化 2000w 数据大表!
|
7月前
|
SQL 关系型数据库 MySQL
软件测试|MySQL主键约束详解:保障数据完整性与性能优化
软件测试|MySQL主键约束详解:保障数据完整性与性能优化
102 0
|
9月前
|
SQL 缓存 NoSQL
MySQL数据库之互联网常用分库分表方案
MySQL数据库之互联网常用分库分表方案
|
10月前
|
存储 负载均衡 Java
Java开发中应对海量数据的分库分表方案探究
在实际的Java开发中,当面临海量数据存储和处理的情况时,单一数据库可能无法满足性能和扩展需求。这时,分库分表方案成为一种常用的解决方案。本文将介绍分库分表的基本概念,并探究其在Java开发中的具体应用和实践。
210 0
|
存储 缓存 Java
分库分表如何做到不迁移数据?避免热点数据?(下)
分库分表如何做到不迁移数据?避免热点数据?
155 0
分库分表如何做到不迁移数据?避免热点数据?(下)
|
存储 算法 关系型数据库
分库分表如何做到不迁移数据?避免热点数据?(上)
分库分表如何做到不迁移数据?避免热点数据?
189 0
分库分表如何做到不迁移数据?避免热点数据?(上)