分库分表——基本概念以及shardingJdbc和Mycat对比

1、什么是分库分表

• 就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。

2、为什么分库分表

• 数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

3、分库分表的实施策略

• 分库分表有垂直切分和水平切分两种。

• 垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB等，分别用于存储项目数据定义表、商品定义表、用户数据表等。

• 水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，然后将这些表按照一定的规则存储到多个userDB上。

• 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
  如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
  而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

• 面对数据递增，解决方案通常是分库分表，冷热数据分离

• 垂直拆分——主要是字段的拆分

• 水平拆分——表结构不变，数据分表

4、分库分表常用的原理策略

• 结合两种原理策略，主要讲解分别使用上述原理的两个中间件

4.1 Mycat

概括

• mycat是一个中间件代理层，对研发无感知
• 官网 http://www.mycat.io

基础介绍

1. 一个彻底开源的，面向企业应用开发的大数据库集群

2. 支持事务、ACID、可以替代MySQL的加强版数据库

3. 一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群

4. 一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server

5. 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品

6. 一个新颖的数据库中间件产品

优点

• 1、开发无感知
• 2、增删节点程序不需要重启
• 3、跨语言（java 、php）

缺点

• 1、性能下降没因为多了一层
• 2、不支持跨数据库

MyCat经典实用场景

• 单纯的读写分离，此时配置最为简单，支持读写分离，主从切换

• 分表分库，对于超过1000 万的表进行分片，最大支持1000 亿的单表分片

• 多租户应用，每个应用一个库，但应用程序只连接Mycat，从而不改造程序本身，实现多租户化

• 报表系统，借助于Mycat的分表能力，处理大规模报表的统计

• 替代Hbase，分析大数据作为海量数据实时查询的一种简单有效方案，比如100 亿条频繁查询的记录需要在3 秒内查询出来结果，
  除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat 可能是最简单有效的选择

Mycat结构

• mycat的使用对研发是无感知的，但是运维成本较大，涉及到一些概念
• 逻辑库(sehema)，逻辑表(table)，配置分片（dataNode），配置物理库分片映射（dataHost）

我们需要了解一点，集中式的Proxy其实现非常复杂，这要从MySQL处理SQL语句的原理说起，因为不是本文要论述的重点，因此只是简单的提及几点：

• SQL语句要被Parser解析成抽象语法树

• SQL要被优化器解析出执行计划

• SQL语句完成解析后，发给存储引擎

只要有解析的过程，其性能损耗就是比较可观的，我们也可以认为这是一种重量级的解决方案。

4.2 ShardingJdbc

ShardingJdbc概括

• 官网 http://shardingsphere.apache.org/index_zh.html

• 定位为轻量级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结构

shardingjdbc中涉及到基础概念

逻辑表、真实表、数据节点——每张真实表

1. 逻辑表
   即水平拆分的表的总称。比如订单业务会被拆分成t_order0，t_order1两张表，但是他们同属于一个逻辑表：t_order

2. 绑定表
   分片规则一直的主表和子表。比如还是上面的t_order表，其分片键是order_id，其子表t_order_item的分片键也是order_id。在规则配置时将两个表配置成绑定关系，就不会在查询时出现笛卡尔积。

3. 广播表
   有一些表是没有分片的必要的，比如省份信息表，全国也就30多条数据，这种表在每一个节点上都是一样的，这种表叫做广播表。

5、关于分表策略通常分为三种

1. 取模

2. 范围分表-通常是时间

3. 城市-有明显业务特征的分表

时间范围策略通常用于冷热数据分离，例如美团限查近3个月的订单，量体比较大，而且历史数据使用相对较少

城市这种分表策略，类似于多租户的概念，业务处理场景一样，但是数据独立

6、总结

本文主要是简单介绍下什么是分库分表，分库分表的实施策略，以及分库分表通用原理。研究这些内容，主要是公司业务数据增长速度过快，单表数据过于庞大，而且如果只做冷热数据分离不够友好，而且不能解决目前业务的发展问题，打算利用分表来实现，而且结合自身业务以及两种框架原理，本着符合业务场景，可靠度高，接入成本低，具有良好的文档，活跃的社区的原则，打算采用shardingJdbc，涉及到分表策略选择使用城市的维度。