分库分表解决300亿记录存储的三个方案方法

ゞ浴缸里的玫瑰 2024-04-08 12:30 36阅读 0赞

## 分库分表解决300亿记录存储的三个方案方法 ##

### 分库分表解决什么问题？ ###

*  分表：单表记录急剧增加，单表物理存储或单表查询遇到瓶颈；
 *  分库：上游服务增多，单库的连接数遇到瓶颈，此时需要考虑分库，分库后吞吐量将成倍增长；

### 场景 ###

我们看下在线酒店预订的一个场景。  
据统计全国有酒店30万家，客房总数1347万间，按照每个酒店有10个售卖房型（标准间、大床房、双床房…）算就有300万个售卖房型。  
我们需要存储每个房型未来365天的房价、房量共20亿的数据，这只是一个分销商的接入接入记录。  
假设我们接入了15分销商，房价、房量的记录就达到了300亿。  
梳理下已知的数据，酒店数据30万，房价数据150亿，房量数据150亿；  
下面探讨下这300亿的记录如何分库分表存储。

### 300亿记录怎么存？ ###

酒店记录在百万级，所以一张表就可以存储；  
房价记录150亿，所以需要考虑分库分表存储，我们使用16个库每个库16张表（共256张表）进行存储，每个表大约存0.58亿记录（硬件好加上读写分离一般无压力）；  
房量记录150亿，存储同上也为 16\*16 分库分表；  
小结：数据库分为三类酒店、房价、房量库，酒店库1x1，房价库16x16，房量库16x16；

### 数据路由？ ###

考虑相同酒店ID的信息需要落到同个分片中，我们可以使用hash取模的方式；  
这里使用我们使用BKDRHash算法，该算法简单高效（java字符串hash也使用这个算法）；  
比如存储一个酒店的价格信息：通过hashHotel(酒店ID)%16得到DB索引，在hashPrice(酒店ID)%16得到DB中价格表的索引；  
应该会发现一个问题，就是用相同酒店ID去做hash取模，索引会一直是同一个！！！  
这个问题解决就要用到BKDRHash算法的一个特性了，算法中可以加入一个因子，比如酒店片区的因子为131，而价格hash函数的因子为31。  
这样就算使用同一个酒店ID也会产生不同的hash结果。  
可以参考下面的code：  
‘’’  
private int patitionCount = 16;  
//酒店片区hash函数  
private int getBKDRHashByHotel(String key) \{  
int seed = 131; //因子取值：31, 1313, 13131, 131313, …  
int hash = 0;  
for (int i = 0; i < key.length(); i++) \{  
hash = (hash \* seed) + key.charAt(i);  
\}  
return hash;  
\}  
//价格片区hash函数  
private int getBKDRHashByPrice(String key) \{  
int seed = 31; //因子取值：31, 1313, 13131, 131313, …  
int hash = 0;  
for (int i = 0; i < key.length(); i++) \{  
hash = (hash \* seed) + key.charAt(i);  
\}  
return hash;  
\}  
‘’’

### 其它路由方案 ###

#### 基因因子分片 ####

基因分库法: 使用基因的思想，从一个维度的信息里，摘取了一个分库基因，其他维度信息里也全会带上,使得所有维度的信息都能通过此分库基因完成分库.  
关于分库方法,参考理论:  
He meant that taking number mod 2^n is equivalent to stripping off all but the n lowest-order *(right-most)* bits of number.  
即: 一个数取余2的n次方，那么余数就是这个数的二进制的最后n位数。所有我们可以位操作符把高位清零就可以得到余数.  
优点：通过ID即可分析所属片区，保证数据落到同一个分片中；  
不足：需要提前规定酒店ID、价格ID、房量ID的主键；

#### 一致性Hash分片 ####

建议使用这个算法，可以保证原有ID的命名规范，同时通过虚拟节点的加入避免了数据倾斜问题；  
在BKDRHash算法上简单修改可以实现虚拟节点的加入；  
也可以网上找个现成的算法改下；

### 关于扩容 ###

数据库拆分一般是业务发展到一定规模后的优化和重构，为了支持业务快速上线，很难一开始就分库分表，垂直拆分还好办，改改数据源就搞定了，一旦开始水平拆分，数据清洗就是个大问题，为此，我们经历了以下几个阶段。

#### 第一阶段 ####

*  数据库双写（事务成功以老模型为准），查询走老模型。
 *  每日job数据对账（通过DW），并将差异补平。
 *  通过job导历史数据。

#### 第二阶段 ####

*  历史数据导入完毕并且数据对账无误。
 *  依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。
 *  每日job数据对账，将差异补平。

#### 第三阶段 ####

*  老模型不再同步写入，仅当订单有终态时才会异步补上。
 *  此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待DW改造完就可以完全废除老模型了。

### 总结 ###

以上是对300亿数据分库分表的一种实现方案。为了保证高可用还需要进行读写分离，同时做好监控体系，包括但不限于：服务器的磁盘容量、磁盘IO、CPU负载；  
主从同步延时、慢查询、db缓存刷新频率等指标。  
阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。  
不同硬件环境下对于分库分表的阈值也有差异，主要还是需要看DB缓存、服务器的磁盘IO。  
服务器磁盘IO良好的情况下，单表1亿查询也是没问题的。