分库分表适用场景

分库分表适用场景

http://www.javashuo.com/article/p-xkkfanka-hq.html

数据库分库分表从互联网时代开启至今，一直是热门话题。在NoSQL横行的今天，关系型数据库凭借其稳定、查询灵活、兼容等特性，仍被大多数公司做为首选数据库。所以，合理采用分库分表技术应对海量数据和高并发对数据库的冲击，是各大互联网公司不可避免的问题。

虽然不少公司都致力于开发本身的分库分表中间件，但截止目前，仍无完美的开源解决方案覆盖此领域。

分库分表适用场景 分库分表用于应对当前互联网常见的两个场景——大数据量和高并发。一般分为垂直拆分和水平拆分两种。

垂直拆分是根据业务将一个库（表）拆分为多个库（表）。如：将常常和不常访问的字段拆分至不一样的库或表中。因为与业务关系密切，目前的分库分表产品均使用水平拆分方式。

水平拆分则是根据分片算法将一个库（表）拆分为多个库（表）。如：按照ID的最后一位以3取余，尾数是1的放入第1个库（表），尾数是2的放入第2个库（表）等。

关系型数据库在大于必定数据量的状况下检索性能会急剧降低。在面对互联网海量数据状况时，全部数据都存于一张表，显然会轻易超过数据库表可承受的数据量阀值。这个单表可承受的数据量阀值，需根据数据库和并发量的差别，经过实际测试得到。

单纯的分表虽然能够解决数据量过大致使检索变慢的问题，但没法解决过多并发请求访问同一个库，致使数据库响应变慢的问题。因此一般水平拆分都至少要采用分库的方式，用于一并解决大数据量和高并发的问题。这也是部分开源的分片数据库中间件只支持分库的缘由。

但分表也有不可替代的适用场景。最多见的分表需求是事务问题。同在一个库则不需考虑分布式事务，善于使用同库不一样表可有效避免分布式事务带来的麻烦。目前强一致性的分布式事务因为性能问题，致使使用起来并不必定比不分库分表快。目前采用最终一致性的柔性事务居多。分表的另外一个存在的理由是，过多的数据库实例不利于运维管理。综上所述，最佳实践是合理地配合使用分库+分表。

Sharding-JDBC简介 Sharding-JDBC是当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问。Sharding-JDBC是继dubbox和elastic-job以后，ddframe系列开源的第3个项目。

Sharding-JDBC直接封装JDBC API，能够理解为加强版的JDBC驱动，旧代码迁移成本几乎为零：

可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。 可基于任何第三方的数据库链接池，如DBCP、C3P0、 BoneCP、Druid等。 理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。 Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其余依赖，DBA也无需改变原有的运维方式。

Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。

SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。

与常见开源产品对比 为了对其余开源项目表示尊重，咱们无心评论目前仍在更新中的项目。这里仅列出目前中止更新，但仍然在数据库分片领域很是有影响力的几个项目，请参见表1。

图片描述

表1 数据库分片工具对比 经过以上表格能够看出，Cobar属于中间层方案，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，须要作一次转发，而基于JDBC协议并没有额外转发，直接由应用程序链接数据库，性能上有些许优点。这里并不是说明中间层必定不如客户端直连，除了性能，须要考虑的因素还有不少，中间层更便于实现监控、数据迁移、链接管理等功能。

Cobar-Client、TDDL和Sharding-JDBC均属于客户端直连方案。此方案的优点在于轻便、兼容性、性能以及对DBA影响小。其中Cobar-Client的实现方式基于ORM（Mybatis）框架，其兼容性与扩展性不如基于JDBC协议的后二者。

实现原理 前文已介绍了Sharding-JDBC是实现了JDBC协议的jar文件。基于JDBC协议的实现与基于MySQL等数据库协议实现的中间层略有差异。

不管使用哪一种架构，核心逻辑均极为类似，除了协议实现层不一样（JDBC或数据库协议），都会分为分片规则配置、SQL解析、SQL改写、SQL路由、SQL执行以及结果归并等模块。

Sharding-JDBC的总体架构图参见图1。

图片描述

图1 Sharding-JDBC的总体架构图 分片规则配置 Sharding-JDBC的分片逻辑很是灵活，支持分片策略自定义、复数分片键、多运算符分片等功能。

如：根据用户ID分库，根据订单ID分表这种分库分表结合的分片策略；或根据年分库，月份+用户区域ID分表这样的多片键分片。

Sharding-JDBC除了支持等号运算符进行分片，还支持in/between运算符分片，提供了更增强大的分片功能。

Sharding-JDBC提供了spring命名空间用于简化配置，以及规则引擎用于简化策略编写。因为目前刚开源分片核心逻辑，这两个模块暂未开源，待核心稳定后将会开源其余模块。

JDBC规范重写 Sharding-JDBC对JDBC规范的重写思路是针对DataSource、Connection、Statement、PreparedStatement和ResultSet五个核心接口封装，将多个真实JDBC实现类集合（如：MySQL JDBC实现/DBCP JDBC实现等）归入Sharding-JDBC实现类管理。

Sharding-JDBC尽可能最大化实现JDBC协议，包括addBatch这种在JPA中会使用的批量更新功能。但分片JDBC毕竟与原生JDBC不一样，因此目前仍有未实现的接口，包括Connection游标，存储过程和savePoint相关、ResultSet向前遍历和修改等不太经常使用的功能。此外，为了保证兼容性，并未实现JDBC 4.1及其后发布的接口（如：DBCP 1.x版本不支持JDBC 4.1）。

SQL解析 SQL解析做为分库分表类产品的核心，性能和兼容性是最重要的衡量指标。目前常见的SQL解析器主要有fdb/jsqlparser和Druid。Sharding-JDBC使用Druid做为SQL解析器，经实际测试，Druid解析速度是另外两个解析器的几十倍。

目前Sharding-JDBC支持join、aggregation（包括avg）、order by、 group by、limit、甚至or查询等复杂SQL的解析。目前不支持union、部分子查询、函数内分片等不太应在分片场景中出现的SQL解析。

SQL改写 SQL改写分为两部分，一部分是将分表的逻辑表名称替换为真实表名称。另外一部分是根据SQL解析结果替换一些在分片环境中不正确的功能。这里具两个例子：

第1个例子是avg计算。在分片的环境中，以avg1 +avg2+avg3/3计算平均值并不正确，须要改写为（sum1+sum2+sum3）/（count1+count2+ count3）。这就须要将包含avg的SQL改写为sum和count，而后再结果归并时从新计算平均值。

第2个例子是分页。假设每10条数据为一页，取第2页数据。在分片环境下获取limit 10, 10，归并以后再根据排序条件取出前10条数据是不正确的结果。正确的作法是将分条件改写为limit 0, 20，取出全部前2页数据，再结合排序条件算出正确的数据。能够看到越是靠后的Limit分页效率就会越低，也越浪费内存。有不少方法可避免使用limit进行分页，好比构建记录行记录数和行偏移量的二级索引，或使用上次分页数据结尾ID做为下次查询条件的分页方式。

SQL路由 SQL路由是根据分片规则配置，将SQL定位至真正的数据源。主要分为单表路由、Binding表路由和笛卡尔积路由。

单表路由最为简单，但路由结果不必定落入惟一库（表），由于支持根据between和in这样的操做符进行分片，因此最终结果仍然可能落入多个库（表）。

Binding表可理解为分库分表规则彻底一致的主从表。举例说明：订单表和订单详情表都根据订单ID做为分片键，任意时刻分片逻辑均相同。这样的关联查询和单表查询难度和性能至关。

笛卡尔积查询最为复杂，由于没法根据Binding关系定位分片规则的一致性，因此非Binding表的关联查询须要拆解为笛卡尔积组合执行。查询性能较低，并且数据库链接数较高，需谨慎使用。

SQL执行 路由至真实数据源后，Sharding-JDBC将采用多线程并发执行SQL，并完成对addBatch等批量方法的处理。

结果归并 结果归并包括4类：普通遍历类、排序类、聚合类和分组类。每种类型都会先根据分页结果跳过不须要的数据。

普通遍历类最为简单，只需按顺序遍历ResultSet的集合便可。

排序类结果将结果先排序再输出，由于各分片结果均按照各自条件完成排序，因此采用归并排序算法整合最终结果。

聚合类分为3种类型，比较型、累加型和平均值型。比较型包括max和min，只返回最大（小）结果。累加型包括sum和count，须要将结果累加后返回。平均值则是经过SQL改写的sum和count计算，相关内容已在SQL改写涵盖，再也不赘述。

分组类最为复杂，须要将全部的ResultSet结果放入内存，使用map-reduce算法分组，最后根据排序和聚合条件作相关处理。最消耗内存，最损失性能的部分便是此，能够考虑使用limit合理的限制分组数据大小。

结果归并部分目前并未采用管道解析的方式，以后会针对这里作更多改进。

性能 路由结果在单库单表的性能测试报告：

查询操做：Sharding-JDBC的TPS为JDBC的TPS的99.8%； 插入操做：Sharding-JDBC的TPS为JDBC的TPS的90.2%； 更新操做：Sharding-JDBC的TPS为JDBC的TPS的93.1%； 能够看到，Sharding-JDBC性能损失很是低。

路由结果在多库多表的性能测试报告：

查询操做：TPS双库比单库能够增长大约94%的性能； 插入操做：TPS双库比单库能够增长大约60%的性能； 更新操做：TPS双库比单库能够增长大约89%的性能； 结果代表，Sharding-JDBC可有效利用多线程与分布式资源大幅度提高性能； 更多详细状况可查看Sharding-JDBC的性能测试报告。

Roadmap 目前Sharding-JDBC集中于分库分表核心逻辑开发，在功能稳定以后将会按照以下线路持续更新：

读写分离； 柔性分布式事务； 分布式主键生成策略； SQL重写优化，进一步提高性能； SQL Hint，可指定某SQL在某具体库表执行，基于业务规则而非SQL解析路由； 小表广播； HA相关； 流量控制； 数据库建表工具； 数据迁移； 复杂SQL解析支持，如子查询、存储过程等； Oracle， SQLServer支持； 配置中心； 开源理念 目前国内不少开源产品都在公司内部经受过期间的考验，而后剥离业务逻辑和敏感代码，再开源贡献给社区。这样作的优势是开源的产品相对成熟。但缺点也不可避免，主要有：

后续支持匮乏。产品已经知足了该公司的业务场景需求，缺少后续提高的动力。文档、支持也会相对较少，甚至出现文档和代码不一样步的情况。 与该公司业务场景耦合较为严重。大部分框架产品都是为了解决特定的问题。好比：有的公司可能并不须要分表；有的公司只需支持几种分片策略就好。 开源不完整。和公司业务耦合紧密的部分不会开源。 缺少粘度。较为成型的项目因为功能繁多、代码结构复杂，社区志愿者难于扩展或修改核心逻辑。若是测试覆盖率不够，难以保证修改后的代码质量。以上一系列问题会致使项目对社区的粘度不高，难于找寻可合做开发的志愿者。 分支众多难于维护。因为开源以后公司缺少持续提高的动力，和本公司关系不大的需求功能得不到重视，致使各公司都开发本身的分支。开源项目虽然一开始给社区注入了新鲜思想，但最终并无吸收社区精华。如：Dubbo一出现即引发了至关多的关注，而各公司都有本身的版本，如当当的DubboX，但最终Dubbo并未能持续发展。 咱们考虑全新的开源策略，在Sharding-JDBC刚完成第一版的时候，即向社区和当当内部同时推广。这样作的好处有：

后续支持完善。Sharding-JDBC与当当内部落地绑定，将会在当当内部和社区同时提供支持。虽然没法提供社区需求的优先级高于当当内部的承诺，但咱们会综合考虑社区与内部的需求，以更高的视角，尽可能整合与优化升级路线。 完整开源。代码的snapshot版本都会首先出如今GitHub上。 共同发展。Sharding-JDBC目前代码较为简单。使社区开源爱好者能更加轻松地理解代码核心，为之后的持续发展奠基基础。而且Sharding-JDBC也会吸纳社区精华，让更多地爱好者参与代码贡献。 最后须要澄清，未经时间考证的Sharding-JDBC并不是Bug成堆，彻底不可用的项目。目前测试覆盖率超过90%，详细功能以及不支持项都明确地罗列在GitHub的文档中，但愿让使用者心中有数。