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范围
这两者来进行查询数据的。