这是微服务还没兴起之前,很多项目的架构,随着业务的堆积,项目越来越庞大,数据量也越来越庞大,如果并发一旦上来,就很容易出现一些性能的问题。而且项目太庞大,维护起来也不容易。
多应用单数据库系统是对之前的单体应用系统进行拆分,分成多个服务,也就是一个分布式的系统,但是数据库层面还是用同一个数据库,仅仅对业务进行拆分,数据量多的话,数据库的压力还是那么大。
对数据库性能进行调优,集群提高性能稳定性各种调优之后,如果性能还是有问题,数据量又特别庞大的情况才可以考虑分库了,这样就是一个多应用多数据库的系统。
分库分表按照拆分方式可以分为垂直拆分和水平拆分
水平分表的规则
不同的业务场景水平分表规则是不一样的,就上面提到的规则,举例如下:
order_1,order_2,order_3,...,order_n
分到多个库里,如图:
随着业务数量的快速增长,一些常用业务表数据量达到了几千万,或者上亿的数据量,这个时候如果SQL没注意,可能导致一些慢SQL的出现。
所以什么时候需要分表?500万,1000万?这个其实也没特定的规定,不过可以参考《阿里巴巴Java开发手册》里面的建议:推荐500万行或者单表容量超过2GB时候才需要分表
当然数据达到500万就需要分表?这个没有确定的,手册里也只是建议,如果数据表设计合理,索引建立也合理,系统也是可以支持500万或者上千万数据,分库分表虽然可以减缓数据库压力,但是分库分表也意味着业务处理起来更麻烦了。比如要查询数据,有时候需要跨几个库或者多张表。如何保证高效查询又是一个问题。所以分库分表要根据业务或者实际情况出发,合理设计。
分库分表带来的问题: