喊话架构师，为什么你需要关注 Database Plus

背景

一直以来, 大一统还是碎片化, 是数据库发展趋势的两种最主流预测。随着数字化进程的推进, 单一场景无法满足应用多样化的需求, 数据库碎片化已呈不可逆的趋势。在当前, 市场占有率最高的商用数据库 --Oracle 并没有明显短板的情况下, 各种全新的数据库依旧如雨后春笋般层出不穷。如今,DB-Engines 上已有超过 300 余种数据库参与排名。

应用场景的不断扩张, 加速了数据库碎片化的进程, 数据库的架构、协议、功能、适用场景也愈加多样化。在数据库架构方面, 基于单机系统演进而来的集中式数据库与原生面向分布式的新一代数据库并存; 在数据库协议方面,MySQL 和 PosrtgreSQL 这两大主要开源生态以及周边厂商所提供的服务生态也在全球数据库体系中各自占有一席之地; 每种数据库的独特功能和适用场景, 也在相关的领域大放异彩。

在企业的应用现状中, 数据库的多元并存已是常态。在互联网行业中, 以 MySQL + 数据分片中间件作为核心业务存储的架构模式为主, 以 GreenPlum、HBase、Elasticsearch、Clickhouse 等其他大数据生态作为分析型数据的计算引擎为辅助。与此同时, 一些遗留系统 (如: 通过.NET 转型时遗留的 SQLServer、或通过外采而遗留的 Oracle) 的数据库仍在运行; 在金融行业中, 核心交易系统仍然大量使用 Oracle 或 DB2, 新业务向 MySQL 或 PostgreSQL 迁移, 部分业务则逐渐尝试使用自主研发的数据库。除了交易型数据库, 分析型数据库的种类则更加繁多。

因此, 碎片化是数据库领域的大势所趋, 单一品类的数据库无法适用于所有场景, 只能适用于某一种或某几种擅长的场景。

数据库碎片化带来的问题

随着企业采用的数据库种类不断增加, 各种问题和痛点也随之出现。

1.架构选型困难

当应用架构为了适应更加灵活多变的业务需求, 将架构设计从单体式向服务化再到微服务进行转化之后, 用于存储业务核心数据的数据库则成为分布式系统的下一个焦点。

相对比无状态的应用, 具有状态的数据库的设计难度则有过之而无不及。分而治之是分布式系统的最佳实践, 显然, 数据库体系也不能简单的用单一产品以及一体化集群来响应所有的服务请求。

首先, 单一品类的数据库无法满足业务应用的全部需求, 在高吞吐量、低延时、分布式无感知、强一致性、运维友好度甚至稳定性等方面难以做到面面俱到。一个应用需要多种数据库共存的可能性尚且不高, 但多个应用混用多种数据库的可能性则大大提升。

其次, 无论是单机数据库, 还是 All in One 的分布式数据库集群, 都难以成为众多微服务应用后端的唯一存储支撑。单机数据库无法承载越来越大的数据量和访问量, 所以越来越多的应用选择采用分布式解决方案。然而, 多应用使用统一的数据库集群, 在 CPU、内存、磁盘、网络等方面的负载无法做到完全隔离。一个应用的超额资源使用, 可能会导致众多毫不相干的应用服务质量下降。

如今, 大部分分布式数据库的搭建成本相当高, 在计算节点、存储节点和治理节点都需要备份和冗余的独立服务器。如果要为每一个微服务都搭建一套独立的分布式数据库, 一定会造成非必要的资源消耗, 最终导致企业无法承受。

最后, 大量企业采用单元化架构。基于数据分片的解决方案, 将数据库的拆分和单元化一并放到应用端解决。随着数据库数量的增多, 架构设计的复杂度会呈指数级增长。长此以往, 业务开发团队将无法把精力集中在最擅长的业务研发层面, 反而需要花费大量精力投入到基础组件的维护。尽管 Apache ShardingSphere 的数据分片功能可以较好解决相关问题, 但面对更多元的数据库, 仅支持单一品类数据库的水平分片能力是远远不够的。

2.技术挑战众多

当碎片化数据库共存成为常态时, 研发人员的学习与开发成本将不可避免的持续增长。尽管数据库大多支持 SQL 的操作方式, 但各数据库间仍有大量 SQL 方言的差异。除此之外, 各数据库间驱动程序的使用方式也或多或少存在不同。

因此如需精细化使用每一种数据库, 必定会占用研发工程师大量的精力, 且沉淀下来的知识和经验不易传承; 如果采用粗粒度的标准模式统一使用异构数据库, 将会湮没数据库自身的特点, 而无法发挥其应有的作用。

3.运维复杂度高

掌握各种数据库特征, 并结合实际场景制定行之有效的运维规范, 需要大量时间和实践经验的积累。除了最基本的运维工作, 数据库周边配套工具的差异性也非常大。通过周边配套工具所组成的监控、备份及其他自动化运维等工作, 随着数据库种类的增加将会产生巨大的运维成本。

4.数据库间缺乏协作和统管能力

站在数据库的角度, 其首要目标是完善自身的能力, 而非面向其他数据库的在线协作能力。跨越异构数据库的关联查询、分布式事务等功能, 是无法在数据库本身实现的。

与相对标准的 SQL 不同, 数据库自身的协议和周边生态工具缺乏统一的标准。对异构数据库的统一管控能力也受到越来越多的关注。但遗憾的是, 数据库上层标准的缺失, 使得数据库间的协作和统管能力难以取得有效的推进。

Database Plus 是什么?

Database Plus 是一种分布式数据库系统的设计理念。旨在碎片化的异构数据库上层构建生态, 在最大限度复用数据库原生存算能力的前提下, 进一步提供面向全局的扩展和叠加计算能力。使应用与数据库间的交互面向 Database Plus 构建的标准, 从而屏蔽数据库碎片化对上层业务带来的差异化影响。

『连接、增强、可插拔』是定义 Database Plus 核心价值的三个关键词。

1.连接: 打造数据库上层标准

相对于提供一个全新的标准,Database Plus 更倾向于提供一个可以适配于各种数据库 SQL 方言和访问协议的中间层, 提供开放的接口用于对接各种数据库。

由于数据库访问协议的实现,Database Plus 和数据库在使用体验上并无二致, 可以支持任意的开发语言和数据库访问客户端。

除此之外,Database Plus 能够最大限度支持 SQL 方言间的相互转换。可以将 SQL 解析而成的 AST (抽象语法树) 根据其他数据库方言的规则重新生成 SQL。SQL 方言转换的能力, 打通了连接异构数据库之间相互访问的通道, 用户可以使用任意一种 SQL 方言访问异构的底层数据库。

『数据库网关』是对连接的最佳诠释。在数据库上层打造开放对接的通用层, 将碎片化数据库的全部访问流量汇集于此, 是 Database Plus 为数据库碎片化提供解决方案的前提条件。

2.增强: 数据库计算增强引擎

数据库经历了数十年的发展, 其自身具备了查询优化器、事务引擎、存储引擎等久经考验的存算能力和设计模型。在 IT 领域, 数据库的设计和使用方式已深入人心, 不可动摇。随着分布式和云原生时代的到来, 将数据库原有的计算和存储能力全部打散, 并织入分布式和云原生级别的全新能力, 会不可避免的重复造轮子。

因此,Database Plus 采用了既重视传统数据库的实践经验, 又适配于新一代分布式数据库的设计理念。无论是集中式还是分布式的数据库,Database Plus 都能复用数据库的存储和原生计算能力, 并在其基础之上提供全局化的能力增强。

全局化的能力增强主要在分布式、数据控制和流量控制三个方面。

无论是原生面向分布式的数据库, 还是基于集中式数据库作为基石的分布式扩展方案, 都离不开分而治之这个分布式系统永恒不变的设计原理。数据分片、弹性伸缩、高可用、读写分离、分布式事务、以及基于垂直拆分的异构数据库联邦查询等功能, 都是 Database Plus 在分布式的异构数据库全局层面下所能够提供的能力。它的关注点不在于数据库自身, 而是站在碎片化的数据库上层, 关注于多个数据库之间的全局协作能力。

除了分布式增强之外, 数据控制和流量控制的增强能力均处于竖井化范畴。面向数据控制的增量能力包括: 数据加密、数据脱敏、数据水印、数据溯源、SQL 审计等; 面向流量控制的增量能力包括: 影子库、灰度发布、SQL 防火墙、黑白名单、熔断限流等。这些均属于数据库生态层所提供的能力, 然而在数据库碎片化的态势下, 为每一种数据库提供全量的增强能力的工作量十分巨大, 且缺失统一的实现标准。Database Plus 通过提供支点, 将支持的数据库种类和增强功能相叠加, 以排列组合的方式提供给用户使用。

3.可插拔: 构建数据库功能生态

不断增加的数据库类型对接和增强功能织入, 会使 Database Plus 通用层逐渐趋于臃肿。连接和增强的可插拔化, 既是 Database Plus 通用层维持小而美的基石, 也是扩展生态无限化的有效保障。可插拔的体系, 为 Database Plus 通用层提供了插件生态无限扩张的可能, 使用者只需根据自身需求裁减插件即可。

通过可插拔体系,Database Plus 将能够真正的构建面向数据库的功能生态, 将异构数据库的全局能力统一纳管。它不仅面向集中式数据库的分布式化, 也同时面向分布式数据库的竖井功能一体化。

微内核设计和可插拔架构是 Database Plus 理念的核心价值, 它面向通用的平台层, 而非某项具体功能。

ShardingSphere 在 Database Plus 方向的探索

Apache ShardingSphere 项目历史悠久, 从开源伊始的数据库分片中间件, 到如今 Database Plus 理念的奠基者和实践者, 它的前进步伐从未放缓。目前,Apache ShardingSphere 遵循 Database Plus 理念, 已完成了 Database Plus 三大核心价值下的大部分基础设施建设。

1.连接层

ShardingSphere 已支持 MySQL、PostgreSQL、openGauss 等数据库协议, 以及 MySQL、PostgreSQL、openGauss、SQL Server、Oracle 和所有支持 SQL92 标准的 SQL 方言。

连接层抽象的顶层接口可供其他数据库开放对接, 包括: 数据库协议、SQL 解析和数据库访问等。

2.增强层

ShardingSphere 的功能增强划分为内核层和可选功能层。

内核层包含查询优化器、分布式事务、执行引擎、权限引擎等与数据库内核强相关的功能, 以及调度引擎、分布式治理等与分布式强相关的功能。内核功能的每个模块都必须存在, 但可以切换至不同的实现类型。以查询优化器为例, 如果待执行 SQL 可以完美下推至后端数据库, 则采用基于原始 SQL 与数据库交互的计算下推引擎; 如果待执行 SQL 需要跨越多数据源进行关联查询, 则采用基于查询计划树与数据库交互的联邦查询引擎。

可选功能层的功能模块由开源社区沉淀而形成。除了最具代表性的数据分片和读写分离之外, 高可用、弹性伸缩、数据加密、影子库等功能模块, 都在逐步的完善之中。

3.可插拔层

从最初的 MySQL + 数据分片为核心的架构模型, 到如今的微内核 + 可插拔架构, 项目进行了彻底的改造。从提供连接的数据库种类和增强功能到内核能力,ShardingSphere 全部面向可插拔。

ShardingSphere 的架构核心外围, 由微内核、可插拔接口、插件实现这三层模型组成, 层次之间单项依赖, 微内核对插件功能完全无需感知, 插件之间也无需相互依赖。对于一个拥有 200 + 模块的大型项目来说, 架构的解耦和隔离, 是社区开放协作、将错误影响范围降低至最小的有效保障。

小结

Database Plus 是 ShardingSphere 的理论支撑,ShardingSphere 是 Database Plus 理念的最佳实践。随着 ShardingSphere 的越来越成熟,Database Plus 的拼图也会越来越丰满。

Database Plus 带来的优势

Database Plus 带来众多的优势, 受限于篇幅, 无法在文中一一列举。下面仅从影响系统架构设计和技术选型方面进行阐述。

1.精细化适配灵活多变的应用场景

用户可以根据自身需求定制化使用相应功能, 数据分片不再是使用 ShardingSphere 的必要条件, 独立使用数据加密功能的用户已不在少数。ShardingSphere 的可插拔能力不仅限于数据库接入层和功能增强模块本身, 每个功能模块的内部也能够基于可插拔架构灵活配置。

以数据分片为例, 作为数据分片模块的可插拔部分, 分片算法可以由用户自定义配置, 无论是标准的哈希、范围、时间等分片算法, 还是自定义分片算法, 使用者都可以根据业务场景需要自由灵活配置, 最大限度切合业务场景。

2.面向架构师的微服务后端支撑能力

Apache ShardingSphere 是微服务后端的数据库单元化最佳方案。正如前文所述, 不同的微服务共享一套分布式数据库集群, 无论从架构设计的不对称性, 还是资源隔离的不可控性, 都不能称之为完善和优雅的解决方案。为每一组微服务搭建一套分布式数据库集群, 则又会造成非必要的资源浪费。

相对于重量级的分布式数据库集群,ShardingSphere-Proxy 所占用的资源节省很多, 为每个微服务集群独享一套数据库集群奠定良好基础。但如果微服务拆分足够精细, 为每一组微服务搭建一套 ShardingSphere-Proxy 的额外资源占用依旧不可小觑。在这种情况下, 可以考虑使用占用资源更少的 ShardingSphere-JDBC, 它作为类库与应用代码部署在一起, 无需额外占用资源。

ShardingSphere-Proxy 和 ShardingSphere-JDBC 不仅可以通过混合使用的方式, 来满足用户的使用友好度、跨语言适配、高性能、资源节省等各方面需求; 还可以通过 Traffic Rule 让 ShardingSphere-Proxy 和 ShardingSphere-JDBC 在不同特征的 SQL 请求中相互路由, 以最小化应用资源占用所带来的影响。

Traffic Rule 可以根据用户自定义的 SQL 特征 (如: 聚合计算、无分片键的全路由查询等), 将占用更多计算资源的请求发送至独占资源的 ShardingSphere-Proxy, 而将交易型的轻量级操作保留在微服务应用端。这与边缘计算的理念不谋而合,ShardingSphere-JDBC 在微服务应用端的算力和边缘计算节点有异曲同工之妙。用于中心计算的 ShardingSphere-Proxy 可以根据业务自身需要, 部署独立的集群服务于多组微服务。

通过灵活使用 ShardingSphere-Proxy、ShardingSphere-JDBC 和 Traffic Rule, 这套组合将能够不断激发着架构师的设计灵感和创造力。开句玩笑, 正确使用 ShardingSphere 进行优雅的系统设计, 可以被当作优秀架构师的准入线。

3.DistSQL 为 DBA 带来数据库原生操作体验

面对数据分片、数据加密等增强功能,Apache ShardingSphere 之前版本主要采用 YAML 的方式进行配置。对于开发工程师来说, 灵活的 YAML 配置使用起来得心应手, 但对于 DBA 而言,YAML 的配置方式确存在诸多不便。除了改变了 DBA 的日常 SQL 操作习惯之外, 无法对接诸如权限、安全、工单、监控、审计等第三方系统, 也让此前的 ShardingSphere 难以适用于生产环境的运维管控。

全新版本的 Apache ShardingSphere 增加了 DistSQL 的操作方式。使用者可以完全通过 SQL 在任意的数据库终端 (如：MySQL Cli、Navicat 等) 操作增强功能。数据分片、数据加密、读写分离等所有的强功能都拥有与之相匹配的 DistSQL, 使用 DBA 所熟悉的 CREATE / ALTER / DROP / SHOW 等 SQL 语法即可完成全部功能的配置。DistSQL 同样支持授权语句的管控, 也可以通过对接 SQL 审计平台记录所有使用者的操作记录。

数据库表结构是 Database 的元数据, 增强功能配置是 Database Plus 的元数据。DistSQL 的出现, 不仅提升了用户友好度, 也补全了 Apache ShardingSphere 上线和运维的最终拼图。

4.Proxyless 模式提升性能至极致

在 Service Mesh 领域, 最为经典就是 Istio + Envoy 架构搭配模式。它通过 Sidecar 的部署方式管理 Envoy, 做到对应用的无侵入, 称之为 Proxy Service Mesh, 降低了开发、使用和升级的成本, 但由于在访问链路中增加了 Proxy / Sidecar 这一层, 使得性能有所下降。

而 Proxyless Service Mesh 则采用另一种设计模式, 它始于 gRPC 对 xDS 协议的实现,Istio 新版本通过 gRPC + xDS 的方式, 允许应用代码直接通过 Istio Agent 提供的 SDK 编程, 有效提升了通信性能。

在分布式数据库领域, 存算分离的架构设计模式已经深入人心。计算节点和存储节点分离的设计, 与 Proxy Service Mesh 的架构模型有些类似。ShardingSphere-Proxy 的设计完全契合了存算分离的架构模型, 它有效降低了用户的开发、使用和升级成本, 却不可避免带来了一定的性能损耗。

对于性能延时敏感的应用而言, 与 Proxyless Service Mesh 设计理念不谋而合的 ShardingSphere-JDBC 无疑更加合适, 其能够将系统的性能发挥至极致。在近期使用 ShardingSphere + openGauss 测试 TPC-C 模型的结果中, 得到了惊人的 16 台服务器超过 1000w tpmC 的测试结果, 行业同等规模下性能最佳。

小结

一直以来, 先进的设计理念和创新均源于西方。但 gRPC 的 Proxyless 设计理念是近期才出现的, 而 ShardingSphere-JDBC 则是项目在 2016 年开源伊始时就已经存在。因此,ShardingSphere-JDBC 并未参考 Proxyless 的设计理念, 它是基于当时国内互联网业务对高并发和低延时的极致性能要求而诞生的。

至于 Database Plus 理念的设计, 又何尝不是如此。伴随着互联网的长期快速发展, 业务的变化直接推动了技术的积累和成长,ShardingSphere 就是这一过程的最好例证, 它的设计方案全部源自于真实业务场景。中国互联网无疑是全球最全面的场景之一, 在此类场景下诞生的设计理念, 在全球范围内也一定拥有十分广阔的生长空间。

未来规划

尽管在 Database Plus 理念的实践道路上越走越远, 但 Apache ShardingSphere 仍然有大量的工作等待完成。数据库网关和异构联邦查询, 是完善 Database Plus 理念的重要功能拼图。

1.数据库网关

Apache ShardingSphere 虽然支持异构数据库的对接, 但无法做到数据库之间方言的相互转换。在 ShardingSphere 的线路规划中,SQL 方言转换是实现数据库网关的重要功能, 用户通过 PostgreSQL 的数据库协议用 MySQL 方言访问 MongoDB 将不再是难以实现的任务。

2.异构联邦查询

Apache ShardingSphere 目前仅支持同构数据库间的联邦查询。在 ShardingSphere 的线路规划中, 异构数据库间的联邦查询也将被提上日程。用户通过一条 SQL 关联查询 MySQL 和 HBase 的场景将不再遥远。

写在最后

Apache ShardingSphere 社区已在开源领域耕耘了 7 年的时间。长久的坚持, 使社区愈加成熟, 已呈开放和多元化的势态。我们诚心诚意地欢迎有开源情怀和编码热情的朋友一起参与社区共建。

Apache ShardingSphere 的可插拔架构和数据分片哲学已在学术界获得广泛认可。在今年的数据库领域顶级的会议 ICDE 中, 已成功发表论文《Apache ShardingSphere:A Holistic and Pluggable Platform for Data Sharding》。