Query Language，结构化查询语言）数据库。 但是，当要快速处理极大的数据量时，被提起的往往是架构灵活、易于扩展的 NoSQL。对于独揽稳定性近五十年的 SQL 数据库来说，易扩展和高性能似乎总是跟它无缘。 历久弥坚的 SQL SQL 最初创建于 1970 年代，因其查询语言摆脱了对数学逻辑和符号的依赖，使得没有经过数学或计算机编程专业培训的普通开发者也能很容易使用，很快便成为关系型数据库事实上的标准编程语言。尤其是随着 Web 应用程序和 MySQL、PostgreSQL和 SQLite 等开源项目的兴起，SQL 在 1990 年代后期更是呈爆炸式增长。 没几年后，SQL 结结实实迎来了一次打击。 二十世纪初，互联网和万维网实现了蓬勃发展，数据生成的数量之多和速度之快，让 SQL 数据库处理不过来。于是，新生的互联网巨头开始琢磨能否采用其他方式来解决这个问题。 在 Google，索引万维网所涉及的大量数据促使该公司开发新的海量数据存储方法，例如 Google 文件系统 (GFS) 和MapReduce。这些技术引导开源社区开发出了 Hadoop。Hadoop 也不负众望，扛起了这面大旗。这严重挑战了关系型数据库市场的企业数据仓库部分。 在亚马逊，由于维护“always-on”事务系统的需求与关系型数据库的一致性模型不匹配，转而开发了自己的“eventually consistent”的 数据库系统——Dynamo。受 Dynamo 的启发，Cassandra 和其他几个早期的 NoSQL 数据库系统也相继问世。 的数量即可。 而 SQL 数据库就只能通过垂直扩展，即通过增强硬件能力，比如通过增加单个服务器上的 CPU、RAM、SSD 等来处理。由于大部分数据仓库都建立在专门的基础架构上，这就意味着SQL 数据库处理大量数据的成本可能非常高。 在执行更复杂的大数据工作负载方面，SQL 数据库要面临另一个问题是，原始数据必须首先通过称为 ETL（提取、转换和加载）的清理和结构化过程，然后才能将其放入仓库。但是这种数据预处理可能会受到错误的困扰。此外，它永久消除了所有潜在有价值的原始数据，同时限制了如何查询“干净和简单”的结果数据。 这么说起来，SQL 面对 NoSQL 的进攻，似乎毫无反击之力。 事实并非如此，因为开发人员很快就发现， NoSQL 看起来很完美，但执行起来并没有那么容易：每个 NoSQL 数据库都提供了自己独特的查询语言，学习成本很高且难以进行大规模协作；将这些数据库连接到应用程序的难度更高了，导致大量脆弱的glue code（即胶水代码，也叫粘合代码，用途是粘合那些可能不兼容的代码）；缺乏第三方生态系统，要求公司开发自己的运营和可视化工具。 而且，这些新的 NoSQL 语言也没有完全开发。例如，在关系数据库中为 SQL 添加必要的特性（比如JOIN）已经有多年的工作；NoSQL 语言的不成熟意味着应用程序级别需要更高的复杂性；缺乏 JOIN 也导致了非规范化，从而导致数据膨胀和僵化。 早在 2008 年，David J. DeWitt 和 Michael Stonebraker 两个人在《 MapReduce：倒退的一大步 》文章中如此评价 MapReduce ：
- 大规模数据密集型应用程序编程范式的巨大倒退；
- 次优实现，因为它使用蛮力而不是索引；
- 一点都不新颖——它代表了近 25 年前开发的众所周知的技术的具体实现；
- 缺少当前 DBMS 中常规包含的大多数功能；
- 与 DBMS 用户依赖的所有工具不兼容。
SQL 依靠自身的独特价值——高标准化、强稳定性、强大的生态，让它在这场争霸赛中捍卫了昔日荣光，直到今天依然坚挺。在 DB-Engines 的 2021 年 9 月最受欢迎的数据库管理系统列表的前 10 个结果中，有六个是关系型或基于 SQL。 当 SQL 拥有高性能
在与 NoSQL 抢市场的过程中，为 SQL 充当护城河的，仍然是那些传统的优势。对于什么类型的数据库适合用于并行处理和大规模大数据解决方案这一问题， 答案大概率会是 NoSQL。
那么，SQL 就注定与易扩展和高性能无缘吗？
2022 年 4 月，Apache ShardingSphere 社区公开表示，Apache ShardingSphere与openGauss 合作的分布式解决方案在TPC-C测试中，使用 16 台服务器得到了平均超过1000万tpmC 的结果。其中，在单机性能方面，openGauss 充分利用了多核 CPU 的性能，实现两路鲲鹏 128 核达到 150 万 tpmC，内存优化表（MOT）引擎达到 350 万 tpmC。
1000万 tpmC ，意味着什么呢？意味着行业同等规模下性能最好。这一解决方案历时近一年，满足了 openGauss 在海量数据场景下关于性能、可用性以及运维成本这三方面的诉求。
2021 年 5 月份，全球顶级开源分布式数据库生态项目 ShardingSphere 与顶级单机开源数据库 openGauss 的正式开展社区层面的合作。在合作前期，双方就技术可行性、兼容性等问题展开了维持两三个月的深度讨论，并在讨论的基础上共同开发出了首个ShardingSphere 与 openGauss 兼容的版本。不过这个版本的性能却不尽如人意，在运行过程中性能损耗过高。
在接下来的大半年时间，ShardingSphere 与openGauss社区专家不断磨合，在技术、部署结构等方面调优，最终让 ShardingSphere-JDBC 连接 openGauss 的性能损耗成功降至10%以下，ShardingSphere-Proxy的性能损耗是降到了 40% 以下。
作为Apache ShardingSphere 的 PMC，吴伟杰最初负责在 Apache ShardingSphere 上实现深度适配 openGauss 的协议。在 7 月 14 日举行的openGauss 开发者峰会上，他透露了很多技术实现的细节。
作为一个典型的关系型数据库，增强 openGauss 性能最直接、有效的方式就是在垂直空间扩展，如在鲲鹏 128 核的环境下还不够用，那就使用256 核。但垂直扩展的空间也是有限的，不可能无限地把CPU 核数往上堆叠。就算把核数叠上去，程序也不一定能能充分地利用如此多的资源。
因此， ShardingSphere 采用的是另一种方式——对 openGauss 进行数据分片，即在水平方向上进行扩展，使总共 8000 仓数据（超过800GB）被分散在 8 台 openGauss节点。吴伟杰表示：“数据分片的难点并不是如何把数据分散到各个地方，而是当数据被分散到各个存储节点以后，数据库如何快速且正确地找到它。这其中涉及到多表关联、子查询等复杂的 SQL 能力，而在已实现数据分片的环境下，这些能力也会受到不同程度的限制。”不过，ShardingSphere 能够透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集群，这也是 ShardingSphere 在水平分片场景下的价值所在。 此外，在读写分离、弹性伸缩、传输协议等方面，ShardingSphere 都对 openGauss 进行了深度适配。以协议适配为例，吴伟杰也分享了开发思路： “PG 数据库执行批量插入时，需要多次发送 Bind 和 Execute。因为在PG的协议层面，每个 Bind 最多只有一组参数。当要插入 100 行数据，PG 就会连续发送 100 次 Bind 和 Execute。 “而openGauss 则在协议上有所创新，它创造了一个叫 Batch Bind 的协议消息。与普通的 Bind 相比，Batch Bind 一次性可以同时传输多组参数，类似于批处理。原来要发送100多个包，但现在只需要通过一个包，减少了很多像消息头之类的网络开销。 “与此同时，ShardingSphere 在 Batch Bind 方面也做了很多优化。比如，当 openGauss 以批量协议的方式把数据发到 ShardingSphere-Proxy 的时候，ShardingSphere-Proxy也同样可以使用批量协议把这些请求分发到多个 openGauss 数据库。“ 为什么是 openGauss ?
那么，为什么是 openGauss ？
ShardingSphere社区认为，作为企业的基石，关系数据库仍然占据着巨大的市场份额。但ShardingSphere 本身作为一款开源分布式数据库生态项目，其本身在底层数据库之上的定位，使其具备了面向底层关系数据库提供扩展数据分片、弹性伸缩、数据加密等增强型计算能力，让整个分布式系统中已有数据库的计算和存储能力利用得更加合理、高效。如其所云：“ShardingSphere 更倾向于关注原生数据库的能力增量，而不是市场格局的彻底颠覆。”
而 openGauss 是国内为数不多的高性能关系型开源数据库之一，有着华为多年的深厚积累，并且已经支持了国内主流服务器芯片架构和操作系统。
今年 3 月上线的openGauss 3.0 版本，在“高性能、高可靠、高安全、高智能”四个方面持续创新。在高性能方面，优化执行技术持续突破，多场景性能持续稳步提升；高可用方面，持续升级，提供全方位高可用能力；高智能方面，AI-Native技术持续领先，内核与AI进一步融合；高安全方面，全方位安全引擎，全程密态，提供极致的安全体验。
此外，还针对应用场景进行重大升级，包括推出面向边缘场景的轻量化版本，完备的集群管理组件，以及支持MySQL语法兼容和数据迁移等。openGauss持续打造面向数字基础设施的开源数据库，从数据中心到边缘，构建多场景支持能力。
这是一次 openGauss 强大的单机性能与 Apache ShardingSphere 生态所提供的分布式能力的完美结合，才打造出了一个适用于高并发 OLTP 场景的国产分布式数据库解决方案。据了解，所有合作成果在 Apache ShardingSphere 5.0.0 版本已经有所体现。
《说苑·谈丛》有云：循流而下，易以至；倍风而驰，易以远。借助生态伙伴的力量，化短板为优势，即使是SQL也能实现易扩展和高性能。这也是openGauss不断强调打造数据库技术生态的原因。
在去年12月举办的openGauss Summit峰会上，openGauss提出了技术愿景：以内核为基础，水平扩展能力，垂直扩大应用场景，联合数据库产业链上下游创新，打造数据库技术生态。
目前，openGauss已在中国邮政储蓄银行、民生银行、中国移动、中国电信、中国联通、国家电网等企业用户广泛应用。例如，中国邮政储蓄银行基于企业级开源数据库openGauss，已于今年4月全量上线新一代个人业务核心系统，系统性能提升5倍，支取和查询等高频业务的响应时间缩短25%，支持日均20亿笔海量交易。邮储银行也是首个完成核心替代，并上线新一代个人业务核心系统的国有大行。
据了解，仅仅在过去半年间，适配行业的解决方案数量从去年底200多个快速增加到当前超过350个。如今，随着越来越多的力量加入openGauss生态，这一愿景正在不断付诸现实。
信息技术应用创新产业国产化势在必行，数据库作为基础软件之一，是其中的重要一环。作为国产开源数据库的佼佼者，openGauss必将携手生态伙伴，共同为夯实我国数字基础设施底座贡献一份力量，为中国数字经济发展注入新动能。
