分库分表实战及中间件

背景描绘

在项目中，运用单库单个mysql去存储数据，其中咱们某个表的数据量现在是3000w 、某个表由于客户一些创建的数据几乎每天增量数据是几十万，并且每个客户相对对应的数据增量也不只相同。考虑到之后到某个节点时间数据可能会到达上限1个亿。
咱们都知道mysql单表数据量是3000w-5000w左右，假如增量再多，单表的查询效率会变慢。

对此咱们需求将其分开存储，也便是需求考虑分库分表的时分了。那咱们怎么进行分库分表操作呢？

为什么要分表

上面也说了，由于单表的数据量在未来会到达一个亿等级乃至更高，单表查询效率会变慢。

这儿是单表查询数据量会变大。故此咱们选用分表操作，事务并不需求分库操作。

即单表数据量太大

在之后的查询、插入、更新操作都会变慢，在加字段、加索引、机器搬迁都会发生高负载，影响服务。

关于分表咱们怎么挑选？

分表分为水平分表和垂直分表

水平分表

针对数据量巨大的单张表（比如订单表），依照规矩把一张表的数据切分到多张表里面去。可是这些表仍是在同一个库中，所以库等级的数据库操作仍是有IO瓶颈。

缺陷是：并没有处理单个数据库并发以及IO的提升，如需求提升可添加机器配置，或许进行水平分库又分表。
好处就不必多说了。

水平分表规矩
  • RANGE

时间：依照年、月、日去切分。例如order_2020、order_202005、order_20200501

地域：依照省或市去切分。例如order_beijing、order_shanghai、order_chengdu

巨细：从0到1000000一个表。例如1000001-2000000放一个表，每100万放一个表HASH

用户ID取模不同的事务运用的切分规矩是不一样，就上面提到的切分规矩，举例如下：

站内信

用户维度：用户只能看到发送给自己的消息，其他用户是不可见的，这种状况下是依照用户ID hash分库，在用户检查历史记录翻页查询时，一切的查询请求都在同一个库内用户表

规模法：以用户ID为划分依据，将数据水平切分到两个数据库实例，如：1到1000W在一张表，1000W到2000W在一张表，这种状况会出现单表的负载较高

依照用户ID HASH尽量保证用户数据均衡分到数据库中假如在登录场景下，用户输入手机号和验证码进行登录，这种状况下，登录时是
不是需求扫描一切分库的信息？

终究计划：用户信息选用ID做切分处理，一起存储用户ID和手机号的映射的联系表（新增一个联系表），联系表选用手机号进行切分。能够经过联系表依据手机号查询到对应的ID，再定位用户信息。

流水表

时间维度：能够依据每天新增的流水来判别，挑选依照年份分库，仍是依照月份分库，乃至也能够依照日期分库

垂直分表

表中字段太多且包含大字段的时分，在查询时对数据库的IO、内存会受到影响，一起更新数据时，发生的binlog文件会很大，MySQL在主从同步时也会有延迟的风险。

大白话即一个表中有很多字段假如50个字段，平时咱们常常运用的有5-10个字段，关于其他字段万年几乎运用一次，对此咱们能够经过主键相关将其拆到另一张表中。这便是分表能够理解为类似于咱们将单体服务拆分红多个微服务。

缺陷是：假如拆分不好的话，多出一张表，关于其他事务，需求相关运用，添加额外表相关操作。
好处就不必多说了。

关于现在这儿的事务而言，现在选用分表操作。

剖析

依据咱们现在的事务（详细是做什么的，由于作业的原因，现在无法透露)，由于咱们的数据量关于订单表和某个表以下都简称C表，尤其是C表数据量在未来可遇见的状况下，数量会到达一个量。

所以这儿咱们选用了对此C表进行分表操作，简而言之依据每个客户对应一个表进行分表操作。

简略的来说，A,B,C,D,E,F…M客户，分表之前发生的数据都在C表中。
在咱们分表之后A,B,C,D,E,F等表分表对应C1,C2,C3,C4等表。

理论上来说能够每个客户对应一个表C，但实际的状况是，每个客户发生的数据不是相同的，有的客户一天乃至几w数据，有的客户乃至今后个月才1W数据。

故此，在分表之前需求对客户数据进行剖析，能够经过一些sql剖析查询，假定统计剖析之后数据如下

客户 数据量 /月
A 9W
B 10W
C 11W
D 0.2W
E 5W
F 7W
H 0.8W
I 2W

关于ABCE等客户能够每个对应一个表C1,C2,C3,C4关于EHI咱们能够让其对应表C5 , 其实关于F也能够对应一张表(能够依据自己的事务进行调整)

也便是如下图

分库分表实战及中间件（一）

实现

以上是简略的对事务分表的剖析，然后才干对齐进行分表。

咱们运用了客户(这儿依据客户id)进行分表，然后咱们开端挑选技术栈，关于市面上的分表中间件而言，有MyCat 和Sharding-JDBC
首先咱们不运用中间件而言怎么进行分表操作呢。

关于程序而言，在查询的时分依据不同的id去不同的C表(C1,C2,C3,C4等)中进行查询，新增更新删去也如此。
就需求咱们手动的去指定响应的路由规矩即依据id去找到相应的表C；

对此手动路由能够看一下代码

   Map<Integer,String> map =  new HashMap<>();
        map.put(1,"C1");
        map.put(2,"C2");
        map.put(3,"C3");
        map.put(4,"C4");
        map.put(5,"C5");
        map.put(6,"C6");
        map.put(7,"C6");
        //获取表C
        map.get(1);

在代码中进行JDBC操作时分，咱们手动的获取响应的表，然后经过替换符在sql中将C表进行替换即可。基本不影响sql操作包含join连表。

 SELECT
        s.a,
        s.b,
    FROM
        ${tableName} ss

但关于查询一切客户数据而言，由于分表的原因，一切的数据都不在一个表中。对此咱们可能需求将其数据都查询出来，然后将其组合起来。在sql或许java代码中都能够操作。

在Sql中，能够经过union关键字将其一切成果都相关起来查询回来，在事务代码中能够经过for循环等操作将其查询组合起来。

这样也存在缺陷：

sql中sql长度变长，编译sql时间长，悉数查询需求更改sql
事务代码中需求编写代码，需求组合查询，额外查询次数变多（单表中查询需求一次），这儿也能够经过保存一份一切的id数据表C。

最终

在上线前需求搬迁数据，将不同id对应的数据搬迁到不同的C表中。

总结

在代码中手动去路由分表

长处：简略，不需求引进其他中间件，复杂sql也能自己去实现（sharding-jdbc某些sql不支持）。

缺陷也是显而易见的，代码改动大，本钱大，几乎一切需求用到的C表都需求手动依据路由去获取C表，然后替换。后续事务发生变化，还需求改动代码。

分表优缺陷

长处：单表数据涣散存储在不同的表中，提高查询速度。
缺陷：没有处理单个数据的IO以及连接数以及并发。