活动回顾｜ShardingSphere X openGauss，将会产生怎样的化学反应？

“ShardingSphere 作为 openGauss 生态的开源分布式数据库解决方案，将持续助力于 openGauss，满足千行百业广大客户分布式场景需求。”

5月29日，由 openGauss 社区主办，北京鲲鹏联合创新中心、云和恩墨、深信服、SphereEx 合力承办的“【北京】openGauss Meetup”活动在北京海淀区中关村智能制造创新中心成功举行，此次 Meetup 也是 SphereEx 正式加入 openGauss 社区后的首次联合活动。在 Meetup 现场， SphereEx CEO 张亮从产品形态、部署架构、性能测试、未来规划等方面为大家带来了 《ShardingSphere 与 openGauss 的化学反应》主题分享。

SphereEx CEO 张亮

1

  ShardingSphere 是完全面向广度的生态类项目

分享伊始，张亮首先展示了 ShardingSphere 的数据报告。ShardingSphere 是 Apache 软件基金会的顶级项目，目前在 GitHub 上 收获 14k 以上的 star 数目，超过 200 位贡献者参与社区开发，拥有 100 个以上模块。整体而言， ShardingSphere 是一个完全面向广度的生态类项目。

在谈到成立 SphereEx 公司的核心理论基础时，张亮认为，“基于目前的行业现状，数据库碎片化的时代已经来临，未来不再会出现大一统的数据库去解决所有问题，众多数据库将在各行各业发挥各自擅长的能力。基于此， SphereEx 公司将主导把 ShardingSphere 打造成为 Database Plus 的产品形态，致力于搭建数据库上层的标准化增量，而非做一个 n+1 的数据库。”

ShardingSphere 具备可插拔的强大架构体系。多种数据库协议和 SQL 方言，及其提供的功能都是它可插拔的一部分。ShardingSphere 最常见的数据分片能力，即是其中的一个可插拔功能。除了数据分片，读写分离、数据加密、高可用、弹性伸缩，以及未来计划的 SQL 审计相关功能均通过可插拔的标准接口织入到系统中。在可插拔架构之上，ShardingSphere 提供 DistSQL 功能，用于控制可插拔功能规则的创建，以便于每个功能均可通过 SQL，以数据库原生的方式进行操作，用户无需像使用传统中间件一样，通过配置启动功能。

2

  ShardingSphere 是一个面向开发者的可定制化编程平台

可插拔架构是 ShardingSphere 长期以来一直致力于打造的“微内核，强生态”架构模式。它追求各个模块的相互独立和互无感知，并且通过一个高灵活度，可插拔和可扩展内核，以叠加的方式将各种功能组合使用。

ShardingSphere 的可插拔的架构共分为三层。

L1 内核层面向数据库内核，包括数据库事务引擎，查询优化器等。当数据库有较为适当的查询优化能力时，ShardingSphere 可直接下推至数据库的方式去执行。在 SphereEx 公司为 ShardingSphere 的产品规划中，当数据库缺失查询优化的相应能力时，比如 KV 数据库，则会调用内置的查询优化器，在其上进行标准查询。

L2 功能层是 ShardingSphere 最核心所在。在功能层完全缺失的情况下，ShardingSphere 会表现成为一个空白的框架，将 SQL 直接透穿至数据库。功能层的每个模块均独立存在，在模块内部的代码开发，不会影响其它模块的稳定性。与此同时，ShardingSphere 可以将各种功能以可叠加的方式组合使用。譬如：开发者既可以同时使用数据分片、读写分离和数据加密，也可以独立使用数据加密，所有功能的排列组合都是自由扩展的。ShardingSphere 不仅是一个面向数据库某项能力所打造的数据库中间件产品，广义上它更是一个面向开发者的可定制化编程平台。

L3 生态层通过三个接口分别实现数据库协议、 SQL 方言和数据库存储对接，用于打造异构数据网关。ShardingSphere 未来会考虑开发 SQL 方言转换模块，在真正意义上实现在异构的数据库中自由的穿梭，并管控所有对数据库的访问流量。

在谈到 ShardingSphere 的部署架构图时，张亮表示： “ShardingSphere 是由两个产品形态组成的多接入端混合架构”。

ShadingSphere-Proxy 的使用方式与数据库一模一样，目前支持 MySQL 和 PostgreSQL 协议，可以直接使用 MySQL/PostgreSQL Cli 命令行，Navicat 等图形界面、以及任何异构语言连接。

ShadingSphere-JDBC 则是一个 Java 端的驱动，与 Proxy 的两次网络调用不同，它采用直连数据库的方式以达到性能的最大化。Proxy 的性能损失大概在 20% 左右，而 JDBC 则在 2%-3% 之间。对于用户来说，选用 JDBC 或 Proxy 都是可以的，同时 ShardingSphere 还提供了 Proxy 和 JDBC 混合使用的架构模型。在对性能要求比较极致的 Java 开发线上应用场景，可使用 JDBC 直连数据库，并且搭建一个 Proxy 便捷 DBA 对数据库的运维操作；对性能要求非敏感的场景，则可以直接使用 Proxy。

ShardingSphere 的分片能力从本质来看，是基于对 SQL 修改，以及对分布式事务的协调进而达成对水平扩展要求的。通过 ShardingSphere 和 openGauss 所组合成的新的产品形态，到底能产生什么样的化学反应呢？

3

  ShardingSphere + openGauss 产生的化学反应

openGauss 是一个性能强劲的交易型数据库，通过 ShardingSphere 可以便捷地实现其水平扩展能力。ShardingSphere 的可插拔能力在此可以更好体现，它可以非常方便的对接 openGauss 协议，而无需改动内核代码。

用户使用 ShardingSphere 与直接使用 openGauss 没有区别。但从配置来说， ShardingSphere 的分片算法是面向开发者的，配置非常灵活，如果封装成为一体化的分布式数据库，通过 Java 类进行分片规则的方式在使用体验上较差。开发者可以使用 ShardingSphere 的模板化分片算法（如：MOD、HASH、RANGE），完全屏蔽分片键以及算法的配置，未来 ShardingSphere 会在配置模版的易用性上做较大提升。

除此之外，ShardingSphere 还将提供高可用切换探测能力。当 openGauss 发生主从切换后，可通过 DistSQL 通知 ShardingSphere 切换读写分离配置。

另外，张亮还展示了 ShardingSphere 在 openGauss 之上所做的性能测试报告。

从图中可以看出，当直连 openGauss 在 TPS 达到 19 w 时，通过 ShardingSphere-Proxy 代理连接的 TPS 则可以达到 15.5 w，接近 20% 的性能损耗。张亮表示未来的测试场景将会更加细化，将添加 MySQL 和 PostgreSQL 的比对测试。

最后张亮分享了 ShardingSphere 和 openGauss 在拓展生态和社区未来发展中的一些规划。首先，将性能提升至极致。未来双方的合作中有大量可提升的空间，会持续的进行优化提升。

其次，通过 ShardingSphere 的可插拔的架构赋予 openGauss 更多能力，如：数据加密、SQL 审计等。

第三，对 openGauss 数据库管控方言的全面支持。ShardingSphere 在之前对 MySQL 的支持较多，未来会对 openGauss 做更强的支持。

最后，通过 DistSQL 对接分布式的管控。目前 ShardingSphere 可以直接对接 MySQL 的 MGR，未来会内置支持 openGauss 的高可用切换方案。

分享最后，张亮总结到：“目前 SphereEx 公司正着力于将 ShardingSphere 和 openGauss 更好地对接和联合优化，使其在高性能的基础之上，增加水平扩展的分布式能力。ShardingSphere 将完全兼容 openGauss 协议，透明化用户使用。在 ShardingSphere 未来的规划中，会不断尝试将其各方面的能力与 openGauss 相结合，使整个数据库产品在水平扩展之外，在数据库灰度迁移和升级、数据安全、压测数据导流、分布式治理等能力上进一步提升。” 希望 ShardingSphere 与 openGauss 携手，带动国内新兴数据库生态不断壮大，助力数据库产业不断前行。

openGauss 北京用户组成立

本次 Meetup 最后进行了 openGauss 北京用户组成立仪式。openGauss User Group，简称 oGUG，是一个让开发者就 openGauss 技术特性、最佳实践、运营进展等方向交流的公益性本地社区，大家共同努力，一起进行原创性、引领性的技术攻关，构建数据库根技术，从而打造数据库根社区和主流生态。SphereEx CEO 张亮成为北京用户组首批成员。

更多精彩视频回顾，请点击“阅读原文”查看。