首页 > 数据库 > 其他综合 >

分库分表及shardingjdbc操作教程

2018-05-12

分库分表及shardingjdbc操作教程。数据库拆分简单来说,就是指通过某种特定的条件,按照某个维度,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面以达到分散单库(主机)负载的效果。

一 序

数据库拆分简单来说,就是指通过某种特定的条件,按照某个维度,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面以达到分散单库(主机)负载的效果。

从理论到自己动手写demo还是有差别的。尤其是调研后发现shardingjdbc的官网例子不能直接用。

有点错位的感觉:官网的文档是基于java的。实际上以yaml或者spring + mybatis配置的多。

所以还是觉得有必要整理一篇。本篇是理论部分,下一篇是demo.

二 垂直拆分

通常是一张大表拆成多张小表,是按照列拆的。举个例子,假设现在交易相关的在一张表。

包含了订单,支付信息,退款等。可以按照垂直拆分为更细的小表,如:订单,支付,退款。

优点:

小表业务逻辑更清晰,容易维护,有的订单表都上百列,有的如状态会有修改,大部分字段不变,还是能拆开的。

缺点:

查询以前是在一个库一张表,如果拆为同一库不同的表需要关联join查询,如果拆为不同的库无法join需要依赖接口。

所以通常的这种垂直拆分是在设计阶段都拆好了。

三 水平拆分

水平分表也称为横向分表,比较容易理解,就是将表中不同的数据行按照一定规律分布到不同的数据库表中(或者保存在同一个数据库中),这样来降低单表数据量,优化查询性能。通常是取模或者hash.

这里hash多说一句,了解负载均衡的同学,通常会想到一致性hash,为数据迁移考虑。但是实际业务场景不太一致:

1 一致性hash是负载均衡下,为了增加减少节点尽量减少数据移动。

2 对于水平拆分的来说,假设这次分了8个表,下一次单表数据量达到上限1000W,又要进行再次扩容到16个,

数据量是从8个表迁移一半到8个新表,一共是16个表。迁移量没有本质的减少。所以这里不适合一致性hash。

扩容方案可以跟dba讨论细节,通常规划是分表后一年内规划好容量,不再进行扩容。

如果是在同一个库,单表的数据量少了,数据库级别的IO还是有的。所以通常更建议是拆分到不同的库。

\

优点:

1. 不存在单库大数据,高并发的性能瓶颈。

2. 按照合理拆分规则拆分,join操作基本避免跨库。

缺点:

1. 分片事务一致性难以解决。

2. 数据多次扩展难度跟维护量极大。每次扩容2倍,比如:8,16,32这种

四 水平拆分相关

拆分原则 1. 尽量不拆分,架构是进化而来,不是一蹴而就。(SOA) 2. 最大可能的找到最合适的切分维度。 3. 由于数据库中间件对数据Join 实现的优劣难以把握,而且实现高性能难度极大,业务读取 尽量少使用多表Join -尽量通过数据冗余,分组避免数据垮库多表join。 4. 尽量避免分布式事务。 5. 单表拆分到数据1000万以内。

切分方案 范围、枚举、时间、取模、哈希、指定等

考虑因素:

历史数据写多都少越近日期查询越频繁?什么业务数据?重不重要?有没有大规模分析查询?数据量多大?保留多久?机器资源有多少?

分布式全局唯一ID

而在分库分表的环境中,数据分布在不同的分片上,不能再借助数据库自增长特性直接生成,否则会造成不同分片上的数据表主键会重复。

常见的id生成算法:

UUID、snowflake等。

补充一句,这里需要自己评估效果,比如snowflake,除了机器数,时间因素等。生成的唯一id要测试,比如考虑到时间到毫秒,生成的id偶数多,这样情况不处理直接取模水平拆分就容易不均匀。

还要考虑多对多情况下,如何设计拆分原则。比如订单id最好包含uid,即使按照Oderid拆分的情况下,同一用户的订单会落到同一个库,不会宽阔查询,这需要一开始的情况就要设计好。

参考沈剑老师的文章:https://blog.csdn.net/qq_18145031/article/details/77867853

扩库的问题不展开说了,查询,函数都需要关注。

五 相关开源组件

这里离不开最原始的jdbc,

jdbc层:实现复杂,属于轻量级,对应用基本没有侵入性;缺点是跨库事务不如mycat强大。类似当当网的sharding-jdbc.

ORM层:比如蘑菇街TSharding框架封装mybatis,实现简单。缺点是必须依赖ORM层,侵入性比较大。

DBProxy层:如cobar和mycat,可以做到连接复用,性能不错,完全没侵入性。缺点是实现复杂,框架比较重,维护工作量大。

DAO层:实现简单,缺点是分表比较麻烦。美团的框架dbproxy,貌似发版本到0.25,最近大半年都没有维护新版本。

shardingjdbc使用客户端直连数据库,以jar包形式提供服务,未使用中间层,无需额外部署,无其他依赖,DBA也无需改变原有的运维方式,可理解为增强版的JDBC驱动,旧代码迁移成本几乎为零。满足目前业务需求,采用这个了。下一篇整理demo。

当当的开源地址:https://github.com/sharding-sphere/sharding-sphere

\

相关文章
最新文章
热点推荐