分库分表和sharding-jdbc

分库分表

关系型数据库在大于一定数据量的情况下性能会急剧下降。在面对互联网海量数据的情况时,所有数据都存于一张表,显然很容易会达到数据表可承受的数据量阈值。
单纯分表虽然可以解决数据量过大导致检索变慢的问题,但无法解决高并发情况下访问同一个库,导致数据库响应变慢的问题。所以通常水平拆分都至少要采用分库的方式,以一并解决大数据量和高并发的问题。

但分表也有不可替代的场景。最常见的分表需求是事务问题。同一个库则不需要考虑分布式事务问题,善于使用同库不同表可有效的避免分布式事务（跨库事物）带来的麻烦。目前,强一致性的分布式事务由于性能问题,导致使用起来性能并不一定会比不分库而分表快,因此采用最终一致性的分布式事务居多。

简单介绍

Sharding-JDBC是当当开源的数据库水平切分的中间件，其代表了客户端类的分库分表技术框架（这一点与MyCat不同，MyCat本质上是一种数据库代理）。Sharding-JDBC定位为轻量级数据库驱动，由客户端直连数据库，以jar包形式提供服务，未使用中间层应用转发，无需额外部署，无其他依赖，业务系统开发人员与数据库运维人员无需改变原有的开发与运维方式。因此Sharding-JDBC即为增强版的JDBC驱动，可以实现旧代码迁移零成本的目标。 目前社区较为活跃。目前已广泛应用于现各大互联网公司。通过社区得知，Sharding-JDBC的作者已去京东做全职的Sharding-JDBC开发，相信未来Sharding-JDBC社区的发展将会更好。

• 分库分表
• 读写分离
• 分布式主键
• 柔性事务(也就是“基本可用，最终一致。”的BASE原理)
• 分布式治理能力（2.0新功能），具体包括：
  • 配置集中化与动态化，可支持数据源、表与分片策略的动态切换
  • 客户端的数据库治理，数据源失效自动切换
  • 基于Open Tracing协议（分布式追踪规范，比如说zipkin就是这种规范的一种实现）的APM（应用性能管理）信息输出

sharding-jdbc目前提供4种分片算法。

由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

• 精确分片算法
  对应PreciseShardingAlgorithm，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。

• 范围分片算法
  对应RangeShardingAlgorithm，用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。需要配合StandardShardingStrategy使用。

• 复合分片算法
  对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，多分片键逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。

• Hint分片算法（Hint分片指的是对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录ID分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。）

对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。

具体使用