“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 张亮成为北京用户组首批成员。
感谢支持 OpenSEC