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

最新推荐文章于 2024-04-28 16:03:45 发布

openGauss社区

最新推荐文章于 2024-04-28 16:03:45 发布

阅读量271

点赞数

文章标签：数据库分布式大数据 java 人工智能

本文链接：https://blog.csdn.net/weixin_49727236/article/details/124014662

版权

近日，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仓数据（超过800GB）被分散在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与 openGaus 组成的国产分布式数据库解决方案的功能与性能推向极致，此次关于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这种合作模式，一定会有更加广阔的发展空间。

💡 关于 Apache ShardingSphere

Apache ShardingSphere是一款开源分布式数据库生态项目，由 JDBC、Proxy 和 Sidecar（规划中）3款产品组成。其核心采用可插拔架构，通过组件扩展功能。对上以数据库协议及 SQL 方式提供诸多增强功能，包括数据分片、访问路由、数据安全等；对下原生支持多种数据存储引擎。Apache ShardingSphere项目理念，是提供数据库增强计算服务平台，进而围绕其上构建生态。充分利用现有数据库的计算与存储能力，通过插件化方式增强其核心能力，为企业解决在数字化转型中面临的诸多使用难点，为加速数字化应用赋能。

💡 关于 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并不限于任何特定业务部门的活动，而是代表必须管理、销售或分销产品或服务的任何行业。

欢迎访问openGauss官方网站