ShardingSphere 分库分表技术实践
一、简介
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC(今天主角)、Sharding-Proxy和Sharding-Sidecar(计划中)这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。
今天给大家主要讲解的说ShardingJdbc应用,先简单介绍下ShardingSphere 两种主要分片应用及场景:
1、垂直分片:
按照业务维度将表拆分到不同的数据库,专库专用,分担数据库压力
白话简介:一张表不是有很多列字段,垂直拆分就是把字段拆出来呗,那怎么拆字段呢,当然是同一维度的拆出来。比如一个订单表。里面的订单相关字段能不能放到订单库的表里,里面的商品字段能不能放商品库的表里,里面的地址信息能不能放用户信息库里。
2、水平分片
按照某种规则将单表数据拆分到多张表中,突破了单机数据量的瓶颈。水平分片从理论上突破了单机数据量处理的瓶颈,并且扩展相对自由,是分库分表的标准解决方案。
白话介绍:一张表随着时间的推移,数据越来越多,查的越来越慢,那么就得横向将行拆出来,横向拆行就是水平分片。比如按订单号单双来拆。
接下来:
(今天主要演示的是常用的水平分片模式,演示前先介绍下数据分片的5种核心概念,如下述二模块:)
二、核心概念及实现
核心概念分为以下5部分
1、逻辑表
水平拆分的数据库(表)的相同逻辑和数据结构表的总称。例:客户信息表分为user_info1,user_info2 2张表,他们的逻辑表名为user_info。(配置文件展示)
2、真实表
在分片的数据库中真实存在的物理表,即user_info1,user_info2。(数据库表展示)
3、数据节点
数据分片的最小单元。由数据源名称和数据表组成,例:ds_0.user_info_0。(配置文件展示)
4、绑定表
指分片规则一致的主表和子表。例如:orders表和orders_items表,均按照order_no分片,则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联,关联查询效率将大大提升。
其中orders在FROM的最左侧,ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略,那么orders_items表的分片计算将会使用orders的条件。故绑定表之间的分区键要完全相同。(代码举例说明)
5、广播表
指所有的分片数据源中都存在的表,表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景,例如:字典表。(代码举例说明)
三、水平分片常用的分片策略
1.取模分片:
优点:数据存放均匀
缺点:假设取模值更改进行扩容,那么更改后,原表中的某些数据就需要迁移到新表中,迁移数据量大**(演示取模分表)**
2.范围分片:比如按时间进行分片,一月的放个表,二月的放个表
优点:增加分片不会引起大面积数据迁移
缺点:可能会导致分片数据倾斜,比如双十一的时候,11月这个表的数据量就会很大。(暂不演示)
四、分布式事务
1、两阶段事务-XA
功能
支持数据分片后的跨库XA事务
两阶段提交保证操作的原子性和数据的强一致性
服务宕机重启后,提交/回滚中的事务可自动恢复
(代码演示跨库事务)
五、FAQ
1、如果只有部分数据库分库分表,是否需要将不分库分表的表也配置在分片规则中?
答案:是。因为ShardingSphere是将多个数据源合并为一个统一的逻辑数据源。因此即使不分库分表的部分,不配置分片规则ShardingSphere即无法精确的断定应该路由至哪个数据源。 但是ShardingSphere提供了两种变通的方式,有助于简化配置。
方法1:配置default-data-source,凡是在默认数据源中的表可以无需配置在分片规则中,ShardingSphere将在找不到分片数据源的情况下将表路由至默认数据源。
方法2:将不参与分库分表的数据源独立于ShardingSphere之外,在应用中使用多个数据源分别处理分片和不分片的情况。
2、sum方法里,当包含ifnull(sum),且条件未含分片键,或者采用范围查询时跨库跨表里,会出现,本该获取出来应该说一条汇总数据,但实际会出现多条(执行了几个sql则得到对应的几条)(代码演示)。