浅谈数据库分库分表

随着互联网数据量激增,传统的单一数据节点解决方案面临性能、可用性和运维成本挑战。本文探讨分库分表的不同策略,如水平和垂直拆分,并分析何时考虑分库分表。同时,指出分库分表带来的事务一致性、跨节点Join问题,以及分片键选择和分片算法的考量。最后,介绍了常用的分库分表中间件,如Cobar、MyCAT、TDDL和ShardingSphere。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、传统的应用将数据集中存储至单一数据节点的解决方案,在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。

1、性能 

大多数关系型数据库采用B+数索引,在数据量查过阈值的情况下,索引深度增加也使得磁盘I/O次数增加,导致查询性能下降。

2、可用性

单一数据节点或者简单的主从结构已经难以满足大数据量请求的场景。

3、运维成本

从运维成本方面考虑,当一个数据库实例中的数据达到阈值以上,对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲,单一数据库实例的数据的阈值在 1TB 之内,是比较合理的范围。

二、分库分表包括  水平分库 、垂直分库、水平分表、垂直分表

1、水平分库

概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

结果:每个库的结构都一样、每个库中的数据不一样,没有交集、所有库的数据并集是全量数据、

应用场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库的情况下。

分析:增加分库,IO 和 CPU的压力成倍减小缓解。

2、水平分表

概念:以字段为依据,按照一定策略(hash、range 等),讲一个表中的数据拆分到多个表中。

结果:每个表的结构都一样、每个表的数据不一样,没有交集,所有表的并集是全量数据。

应用场景:系统绝对并发量没有上来,只是单表的数据量太多,影响了 SQL 效率,加重了 CPU 负担,以至于成为瓶颈,可以考虑水平分表。

分析:单表的数据量少了,单次执行 SQL 执行效率高了,自然减轻了 CPU 的负担。

3、垂直分库

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值