活动回顾|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 张亮成为北京用户组首批成员。

感谢支持 OpenSEC

京ICP备2021015875号