Apache ShardingSphere 5.1.2 发布｜全新驱动 API + 云原生部署，打造高性能数据网关

在 Apache ShardingSphere 5.1.1 发布后，ShardingSphere 合并了来自全球的团队或个人的累计 1028 个 PR，为大家带来 5.1.2 新版本。该版本在功能、性能、测试、文档、示例等方面均有不少优化。

值得一提的是，本次更新带来了以下全新功能：

• ShardingSphere-Proxy Helm Chart

• SQL 方言翻译

• 以 Driver 形式使用 ShardingSphere-JDBC

这些全新的能力让 ShardingSphere 的数据网关能力得到了质的提升，助力 ShardingSphere 在云上部署，优化用户体验。

除了上述新功能，本次更新大量提升了 SQL 解析支持度，内核、运行模式、弹性伸缩都完善了对 PostgreSQL / openGauss schema 的支持，弹性伸缩、事务、DistSQL 在健壮性与用户体验方面也有不少提升。

本篇将给大家介绍 ShardingSphere 5.1.2 版本更新内容。

新功能介绍

• 使用 Helm 部署 ShardingSphere-Proxy

ShardingSphere-Proxy 提供了 Docker 镜像以便于用户容器化部署。不过，对于需要在 Kubernetes 部署 ShardingSphere-Proxy 的用户，还需要自行处理数据库驱动挂载、配置挂载、自定义算法挂载等必要步骤，部署过程相对繁琐，运维成本相对较高。

ShardingSphere 本次更新带来了全新的 ShardingSphere-Proxy Helm Chart。这项新功能由企业级、云原生数据增强计算产品及解决方案提供商 SphereEx 向 Apache ShardingSphere 社区捐赠，推动 Apache ShardingSphere 在云原生方向前进。

ShardingSphere 在集群模式下依赖注册中心存储元数据，ShardingSphere-Proxy 的 Helm Chart 能够自动部署 ZooKeeper 集群，帮助用户快速搭建 ShardingSphere-Proxy 集群。

受限于开源协议，ShardingSphere-Proxy 的二进制发布包、Docker 镜像受限于开源协议，无法打包 MySQL JDBC 驱动，用户需要手动添加 MySQL JDBC 驱动到 classpath 才能使用 MySQL 作为 ShardingSphere 的存储节点。对于这类情况，ShardingSphere-Proxy Helm Chart 能够在 Pod 的 Init 容器自动获取 MySQL JDBC 驱动，降低了用户的部署操作成本。

• 全新 SQL 方言翻译能力

随着数据库碎片化趋势的不可逆转，多种类型数据库的共存已渐成常态。使用一种 SQL 方言访问异构数据库的场景在不断增加。

多样化的数据库的存在，使访问数据库的 SQL 方言难于标准化，工程师需要针对不同种类的数据库使用不同的方言，缺乏统一化的查询平台。

将不同类型的数据库方言自动翻译为后端数据库所使用的方言，让工程师可以使用任意一种数据库方言访问所有的后端异构数据库，可以极大地降低开发和维护成本。

Apache ShardingSphere 5.1.2 在打造极具生产力的数据网关的路途中迈出了重要的一步。本次更新带来了全新的 SQL 方言翻译能力，能够支持主流开源数据库之间的方言转换。例如，用户可以使用 MySQL 客户端连接 ShardingSphere-Proxy 并发送基于 MySQL 方言的 SQL，ShardingSphere 能自动识别用户协议与存储节点类型，自动完成 SQL 方言转换，访问 PostgreSQL 等异构存储节点，反之亦然。

• 以 Driver 的形式使用 ShardingSphere-JDBC

在过去的 ShardingSphere 版本中，ShardingSphere-JDBC 以 DataSource 的形式向用户提供服务。对于不使用 DataSource 的项目或工具，需要进行改造才能引入 ShardingSphere-JDBC，增加了用户的使用成本。

在 Apache ShardingSphere 5.1.2 中，ShardingSphere-JDBC 实现了标准的 JDBC Driver 接口，用户可以通过 Driver 的形式引入 ShardingSphere-JDBC。

用户可以直接通过 DriverManager 获取 Connection：

Class.forName("org.apache.shar