分库分表——基本概念以及shardingJdbc和Mycat对⽐
1、什么是分库分表
就是把原本存储于⼀个库的数据分块存储到多个库上，把原本存储于⼀个表的数据分块存储到多个表上。
2、为什么分库分表
数据库中的数据量不⼀定是可控的，在未进⾏分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越⼤，相应地，数据操作，增删改查的开销也会越来越⼤；另外，由于⽆法进⾏分布式式部署，⽽⼀台服务器的资源（CPU、磁盘、内存、IO 等）是有限的，最终数据库所能承载的数据量、数据处理能⼒都将遭遇瓶颈。
3、分库分表的实施策略
分库分表有垂直切分和⽔平切分两种。
垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建⽴定义数据库workDB、商品数据库payDB、⽤户数据库userDB等，分别⽤于存储项⽬数据定义表、商品定义表、⽤户数据表等。
⽔平切分，当⼀个表中的数据量过⼤时，我们可以把该表的数据按照某种规则，例如userID散列，进⾏划分，然后存储到多个结构相同的表，和不同的库上。例如，我们的userDB中的⽤户数据表中，每⼀个表的数据量都很⼤，就可以把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的⽤户数据表userTable，切分为很多userTable：userTable0、userTable1等，然后将这些表按照⼀定的规则存储到多个userDB上。
应该使⽤哪⼀种⽅式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项⽬的业务类型进⾏考虑。
如果数据库是因为表太多⽽造成海量数据，并且项⽬的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是⾸选。
⽽如果数据库中的表并不多，但单表的数据量很⼤、或数据热度很⾼，这种情况之下就应该选择⽔平切分，⽔平切分⽐垂直切分要复杂⼀些，它将原本逻辑上属于⼀体的数据进⾏了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项⽬⼈员及应⽤程序产⽣额外的数据管理负担。
⾯对数据递增，解决⽅案通常是分库分表，冷热数据分离
垂直拆分——主要是字段的拆分
⽔平拆分——表结构不变，数据分表
4、分库分表常⽤的原理策略
结合两种原理策略，主要讲解分别使⽤上述原理的两个框架
Mycat
mycat是⼀个中间件代理层，对研发⽆感知
1、⼀个彻底开源的，⾯向企业应⽤开发的⼤数据库集
2、⽀持事务、ACID、可以替代MySQL的加强版数据库
3、⼀个可以视为MySQL集的企业级数据库，⽤来替代昂贵的Oracle集
4、⼀个融合内存缓存技术、NoSQL技术、HDFS⼤数据的新型SQL Server
5、结合传统数据库和新型分布式数据仓库的新⼀代企业级数据库产品
6、⼀个新颖的数据库中间件产品
优点：
1、开发⽆感知
2、增删节点程序不需要重启
3、跨语⾔（java 、php）
缺点：
mysql下载jar包1、性能下降没因为多了⼀层
2、不⽀持跨数据库
MyCat经典实⽤场景
单纯的读写分离，此时配置最为简单，⽀持读写分离，主从切换
分表分库，对于超过1000 万的表进⾏分⽚，最⼤⽀持1000 亿的单表分⽚
多租户应⽤，每个应⽤⼀个库，但应⽤程序只连接Mycat，从⽽不改造程序本⾝，实现多租户化
报表系统，借助于Mycat的分表能⼒，处理⼤规模报表的统计
替代Hbase，分析⼤数据作为海量数据实时查询的⼀种简单有效⽅案，⽐如100 亿条频繁查询的记录需要在3 秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat 可能是最简单有效的选择
mycat的使⽤对研发是⽆感知的，但是运维成本较⼤，涉及到⼀些概念
逻辑库(sehema)，逻辑表(table)，配置分⽚（dataNode），配置物理库分⽚映射（dataHost）
我们需要了解⼀点，集中式的Proxy其实现⾮常复杂，这要从MySQL处理SQL语句的原理说起，因为不是本⽂要论述的重点，因此只是简单的提及⼏点：
1. SQL语句要被Parser解析成抽象语法树
2. SQL要被优化器解析出执⾏计划
3. SQL语句完成解析后，发给存储引擎
只要有解析的过程，其性能损耗就是⽐较可观的，我们也可以认为这是⼀种重量级的解决⽅案。
ShardingJdbc
定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使⽤客户端直连数据库，以jar包形式提供服务，⽆需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。
1、适⽤于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使⽤JDBC。
2、⽀持任何第三⽅的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
3、⽀持任意实现JDBC规范的数据库。⽬前⽀持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92标准的数据库。
优点：
1、性能很好的
2、⽀持跨数据库jdbc
缺点：
1、增加了开发难度
2、不⽀持跨语⾔（java）
ShardingJdbc是ShardingSphere中关于jdbc增强⽅式的⼀种，⽽且ShardingSphere已经孵化为apache顶级项⽬
每⼀个服务都持有⼀个Sharing-JDBC，这个JDBC以Jar包的形式提供，基本上可以认为是⼀个增强版的jdbc驱动，需要⼀些分库分表的配置，业务开发⼈员不需要去对代码进⾏任何的修改。可以很轻松的移植到SpringBoot，ORM等框架上
但是这个结构也不是完美的，每⼀个服务持有⼀个proxy意味着会在MySQL服务端新建⼤量的连接，维持连接会增加MySQL服务器的负载，虽然这种负载提升⼀般⽆法察觉。
shardingjdbc中涉及到基础概念
逻辑表、真实表、数据节点——每张真实表
逻辑表
即⽔平拆分的表的总称。⽐如订单业务会被拆分成t_order0，t_order1两张表，但是他们同属于⼀个逻辑表：t_order
绑定表
分⽚规则⼀直的主表和⼦表。⽐如还是上⾯的t_order表，其分⽚键是order_id，其⼦表t_order_item的分⽚键也是order_id。在规则配置时将两个表配置成绑定关系，就不会在查询时出现笛卡尔积。
⼴播表
有⼀些表是没有分⽚的必要的，⽐如省份信息表，全国也就30多条数据，这种表在每⼀个节点上都是⼀样的，这种表叫做⼴播表。
简单来说
1）mycat是⼀个中间件的第三⽅应⽤，sharding-jdbc是⼀个jar包
2）使⽤mycat时不需要改代码，⽽使⽤sharding-jdbc时需要修改代码
5、关于分表策略通常分为三种
1、取模
2、范围分表-通常是时间
3、城市-有明显业务特征的分表
时间范围策略通常⽤于冷热数据分离，例如美团限查近3个⽉的订单，量体⽐较⼤，⽽且历史数据使⽤相对较少
城市这种分表策略，类似于多租户的概念，业务处理场景⼀样，但是数据独⽴
总结
主要是简单介绍下什么是分库分表，分库分表的实施策略，以及分库分表通⽤原理。研究这些内容，主要是公司业务数据增长速度过快，单表数据过于庞⼤，⽽且如果只做冷热数据分离不够友好，⽽且不能解决⽬前业务的发展问题，打算利⽤分表来实现，⽽且结合⾃⾝业务以及两种框架原理，本着符
合业务场景，可靠度⾼，接⼊成本低，具有良好的⽂档，活跃的社区的原则，打算采⽤shardingJdbc，涉及
到分表策略选择使⽤城市的维度。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。