数据库分表策略

在面临数据库大量数据时,分库分表是常用的方式。分库分表本质上是业务并发复杂度的降级。本质上降低了业务的关联复杂度,损失了数据关联计算的特性,才得以提高数据的存取性能。分库分表之后,不能做:

  1. 全局的join、分页、排序等,也就是两个表之间的数据就相对独立了。

  2. 跨库事务

常用的Sharding策略如下。

1. Sharding策略

按业务主键ID范围分表

例如按用户uid分段分布,例如0-1000000分在第1个表,1000001-2000000分在第二个表,以此类推。

优点:满足水平扩展能力,当一个表数据量太大需要再拆分时,其它表不受影响,扩容过程可控。

缺点:分表路由可能需要分段维护,分段不一定均匀。因此分表路由就需要一个服务来维护,增加了维护成本。

按业务主键ID hash分表

例如按用户uid 100取模分表,分为100张表,看uid尾数就知道落在哪个表中,例如243就落在第44张表(命名可以从_0开始)中。

实际上,hash分表的hash函数可以设计得很复杂以满足需求。例如根据统计的用户活跃度,将相同的活跃度用户分在不同的表中,避免过多高活跃用户分在同一张表中。

当查询有多个维度时,例如交易双方买卖家,交易数据即需要按买家维度查,也需要按卖家维度查询,所以多个维度查询时就需要冗余多份数据

优点:分表逻辑简单,直观看出数据落在哪张表中,分表效果均匀。

缺点:当数据需要扩容时,几乎所有数据都要移动,成本大风险大。因此,对于表容量的预估很重要,通常要按几倍于设计容量的大小进行分表。

按时间范围分表

互联网的数据都有这个特点:时间离现在越近,数据访问次数越多。可以分一个当前的表,一个或多个历史表,按年或月为维度存放数据。

优点:符合互联网数据读写热点特征。

缺点:对同一用户的历史数据读取需要分开处理。如果分表逻辑简单,那么需要定时迁移数据。如果手工迁移数据,那需要持久化维护分表路由。

上述方式的组合

例如先按用户范围分段,分段里面再取模分表。一定程度上减少了hash重分表时对整体数据的影响。

文档更新时间: 2018-11-10 17:06   作者:nick