互联网应用架构：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。





前言

现在网络的访问量激增，数据的量能也激增，在进行DB层面设计的时候，很多时候都要考虑分库分表，但是笔者发现一个问题，就是很多人一遇到这种问题就直接分库分表，不考虑现实的环境应该怎样？或者不考虑现在的项目应该怎么去设计，是否需要分库，是否需要分表。业务的增量如何？如何做到根据业务做后续拓展，今天我们来聊一下针对mysql的几种分库分表方案。





性能分析

俗话说，知己知彼，方能百战不殆。要想解决问题，那就必须知道我们的问题所在，及尽可能预测后面要发生的问题。在一个系统中，针对不同的业务，设计不同的方案，例如并发问题，例如存量问题，总结起来有以下三种问题。



1、网络IO问题



互联网的世界什么东西最常见，就是高并发，并发一高很多你见不到的问题就来了，其中请求的数据太多导致宽带不够，这就是网络IO问题。



2、磁盘IO问题



现在很多时候，我们在进行数据库查询的时候经常要做缓存，但是缓存也不能万能的，有时候热点数据很多，缓存已经放不下导致几乎全部走数据库查询，这样子在高并发请求下的每一次请求都会消耗大量的磁盘IO，从而查询速度会降低下来，现在的直接IO或者零拷贝也只能缓解，并不能最终解决问题。



3、计算性能问题



在普通的应用程序中一般都是CPU计算，虽然速度很快但是架不住大量的查询，例如单表数据很大，单表字段太多，没有合适的索引，SQL查询需要优化等，从而导致CPU的计算效率很低，导致CPU出现性能瓶颈。



针对以上三种问题，我们来讲讲不同的分库分表方案





分库分表不同实现

1、垂直分库



1.1.原理



按照业务定义不同，把不同的表放入到不同的库里面



1.2.切入点



以业务为导向，例如订单系统，库存系统



1.3.结果



• 每个数据库的业务范围不一样，因此每个库里面的表结构不一样

• 每个数据库里面的数据并不一样



1.4.场景



现在经常做的微服务系统，很多时候都是一个服务一个数据库



1.5.优点



面对一些高并发，高存量的时候，每个数据库都可以独立服务化存在，从而实现服务化的集群部署



1.6.缺点



由于把全量数据分散到各个数据库中去，在面对一些复杂的业务场景的时候会出现数据聚合问题，需要把各个数据库里面的数据聚合在一起，这需要根据不同的需求设计不同的实现方案。





2、垂直分表



2.1.原理



根据特定的业务场景寻找热点数据，并根据热点数据做表切分



2.2.切入点



主从表的设计思想



2.3.结果



• 存在实际意义的主从表之分，主表与从表之间一般采用主键进行数据关联



2.4.场景



这里主要应对一些复杂的业务场景，并发量不大但是计算比较大的情况，存在一定情况的数据冗余，查询数据的由于缓存数据的减少从而增加了磁盘的IO请求，例如缓存了主表的基础数据，但是从表需要查询。



2.5.优点



抽离出共性或者可以作为热点的数据，降低磁盘IO的瓶颈



2.6.缺点



由于一个表被拆分成两个，导致进行关联查询的时候容易增加CPU的计算负担，特别是在写SQL的时候采用join，是比较考验CPU的计算能力，因此针对这方面，笔者建议在代码层面进行数据的聚合。





3、水平分库



3.1.原理



按照一定的策略入hash或者range等，把数据分散放到不同的数据库上。



3.2.切入点



根据规则（技术算法层面或者业务规则）数据分散放到不同的数据库



3.3.结果



• 每个数据库结构一样，但是每个数据库的数据是不一样的

• 每个数据库并没有任何的交集，他们只存储部分数据



3.4.场景



数据量比较大，并发量比较小的时候



3.5.优点



数据分散来，从而来减少每个数据库的压力



3.6.缺点



当数据库多了的时候，在进行计算跟数据读取的时候，磁盘IO，网络IO，CPU计算都会成倍增长，这点上需要非常注意做适当操作，不可以随意切分。





4、水平分表



4.1.原理



按照一定的策略入hash或者range等，把数据分散放到不同的表上



4.2.切入点



以每个表的某些字段为切分点，例如订单日期等，每三个月一个表



4.3.结果



• 每个表的结构一样

• 每个表的数据不一样



4.4.场景



当某一个表增量比较大，可以按照指定的字段作为切分点来做，例如订单，例如历史记录都可以做



4.5.优点



查询特定业务范围的数据，表数据减少了从而增加来查询效率



4.6.缺点



分表后数据分散在不同的表中，联合查询会增加磁盘的IO以及CPU的计算，尽可能放弃join并在代码上实现数据聚合操作





分库分表中间件

• Mycat

• Sharding-sphere



选型原则：建议社区的热度优先，笔者以前用sharding-sphere，现在喜欢用mycat，文档及社区热度较好。



总结

不是所有的应用都适合分库分表或者需要分库分表，进行分库分表的时候代表着你引入了更加复杂的问题，是垂直还是水平，分几个库，分几个表都需要做增量预测，从而达到一个平衡态。



--END--



作者：@互联网应用架构



原创作品，抄袭必究



如需要源码或转发，请关注后私信我



部分图片或代码来源网络，如侵权请联系删除，谢谢！