共计 2866 个字符，预计需要花费 8 分钟才能阅读完成。
近日，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 爱好者一起交换。
