16 台服务器达成 1000 万 tpmC！挑战分布式数据库性能极限

近日，Apache ShardingSphere 社区与 openGauss 社区再度展开合作，Apache ShardingSphere + openGauss 的分布式解决方案，突破了单机性能瓶颈，使用 16 台服务器在超过 1 小时的测试中，得到了平均超过 1000 万 tpmC 的结果。

ShardingSphere + openGauss，达成 1000 万 tpmC

在本次测试中，openGauss 社区基于标准 BenchmarkSQL 5.0 工具，进行本轮 TPC-C 测试。

在单机性能方面，openGauss 突破了多核 CPU 的瓶颈，实现两路鲲鹏 128 核达到 150 万 tpmC，内存优化表（MOT）引擎达到 350 万 tpmC。但业务场景及用户体验对于性能的追求是无止境的，尤其在如今海量数据的场景下，追求性能极限仍然是每一款数据库的目标。

在此情况下，openGauss 团队采用了 7 台机器运行适配了 ShardingSphere-JDBC 的 BenchmarkSQL 测试工具，连接 8 台 openGauss 数据库，并部署了 1 台 ShardingSphere-Proxy 用于数据初始化、一致性校验等维护操作。通过数据分片能力，ShardingSphere 使总共 8000 仓数据（超过 800 GB）被分散在 8 台 openGauss 节点。在完美 Sharding 的情况下进行持续超过 1 小时的测试后，得到了平均超过 1000 万 tpmC 的结果，行业同等规模下性能最好。

这极大突破了 openGauss 现有的性能极限，突破了单机性能瓶颈，满足 openGauss 在海量数据场景下关于性能、可用性以及运维成本这三方面的诉求。两者的结合，正在持续挑战分布式数据库的性能极限。

ShardingSphere 与 openGauss 的生态合作

Apache ShardingSphere 社区自 2021 年起就开始与 openGauss 社区展开密切合作。

随着业务场景的细分以及数据体量的增长，将数据集中存储至单一节点的传统解决方案，已经难以在性能、可用性和运维成本等方面满足业务需求。诚然，数据分片能力能够解决单机数据库在性能、可用性以及单点备份恢复等问题，但也带来了分布式架构较高的系统复杂性。

作为 Database Plus 理念的提出者和实践者，Apache ShardingSphere 旨在构建异构数据库上层的标准和生态，以叠加扩展数据分片、弹性伸缩、数据加密等更多计算能力为基础，站在数据库的上层视角来关注数据库之间的协作方式，以能够合理且充分地利用数据库计算与存储能力。目前，Apache ShardingSphere 已经形成了微内核 & 可插拔架构模型，并在此基础上持续完善内核及功能层面的能力，为企业及开发者用户提供更多更灵活的解决方案，以满足在不同场景下的特定需求。

得益于 ShardingSphere 可插拔架构的设计理念，在 ShardingSphere 中实现对 openGauss 的支持无须进行额外改造，只需要基于 ShardingSphere 各个模块所提供的 SPI 扩展点，增加对应 openGauss 数据库的实现。在 Apache ShardingSphere 5.0.0 版本，已正式完成对 openGauss 数据库的支持。

双方在合作过程中，通过将 openGauss 强大的单机性能与 Apache ShardingSphere 生态所提供的分布式能力结合，打造出了适用于高并发 OLTP 场景的国产分布式数据库解决方案；除功能层面的合作外，ShardingSphere 与 openGauss 在性能方面不断磨合，充分利用 openGauss 内核技术的创新，不断地将 ShardingSphere 与 openGauss 组成的国产分布式数据库解决方案的功能与性能推向极致，此次关于 TPC-C 的性能测试，就是双方密切合作的一次典型案例。

使用 ShardingSphere 打造基于 openGauss 的分布式数据库解决方案

当然，Apache ShardingSphere 的能力不仅有数据分片，还有读写分离、数据加密、影子库等功能，在不同的场景下各项功能既可以单独使用，也可以结合使用，用户完全可以按照自己的需求组合 ShardingSphere 的能力。

Apache ShardingSphere 目前提供两种接入方式，分别为 ShardingSphere-JDBC 和 ShardingSphere-Proxy。在业务中使用 ShardingSphere-JDBC 对数据库轻松进行分库分表以及读写分离等透明化操作，来解决其对于“高并发”、“低延迟” 场景的需求。同时在 JDBC 的基础上，ShardingSphere 提供 Proxy 端的部署模式，将数据库部分能力和操作部署在 Proxy 层面，让用户可以像使用原生数据库一样使用 Apache ShardingSphere，为用户带来更加优质的使用体验。

因此，建议 ShardingSphere-JDBC 和 ShardingSphere-Proxy 混合部署使用，这样可以实现维护友好与性能兼顾的平衡。

在 openGauss 的体系中，Apache ShardingSphere 能够通过水平拆分以使 openGauss 的计算与存储能力实现线性扩展，性能也随着扩展准线性增长，从而有效解决单表数据量膨胀问题；此外结合业务流量，灵活平滑进行数据节点的扩缩容，智能读写分离，实现分布式数据库的自动负载均衡。

后续发展

本次 Apache ShardingSphere 与 openGauss 两家社区的合作，向外界展示了开源社区之间的合作潜力。随着应用场景的细化以及数据体量的增长，未来对于数据库性能的要求只会更高。此次合作的成功只是双方构筑数据库协作生态的一个开始，相信 ShardingSphere 与 openGauss 这种合作模式，一定会有更加广阔的发展空间。

💡 关于 openGauss

openGauss 是一款开源的关系型数据库管理系统，它具有多核高性能、全链路安全性、智能运维等企业级特性，融合了华为在数据库领域多年的内核经验，在架构、事务、存储引擎、优化器及 ARM 架构上进行了适配与优化。

💡 关于 TPC-C

TPC-C（Transaction Processing Performance Council Benchmark C）用于比较在线事务处理（OLTP）系统性能的基准测试标准规范，由 TPC 于 1992 年发布，目前最新的规范为 2010 年更新的 TPC-C v5.11。TPC-C 具有多种事务类型、复杂的数据库和整体执行结构。TPC-C 涉及五个不同类型和复杂性的并发事务的混合，事务会实时执行或进入队列延迟执行。数据分布在数据库九种类型的表中，表的数据量各不相同。TPC-C 以每分钟事务数（tpmC, transactions per minute C）衡量。虽然 TPC-C 模拟了批发供应商的业务，但 TPC-C 并不限于任何特定业务部门的活动，而是代表必须管理、销售或分销产品或服务的任何行业。

欢迎添加社区经理微信（ss_assistant_1）加入交流群，与众多 ShardingSphere 爱好者一同交流。