aristotll / sharding-jdbc-test

基于 SpringBoot + ShardingSphere（Sharding-JDBC）+ Flyway + JOOQ + Gradle 的水平分表测试项目

基于 SpringBoot + ShardingSphere（Sharding-JDBC）+ Flyway + JOOQ + Gradle 的水平分表测试项目

一、Sharding-JDBC 与 JOOQ 的兼容性测试

• 测试项
  
  • 不分片时，使用默认数据源的增、删、改、查
    
  • 分片时，使用ShardingDataSource数据源的增、删、改、查
    
  • 分片表与不分片表的连表查询
    
  • 分片表的分页查询
    
  • 单路由单个字段的查询
    
  • 全路由 count 查询
    
  • 全路由 max 查询
    
  • 不分片表的事务
    
  • 分片表的事务
    
  • 维护不分片表和分片表的表操作在同一个事务中
    
• 结论： 本项目主要测试 Sharding-JDBC 与 JOOQ 的兼容性，就测试结果来看，所以测试项均兼容

二、Sharding-JDBC VS JDBC 性能测试

• 压测环境：MacBook Pro，处理器：2.3GHz、双核、Intel Core i5，内存：8GB、2133MHz LPDDR3
  
• 分片数量：30
  
• 测试数据基数：一百万条左右
  
• 压测汇总表
  
  • 分片： 单库多表，通过 Sharding-JDBC 水平分表后操作
    
  • 不分片： 单库单表，通过 JDBC 操作
    

-	线程数	测试时长	吞吐量	最小延迟（单位：ms）	平均延迟（单位：ms）	最大延迟（单位：ms）
分片插入	100	50s	87/s	84.61	1154.35	4312.13
分片插入	300	50s	86/s	83.78	3372.41	10074.58
分片插入	500	50s	87/s	82.05	5770.71	18790.38
不分片插入	100	50s	56/s	112.36	1754.26	7439.54
不分片插入	300	50s	60/s	105.79	4852.61	11497.53
不分片插入	500	50s	74/s	100.33	6737.00	21844.40
分片读	100	50s	192/s	36.27	508.03	5665.64
分片读	300	50s	217/s	35.22	1388.15	8234.14
分片读	500	50s	219/s	35.50	2282.93	12085.62
不分片读	100	50s	126/s	63.90	792.03	4240.31
不分片读	300	50s	111/s	64.08	2629.48	10194.41
不分片读	500	50s	98/s	64.07	4924.64	14170.59
分片更新	100	50s	132/s	65.77	757.52	4707.86
分片更新	300	50s	133/s	60.19	2257.25	9191.09
分片更新	500	50s	122/s	65.01	3994.44	13505.07
不分片更新	100	50s	86/s	95.67	1151.40	6052.50
不分片更新	300	50s	75/s	94.99	3903.93	11014.60
不分片更新	500	50s	81/s	94.88	5790.05	14319.90
分片删	100	50s	122/s	65.14	814.10	3853.16
分片删	300	50s	132/s	67.89	2280.78	7934.02
分片删	500	50s	136/s	36.97	3692.07	11425.84
不分片删	100	50s	90/s	15.50	1105.34	4286.00
不分片删	300	50s	92/s	95.55	3283.93	8169.72
不分片删	500	50s	101/s	96.61	4952.89	15578.29

• 结论： 通过观察以上压测汇总表，可见，
  分片增、删、改、查的吞吐量 > 不分片增、删、改、查的吞吐量
分片增、删、改、查的延迟 < 不分片增、删、改、查的延迟

三、踩坑

• 坑
  • 版本号兼容问题
    
  • 多数据源的配置问题
    
  • Flyway 与多数据源的兼容问题
    
  • 不分片表与分片表的事务问题
    
  • 等等
    
• 注意
  • 配置时，需要注意上面提到的坑