水平分表常见的路由算法

水平分表后,某条数据具体属于哪个切分后的子表,需要增加路由算法进行计算。

常见的路由算法有如下几种:

1)范围路由

          以最常见的用户ID为例,路由算法可以按照1000000的范围大小进行分段,1~999999放置于数据库1的表中,1000000~1999999放到数据库2的表中,以此类推。

    优点: 随着数据的新增可以平滑地扩充新的表。缺点是分布可能不均匀。

2)Hash路由

  选取某个列(或者某几个列的组合)的值进行hash运算,然后根据Hash的结果分散到不同的数据库表中。同样以用户ID为例,假如一开始规划了10个数据库表,路由算法可以简单地用user_id%10的值来表示数据所属的数据库表编号。

  缺点:增加子表数据非常麻烦,可能所有数据都需要重分布。

3. 路由配置

    用一张独立的表来记录路由信息

 缺点:多查询一次,会影响整体性能;如果路由表本身如果太大,性能同样又成为瓶颈,面临死循环式的路由算法选择问题。

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Sharding-JDBC 是一个开源的分库分表中间件,它可以帮助我们实现数据库的水平扩展和分布式架构。在 Sharding-JDBC 中,强制分片路由策略可以用于实现分表操作。 强制分片路由策略是一种在分表操作时,强制路由到指定的分片的策略。通常,在分表操作中,我们会通过某种规则或算法来决定数据应该路由到哪个分片上,比如根据某个字段的哈希值进行路由。而强制分片路由策略则会忽略这些规则,直接将数据路由到指定的分片。 在 Sharding-JDBC 中,我们可以通过配置数据源、分片规则和强制路由规则来实现强制分片路由策略。配置文件中的示例代码如下: ```xml <sharding-rule> <binding-tables> <binding-tables-strategy> <standard> <sharding-column>user_id</sharding-column> <algorithm-expression>user_id % 2</algorithm-expression> </standard> </binding-tables-strategy> </binding-tables> <table-rule> <table>user</table> <actual-data-nodes>ds${0..1}.user_${0..1}</actual-data-nodes> <database-strategy> <standard> <sharding-column>user_id</sharding-column> <algorithm-expression>user_id % 2</algorithm-expression> </standard> </database-strategy> <table-strategy> <standard> <sharding-column>user_id</sharding-column> <algorithm-expression>user_id % 2</algorithm-expression> </standard> </table-strategy> </table-rule> </sharding-rule> ``` 在上述配置中,`user_id` 是用来分片的字段,我们通过对 `user_id` 进行取模运算来实现分表路由。同时,我们可以通过配置强制路由规则,将数据强制路由到指定的分片。 需要注意的是,强制分片路由策略在某些特定场景下可能会有一定的限制和风险,因此在使用时需谨慎评估。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值