一、什么是分库分表?什么时候要分库分表?
先将tulingmall-order的jdbc数据源调整到本地,然后在本地数据库中,已经插入了20+W的订单数据,全都是Monkey用户插入的。
调整方法:
1、在启动类上排除掉SpringBootConfiguration.class,这个是ShardingSphere进行分库分表的配置类。@SpringBootApplication(exclude = {SpringBootConfiguration.class})
2、调整配置文件,打开application.yml中的datasource配置。
然后在前端tuling-front用Monkey/123用户登录,进入"我的订单"页面,这个页面可以查询到所有的订单。--页面没有分页,但是能够加载更多的订单。简单分析下这个查询订单的SQL:
查第一页会非常快,只要0.002秒。但是往后翻页时,效率会越来越低。当翻页翻到 10000,10时,执行时间需要3秒多。100000,10时执行时间需要4秒多。
查询会耗时2秒多。而简单执行下面这个SQL语句,会要消耗7秒多。
select * from (
select 1 from oms_order o LEFT JOIN oms_order_item ot on o.id = ot.order_id
) t limit 200000,10
这个时长如果需要响应到页面上,那就已经是无法忍受了。这还只是一个简单的查询,并且返回的数据其实还不多。如果数据更多(比如导出),查询更复杂,并发量更大,那消耗的时间会更长。
单表数据量太大带来的问题还不止是查询变慢,如果数据更多,还很容易造成系统假死。如果我们的订单页面不断的加载订单,那浏览器也会崩溃。
二、分库分表的作用
-
加大存储,
-
提升查询效率,
-
提升数据库的并发能力。
阿里的开发规范中建议预估三年内单表数据量上500W,或者大小上2G,就要考虑分库分表。
三、定制分库分表策略
定制分库分表策略的注意点:
-
分库分表一般要在开发之前设计,尽量避免临时设计。只针对最核心的表。
-
分库分表后,对表的查询必须足够简单,不要有跨表,跨库的复杂查询。
-
分库和分表尽量同时进行,分库可以分担网络压力。
关于数据分片策略:
-
分库策略:将核心的订单表和订单物品表从业务库中移出来,单独放到一个库。我们分成两个库。分散网络压力。
-
分表策略:在每个库分两个表,尽量将数据平均的分配到这四个表中。分散单表查询压力。
考虑的问题:
-
取模分片能够将数据分配得尽量的平均,但是不利于扩展。
-
按范围分片便于扩展但是他的数据分布又不够均匀。
-
是不是可以定制一种分片策略,将这两种分片策略结合起来?比如大尺度上按范围分片,但是在每个数据范围内,使用取模分片。这种分片策略要如何在ShardingSphere中实现?提供思路,留给大家自己实现。
-
1、回顾下ShardingSphere的几种分片策略实现方式:inline, standard, complex, hint。
-
2、两个库,四个表。要如何将数据分