talk is cheap, show me the scheme.
分析数据特征
- 统计数据量,少量数据?百万级?千万级?亿级?
- 是否含有自增ID
- 是否每条数据都有
create_time - 明确
WHERE字段是否有索引 - 是否包含批量导入的历史数据,即:某个时间点内数据量达到百万级别甚至更高
通用方案
以处理2020年~2021年数据为例。
利用
数据的时序性和自增ID处理大数据量(百万、千万、亿级别)的通用方案。
该方案无论对于单节点还是分布式数据库均适用,作者的实践就是基于
阿里云DRDS上处理亿级数据。
单节点的数据库,我们可以认为
create_time与自增ID是正相关的。
即:10001 >= id <= 40000之间的所有数据肯定都是2021-07-07的。
而在分布式数据库中,自增ID与create_time的关系可能出现如下情况:
| database | 自增ID段 | id | create_time |
|---|---|---|---|
| user_db1 | 10001~20000 | 10001 | 2021-07-07 12:00:00 |
| user_db1 | 10001~20000 | 16666 | 2021-07-09 12:00:00 |
| user_db2 | 20001~30000 | 20001 | 2021-07-07 12:00:00 |
| user_db2 | 20001~30000 | 26666 | 2021-07-08 12:00:00 |
| user_db3 | 30001~40000 | 30001 | 2021-07-07 12:00:00 |
| user_db3 | 30001~40000 | 36666 | 2021-07-07 13:00:00 |
出现这个现象的原因是由于:数据落库的路由算法不均匀或者选择的分库键的值本身就是不均匀的。
所以,我们的流程图中第3步的WHERE条件是使用id范围和create_time范围这两者来进行查询数据的。
952

被折叠的 条评论
为什么被折叠?



