亿级数据量性能优化必备之分库分表

每个业务系统根据业务拆分成不同的系统，用不同的数据库，比如客户系统-》客户DB Oracle,

合同系统-》合同DB MySQL  放款系统-》放款DB Postgresql

 

1.什么情况下分库分表，分库分表解决什么问题

分库分表的好处 1.提升数据的查询速度 2.缓解数据库的压力 3.提升存储容量 

4. 高可用：某个数据库出现了问题，其他业务不影响

 

消费金融核心系统

客户、账户、商户、产品、放款、还款、合同、信审、资金拆分这些模块，单独开发，部署

单张表数据量超载 数据水平拆分，分散存储

 

单表行数达到多少时适合分表？

单表行数超过500万行时或者单表容量超过2GB时，才推荐使用分库分表。

如果项目中预计三年以上的时间数据量才能达到这个级别时，请不要在创建表时就进行分库分表。

 

核心数据库-Oracle

客户表、账户表、商户表、产品表、放款表、还款表、合同表、

信审表、批扣表、资金表、风控表、催收表

 

2. 数据库表到了分库分表的地步，怎么分库分表

要从哪些纬度分库分表，垂直和水平切分，

垂直切分，按照表结构或说字段划分，得到不同业务相关的表（客户或合同业务相关的表放到一个数据库），单张表拆分成多张表也是一类

水平切分，基于数据划分，划分的结果是表结构相同，数据量不同；单库或多库的水平切分

单库的水平切分：比如交易历史表，拆分成当天，当月，历史（在历史记录上按月份分区）

 

分库的话，多个库，数据源怎么选择，动态的数据源的选择

编码层 AbstractRoutingDataSource

框架层 MyBatis

驱动层 Sharding-JDBC

代理层 Mycat

服务层 一些特殊的SQL版本

--------------------------------------------------

 

3.分库分表带来的问题与解决方案

跨库的关联查询问题，怎么解决，方法

一、垂直分库分表带来的问题：关联查询 和 分布式事务

 

关联查询解决思路：

①字段冗余：通过字段冗余的方式，尽量避免关联查询

②数据同步：商户系统、产品系统,依赖数据的来源，通过MQ将另一个库的表数据同步到本库；dblink、ETL（通过定时任务将表数据同步，实时性低）

③全局表（广播表）：每个库中都有一张一样的表，且表中数据一致。例如，行名行号表（10w数据量），类似字典表，通用表

④代码中：将各个库中表的数据都查询出来，然后在代码在内存中去整理出来我们需要的数据

⑤尽量把有业务关联的表放在一个库

⑥RPC 这种远程跨库关联查询，要少用，原因：消耗网络IO，数据库IO

⑦缓存、视图

 

分布式事务解决思路：

seata、tcc…等分布式框架很好的解决了分布式事务的问题，但是使用分布式事务会带来效率变慢，这是必然的。

分布式事务：这中间要有协调者询问相关的数据库表是否可以提交。方案有两阶段的提交，三阶段的提交，TCC分布式补偿事务。Sharding JDBC中有SEATA，原来叫Fescar，Atomikos，LCN

 

微服务其实就是垂直分库

 

二、水平拆分带来的问题：分页查询、全局ID、数据的均匀分布

分页查询解决思路：

①如果数据量大，可以将表每个月一张表，甚至每周一张表，查询的时候只支持查某个月的数据

②在代码中将数据排序

 

全局ID解决思路：

①UUID

②雪花算法

 

数据的均匀分布：

①hash % 取模

②随机

③范围：0-1亿数据在一个表，1-2亿数据在另一个表，2-3亿数据在另一表

④时间：月度、周…

⑤按地区，同地区产生的数据在一个表

⑥复合算法：范围取模 取模范围

⑦枚举：男 女

 

水平的分库分表：

跨库 避免各个表ID重复；auto_increment

解决,用全局ID；全局ID的实现方式，数据库 for update seq, UUID主键，Redis,ZK，

这样做的ID不一定是全部连续的，只不过ID会呈现趋势递增的形式

雪花算法Leaf

 

原文链接：https://blog.csdn.net/RookiexiaoMu_a/article/details/106630959

 

4. Sharding JDBC分库分表实战

真实表，LogicTable(逻辑表)，ShardingColumn（分片键），DataNode数据节点

 

逻辑表：相当于视图，虚拟表

ShardingColumn（分片键）:表分片，用一个字段作为分片键

 

分片策略：随机

取模，用的比较多，因为取模的情况下 数据分布比较均匀

Range，范围存储，按照比较均匀的方式把数据分布在算好的范围内

日期，按照年月日划分数据

 

哈希，对于非整型的字段是先哈希再取模节点。如果取模后的节点放不下存储的数据，

那么要重新取模，所有数据要重新分布，这就出现了严重的问题，为了解决这个问题

出现了一致性哈希

一致性哈希，解决了会影响全部节点数据重新分布的问题。 只会影响相邻的节点，而不会影响其他的节点。做分布式负载均衡常用的方式

 

组合的算法

根据业务综合考虑，根据业务情况尽量少的减少数据的重新分配，又要尽量避免热点数据的问题  

Mycat中自带这些分片策略

 

扩容/缩容

 

动态表：在应用端还用这张逻辑表。ORM框架中的查询语句放到ShardingJDBC，这个组件根据查询条件自动把表名拼接上去

广播表：数据量不大，变化小，在各个表中都有重复的数据

绑定表：把父表和子表绑定起来 遵循相同的路由规则来实现关联查询

 

Spring Boot集成Sharding-JDBC：

配置方式（多种），配置内容：数据源、分片规则   验证

MyBatis Generator(MBG) 自动生成一些配置文件

 

优化数据库的几个方面

SQL与索引

存储引擎与表结构

数据库架构

MySql配置

硬件与操作系统

 

架构优化：缓存 主从复制，分库分表