分库分表技术选型

1、为什么分库分表

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

2、分库分表的实施策略

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

• 垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。
• 水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库上。

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

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

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

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

3、分库分表中间件

Mycat

官网 http://www.mycat.io

mycat是一个中间件代理层，对研发无感知

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

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

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

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

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

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

优点：
1、开发无感知
2、增删节点程序不需要重启
3、跨语言
缺点：
1、性能下降没因为多了一层
2、对于复杂的sql支持不是很好

MyCat经典实用场景

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

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

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

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

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

mycat的使用对研发是无感知的，但是运维成本较大，涉及到一些概念

逻辑库(sehema)，逻辑表(table)，配置分片（dataNode），配置物理库分片映射（dataHost）

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

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

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

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

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

Sharding-Jdbc

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

定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

• 适用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。

• 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。

• 支持任意实现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服务器的负载，虽然这种负载提升一般无法察觉。

sharding-jdbc中涉及到基础概念

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

逻辑表

即水平拆分的表的总称。比如订单业务会被拆分成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时需要修改代码

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

• 取模

• 范围分表-通常是时间

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

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

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