业务分库
按照业务分库,比如用户、商品、订单分库
带来的问题
- join 问题
不在同一数据库无法join,只能先查一个数据库拿到id列表,在去另外一个库查询 - 事务问题
原本在同一个数据库的不同表的操作可以在同一个事务里边,分散到不同数据库后无法通过事务统一修改。 - 成本问题
分表
- 垂直分表
把不常用且占用了大量空间的列拆分出去。带了的问题是原来只要查询一次就能获取所有所有列,现在需要查询多次 - 水平分表
-
路由
- 范围路由
按照userId的范围分表,特点可能分配不均(例如按照1000万分表,可能一个表有1000万另一个表只有1000),随着数据的增加平滑的扩充新表,原数据不动 - hash路由
按照hash取模分表,特点分配均匀,但是新增表所有数据需要重新分布,但是使用一致性hash算法可以优化 - 配置路由
增加一个配置表比如 user_router表 包含 user_id,table_id两列,优点灵活,缺点多查询一次表太大了性能也会不好
- 范围路由
-
join
需要多次join然后合并 -
count()
多个表count()相加,实现简单去诶单性能较低。增加一个记录数表,性能优化了,但是复杂度增加了,必须要同步记录,但是又不能放在同一事务里处理,因为记录表插入失败不应该回滚业务逻辑 -
order by
数据分散多个字表中,排序无法在数据库中完成,只能由业务或者中间件去分表查询每个子表中的数据然后汇总。
网友评论