纯干货：深度认识Sharding-JDBC！做最轻量级的数据库中间层

| 摘要: Sharding-JDBC 采用在 JDBC 协议层扩展分库分表，是一个以 jar 形式提供服务的轻量级组件，其核心思路是小而美地完成最核心的事情。

基于关系型数据库的水平扩展方案有很多开源的解决方案，但成熟稳定的产品凤毛麟角。当当自研的数据库中间层 Sharding-JDBC 在公司内部已广泛使用，并在开源社区推广且初见成果。目前的 Sharding-JDBC 已经历从初出茅庐到稳定运行，再到变革的关键点。

Sharding-JDBC 采用在 JDBC 协议层扩展分库分表，是一个以 jar 形式提供服务的轻量级组件，其核心思路是小而美地完成最核心的事情。

本文整理了此次高手问答中一些精彩的问答。

对于这样一个项目，想必大家都会关心它的开发初衷和适用场景等相关问题。下面先来看看张亮老师对于这些问题的解答。

Q：Sharding-JDBC 的设计初衷是什么？旨在解决什么场景的问题？

Sharding-JDBC 的设计初衷是想提供一个数据库中间层，用于透明的处理分库分表，而无需业务开发人员在业务代码中根据分片键生成 SQL。

第一版的分库分表并不是现有的 Sharding-JDBC，而是当当的一个内部框架 ddframe 的数据库模块，dd-rdb 的其中一项功能就是分库，没有分表功能，当时只是做了简单的 SQL 解析。后来随着 ddframe 被各个团队采用，只分库的需求渐渐不够用了，而 dd-rdb 里面有大量的数据库 ORM 相关的东西，为了使分库分表这一核心需求更加纯粹，我们才将其中的分片的部分单独提炼出来并命名为 Sharding-JDBC，用于在 Java 的 JDBC 层面提供一层驱动，无缝的处理这方面的需求。

Q：Sharding-JDBC 适用于哪些场景，不适用于哪些场景？是否有性能评估？

对于关系型数据库数据量很大的情况，需要进行水平拆库和拆表，这种场景很适合使用 Sharding-JDBC。

举例说明：假设有一亿数据的用户库，放在 MySQL 数据库里查询性能会比较低，而采用水平拆库，将其分为 10 个库，根据用户的 ID 模 10，这样数据就能比较平均的分在 10 个库中，每个库只有 1000w 记录，查询性能会大大提升。分片策略类型非常多，大致分为 Hash + Mod、Range、Tag 等。

Sharding-JDBC 还提供了读写分离的能力，用于减轻写库的压力。

此外，Sharding-JDBC 可以用在 JPA 场景中，如 JPA、Hibernate、Mybatis，Spring JDBC Template 等任何 Java 的 ORM 框架。

Java 的 ORM 框架也都是采用 JDBC 与数据库交互。这也是我们选择在 JDBC 层，而非选择一个 ORM 框架进行开发的原因。我们希望 Sharding-JDBC 可以尽量的兼容所有的 Java 数据库访问层，并且无缝的接入业务应用。

不合适的场景主要是两方面：

1. 不适合 OLAP 的场景。虽然 Sharding-JDBC 也能做聚合分组查询，但大量的 OLAP 场景，仍然会比较慢，而且复杂的 SQL（如子查询等）目前还没有支持。这种查询不太适合大数据和高并发的互联网 online 数据库，建议使用合理的 OLTP 查询。
2. 不适合事务强一致的要求。目前 Sharding-JDBC 的事务支持两种，一种是弱 XA，另一种是柔性事务（BASE）。因为 XA 的两阶段或三阶段提交其性能较低，因此互联网公司基本不会采用。而无论是弱 XA 还是柔性事务，都无法保证事务在任意时间段完全保证一致，其中柔性事务能保证数据的最终一致性，但达到最终一致性的时间仍然不可控。因此对于对跨库事务强一致要求很高的场景，需要从设计方面去考虑数据库 schema 的合理性。

对于 JTA 事务，目前 Shariding-JDBC 没有实现 JTA 的标准。而且由于在互联网场景下使用 JTA 比较少见，因此暂时不支持 JIA 事务。

在 osgit 上有性能测试文档。单库的场景下，由于需要进行 SQL 解析以及路由，器性能损失是 0.02%。双库的场景下，采用了分布式的方式存取数据，性能提升越 94%。

那么对于同类的项目，老师又是如何看待的呢？

Q：Sharding-JDBC 和其他同类产品有什么区别？能不能集成到 SparkSQL 或者 Hive？

目前和 Sharding-JDBC 这种基于 JDBC 层架构类似的，据我所知只有 TDDL，而 TDDL 并未将分库分表这块开源。基于 JDBC 层进行分片的好处是轻量、简单、兼容性好以及无需额外的运维工作。缺点是无法跨语言，目前仅支持 Java。

现在暂时未考虑集成 SparkSQL 或者 Hive。因为 Sharding-JDBC 的定位还是关系型数据库中间层，为了稳定性的考虑，不会改变数据库的存储引擎。未来我们会做基于 Proxy 版本的 Sharding-JDBC-Server，会渐渐的考虑将 Spark 等大数据的查询方式引入进来。

Qÿ