Sharding JDBC (二)分库分表关键问题与解决方案

x33g5p2x  于2021-12-19 转载在 其他  
字(6.4k)|赞(0)|评价(0)|浏览(677)

一、分库分表产生问题的原因

当系统数据库达到一定的量级,单数据库实例已经无法支撑的时候,我们就要考虑采用分库分表的策略了.那么进行数据分库分表后会

带来哪些影响呢?

1.1 垂直拆分的影响

  1. 单机ACID打破了
  2. 一些Join操作变得困难
  3. 外键约束的场景受影响

1.2 水平拆分的影响

  1. 单机ACID打破了
  2. 一些Join操作变得困难
  3. 外键约束的场景受影响
  4. 依赖单库的自增序列生成id受影响
  5. 逻辑意义上的单表查询可能要跨库
     

二、分库分表带来的难点问题

2.1 分布式全局唯一ID

在很多中小项目中,我们往往直接使用数据库自增特性来生成主键ID,这样确实比较简单。而在分库分表的环境中,数据分布在不同的分片上,如果每个分片都采用原有的主键自增策略。不可避免的会造成主键ID重复。简单介绍下使用和了解过的几种ID生成算法。

方案一 :设置主键自增id 的起始和步长

ds0.t_user  设置主键id   自动增长   起始1  步长2   -->> 1,3,5,7,9...

ds1.t_user  设置主键id   自动增长   起始2  步长2   -->> 2,4,6,8,10...

多少个库步长就为分库的数量

缺点:

  1. 不利于扩展,新增库之后要维护所有表的自动增长步长,
  2. 中小型使用自增序列,但是大型项目不使用

方案二 :UUID/GUID

优点:

  1. 好处就是本地生成,不要基于数据库

缺点:

  1. UUID 使用字符串形式存储、太长占用空间大,作为主键性能太差了
  2. UUID 不具有有序性,会导致 B+ 树索引在写的时候有过多的随机写操作(连续的 ID 可以产生部分顺序写),还有,由于在写的时候不能产生有顺序的 append 操作,而需要进行 insert 操作,将会读取整个 B+ 树节点到内存,在插入这条记录后会将整个节点写回磁盘,这种操作在记录占用空间比较大的情况下,性能下降明显
  3. 采用无意义字符串,区别于SKUID,没有任何业务上体现(淘宝,京东等商品的SKUID包含商品的信息)

方案三 :Twitter的分布式自增ID算法Snowflake

雪花算法概述

有这么一种说法,自然界中并不存在两片完全一样的雪花的。每一片雪花都拥有自己漂亮独特的形状、独一无二。雪花算法也表示生成的ID如雪花般独一无二。

组成结构

大致由:首位无效符、时间戳差值,机器(进程)编码,序列号四部分组成,雪花算法生成的ID是纯数字且具有时间顺序的。

  • 时间位:可以根据时间进行排序,有助于提高查询速度。
  • 机器id位:适用于分布式环境下对多节点的各个节点进行标识,可以具体根据节点数和部署情况设计划分机器位10位长度,如划分5位表示进程位等
  • 序列号位:是一系列的自增id,可以支持同一节点同一毫秒生成多个ID序号,12位的计数序列号支持每个节点每毫秒产生4096个ID序号

优点:

  1. 时间自增排序
  2. 适合分布式场景,整个分布式系统内不会产生ID碰撞(由datacenter和机器ID作区分)
  3. 效率较高,每毫秒4096个ID序号

缺点:

雪花算法在单机系统上ID是递增的,但是在分布式系统多节点的情况下,所有节点的时钟并不能保证不完全同步,所以有可能会出现不是全局递增的情况

简单配置实现

https://blog.csdn.net/womenyiqilalala/article/details/106118983

方案四:Redis Increment

incr可以用作计数器模式,它是原子自增操作

方案五:Zookeeper 分布式事务锁

方案六:MongoDB ObjectID(类似于UUID)

方案七:Ticket Server (数据库生成方式,Flickr采用这种方式)

2.2 常见分片规则

存储的规则

  • 随机分片:hashcode 取模 (user_id % 片数量 ,取模结果为 0 ,insert t_user0,取模结果为 1,insert t_user1)
  • 连续分片: 时间范围,int ,可能会造成数据倾斜(每个库数据量不平衡) 

根据业务需求来决定分片键 ,在业务之初分片键确定之后一般情况不更换,如果更换,对数据迁移,数据维护 非常的麻烦

2.3 常见分片策略

Sharding-JDBC中的分片策略有两个维度:

  • 数据源分片策略(DatabaseShardingStrategy):数据被分配的目标数据源
  • 表分片策略(TableShardingStrategy):数据被分配的目标表
  • 两种分片策略API完全相同,但是表分片策略是依赖于数据源分片策略的(即:先分库,然后才有分表

Sharding分片策略继承自ShardingStrategy,提供了5种分片策略。
io.shardingsphere.core.routing.strategy.ShardingStrategy
    --io.shardingsphere.core.routing.strategy.standard.StandardShardingStrategy
    --io.shardingsphere.core.routing.strategy.standard.ComplexShardingStrategy
    --io.shardingsphere.core.routing.strategy.standard.InlineShardingStrategy
    --io.shardingsphere.core.routing.strategy.standard.HintShardingStrategy
    --io.shardingsphere.core.routing.strategy.standard.NoneShardingStrategy

由于分片算法和业务实现紧密相关,因此Sharding-JDBC并未提供内置分片算法,而是通过分片策略将各种场景提炼出来,提供更高层级的抽象,并提供接口让应用开发者自行实现分片算法。

策策略一:标准分片策略StandardShardingStrategy

简单配置实现链接:https://blog.csdn.net/womenyiqilalala/article/details/106113983

  • 提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持
  • StandardShardingStrategy只支持单分片键,提供PreciseShardingAlgorithm(精准分片)和RangeShardingAlgorithm(范围分片)两个分片算法
  • PreciseShardingAlgorithm是必选的,用于处理=和IN的分片
  • RangeShardingAlgorithm是可选的,用于处理BETWEEN AND分片,如果不配置RangeShardingAlgorithm,SQL中的BETWEEN AND将按照全库路由处理
  • 如果需要使用RangeShardingAlgorithm,必须和PreciseShardingAlgorithm配套使用

分片策略二:复合分片策略ComplexShardingStrategy

简单配置实现链接:https://blog.csdn.net/womenyiqilalala/article/details/106115560

  • 提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持
  • ComplexShardingStrategy支持多分片键,由于多分片键之间的关系复杂,因此Sharding-JDBC并未做过多的封装,而是直接将分片键值组合以及分片操作符交于算法接口,完全由应用开发者实现,提供最大的灵活度

分片策略三:Inline表达式分片策略InlineShardingStrategy

简单配置实现链接:https://blog.csdn.net/womenyiqilalala/article/details/106115295

  • 使用Groovy的Inline表达式,提供对SQL语句中的=和IN的分片操作支持。
  • 只支持单分片键
  • InlineShardingStrategy只支持单分片键,对于简单的分片算法,可以通过简单的配置使用,从而避免繁琐的Java代码开发,如: tuser${user_id % 8} 表示t_user表按照user_id按8取模分成8个表,表名称为t_user_0到t_user_7

分片策略四:Hint分片HintShardingStrategy

简单配置实现链接:https://blog.csdn.net/womenyiqilalala/article/details/106115831

在分库分区中,有些特定的SQL,Sharding-jdbc、Mycat、Vitess都不支持(可以查看相关文档各自对哪些SQL不支持),例如:insert into table1 select * from table2 where ....这种SQL 路由很麻烦,需要解析table2的路由(是在ds0 /ds1 table2_0/table_1),结果集归并,insert 语句也需要同样的路由解析。这种情况Sharding-jdbc可以使用Hint分片策略来实现各种Sharding-jdbc不支持语法的限制

  • 通过Hint而非SQL解析的方式分片的策略。对于分片字段非SQL决定,而由其他外置条件决定的场景,可使用SQL Hint灵活的注入分片字段
  • Hint分片策略是绕过SQL解析的,所以对于这些比较复杂的需要分片的查询,采用Hint分片策略性能可能会更好
  • 在读写分离数据库中,Hint 可以通过HintManager.setMasterRouteOnly()方法,强制读主库(主从复制存在一定延时,但在某些特定的业务场景中,可能更需要保证数据的实时性)

分片策略五:NoneShardingStrategy

不分片的策略。和直接不使用Sharding-JDBC 效果相同

2.4 分片算法

Sharding提供了以下4种算法接口:

  • PreciseShardingAlgorithm:精确分片算法,用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。
  • RangeShardingAlgorithm:范围分片算法用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。需要配合StandardShardingStrategy使用。如果需要使用RangeShardingAlgorithm,必须和PreciseShardingAlgorithm配套使用,否则会报错
  • HintShardingAlgorithm:Hint分片算法
  • ComplexKeysShardingAlgorithm:复合分片算法

2.3 跨分片技术问题

2.3.1 跨分页的排序分页

跨节点多库进行查询时,会出现limit分页、order by排序等问题

分页需要按照指定字段进行排序当排序字段就是分片字段时,通过分片规则就比较容易定位到指定的分片。

当排序字段非分片字段时,就变得比较复杂。各分片节点中的数据可能是随机的,为了排序的准确性,必须把所有分片节点的前N页数据都排序好后做合并,最后再进行整体的排序。很显然,这样的操作是比较消耗资源的,用户越往后翻页,系统性能将会越差。

例如:现有db0.t_user0 ,db1.t_user1 ,db2.t_user2 三张表

select id from t__user where id < 10 order by  id limit 0,2 

每张表的数据:

db0.t_user0   1,4,7

db1.t_user1    5,2,8

db2.t_user2    9,6,3

必须要对db0.t_user0 ,db1.t_user1 ,db2.t_user2 三张表进行排序,然后合并为结果 1,4,7,2,5,8,3,6,9 ,再对合并的结果排序分页

2.3.2 跨分页的函数处理

在使用Max、Min、Sum、Count之类的函数进行统计和计算的时候,需要先在每个分片数据源上执行相应的函数处理,然后再将各个结果集进行二次处理

2.3.3 跨分片join

Join是关系型数据库中最常用的特性,但是在分片集群中,join也变得非常复杂(这种场景,比上面的跨分片分页更加复杂,而且对性能的影响很大),应该采取尽量避免跨分片的join查询。在分库分表中,尽量减少跨库的join,基本上所有的组件都不提供跨库join的功能,目前没有好的办法去解决

a)全局表

全局表 (等同于维度表,例如省份表,城市表,名族表等),使用的是空间换时间的思想,每个db数据库上都存在一张相同数据的表,维护同步

b) ER表

在关系型数据库中,表之间往往存在一些关联的关系。如果我们可以先确定好关联关系,并将那些存在关联关系的表记录存放在同一个分片上,那么就能很好的避免跨分片join问题

2.4 跨分片事务问题

跨分片事务也叫分布式事务,想要了解分布式事务,就需要了解“XA接口”和“两阶段提交”。值得提到的是,MySQL5.5x和5.6x中的xa支持是存在问题的,会导致主从数据不一致。直到5.7x版本中才得到修复。Java应用程序可以采用Atomikos框架来实现XA事务(J2EE中JTA)

三、Sharding JDBC 概念

真实表

如果t_user 表分库分表之后四张表(ds0.t_user0、ds0.t_user1、ds1.t_user0、ds1.t_user1)

在sharding-jdbc 查询时:直接select * from t_user where age =18 ,shardig-jdbc回去查询四张表中符合的数据,对于程序代码sql 中t_user 是逻辑表,并不存在,而 ds0.t_user0、ds0.t_user1、ds1.t_user0、ds1.t_user1 是存放了数据并且存在的真实表(可以参考接口和实现类,接口不能不能被实例化)

广播表

也就是上面的 2.3.3中的全局表

绑定表

sharding-jdbc使用绑定表名称,Mycat使用ER表名称

例如

主表-> t_person_main(id,name,age,qq_level);

子表-> t_person_detail (id,gender,address,phone_num,e-mail,city_id);

如果主表id = 1 分表时在ds0,子表id=1 在ds1 。

Select  *  from  t_person_main as mian left join t_person_detail as detail on mian .id = detail .id where mian .id=1;查询时就需要跨库join.

sharding-jdbc 使用绑定表解决跨库join ,判断相关联的数据插入时是否在同一个库,例如 t_person_main id=1在ds0上,那么t_person_detail id=1 就不会插入到ds1上,保障主表和子表相同数据在同一个库中。出现上面id相同不同库的情况, join时也不会去其他的库上查找数据。避免跨库join

四、系统是否分库分表分析

mysql单表经验

  • 300W Mysql 可以轻松抗住
  • 600 W 数据开始卡,优化可以解决(表结构,索引设计)
  • 800W ~ 1000W 牛逼的DBA 优化都会遇到瓶颈

一般MySQL单表1000W左右的数据是可以不需要考虑分表的。当然,除了考虑当前的数据量和性能情况时,我们需要提前考虑系统半年到一年左右的业务增长情况。但是要避免过度设计(考虑了很多未来几年的需求。例如一张表在未来几年内 数据预计会达到几千万(存在很多的不确定性))

根据数据量增长速度,选择实现步骤

第一步:不分库不分表

第二步:同库内的分表

第三步:分库分表

不要过度设计,一上来玩大的就进行分库分表

分库如果多个实例存在同一台服务器上,只是解决了数据库最大连接数的问题

但是 io(数据库数据是存储在硬盘上,每次获取都需要去硬盘把数据捞出来),cpu 等服务器资源瓶颈并没有解决。数据库的性能取决于服务器等性能

相关文章