一、传统的应用将数据集中存储至单一数据节点的解决方案,在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
1、性能
大多数关系型数据库采用B+数索引,在数据量查过阈值的情况下,索引深度增加也使得磁盘I/O次数增加,导致查询性能下降。
2、可用性
单一数据节点或者简单的主从结构已经难以满足大数据量请求的场景。
3、运维成本
从运维成本方面考虑,当一个数据库实例中的数据达到阈值以上,对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲,单一数据库实例的数据的阈值在 1TB 之内,是比较合理的范围。
二、分库分表包括 水平分库 、垂直分库、水平分表、垂直分表
1、水平分库
概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。
结果:每个库的结构都一样、每个库中的数据不一样,没有交集、所有库的数据并集是全量数据、
应用场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库的情况下。
分析:增加分库,IO 和 CPU的压力成倍减小缓解。
2、水平分表
概念:以字段为依据,按照一定策略(hash、range 等),讲一个表中的数据拆分到多个表中。
结果:每个表的结构都一样、每个表的数据不一样,没有交集,所有表的并集是全量数据。
应用场景:系统绝对并发量没有上来,只是单表的数据量太多,影响了 SQL 效率,加重了 CPU 负担,以至于成为瓶颈,可以考虑水平分表。
分析:单表的数据量少了,单次执行 SQL 执行效率高了,自然减轻了 CPU 的负担。
3、垂直分库