数据分片架构的下一次进化

随着手机和互联网成为人们眼中的日常必需品，网站和商业服务每周接收数十亿次访问的情况已经司空见惯——这还只是一个侧面。

北美的黑色星期五或亚洲的双十一（又名光棍节）等销售日是传统零售企业正在适应数字世界的绝佳案例。这些企业现在必须应对一系列新的需求和挑战，才能成功实现其业务目标。

他们都必须回答同一个问题：我们需要在这个黑色星期五推动我们的数字销售业绩，但是当我们成功实现目标，并且伴随而来的惊人流量到达数据库集群时，我们的数据库能处理好它吗？

涉及到数据库解决方案时，不同的业务用例有多种选项。选择范围从 NoSQL 产品（例如 MongoDB、Cassandra、Amazon DynamoDB 等）到 NewSQL 产品（例如如今流行的 Amazon Aurora 或 CockroachDB）。

除了这些出色的解决方案之外，一些行业还会考虑在现有数据库集群之上进行透明分片。

根据DB-Engines的数据库趋势排名，尽管市面上出现了许多新的数据库产品，但传统的关系型数据库仍然占据了相当大的市场份额。

考虑到数据库面临的众多新挑战，是否有一种经济高效的方式来利用这些类型的数据库，并通过一些新的实用理念来增强它们呢？数据库透明分片是这个问题的最佳答案之一。

DB-Engines 上的数据库流行度排名

这方面最好的技术之一是将数据拆分为单独的行和列。这种将大型数据库表拆分为多个小表的做法称为分片。原始表被分为许多垂直分片或水平分片。为了标记这些表，我们可能对垂直分片用“VS1”，对水平分片用“HS1”，诸如此类。数字代表第一个表或第一个模式（schema）。然后是 2 和 3，以此类推。这些数据子集称为表的原始模式。

那么分片和分区有什么区别呢？分片和分区都包括了将大型数据集分解为一些较小数据集的操作。但一个关键的区别是，分片意味着数据打散后分布在多台计算机上，可以是水平分区或是垂直分区。相比之下，分区是将数据库分解为不同的子集但保存在单个数据库中，有时称为数据库实例。

由于分片数据被分成许多块存储在不同的机器上，这种方法具有以下优点：

• 它让独立的 DBMS 成为分布式系统。

• 扩展数据库系统的存储容量。

• 流量在不同的分片之间平均共享。

• 高可用性。

但分片架构并不完美，还是有一些缺点：

• 复杂的路由/查询拓扑。

• 分布式数据库集群的管理很复杂。

• 查询开销。

• 对原生 SQL 的支持不完全。在原本存在的分布式数据库系统上采用分片架构，可能会导致 SQL 兼容性问题。以前正常运行的 SQL 可能无法在新创建的分片数据库中成功运行。

分片：一个到多个分片

就像技术领域中的大多数事情一样（更不用说生活中的事情了），银弹是不存在的。你应该进行彻底的分析以全面了解你的需求和场景，然后才能走下一步，选择最佳解决方案。

总的来说，分片架构的优势占上风，很多在数据库行业发挥重要作用的优秀产品都是基于这种架构。Citus或Vitess有各自的定义，但它们本质上是基于数据库分片架构的。

Citus 管理一个协调器（代理）集群来分发 PostgreSQL 集群，而 Vitess 则对 MySQL 进行分片。它们都专注于为传统但流行的关系型数据库提供低成本和高效的分布式解决方案。实际上，分片架构也是大多数 NoSQL 和 NewSQL 产品的基础，但这涉及到另一个关注 NoSQL 和 NewSQL 分片的主题。本文重点介绍关系型数据库的分片，因为经典分片技术带来了一些创新。

分片的出现是数据库分布式需求的产物。如今，越来越多的新问题都与数据库相关，例如隐私保护、SQL 审计、租户、分布式身份验证等。

这些问题代表了现实世界对数据库的新需求。如何处理这些问题是所有数据库产品都不可避免的挑战，无论是哪种数据库都一样。这些问题可以通过数据库分片方案来解决吗？看起来分片需要进化来应对这些挑战，这也正是我们的主题，即数据库分片架构的下一个进化方向是什么。

我的答案是Database Plus，它是创建分布式数据库系统的指导概念，并不只是要做分片，位于 DBMS 之上。

它的构想是要在现有和碎片化的数据库之上建立一个标准化的层和生态系统，并提供统一和标准化的数据库使用规范。这为上层应用提供了保障，尽可能减少了业务由于底层数据库碎片化而面临的挑战。它的结果是一个应用程序只需要与标准化服务对话，而不是和每个数据库的不同服务对话的环境。

这个想法是由 Apache ShardingSphere 的 PMC（项目管理委员会）发起的，花了大约一年的时间发布 5.0.0 GA，并在其架构中实现了这个概念。

在 3.x 和 4.x 发布阶段，我们将 Apache ShardingSphere 定义为分布式数据库中间件（分片架构），仅解决分片问题。然而，数据库和社区面临的新挑战推动了这个项目的发展，项目开始包含更多特性，如数据加密、影子数据库、分布式认证、分布式治理等。所有这些变化都超出了传统的分片范围，因为分片只是 Database Plus 的一部分。

ShardingSphere 的 Database Plus 架构演进

Apache ShardingSphere 的示例支持了我的论点，即简单而经典的分片架构可以做的不仅仅是分片。内核机制通过代理或驱动程序引导所有流量，然后如果它可以解析 SQL 并知道每个数据库的位置，那么以下工作将很容易执行：

• 了解用户对数据的期望。

• 劫持流量并对其进行修改。

• 将此修改后的查询重新路由到某个数据库。

• 合并或更改结果的元数据和数据。

• 监控计算节点（Proxies）和存储节点（Databases）的状态。

• 收集这个分布式系统的变化或日常信息。

• 使用机器学习（ML）技术提供个性化推荐。

那么这些工作对最终用户意味着什么呢？基于这些内核工作，Apache ShardingSphere 的产品就能缓解用户的许多数据库痛点。

原始分片、数据加密、影子数据库、分布式认证、分布式治理等都是基于上面这些必要步骤。Apache ShardingSphere 的 Database Plus 概念提出的架构在考虑到灵活性的同时带来了这些增强特性。

所有功能都只是可以在这个分布式系统中的任何给定时间添加或删除的插件。有些人可能只想对数据库进行分片，而另一些人可能更喜欢进行数据加密。用户的需求永远都是多样化的，随时都在变化，因此 Database Plus 可以完全可定制并不断接收新的插件（特性），使其能够具体灵活地满足用户的需求。

架构

ShardingSphere 的架构包括如下四层，如下图 1 所示。

ShardingSphere 的四层架构

基础层：提供驱动或代理等多种接入终端，灵活满足用户不同场景的需求。

存储层：这些数据库支持所有功能，并有可能包含更多功能。

功能层：提供多种满足用户需求的功能插件，插件选择和组合具有高度的灵活性。

解决方案层：为终端用户提供面向行业（如金融、电商、娱乐行业）和面向特定场景的标准产品解决方案（如分布式数据库解决方案、加密数据库解决方案或数据库网关）。

多接入终端混合模式已生产就绪

ShardingSphere JDBC和ShardingSphere Proxy经过了五年的打磨和测试，现已投入生产。许多社区用户提供了很多相关的生产用例，生产可行性得到了验证。

通过在不同 ShardingSphere 客户端之间共享核心功能，用户还可以选择混合部署，在查询性能和管理便利性之间取得平衡（如下图 2 所示）。

ShardingSphere JDBC 和代理混合开发

使用 DistSQL 的标准化集群管理

Apache ShardingSphere 社区提出了一种 SQL 方言，即DistSQL（分布式 SQL）来运维和管理 ShardingSphere 的所有功能。

SQL 是与数据库的标准和常规交互方法。但是这个分布式数据库系统有很多新特性，需要我们想出一种 SQL 方言来配置和使用这些新功能。

DistSQL 允许用户使用类似 SQL 的命令来创建、修改或删除分布式数据库和表，或者加密或解密数据。上述所有功能都可以使用分布式 SQL 执行。下面介绍了一些 DistSQL 片段。

DistSQL 实践示例

分布式治理能力

分布式数据库系统治理能力对于减轻分布式集群管理的痛苦是很必要的。在计算和存储分离的 ShardingSphere 生态中，新版本的特性得到了极大的增强，包括：

• 数据库（即存储节点）和 Proxy/JDBC（即计算节点）的分布式治理，

• 在线用户元数据 DDL 更改，

• 开/关运行存储节点和计算节点，

• 断路器和禁用，以及

• 高可用性。

此外，新的分布式锁特性也计划在近期发布。

ShardingSphere 的分布式治理

部署前通知

尽管上面列出了许多优点，但仍有一些限制或限制值得一提。在采用 ShardingSphere 之前，你应该仔细考虑以下事项：

• 一些复杂的原生 SQL，尤其是加入不同分片的 SQL，不能很好地工作，或者比在 DBMS 中执行的 SQL 需要更长的时间。建议使用面向业务的分片策略来防止这种情况发生，以避免此类复杂 SQL。

• 代理模式会产生网络开销。出于这个原因，我推荐混合适配器部署。

• 分布式事务将显着降低每秒事务数（TPS）或每秒查询数（QPS）。

• 跨分片获得一致的时间点快照不是很容易。

实践案例

本节将介绍两个实际示例来演示如何使用 DistSQL（连接 ShardingSphere 生态系统所有元素的 SQL 方言）创建分布式数据库和创建加密表。

分布式数据库解决方案

这一部分将通过一个示例指导你如何利用 DistSQL 创建分布式数据库。用户和应用程序访问代理（Proxy）实现一个逻辑表（分布式表），该表已经分片到了不同的服务器上。你无需处理这些分片，而是让你的应用程序操作和管理这个逻辑表。

前置条件：

• 部署 MySQL 实例并创建两个 MySQL 数据库

• 部署一个 ShardingSphere 代理

过程：

1. 执行以下 SQL 命令登录代理 CLI：

mysql -h127.0.0.1 -uroot -P3307 -proot

1. 使用 DistSQL 注册两个 MySQL 数据库

ADD RESOURCE ds_0( HOST=127.0.0.1, PORT=3306, DB=demo_ds_0, USER=root, PASSWORD=root );

ADD RESOURCE ds_1 ( HOST=127.0.0.1, PORT=3306, DB=demo_ds_1, USER=root, PASSWORD=root );

1. 使用 DistSQL 创建分片规则

CREATE SHARDING TABLE RULE t_order( RESOURCES(ds_0,ds_1), SHARDING_COLUMN=order_id, TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=4)), GENERATED_KEY(COLUMN=order_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123))) );

1. 按之前的分片规则创建分片表

CREATE TABLE `t_order` ( `order_id` int NOT NULL, `user_id` int NOT NULL, `status` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

1. 显示资源、分库和分表

sql SHOW SCHEMA RESOURCES;

SHOW DATABASES;

SHOW TABLES;

1. 显示分片表

SHOW TABLES;

以下是 MySQL 中的表：

以下是 ShardingSphere Proxy 中的表：

1. 删除分片表

DROP TABLE t_order;

数据加密示例

此示例向你展示如何使用 DistSQL 创建加密表。数据加密特性是 ShardingSphere Proxy，它负责帮助加密和解密数据。应用程序不需要任何编码重构，只需将明文发送到 Proxy，其将明文加密并将密文重新发送到数据库。此外，用户可以配置哪个表中的哪一列应该使用哪种加密算法进行加密。

前置条件：

• 部署 MySQL 实例并创建两个 MySQL 数据库。

• 部署一个 ShardingSphere 代理。

过程：

1. 执行以下命令登录代理 CLI：

mysql -h127.0.0.1 -uroot -P3307 -proot

1. 使用 DistSQL 添加资源。

ADD RESOURCE ds_0 ( HOST=127.0.0.1, PORT=3306, DB=ds_0, USER=root, PASSWORD=root );

1. 创建加密规则

CREATE ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=AES,PROPERTIES('aes-key-value'='123456abc')))));

SHOW ENCRYPT TABLE RULE t_encrypt;

1. 创建加密表

CREATE TABLE `t_encrypt` ( `order_id` int NOT NULL, `user_plain` varchar(45) DEFAULT NULL, `user_cipher` varchar(45) DEFAULT NULL, PRIMARY KEY (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

以下是 MySQL 中的结果：

向该表中插入数据

INSERT INTO `t_encrypt` VALUES(1,"abc");

MySQL 中发生的事情：

1. 更改加密规则

ALTER ENCRYPT RULE t_encrypt ( COLUMNS( (NAME=user_id,PLAIN=user_plain,CIPHER=user_cipher,TYPE(NAME=MD5)) ));

SHOW ENCRYPT RULES;

1. 删除加密规则

DROP ENCRYPT RULE t_encrypt;

位于 DBMS 之上，包含分片、加密和其他附加特性的数据库分布式系统是一种实用且高效的方式，能够以低成本满足用户不断变化的需求。这样的解决方案将消除对不稳定性的担忧，以及采用全新分布式数据库导致的繁重负载。

作为 ShardingSphere PMC（项目管理委员会）成员，我可能会显得有些偏见，但我选择为这个开源项目做出贡献也是事实，因为它具有解决现实世界数据库相关问题和生产场景的巨大创新潜力。

在我的职业生涯中，我曾在世界上互联网普及率最高的社会之一中管理和利用大量数据的公司工作。我很清楚数据高峰所带来的挑战，以及生产需求和现成的数据库解决方案之间的差距。

我并不是说 Database Plus 是解决云时代新挑战的最佳和唯一方法，但我会推荐它作为一种可行的创新解决方案。

最后提一下分片。分片是解决互联网发展带来的众多新挑战的众多方法之一。一些专家可能会说分片数据库架构已经过时，但事实并非如此。

它可能听起来不那么花哨，或者没有其他解决方案的那些闪亮特点，但它肯定是有效和实用的。

最近，它得到了很多重要的创新贡献，这些贡献使分片技术的发展超出了不久前的想象，也许这就是为什么它在寻求实现可扩展性的区块链公司中越来越受欢迎的原因。

作者介绍：

Juan Pan 是 SphereEx 联合创始人兼 CTO，AWS 数据英雄，Apache 会员，Apache ShardingSphere PMC，中国木兰开源社区导师。曾任京东科技高级 DBA，负责京东数科智能数据库平台的设计与开发。她现在专注于分布式数据库和中间件生态系统以及开源社区。她对开源的贡献意义重大。她是 Apache ShardingSphere 的第二贡献者，“2020 中国开源先锋”和“2021 中国 OSCAR 开源先锋”奖项获得者。她经常被邀请数据库和数据库架构领域的相关会议上发言和分享她的见解。

原文链接：

The Next Evolution of the Database Sharding Architecture