Sharding JDBC 学习了解 - 总览和概念

第一部分：概述

ShardingSphere是一个由一套分布式数据库中间件解决方案组成的开源生态圈，包括Sharding-JDBC、Sharding-Proxy和Sharding-Proxy 3个独立产品。
它们都提供了数据分片、分布式事务、数据库编排等功能，适用于Java同构、异构语言、云原生等多种场景。
ShardingSphere将自己定义为一个中间件，而不是一种全新的数据库。关系数据库作为众多企业的基石，仍然占据着巨大的市场份额。因此，现阶段我们更愿意关注它的增量，而不是彻底的颠覆。

1.1 Sharding-JDBC

Sharding-JDBC将自己定义为一个轻量级的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) 读写分离； (3) 分片策略定制； (4) 无中心分布式主键。

1.2 Sharding-Proxy

Sharding-Proxy将自己定义为透明的数据库代理，提供封装数据库二进制协议以支持异构语言的数据库服务器。对DBA来说更加友好，现在提供的MySQL版本可以使用任何兼容MySQL协议的终端（例如MySQL Command Client、MySQL Workbench等）来操作数据。

对应用程序完全透明，可以直接像MySQL一样使用。
适用于任何兼容MySQL、PostgreSQL协议的终端。

1.3 Sharding-Sidecar（TODO）

目前（2023年12月22日）还没没有完成。

Sharding-Sidecar（TODO）将自己定义为 Kubernetes 环境的云原生数据库代理，以 sidecar 的形式负责所有对数据库的访问。它提供了一个与数据库交互的网格层，我们称之为Database Mesh。

Database Mesh强调如何将分布式数据库访问应用程序与数据库连接起来。以交互为中心，有效地组织了杂乱的应用程序与数据库之间的交互。使用Database Mesh访问数据库的应用程序和数据库将形成一个大的网格系统，只需将它们相应地放置到正确的位置即可。它们都受网格层的控制。

对比

	Sharding-JDBC	Sharding-Proxy	Sharding-Sidecar
数据库	任何	MySQL	MySQL
连接计数成本	高的	低的	高的
支持的语言	仅限 Java	任何	任何
表现	低损耗	相对较高的损耗	低损耗
去中心化	是的	不	不
静态条目	不	是的	不

特点总结：

Sharding-JDBC采用去中心化架构，适用于Java开发的高性能轻量级OLTP应用；
Sharding-Proxy提供静态入口和全语言支持，适用于OLAP应用和分片数据库管理和操作场景。
ShardingSphere是一个由多个端点共同组成的生态圈。
通过Sharding-JDBC和Sharding-Proxy的混合使用以及同一注册中心统一的分片策略，ShardingSphere可以构建适用于各种场景的应用系统。架构师可以更自由地将系统架构调整为最适合当前业务的架构。

第二部分：快速入门

2.1 Sharding-JDBC

主要包括以下三步：

导入maven依赖
分片规则配置
创建数据源

Step 1 导入maven依赖

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-core</artifactId>
    <version>${latest.release.version}</version>
</dependency>

Step 2 分片规则配置
Sharding-JDBC 可以通过四种方式进行配置：Java、YAML、Spring namespace 和 Spring boot starter。
开发者可以根据不同的情况选择合适的方法。

Step 3 创建数据源
使用ShardingDataSourceFactory和规则配置对象创建ShardingDataSource，ShardingDataSource是由标准JDBC接口DataSource实现的。然后，用户可以使用原生的JDBC或JPA、MyBatis等ORM框架进行开发。

DataSource dataSource = ShardingDataSourceFactory.createDataSource(dataSourceMap, shardingRuleConfig, props);

2.2 Sharding-Proxy

Todo

2.3 Sharding-Scaling(Alpha)

Todo

核心概念和特征

背景

传统的将所有数据存储在一个集中节点的解决方案在性能、可用性和运营成本三个方面已经很难满足海量互联网数据场景的需求。

在性能上，关系型数据库大多采用B+树索引。当数据量超过阈值时，更深的索引会增加磁盘IO访问次数，从而削弱查询性能。同时，高并发请求也使得中心化数据库成为系统的最大限制。
在可用性方面，可以通过无状态服务以相对较低的成本、任意程度的扩容，最终将所有的压力都落在数据库身上。但单一数据节点或者简单的主从结构已经越来越难以承受这些压力。因此，数据库的可用性就成为整个系统的关键。
从运营成本方面来看，当数据库实例中的数据达到阈值以上时，DBA的运营压力也会增加。随着数据量的增加，数据备份和数据恢复的时间成本将更加不可控。一般来说，单库情况下的数据在1TB以内是一个比较合理的范围。

在传统关系数据库无法满足互联网需求的情况下，越来越多的尝试将数据存储在原生分布式NoSQL中。但其与SQL的不兼容以及生态系统的不完善，使其无法在竞争中击败关系数据库，因此关系数据库仍然占据着不可动摇的地位。

分片是指 将一个数据库中的数据按照一定的标准切分到多个表和数据库中，从而提高性能和可用性。 两种方法都可以有效避免由于数据超过可承受阈值而导致的查询限制。更重要的是，数据库分片还可以有效分散TPS。分表虽然不能缓解数据库压力，但可以提供将分布式事务转移到本地事务的可能性，因为一旦涉及到跨库升级，分布式事务有时会变得相当棘手。采用多主从分片方式，可以有效避免数据集中于一个节点，提高架构可用性。

通过分库分表进行数据拆分是应对高TPS、海量数据系统的有效方法，可以使数据量保持在阈值以下，疏散流量。

分片方式可以分为垂直分片和水平分片。

垂直分片

按照业务分片的方式，称为垂直分片，或者说纵向分片，其核心理念是数据库的专用化。在分片之前，数据库由很多表组成，对应不同的业务。但分片后，**表按照业务分到不同的数据库，压力也分到不同的数据库。**下图给出了根据业务需求，通过垂直分片将用户表和订单表分配到不同数据库的解决方案。

垂直分片需要不时调整架构和设计。总体来说还不够快，无法应对互联网业务快速变化的需求，无法真正解决单节点问题。它可以缓解高数据量和并发量带来的问题，但不能完全解决。垂直分片后，如果表中的数据量仍然超过单节点阈值，则应进一步进行水平分片处理。
在这里插入图片描述

水平分片

水平分片也称为横向分片。与垂直分片按照业务逻辑进行分类的方法相比，水平分片通过一定的字段，按照一定的规则将数据分类到多个数据库或表中，每个分片只包含部分数据。

例如，根据主键分片，偶数主键放入0数据库（或表），奇数主键放入1数据库（或表）。

理论上，水平分片克服了单机数据处理量的限制，并且可以相对自由地扩展，因此可以作为分库分表的标准解决方案。

挑战和目标

分片虽然解决了性能、可用性、单节点备份恢复等问题，但其分布式架构在获取利润方面也带来了一些新的问题。

一个问题是，面对如此分散的数据库和表格，应用开发工程师和数据库管理员的操作变得异常费力。他们应该确切地知道要从哪个数据库表获取数据。
另一个挑战是，在单节点数据库中正确运行的SQL在分片数据库中可能并不正确。分片后表名改变，或者分页、order by、聚合group by等操作导致的误操作就是这样的例子。
跨数据库事务也是分布式数据库需要处理的一件棘手的事情。合理使用分表还可以在单表数据量减少时充分利用本地事务。通过明智地使用同一个数据库中的不同表，可以避免分布式事务带来的麻烦。当跨库事务无法避免时，部分业务仍然需要保持事务一致。

互联网巨头并没有大量采用基于XA的分布式事务，因为他们无法保证其在高并发情况下的性能。它们通常用最终一致的软状态替换强一致的事务。

ShardingSphere数据分片模块的主要设计目标是尽量减少分片的影响，让用户像使用一个数据库一样使用水平分片数据库组。