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

nettips
发布于 2022-5-13 17:08
浏览
0收藏

 

近日,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。但业务场景及用户体验对于性能的追求是无止境的,尤其在如今海量数据的场景下,追求性能极限仍然是每一款数据库的目标。
 16台服务器达成1000万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的能力。

16台服务器达成1000万tpmC!挑战分布式数据库性能极限-鸿蒙开发者社区

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

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

16台服务器达成1000万tpmC!挑战分布式数据库性能极限-鸿蒙开发者社区

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

 

以下文章来源于ShardingSphere官微,作者ShardingSphere

 

文章转自公众号:openGauss

分类
标签
已于2022-5-13 17:08:28修改
收藏
回复
举报
回复
    相关推荐