本篇为大家分享下GaussDB的商业进展以及产品能力升级方面的最新情况。
- 华为云GaussDB正在从金融覆盖到更多行业
从2019年开始，在华为内部通过持续的锤炼，推出了融合多项技术的自主创新的GaussDB数据库，而且陆续完成了华为公司内部核心系统的替代，这里面包括三个方面。
第一，在终端云上实现了6PB数据的全面替代和上线，分布式节点有6千个节点的规模，资源利用率提升了30%。
第二，在ERP的替换中，替换了600多套的业务库，经历了十倍流量的突发流量考验，业务效率得到了10倍的提升，实现了零故障、零时延和零调账。这里简单给大家普及一下，华为公司的订单系统的特点，每到一个月的月末，每到一个季度的结束以及每年结束的时候，它的流量是平时流量的5-10倍。所以华为公司在ERP上线的时候，我们是经历了20倍流量的测试和压测才能上线。
第三，运营商设备，累计发货也有30多万套。
从收入结构也可以发现，GaussDB从最初的金融行业已经覆盖到更多的关基行业，非金融的占比提升了一倍，越来越多的客户选择GaussDB作为其数字化转型的伙伴。
- 在丰富的实践场景中打磨成熟 数据库是一个全场景的软件，所以场景实际上是数据库的磨刀石。下面，将进一步解读刚才讲的这几个业务和后面要讲的金融业务对数据库的磨炼是极其重要的。
华为的MetaERP系统，是一个典型的重度的使用传统商业数据库的场景，也是制造业里面非常典型的一个应用的代表，在华为公司，ERP是我们的生产系统，它支撑了华为每年数千亿订单，170多个国家的订单发货。从华为自身业务连续性的视角看，华为的ERP替换，相当于长征途中的强渡大渡河。
作为全球数据库应用场景最复杂的ERP系统之一，华为的MetaERP面临几个挑战：
首先，就是有近7亿行的SQL脚本需要改造；
其次，业务高峰期业务流量可能达到5-10倍，在实际上线前，我们做了20倍流量的压测；
最后，就是大表的改造，有最大160亿行大表，超过100亿行的表就有十几个，这些大表的迁移都非常具有挑战性。那如何解决呢？
第一，对于SQL脚本的替换，UGO工具实现了近100%的自动化结构迁移。今天，去替换数据库，如果还投入几十个人去改造一个应用实现替换的话，是不可以维系的。
第二，数据迁移，在35个小时内，实现了3200亿行数据的迁移。也就是说，今天大家已经不用担心数据迁移的一致性和完备性问题了。
另外，通过智能代价估计、高效索引并发控制等算法顺利地通过了业务历史最大峰值20倍流量的压测。
这里也给大家讲一个小故事，在ERP切换成功后，华为成都的一个操作人员，第一次运行资产核算任务，只用了3分钟。但服务器托管网是之前这个操作人员的历史经验都需要2个多小时。所以他认为这次可能是运行失败了，按照操作的规范立即预警。经过实际确认，结果是准确的，是一个“美丽的误会”。
而华为终端云服务，这个代表着新兴的一类生于云、长于云的云原生企业的典型应用，它的主要挑战是什么呢？首先是成本问题，如何提升资源利用率，特别是在海量的数据和分布式的情况下，大量的部署节点带来的成本问题以及传统的机房转换到云上的成本挑战；其次是海量业务带来的大量的分布式的诉求，需要有非常强的扩展性，和弹性伸缩能力；最后是数据多样化，因为其中既有关系型数据，也有非关系型数据。
GaussDB原生的分布式架构，使负载更加均衡，已经上线的最大单集群节点数超过了200个，并且支持多种生态，实现了资源利用率和运营效率的大幅度提升。
还有就是对数据库要求最高的金融核心系统，几乎所有的金融CIO或CTO都知道迁移并不好做，金融行业大量的应用都重度依赖传统数据库的接口，存在大量的不确定性，客户都希望有一套可量化的、逐步推进执行的方案。
从芯片、服务器、存储、网络到数据库、操作系统，GaussDB是当前国内唯一能够做到软硬协同、全栈自主创新的国产品牌，高度兼容传统数据库的语法，有一站式的数据加应用平滑迁移方案，使得迁移变得更简单。同时基于多数派协议的原生分布式架构，更大幅提升了系统的可用性。
- 面向更深入、更广泛的场景，我们思考如何更好地满足客户诉求 随着GaussDB的成熟，未来GaussDB将向两个方向发展。第一是做深做透金融行业，一次性解决金融客户数字化转型和可持续发展的双重诉求；第二是从金融走向政务、能源、交通等更多关键信息基础设施行业，这也是一个新的使命。
在做深做透金融上，发现客户以前只关注接口的适配性，现在开始逐步重视替换后应用的可用性、稳定性。大家都知道，主机的可靠性大部分来自硬件，而没有了这种专用硬件的加持，如何通过软硬件协同保障大机整体可用性指标就非常重要了。金融核心业务不同于互联网追求性能峰值的极限，更需要的是一个确定的不抖动的性能，让每一笔交易的时延都可控。最后，在客户从几个应用替换到几百个应用替换的落地过程中，如何把迁移做成可量化的实施过程，是摆在每个金融CIO眼前最大的挑战。
近些年，关基行业的数据规模也越来越大，由于科技力量薄弱，技术人员投入相对较少，就需要数据库简单易用，最好能直接复用在金融行业已经实践成熟的技术来降低总体拥有成本，实现快速推进。
- GaussDB始终以安全可信、高质量为首要目标 为了满足更多场景的客户诉求，发布了新一代的分布式数据库GaussDB，具备“五高两易”的全面能力。下来我就其中的一些关键的新能力跟大家做一下解读和分享。
在讲具体的产品能力升级变化之前，想先给大家分享下GaussDB没变的东西，那就是对安全可信、高质量的追求。
从产品定义、代码实现、开源治理到运营运维等各个环节，GaussDB基于华为软件工程全栈可信框架，实现了从结果可信到过程可信服务器托管网，做到了包括开发GaussDB软件的整个工具链在内的真正的自主创新。
同时，构建起了一个9层的测试防护网，通过全链路的深度交互测试平台减少低概率、复杂交互类的问题，当前已有20万测试用例消减了大部分基本问题，今年还会继续增加到80万，还构建了10多个金融客户场景化的防护网，消减了金融场景化的问题，实现真正的高质量。
- 聚焦客户业务痛点，GaussDB产品关键能力全新升级 在产品能力升级上，大家最关心的还是可用性。GaussDB新版本支持了Paxos一致性协议，更好地提升了RTO，高负载业务下DN故障倒换可以稳定在10秒以内；去年跟工商银行联创推出了国内首个双集群强一致的方案，实现了集群级故障完全隔离RPO=0，双AZ双活；今年又进一步支持了双集群的逻辑复制，以及全新的应用无损透明切换方案，做到应用大版本升级完全不停机，主备倒换应用微感知，真正实现大机业务7*24小时不间断。
在性能上，GaussDB存储引擎可以实现业务长时间频繁更新下依然保持系统高性能，同时不抖动。这得益于GaussDB和招行的联创，重构了底层的整个存储引擎，采用的是原地更新的模式，它和常见的基于不断追加的这种引擎最大的区别是，传统的模式在底层垃圾的回收和内存做数据化的时候会有非常大的抖动。经过实测，在大压力的情况下，性能的抖动依然可以控制在3%，同时存储空间的利用率提升了17%。
在智能化上，对DBA来说，最头疼的就是在系统出现亚健康状态的时候，如何能够快速感知到问题，及时地进行识别和分析，方便进一步操作。作为国内首个AI-Native数据库，GaussDB提供从应用开发到运维阶段全流程的数据库智能化体验，有全新的SQL Audit工具，在开发验证阶段就完成SQL自动审核，减少亚健康出现的情况，一旦出现亚健康状态，GaussDB可以快速感知到问题，识别出实时慢SQL，并进一步通过慢SQL的耗时点分析，自动诊断出是否处于被阻塞状态，以便运维人员进行判断查杀。
在一些严重过载的情况下，过载熔断能力可以自动kill过载会话，避免因个别慢SQL拖住整个系统。还有DBMind的慢SQL根因分析、索引推荐、异常检测等多种运维功能也让DBA更加得心应手。
除了上面讲的这些硬核技术外，对于客户关注的性价比、平滑迁移，GaussDB的新版本也做了大量的工作。
首先是海量数据带来的存储资源压力。压缩是一个办法，但简单的高压缩比并不是我们追求的目标，我们更关注的是如何让业务尽量无感地使用压缩，并且性能不会有大幅降低，最好控制在5%，甚至更低的性能影响，这才是真正有用的压缩。我们既能够降低资源的使用，对应用的侵入性更小。
其次，新版本还将支持内核多租户的能力，帮助用户可以快速在不同的租户资源上进行迁移，让应用使用更加灵活，资源利用率更高。
最后，GaussDB有一站式的迁移解决方案，让原本不确定的迁移工作变成一个确定性的事情。
第一个就是我们的UGO，可以对现有系统的所有应用进行扫描和评估，告诉我们哪些能够兼容，哪些不能兼容，以及如何进行改造，现在我们已经做到95%的自动化。
第二个就是DRS，可以实现在线零中断迁移，并且通过数据比对保证数据零丢失。
第三个是流量回放，和UGO配合，可以真实地抓取源数据库上的流量，在新数据库上进行回放，避免大家现在普遍遇到的覆盖不全的问题。我认为，只有通过上述工程化可落地的方案，才能真正地实现国产数据库的规模替换。
数据库的发展，除了产品的创新，更离不开产学研用的通力合作。金融客户是数据库的重要出发点和落脚点，为GaussDB的发展起到了关键的作用。我们希望更多的金融客户能够开放自己更多的典型业务场景，基于分布式架构，来设计自己的多地多中心方案，形成最佳实践，加速推进行业数字化转型。
今天的分享就到这里，欢迎大家一起探讨、交流。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
相关推荐: 使用Github Copilot生成单元测试并执行
上一篇文章我们介绍了 使用Github Copilot完成代码编写 本文我们继续使用Github Copilot在已有代码的基础上生成代码测试并执行。 一、先说一下代码的背景 需要上需要提供一个度量衡的工具类，实现各种转换，例如 将长度值转换为英寸 将长度值转…
