数字经济时代下，数据成为继土地、劳动力、资本、技术四大生产要素之后的第五大生产要素。如何更好管理数据，对企业尤为关键，ERP这一管理信息化的核心系统也愈发受到重视。而作为企业OTC（订单到回款）业务流中的“最后一站”，“收入成本”产品既承担着海量数据的汇入，又处于库存交易和交易核算的数据流中转，因而收入成本想要与海量数据打交道，必然需要一个“大容量”的数据库作为底层支撑。日前，华为宣布实现自主创新的MetaERP研发，完成对旧ERP系统的替换，目前已覆盖了华为公司100%的业务场景和80%的业务量。其中，基于华为云GaussDB，MetaERP构建了“收入成本”产品，进行收入成本集中管理，高效支撑了华为公司运营商业务、企业业务、终端业务、智能汽车解决方案业务、华为云计算、数字能源等多种业务的统一、实时收入成本核算。01 “收入成本”产品面临亿级数据量难题ERP作为华为企业经营最核心的系统，伴随着华为20多年的快速发展，支撑了每年数千亿产值的业务以及全球170+国家业务高效经营。因而，想要实现MetaERP的替换，就必须面对华为极度复杂的业务、巨大的账本业务量，以及千万级流量洪峰。其中，收入成本确认核算单总数据量为66.24亿。面对如此大的数据量，如何保证业务系统零故障、零延时、零调账是MetaERP收入成本产品团队的最大难题。“这是因为‘收入成本’产品的使用特殊性。一般每月月底最后一天，业务都会进行冲刺，在最后1个小时极有可能出现100W+的收入成本核算行。此前基于旧ERP系统，业务处理完100W的收入成本核算单预计需要8小时左右，如果当晚18点之后才处理完成，相应的收入核算只能计入到下一个会计期，从而导致关账不及时，影响财务报表出具的及时性和准确性。”产品团队解释道。亿级数据量、瞬时百万级峰值，这让MetaERP的替换攻坚难度陡增，也对数据库这一“收入成本”产品底层技术支撑的容量和可用性提出了更高要求。02 GaussDB按需弹性扩展，包容海量数据面对如此高要求，什么样的数据库能够完美胜任？开源的MySQL或PG数据库在数据量达到2.4TB后，一定几率会出现IO瓶颈导致业务性能下降；并且2.4TB数据量后高概率无法在业务低峰期完成全量备份，导致全量备份失败并进一步抢占业务IO；这些问题和限制都无法满足华为ERP业务的诉求。当时团队面临两个选择：第一个选择，由应用自己做分库分表，但是ERP因为其特殊性，可能有不少跨数据库的操作，比如数据归集或者合并等等。这些请求如果是通过分库分表来做，会非常复杂；另一个选择是找到一个功能强大的原生分布式数据库，既能满足业务场景，又能满足安全可信的要求。而华为云GaussDB就是那个选择。基于此，研发团队选择了GaussDB， GaussDB也用其硬核实力很好回应了MetaERP“收入成本”产品构建的技术要求。具体而言，GaussDB单库容量可达24TB，一方面轻松支撑ERP系统的存储需求，另一方面采用缓冲区淘汰算法、并行逻辑复制（突破300MB/s）等技术，确保大容量下性能表现依旧稳定强劲；基于备机快照备份，实现永久增量备份，解决备份抢占业务IO痛点问题；并且可以根据业务压力动态伸缩读节点，读吞吐量提升2倍，主/读节点间数据同步秒级时延，轻松应对ERP月底、年底冲刺期间亿级数据量、瞬时百万级峰值的并发访问压力，足以支撑华为ERP超过200+子公司的业务体量。有了GaussDB的强力加持，MetaERP成功构建了“收入成本”产品，稳定支撑华为公司运营商业务、企业业务、终端业务、智能汽车解决方案业务、华为云计算、数字能源等多种业务的实时收入成本核算。同时，MetaERP“收入成本”产品通过将收入核算、成本核算统一解耦到“收入成本”产品进行集中管理，实现核算规则的抽象和标准化，核算入口支持灵活可配，并已在华为公司中国区、海外切换中得到了充分实践验证。值得一提的是，在本次MetaERP系统迁移中，华为云GaussDB从老ERP系统完整迁移和装载了超过168TB （ERP）的数据，为上层业务实现无感和可靠切换提供了最基础的数据保障。如今，GaussDB已全面支撑MetaERP，上线包括收入成本在内的9大核心产品，实现稳定运行无问题，端到端业务效率10倍提升。事实上，在MetaERP这场被称为“强渡大渡河”的3年技术突破中，华为云GaussDB作为智能数据底座，在成功支撑华为集团新MetaERP系统实现全栈自主创新的同时，更依靠其“高性能、高可用、高安全”的技术特性，全面支持华为业务需求快速响应、经营决策科学高效、应用数据安全可信。面向未来，华为云GaussDB也将持续技术创新，用技术力量提升企业服务质量、效率、体验，保障企业业务稳定运行。

1、目前集群3节点状态都正常2、也没有处于锁状态3、集群暂无磁盘满的告警，而且查看了3个节点的磁盘使用情况，目前只有一个节点上media文件夹满4、【补充信息】目前DDL操作一直报“cannot execute *** in a read-only transaction”。还请各位大神抽空帮忙看看指点一下解决办法

近日，华为联合新意科技、掌数科技在华为东莞松山湖基地共同举办了“证券、基金行业DBA走进华为——GaussDB赋能培训”活动。本次培训有近30家证券、基金等行业机构的DBA积极参与，旨在分享华为自身GaussDB数据库经验，帮助客户用好数据库，与伙伴建立深度合作，共同打造数据库生态，推动国产数据库在企业落地。共建数据库生态，DBA是推动数据库行业发展的关键​华为云数据库服务产品部部长苏光牛在开班典礼上致辞表示：华为公司必须做数据库，而且要坚定不移地做下去。今年华为公司继续加大数据库研发投入，攻克数据库中的重难点。DBA是企业能否突破数据库局限的关键，加强DBA人才的培养力度，打造GaussDB数据库生态，让GaussDB数据库成为世界最优选。​华为云全球生态部软件伙伴发展部总经理李欣表示：DBA是一群真正懂数据库、且有能力推动数据库行业发展的人。华为在国产数据库领域长期努力已经取得了一定成果，希望大家通过本次培训提升使用GaussDB数据库的技术与能力，成为华为云GaussDB开发者、专家和DBA，一起推动数据库产业发展。本次培训联合主办单位掌数科技总经理刘建，代表新意科技和掌数科技两家公司共同致辞，表达了掌数科技、新意科技与GaussDB、行业客户共同发展的愿景。同时，结合自己在数据库行业21年的从业经验，分享DBA成长发展、理论结合实践以及学习长期主义的重要性。GaussDB数据库势不可挡，学员学习热情高涨 数据库是连接上层应用和底层基础资源的重要纽带，也是国家“核高基”项目重点攻关的领域之一。GaussDB结合华为在数据库领域长期的技术沉淀和业界独有的软硬件全栈能力，持续聚焦技术创新，与行业TOP ISV强强联合，共同服务行业客户，打造坚实数据底座。本次培训讲师由数十位华为云GaussDB数据库专家组成，通过体系化的GaussDB课程设计，围绕DBA日常实际应用场景，结合华为集团质量与流程IT部的成功经验，帮助客户DBA学好、用好GaussDB！三天的培训课程干货满满，学员们学习热情高涨，与讲师积极互动，不断碰撞出思维的火花，培训结束后主动加入GaussDB开发者认证，持续提升DBA核心竞争力。此外，结班仪式上还举行了颁奖，为优秀学员颁发证书，纪念此次难忘的学习之旅，为期三天的培训在轻松愉悦的松山湖园区游览中圆满落幕。华为与伙伴共建数据库繁荣生态，持续体系化赋能行业DBA 数据库是需要长期投入的产业，技术创新是立足之本，生态构建是繁荣的关键。随着云计算、人工智能、大数据等技术的蓬勃发展，数据库及DBA也将迎来了更多的机遇。在数据库生态建设方面，华为通过产学研用深度融合，联合伙伴、高校一起推动数据库人才培养，保障客户及华为自身业务发展的人才供给。华为将继续联合更多像掌数科技、新意科技等这样的合作伙伴举办此类培训，持续为行业客户培养GaussDB专业人才，为客户在GaussDB的方案构建、项目应用等方面提供坚实的保障。生态是数据库竞争的终极战场，华为云GaussDB携手DBA和生态伙伴，持续打造领先的技术和服务，助力行业数字化转型，共创数据库生态繁荣。

近日，华为联合新意科技、掌数科技在华为东莞松山湖基地共同举办了“证券、基金行业DBA走进华为——GaussDB赋能培训”活动。本次培训有近30家证券、基金等行业机构的DBA积极参与，旨在分享华为自身GaussDB数据库经验，帮助客户用好数据库，与伙伴建立深度合作，共同打造数据库生态，推动国产数据库在企业落地。共建数据库生态，DBA是推动数据库行业发展的关键​华为云数据库服务产品部部长苏光牛在开班典礼上致辞表示：华为公司必须做数据库，而且要坚定不移地做下去。今年华为公司继续加大数据库研发投入，攻克数据库中的重难点。DBA是企业能否突破数据库局限的关键，加强DBA人才的培养力度，打造GaussDB数据库生态，让GaussDB数据库成为世界最优选。​华为云全球生态部软件伙伴发展部总经理李欣表示：DBA是一群真正懂数据库、且有能力推动数据库行业发展的人。华为在国产数据库领域长期努力已经取得了一定成果，希望大家通过本次培训提升使用GaussDB数据库的技术与能力，成为华为云GaussDB开发者、专家和DBA，一起推动数据库产业发展。本次培训联合主办单位掌数科技总经理刘建，代表新意科技和掌数科技两家公司共同致辞，表达了掌数科技、新意科技与GaussDB、行业客户共同发展的愿景。同时，结合自己在数据库行业21年的从业经验，分享DBA成长发展、理论结合实践以及学习长期主义的重要性。GaussDB数据库势不可挡，学员学习热情高涨 数据库是连接上层应用和底层基础资源的重要纽带，也是国家“核高基”项目重点攻关的领域之一。GaussDB结合华为在数据库领域长期的技术沉淀和业界独有的软硬件全栈能力，持续聚焦技术创新，与行业TOP ISV强强联合，共同服务行业客户，打造坚实数据底座。本次培训讲师由数十位华为云GaussDB数据库专家组成，通过体系化的GaussDB课程设计，围绕DBA日常实际应用场景，结合华为集团质量与流程IT部的成功经验，帮助客户DBA学好、用好GaussDB！三天的培训课程干货满满，学员们学习热情高涨，与讲师积极互动，不断碰撞出思维的火花，培训结束后主动加入GaussDB开发者认证，持续提升DBA核心竞争力。此外，结班仪式上还举行了颁奖，为优秀学员颁发证书，纪念此次难忘的学习之旅，为期三天的培训在轻松愉悦的松山湖园区游览中圆满落幕。华为与伙伴共建数据库繁荣生态，持续体系化赋能行业DBA 数据库是需要长期投入的产业，技术创新是立足之本，生态构建是繁荣的关键。随着云计算、人工智能、大数据等技术的蓬勃发展，数据库及DBA也将迎来了更多的机遇。在数据库生态建设方面，华为通过产学研用深度融合，联合伙伴、高校一起推动数据库人才培养，保障客户及华为自身业务发展的人才供给。华为将继续联合更多像掌数科技、新意科技等这样的合作伙伴举办此类培训，持续为行业客户培养GaussDB专业人才，为客户在GaussDB的方案构建、项目应用等方面提供坚实的保障。生态是数据库竞争的终极战场，华为云GaussDB携手DBA和生态伙伴，持续打造领先的技术和服务，助力行业数字化转型，共创数据库生态繁荣。

最近看到一篇《我说MySQL每张表最好不要超过2000万数据，面试官让我回去等通知》的文章，非常有趣。文中提到，他朋友在面试的过程中说，自己的工作就是把用户操作信息存到MySQL里，因为数据量超大（5000万条左右），需要每天定时生成3张表，然后将数据取模分别存到这三张表里。下面是两人的对话：面试后续暂且不论，不过，互联网江湖上的确流传着一个说法：单表数据量超过500万行时就要进行分表分库，已经超过2000万行时MySQL的性能就会急剧下降。那么，MySQL一张表最多能存多少数据？今天我们就从技术层面剖析一下，MySQL单表数据不能过大的根本原因是什么？猜想一：是索引深度吗？很多人认为：数据量超过500万行或2000万行时，引起B+tree的高度增加，延长了索引的搜索路径，进而导致了性能下降。事实果真如此吗？我们先理一下关系，MySQL采用了索引组织表的形式组织数据，叶子节点存储数据，非叶子节点存储主键与页面号的映射关系。若用户的主键长度是8字节时，MySQL中页面偏移占4个字节，在非叶子节点的时候实际上是8+4=12个字节，12个字节表示一个页面的映射关系。MySQL默认是16K的页面，抛开它的配置header，大概就是15K，因此，非叶子节点的索引页面可放15*1024/12=1280条数据，按照每行1K计算，每个叶子节点可以存15条数据。同理，三层就是15*1280*1280=24576000条数据。只有数据量达到24576000条时，深度才会增加为4，所以，索引深度没有那么容易增加，详细数据可参考下表：索引深度最大数据量（行数）115219200   (15*1280)324576000  (15*1280*1280)431457280000  (15*1280*1280*1280)搜索路径延长导致性能下降的说法，与当时的机械硬盘和内存条件不无关系。之前机械硬盘的IOPS在100左右，而现在普遍使用的SSD的IOPS已经过万，之前的内存最大几十G，现在服务器内存最大可达到TB级。因此，即使深度增加，以目前的硬件资源，IO也不会成为限制MySQL单表数据量的根本性因素。那么，限制MySQL单表不能过大的根本性因素是什么？猜想二：是SMO无法并发吗？我们可以尝试从MySQL所采用的存储引擎InnoDB本身来探究一下。大家知道InnoDB引擎使用的是索引组织表，它是通过索引来组织数据的，而它采用B+tree作为索引的数据结构。B+Tree操作非原子，所以当一个线程做结构调整（SMO，Struction-Modification-Operation）时一般会涉及多个节点的改动。SMO动作过程中，此时若有另一个线程进来可能会访问到错误的B+Tree结构，InnoDB为了解决这个问题采用了乐观锁和悲观锁的并发控制协议。InnoDB对于叶子节点的修改操作如下：方式一，先采用乐观锁的方式尝试进行修改对根节点加S锁（shared lock，叫共享锁，也称读锁），依次对非叶子节点加S锁。如果叶子节点的修改不会引起B+Tree结构变动，如分裂、合并等操作，那么只需要对叶子节点进行加X锁（exclusive lock，叫排他锁，也称为写锁）即可完成修改。如下图中所示 ：方式二，采用悲观锁的方式如果对叶子结点的修改会触发SMO，那么会采用悲观锁的方式。采用悲观锁，需要重新遍历B+Tree，对根节点加全局SX锁（SX锁是行锁），然后从根节点到叶子节点可能修改的节点加X锁。在整个SMO过程中，根节点始终持有SX锁（SX锁表示有意向修改这个保护的范围，SX锁与SX锁、X锁冲突，与S锁不冲突），此时其他的SMO则需要等待。因此，InnoDB对于简单的主键查询比较快，因为数据都存储在叶子节点中，但对于数据量大且改操作比较多的TP型业务，并发会有很严重的瓶颈问题。在对叶子节点的修改操作中，InnoDB可以实现较好的1与1、1与2的并发，但是无法解决2的并发。因为在方式2中，根节点始终持有SX锁，必须串行执行，等待上一个SMO操作完成。这样在具有大量的SMO操作时，InnoDB的B+Tree实现就会出现很严重的性能瓶颈。解决方案目前业界有一个更好的方案B-Link Tree，与B+Tree相比，B-Link Tree优化了B+Tree结构调整时的锁粒度，只需要逐层加锁，无需对root节点加全局锁。因此，可以做到在SMO过程中写操作的并发执行，保持高并发下性能的稳定。B-Link Tree主要改进点有2个：1.中间节点增加link指针，指向右兄弟节点；2.每个节点内增加字段high key，存储该节点中最大的key值。新增的link指针是为了解决SMO过程中并发写的问题，在SMO过程中，B-Link Tree对修改节点逐层加锁，修改完一层即可放锁，然后去加上一层节点的锁继续修改。这样在InnoDB引擎中被SMO阻塞的写操作可以有机会在SMO操作过程中并发进行。如下图所示，在节点2分裂为节点2和4的过程中，只需要在最后一步将父节点1指向新节点4时，对父节点1加锁，其他操作均无需对父节点加锁，更无需对root节点加锁，因此，大大提升了SMO过程中写操作的并发度。由此可见，与B+Tree全局加锁对比，B-Link Tree在高并发操作下的性能是显著优于B+Tree的。GaussDB当前采用的就是B-Link Tree索引数据结构。InnoDB的索引组织表更容易触发SMO索引组织表的叶子节点，存储主键以及应对行的数据，InnoDB默认页面为16K，若每行数据的大小为1000字节，每个叶子节点仅能存储16行数据。在索引组织表中，当叶子节点的扇出值过低时，SMO的触发将更加频繁，进而放大了SMO无法并发写的缺陷。目前业界有一个堆组织表的数据组织方案，也是华为云数据库GaussDB采用的方案。它的叶子节点存储索引键以及对应的行指针（所在的页面编号及页内偏移），堆组织表叶子节点可以存更多的数据，分析可得在同样的数据量与业务并发量下，堆组织表会比索引组织表发生SMO概率低许多。性能对比 在8U32G的两台服务器分别搭建了MySQL（B+Tree和索引组织表）与GaussDB（B-Link Tree和堆组织表）的环境，进行了如下性能验证：实验场景：在基础表的场景上，测试增量随机插入性能。1.基础表总大小10G，包含主键随机分布的1000w行数据，每行数据1k；2.插入主键随机分布的1000w行数据，每行数据大小1k，测试并发插入性能。结论：随着并发数的上升，GaussDB能稳步提升系统的TPS，而MySQL并发数的提高并不能带来TPS的显著提升。综上所述，MySQL无法支持大数据量下并发修改的根本原因，是由于其索引并发控制协议的缺陷造成的，而MySQL选择索引组织表，又放大了这一缺陷。所以，开源MySQL数据库更适用于主键查询为主的简单业务场景，如互联网类应用，对于复杂的商业场景限制比较明显。相比之下 ，采用B-Link Tree和堆组织表的GaussDB数据库在性能和场景应用方面更胜一筹。

吊炸天的全密态数据库，到底是个啥？藏不住了，这全密态数据库真上头！有一种数据泄露的死敌，叫全密态！数据被标价售卖莫名其妙接到诈骗电话企业数据泄露事件让人恐慌......表面上看似乎是个人数据信息的泄露再深究其实是掌握着个人数据信息的企业面临的数据泄露、数据篡改等风险越来越多作为数据的核心载体数据库，该如何提供安全保障?这就需要一项能支持数据端到端加密的技术我们称之为：全密态今年2月，中国信通院已经联合华为等企业共同制定并发布了业内首个全密态数据库产品标准标准包含全周期数据库密态、密态数据处理加密算法与密钥管理、数据库基本能力四大能力域共计30个测试项有人问，全密态技术是做什么的？其实，把信息系统安全等级分解开来可以归为三点而全密态，指向的就是其中的“C”也就是在数据流动的整个过程中如何做到数据的完全机密性从而避免数据泄露和数据篡改的风险听着很厉害，背后的逻辑是啥？首先，一份数据会经历采集、传输、存储、处理、交换、销毁这样一个完整的流程环节多，数据被恶意获取的几率也大而全密态数据库除了有数据库的功能外还可以额外对数据进行加密保护用户自己掌握数据加解密密钥加解密过程仅在客户侧完成其他的查询运算在服务端完成因为从源头开始就直接对数据上了锁所以数据在整个流程中都是以密文的形态存在环节再多也不怕！如此一来不管在哪个环节，攻击者都只能碰壁信息泄露、数据篡改问题都迎刃而解了用户隐私和数据全生命周期的安全自然也不在话下对企业和用户来说这无疑是数据隐私安全风险的大救星！首先，用户信任 get √全密态让数据全流程高度安全因为客户自己掌握加密密钥企业也更容易获取用户的信任其次，个人隐私保护法律法规 get √假如没有全密态，就要在应用层加密企业要做大量的应用改造而且，加密之后无法直接进行数据的查询和处理数据库只能做单纯的存储查询处理数据时只能将数据从数据库中取出来再解密使用，累！有了全密态，直接对数据做加密保护企业遵守个人隐私保护法律法规，省心了用户使用也更放心再次，跨地域数据可信流动 get √很多项目都需要跨地域、跨企业运行比如东数西存数据的存储和结果在不同地域全密态相当于从源头就加上了一层带密码的保护罩跨企业、跨地域的数据可信自由流动也不是事儿了全密态这么能，国内到底哪家强？这就不得不提华为云GaussDB数据库了日前，华为云GaussDB 100%全量完成了中国信通院首批“全密态数据库”产品能力评测GaussDB凭啥做到业界领先？必须是强硬的技术实力！20年+投入，1000+人才投入不是吹的听说，今年华为的数据库团队还要增加到2000多人！难点一：如何让用户在使用上完全无感？还不需要修改原有的SQL语句、数据类型？GaussDB的处理方式是语法可以自动解析而且将语法解析工作内置到客户端驱动中不仅用户无感，还省力难点二：如何摆脱加密硬件的依赖？能不能只靠纯软件的方式来实现？答案是：能！GaussDB支持纯软方案全程以密文形式存储并且通过数学算法在密文空间直接进行查询和运算堪称安全领域的高精尖技术了！绝对是yyds！难点三：如何让全密态下的性能损耗是可控的？大家都知道，加解密必然导致性能的损耗GaussDB通过软硬结合数学算法可以直接在密文形态下进行查询而不需要在可信硬件环境下进行加解密过程传递从而极大减少了硬件IO和额外加解密时的性能损耗一个字，绝！当然，光说不练假把式是骡子是马，还得拉出来遛遛近日，华为宣布实现自主创新的MetaERP系统的研发完成对旧ERP系统的替换这场攻坚战是华为有史以来牵涉面最广、复杂性最高的项目这其中，GaussDB全密态技术至关重要支撑着华为这个业务遍布170+国家，服务于30亿人口的世界500强大企业的所有核心账务绝密数据的密文查询和计算筑起了数据安全保护墙从各个环节避免数据泄露简言之，全密态技术就像为用户数据从头到尾上了一把牢固的锁只有用户自己才有解锁的钥匙如此，数据安全威胁就再也“飙”不起来了！

5月16日，“数智深耕 让美好发生 2023华为云城市峰会广州站”成功举行。大会聚集了众多城市管理者、产业领袖、企业家和媒体，共同探讨工业数字化发展新趋势，共谋工业数字化发展之路。华为公司副总裁、华为云中国区总裁张修征，华为云生态解决方案部部长肖苡亮相大会，围绕行业数字化发展和华为科技创新实践进行了精彩演讲。聚焦实践，共建行业数字化与科技创新高地张修征说，在数字化转型中，战略驱动是根本、数据治理是基础、数据智能是方向，数与智融合的深度决定了一个企业迈入数字化新阶段的速度。华为在工业领域深耕了30多年，深刻理解工业数字化的关键，同时，华为也是数字化的赋能者，把自身数字化转型实践中的技术、方法、流程等经验沉淀在华为云上，叠加上云转型的方法论，赋能给工业领域的伙伴和客户。华为云GaussDB就是华为基于多年研发经验，结合数据库云化改造技术，打造出的企业级分布式数据库，为行业数字化转型提供一个安全可靠、性能强劲、自主创新的数据处理底座，并且历经华为内部和外部的实践考验，已经非常成熟。在内部，GaussDB支撑MetaERP系统实现了全面替换，完成系统迁移，这是华为有史以来牵涉面最广、复杂性最高的项目，还规模承载了华为终端云服务的业务。在外部，华为云GaussDB已经在工行、邮储、建行等多家国有大行上线，是金融政企科技自主创新的不二之选，希望为广东金融政企客户数字化转型和业务可持续长期发展提供一个更优选择。华为云GaussDB支撑华为MetaERP系统全面替换会上，肖苡围绕华为在工业领域的数字化建设和多年来的创新成果进行了分享，并详细介绍了华为内部MetaERP全面替换的成功实践。目前，MetaERP已经覆盖了华为公司100%的业务场景和80%的业务量。华为云GaussDB作为重要的智能数据底座，支撑MetaERP实现了存储空间的弹性扩展，轻松应对海量数据存储和并发访问压力，整体性能提升了10%以上；通过高可用容灾部署，保障了数据强一致，让业务不掉线；结合华为云数据复制服务DRS，在35小时内完成了高度关联的3200亿行数据搬迁验证，在不影响企业正常运转的情况下让整个过程高效、无感、安全。上线后的新ERP系统马力全开，各项性能和指标远远超过预期，轻松支撑起ERP系统5倍业务压力性能保持线性，10倍压力下系统不崩溃，采购履行耗时从90分钟下降到了15秒，端到端订单履行耗时从23分钟下降到了9秒，端到端业务效率得到了10倍提升。华为云GaussDB拥抱新技术，给世界一个更优选择GaussDB是华为主打政企核心业务负载的企业级分布式数据库产品，采用行业先进的全并行分布式架构，支持1000+超大分布式集群和PB级海量存储，具备应对海量并发事务处理与复杂查询混合负载的能力；跨中心多集群方案支持同城的两个数据中心完全部署两套独立的数据库软件，真正做到软硬件故障完全隔离、7*24小时服务不间断、双集群下RPO=0，以及极致的同步性能；在安全上，GaussDB已经做到了数据从传输、计算到存储的全流程加密，从而实现数据全生命周期内的安全保护，还通过了数据库领域国际CC EAL4+安全认证，做到源码级安全，是当前国内数据库在该领域获得的最高级别认证。当前，华为云GaussDB已在多家大客户中规模商用，历经华为终端云、华为流程IT、全球TOP银行、政企等严苛场景的考验。数字化时代下，各行各业更需要发挥数据的最大价值，通过核心技术创新来赋能产业智能化升级。华为云GaussDB有多年的技术实力和全场景、全开放的数据库服务，在这个数字化转型的关键时刻，将一如既往地深入打造数据库根技术，为千行百业科技创新提供坚实数据底座。

近日，北京宝兰德软件股份有限公司（简称：宝兰德）携手华为云完成宝兰德应用服务器软件9.5（BES Application Server 9.5）与GaussDB数据库兼容性测试，并获得华为云授予的技术认证书。宝兰德应用服务器软件（ BES Application Server ）是遵循最新JavaEE、JakartaEE 规范的企业级中间件，提供了规范定义的关键容器和服务，包括 Web 容器、EJB 容器、JMS 容器、事务服务、JNDI 服务等，为企业级应用提供一个稳定、安全、高效、基于标准的管理和运行平台，可帮助客户降低企业级应用的开发难度，支撑应用更加稳定、可靠、高性能、安全的运行。华为云GaussDB是华为自主创新研发的分布式关系型数据库，面向金融政企打造了企业级复杂事务混合负载能力，支持1000+超大分布式集群和PB级海量存储，同城双集群RPO=0业界领先，确保数据0丢失；实现数据全⽣命周期安全，是国内唯一一款满足国际CC EAL4+安全标准的数据库产品，为企业提供了功能全面，稳定可靠，扩展性强，性能优越的企业级数据库服务。宝兰德与华为云结合双方产品优势，基于宝兰德应用服务器软件9.5（BES Application Server 9.5）与GaussDB数据库共同打造了领先的联合解决方案。该方案对中间件数据访问层进行了多样优化，包括：数据库连接池化管理，分布式数据节点动态感知、自动负载管理、事务管理接口优化、SQL缓存优化等，通过这些机制帮助业务系统更好应对海量数据访问处理的需要，提供更高的访问效率、更高的数据可用性。目前，该解决方案已经在某大型国有银行的多个重要业务系统成功上线使用，并获得了客户的高度认可。随着企业数字化转型进入深水区，企业面临的业务场景更加复杂，华为云将继续携手产业伙伴一起构建更加高效、敏捷的数据服务，共同为各行各业提供高价值的数据库解决方案，助力企业数字化转型成功。

我们有个表，因为更新频繁，现在表膨胀了250%，空间占得比较多，浪费空间。

近日，在第六届数字中国建设峰会数字技术融合创新应用研讨会上，工业和信息化部网络安全产业发展中心（工业和信息化部信息中心）公布了 2022年数字技术融合创新应用解决方案征集工作成果，华为云GaussDB金融交易型数据库解决方案入选“2022年数字技术融合创新应用解决方案（典型解决方案）”。数字技术融合创新应用解决方案奖项是由工业和信息化部网络安全产业发展中心（工业和信息化部信息中心）牵头设立的，旨在进一步激发产业自主创新活力，高效促进供需协同发展，加强区域联动和资源整合。华为云GaussDB金融交易型数据库解决方案，面向金融政企核心交易和企业生产系统等复杂场景，通过在分布式领域创新，支持1000+超大分布式集群和PB级海量存储，同城双集群RPO=0业界领先，确保数据0丢失；实现数据全⽣命周期安全，是国内唯一一款满足国际CC EAL4+安全标准的数据库产品，已经构建起了完全独立的技术创新能力，解决了传统数据库在高性能、高可用、高扩展、高安全等方面的挑战，能够满足企业当下以及未来对数据库的需求。凭借卓越的技术能力，华为云GaussDB已经在工商银行、邮储银行等国有大行，以及多家股份制银行和保险证券公司，积累了非常多的成功经验。在邮储银行新一代个人业务分布式核心系统建设中，华为云GaussDB通过分布式、单元化架构设计，打破了容量瓶颈，提升了可扩展性，增强了业务连续性，实现了基于大型银行核心级场景产品能力的快速提升，为金融服务转型提供了技术支撑，具备高峰期每秒6.7万笔的交易处理能力，能满足邮储银行超6.5亿客户、18亿账户的服务需要。投产以来运行平稳，各项指标表现优异，全天联机交易处理时间仅需65毫秒，比原系统减少30％；日终处理耗时从273分钟减至197分钟，降低28％；季度结息总时长从140分钟减至25分钟，降低82％。华为云GaussDB此次入选，表明技术实力再次被权威认可，也更加坚定了其持续战略投入、技术创新的决心，未来将继续做好金融政企核心业务云化的智能数据底座，为千行百业提供更专业贴心的服务。

请问下GaussDB支持INSERT .. ON CONFLICT语法吗？

GaussDB创建视图后，无法对视图进行删除数据的动作吗？

本文作者丨数据库领域科学家、华为云数据库GaussDB首席专家  冯柯当前，金融等重点行业都在进行数字化转型，而分布式数据库作为数据承载工具，为数字化转型提供了有力的支撑。分布式数据库近年来发展迅猛，在产品成熟度上有了很大提升，但在行业应用和生态建设上仍有很多挑战。本文分析了分布式数据库发展情况、分布式数据库应用的主要问题，从行业应用的角度给出了分布式数据库发展的建议。一、发展情况过去三十年，以金融业为代表的核心信息系统架构依托IOE（即IBM、Oracle、EMC）技术，构建了一套集中、专用、封闭的稳态技术体系。但是，随着互联网及云化时代的到来，企业业务架构产生巨大变化，以银行为代表的金融业需加速构建敏态体系，推动底层数据库的分布式改造和互联网金融业务创新。分布式数据库具有满足行业关键应用的高扩展性、高性能、高可用性及软硬件解耦等特性，是金融等重点行业信息系统数字化转型的基石。（一）产品成熟度提升随着分布式数据库在金融等重点行业的不断应用，产品成熟度得到很大提升。一是新技术的不断发展使得分布式数据库在自身固有的优势领域，如扩展性、高可用等方面进一步强化，已有多个应用在重点行业核心业务中落地。二是国产分布式数据库的性能已经实现了与其他商业数据库持平甚至超越，这在多个大型企业机构产品准入测试及业内国际基准测试（如在线交易场景TPCC、在线分析场景TPCH等）中得到充分证明，可对行业核心业务起到重要的支撑作用。三是更多厂商开始提供对主流国产分布式数据库的功能支持，产品的兼容性取得显著进展。管理控制软件、迁移工具等配套设施逐渐完善，极大地降低了数据库的使用门槛和迁移成本。（二）生态逐步完善一是加快推动分布式数据库在重点行业落地，主流分布式数据库厂商纷纷与众多大型银行、企业等开展联合创新活动，取得了许多突破性的成果。以某厂商的分布式数据库为例，在与大型商业银行的联创过程中，已完成10个以上业务系统的分布式数据库替 换，覆盖银行A类到C类全场景业务。二是通过一站式的迁移解决方案，实现以较小的业务改造工作量从传统数据库向分布式数据库转型，迁移成本相对较低。而且使用分布式数据库后，业务系统运行稳定，可靠性和扩展性有所增强，从各项指标看，已基本具备承接Oracle及DB2大机下移的能力。三是分布式数据库相关的行业标准和评价体系逐步健全，对产品发展起到较强的规范引领作用。（三）总体发展情况向好当前国产分布式数据库已经渡过了“能用”阶段，正在迈向“好用、易用”阶段。横向来看，我国分布式数据库的发展基本与国际同步，tpcc、sysbench等性能指标和RTO、RPO等可靠性指标甚至具有优势，在应用领域取得些许领先。纵向来看，以金融业为例，分布式数据库应用取得较大进展，不管是在互联网新核心业务，还是传统核心业务中，分布式数据库行业应用落地数量大幅增加，有逐步替代集中式数据库的趋势。二、面临的主要问题（一）主体改造意愿不强，行业实践尚不充分一方面，原有数据库系统改造为分布式数据库，对用户及应用单位提出了较高的要求。改造所面临的成本问题，以及改造完成后分布式运维实施的复杂性，使得部分金融机构对于全面应用分布式还存在有一定的疑虑，主动改造意愿不强。另一方面，分布式数据库在行业典型应用场景中的落地仍处于摸索阶段。由于部分项目中存在一定的需求定制化，应用解决方案与产品的边界不够清晰，产品的规模化复制能力仍有待加强，行业最佳实践相对缺乏。这些因素也影响了金融机构对迁移采用分布式数据库技术的积极性。（二）分布式数据库的生态建设仍需加强生态建设是当前我国基础软件相对薄弱的一环，特别是对分布式数据库厂商而言，虽然在实现技术和产品方面实现突破，但在生态建设方面仍需积极应对投入转化慢、门槛高、市场接受程度低等挑战。一方面，部分产品的技术体系相对封闭，用户无法从市场快速获取合格的开发运维人员，导致业务改造及生产运维仍严重依赖原厂，规模化复制效应较差。另一方面，部分产品的开放性仍有待提升，与其他平台数据互联互通的能力不足在客观上造成了业务“上车容易下车难”的现实困境，增加了用户被锁定的风险。（三）可持续发展的盈利模式需进一步探索我国数据库的发展可以追溯到30多年前，在这样一个相对较长的发展周期内，技术和产品都取得了显著进展，但在产业化方面，知识产权的保护不够充分等诸多问题造成部分参与主体的市场化盈利能力较弱，产业整体规模难以做大。分布式数据库虽然已取得了一定进展，但“池子深才能养大鱼”，如何依托当前政策窗口，真正形成可持续发展的商业模式，还需进一步探讨。三、行业的应用建议尽管存在一些问题，但我们坚信分布式是数据库未来的发展趋势。如果将分布式数据库和单机数据库类比为“高铁”和“轿车”，因两者定位不同，期望“高铁”像“轿车”一样简单易用既不现实也不科学。所以应避免将分布式数据库的应用简单地理解为对单机或者集中式数据库的一对一替 换，而要深入考虑如何充分发挥分布式数据库的技术优势。遵循以上思路，我们对于分布式数据库在金融等重点行业的应用提出以下几点建议：（一）通过技术创新和最佳实践，推动行业应用不断深入一方面，要探索利用人工智能等新技术提升产品服务效能。人工智能技术可实现自动数据分区规划、故障自动诊断和自愈、自动负载均衡、面向混合负载的自调优等功能。目前人工智能技术在分布式场景已经有了一些单点突破，但距离全场景落地、实现整体成本的全面降低还有很长的一段路要走，需要继续加以积极的行业引导，推进技术交流和产业落地。另一方面，需充分发挥好示范项目效应。在金融等重点行业典型应用场景如分布式架构设计、多地多中心容灾等，形成最佳解决方案，并在行业推广落地。在此过程中，提炼出更适合分布式数据库的开发、运维、硬件建设等相关要求，研究制定数据库开发、运维、应用方面的标准规范，提高行业的标准化水平，引导各参与主体规范应用分布式数据库，推进行业转型。同时应约束不必要的定制化需求，减少无序竞争，实现技术聚焦。（二）积极推进生态建设，发挥产业引领作用从软件发展历史看，生态建设是基础软件产业化的重要一环。任何一款商业上真正成功的软件产品，无一不是生态建设上获得广泛认可的成功案例。首先，充分发挥产业联盟桥梁纽带作用，推动产业发展。在行业内积极进行资源引流，逐步提升技术营运效率及影响力，搭建高端对话平台，促进分布式数据库应用方、应用开发方及厂商更好地交流，共同面对分布式转型下的业务及技术挑战，推进行业生态繁荣；加强与分布式中间件、分布式服务框架的合作与交流，通过开源、社区等形式建立广泛的赋能体系；鼓励应用软件厂商全面向分布式架构转型，建立相应的培训体系和检测认证体系。其次，完善技术生态，鼓励引入第三方软件垂直提供商。在运维管控、工具端以及解决方案层面实现更多差异化的平台能力，加厚行业整体的技术底盘；鼓励第三方产品服务化和上下游集成，推进各产品的互联互通，打造良好技术生态，促进行业健康发展。再次，建立基础软件开放生态体系，推动开源建设。应鼓励有研发实力的厂商基于国产开源数据库做发行商，有运维能力的厂商基于优质的国产数据库打造适用于自主可控要求的数据库解决方案。数据库厂商和合作伙伴应基于数据库代码开源、产品开放等形式，使数据库产业从封闭商业生态走向产业共赢的开放生态，共同打造开放的数据库生态体系。最后，进一步推进政产学研合作，加强人才储备。明确人才发展战略，梳理多层次行业人才资源地 图。加强厂商与各科研院所合作，推进高校在包括数据库在内的基础软件方面专业投入，鼓励有条件的厂商和高校开展课程共建、实践共建，为联合推进分布式数据库关键技术在理论和实践层面的难点问题攻关储备智力资源。（三）全面拥抱云，开展行业可持续发展的尝试与探索数据库上云已逐步成为产业共识。发展云数据库，不仅是对技术和产品的重要升级，更是对数据库良性健康发展的商业模式有益探索，对于实现主体可控、支撑行业长期稳定发展具有重要的现实意义。分布式数据库与单机数据库不同，需要更大的集群规模才能实现资源的更有效利用。分布式数据库与云计算是天然伴生关系，通过云化部署，能够帮助分布式数据库扬长避短，充分发挥分布式数据库在扩展性、资源调度方面的灵活性和优势，在提升资源利用效率同时，显著降低运维成本，实现真正业务价值。一是云化基础设施可以通过智能调度、运维系统高效管理更为丰富的应用，并通过多云及边缘计算将应用扩展到多种场景中。二是软硬协同可为应用提供更好的性能，提升应用隔离性等。三是云数据库和云基础设施结合，如利用云基础设施本身的能力实现数据库的跨数据中心访问等，可使存储具备理解、预处理数据库语义的能力。基于以上，一是建议扩大云数据库在金融行业的应用规模。云数据库已经在互联网、电子政务等各行业得到了广泛应用，在金融行业的应用及推广也在稳步推进中。应引导重点用户单位与厂商尝试在行业落地云数据库及云平台，鼓励技术共创，共同探索基于现代云平台的分布式数据库运维及业务开发体系。二是建议推进行业云发展以提高行业标准化程度。在满足合规营运的前提下，应实现底层基础设施共享，降低中小用户对于分布式数据库的使用门槛和人才需求，减少重复投资，实现集约化营运，充分发挥分布式数据库的规模化优势。厘清各参与主体运营职责与边界，依托业内现有的成熟云平台技术，形成一个或若干个云技术底座，鼓励传统非云数据库厂商根据自身产品技术特点完成与云平台的对接，最终形成行业的云上产品集市，逐步简化并统一运维及交付界面，降低行业应用门槛，提高行业标准化程度。

本文作者丨数据库领域科学家、华为云数据库GaussDB首席专家  冯柯当前，金融等重点行业都在进行数字化转型，而分布式数据库作为数据承载工具，为数字化转型提供了有力的支撑。分布式数据库近年来发展迅猛，在产品成熟度上有了很大提升，但在行业应用和生态建设上仍有很多挑战。本文分析了分布式数据库发展情况、分布式数据库应用的主要问题，从行业应用的角度给出了分布式数据库发展的建议。一、发展情况过去三十年，以金融业为代表的核心信息系统架构依托IOE（即IBM、Oracle、EMC）技术，构建了一套集中、专用、封闭的稳态技术体系。但是，随着互联网及云化时代的到来，企业业务架构产生巨大变化，以银行为代表的金融业需加速构建敏态体系，推动底层数据库的分布式改造和互联网金融业务创新。分布式数据库具有满足行业关键应用的高扩展性、高性能、高可用性及软硬件解耦等特性，是金融等重点行业信息系统数字化转型的基石。（一）产品成熟度提升随着分布式数据库在金融等重点行业的不断应用，产品成熟度得到很大提升。一是新技术的不断发展使得分布式数据库在自身固有的优势领域，如扩展性、高可用等方面进一步强化，已有多个应用在重点行业核心业务中落地。二是国产分布式数据库的性能已经实现了与其他商业数据库持平甚至超越，这在多个大型企业机构产品准入测试及业内国际基准测试（如在线交易场景TPCC、在线分析场景TPCH等）中得到充分证明，可对行业核心业务起到重要的支撑作用。三是更多厂商开始提供对主流国产分布式数据库的功能支持，产品的兼容性取得显著进展。管理控制软件、迁移工具等配套设施逐渐完善，极大地降低了数据库的使用门槛和迁移成本。（二）生态逐步完善一是加快推动分布式数据库在重点行业落地，主流分布式数据库厂商纷纷与众多大型银行、企业等开展联合创新活动，取得了许多突破性的成果。以某厂商的分布式数据库为例，在与大型商业银行的联创过程中，已完成10个以上业务系统的分布式数据库替换，覆盖银行A类到C类全场景业务。二是通过一站式的迁移解决方案，实现以较小的业务改造工作量从传统数据库向分布式数据库转型，迁移成本相对较低。而且使用分布式数据库后，业务系统运行稳定，可靠性和扩展性有所增强，从各项指标看，已基本具备承接Oracle及DB2大机下移的能力。三是分布式数据库相关的行业标准和评价体系逐步健全，对产品发展起到较强的规范引领作用。（三）总体发展情况向好当前国产分布式数据库已经渡过了“能用”阶段，正在迈向“好用、易用”阶段。横向来看，我国分布式数据库的发展基本与国际同步，tpcc、sysbench等性能指标和RTO、RPO等可靠性指标甚至具有优势，在应用领域取得些许领先。纵向来看，以金融业为例，分布式数据库应用取得较大进展，不管是在互联网新核心业务，还是传统核心业务中，分布式数据库行业应用落地数量大幅增加，有逐步替代集中式数据库的趋势。二、面临的主要问题（一）主体改造意愿不强，行业实践尚不充分一方面，原有数据库系统改造为分布式数据库，对用户及应用单位提出了较高的要求。改造所面临的成本问题，以及改造完成后分布式运维实施的复杂性，使得部分金融机构对于全面应用分布式还存在有一定的疑虑，主动改造意愿不强。另一方面，分布式数据库在行业典型应用场景中的落地仍处于摸索阶段。由于部分项目中存在一定的需求定制化，应用解决方案与产品的边界不够清晰，产品的规模化复制能力仍有待加强，行业最佳实践相对缺乏。这些因素也影响了金融机构对迁移采用分布式数据库技术的积极性。（二）分布式数据库的生态建设仍需加强生态建设是当前我国基础软件相对薄弱的一环，特别是对分布式数据库厂商而言，虽然在实现技术和产品方面实现突破，但在生态建设方面仍需积极应对投入转化慢、门槛高、市场接受程度低等挑战。一方面，部分产品的技术体系相对封闭，用户无法从市场快速获取合格的开发运维人员，导致业务改造及生产运维仍严重依赖原厂，规模化复制效应较差。另一方面，部分产品的开放性仍有待提升，与其他平台数据互联互通的能力不足在客观上造成了业务“上车容易下车难”的现实困境，增加了用户被锁定的风险。（三）可持续发展的盈利模式需进一步探索我国数据库的发展可以追溯到30多年前，在这样一个相对较长的发展周期内，技术和产品都取得了显著进展，但在产业化方面，知识产权的保护不够充分等诸多问题造成部分参与主体的市场化盈利能力较弱，产业整体规模难以做大。分布式数据库虽然已取得了一定进展，但“池子深才能养大鱼”，如何依托当前政策窗口，真正形成可持续发展的商业模式，还需进一步探讨。三、行业的应用建议尽管存在一些问题，但我们坚信分布式是数据库未来的发展趋势。如果将分布式数据库和单机数据库类比为“高铁”和“轿车”，因两者定位不同，期望“高铁”像“轿车”一样简单易用既不现实也不科学。所以应避免将分布式数据库的应用简单地理解为对单机或者集中式数据库的一对一替换，而要深入考虑如何充分发挥分布式数据库的技术优势。遵循以上思路，我们对于分布式数据库在金融等重点行业的应用提出以下几点建议：（一）通过技术创新和最佳实践，推动行业应用不断深入一方面，要探索利用人工智能等新技术提升产品服务效能。人工智能技术可实现自动数据分区规划、故障自动诊断和自愈、自动负载均衡、面向混合负载的自调优等功能。目前人工智能技术在分布式场景已经有了一些单点突破，但距离全场景落地、实现整体成本的全面降低还有很长的一段路要走，需要继续加以积极的行业引导，推进技术交流和产业落地。另一方面，需充分发挥好示范项目效应。在金融等重点行业典型应用场景如分布式架构设计、多地多中心容灾等，形成最佳解决方案，并在行业推广落地。在此过程中，提炼出更适合分布式数据库的开发、运维、硬件建设等相关要求，研究制定数据库开发、运维、应用方面的标准规范，提高行业的标准化水平，引导各参与主体规范应用分布式数据库，推进行业转型。同时应约束不必要的定制化需求，减少无序竞争，实现技术聚焦。（二）积极推进生态建设，发挥产业引领作用从软件发展历史看，生态建设是基础软件产业化的重要一环。任何一款商业上真正成功的软件产品，无一不是生态建设上获得广泛认可的成功案例。首先，充分发挥产业联盟桥梁纽带作用，推动产业发展。在行业内积极进行资源引流，逐步提升技术营运效率及影响力，搭建高端对话平台，促进分布式数据库应用方、应用开发方及厂商更好地交流，共同面对分布式转型下的业务及技术挑战，推进行业生态繁荣；加强与分布式中间件、分布式服务框架的合作与交流，通过开源、社区等形式建立广泛的赋能体系；鼓励应用软件厂商全面向分布式架构转型，建立相应的培训体系和检测认证体系。其次，完善技术生态，鼓励引入第三方软件垂直提供商。在运维管控、工具端以及解决方案层面实现更多差异化的平台能力，加厚行业整体的技术底盘；鼓励第三方产品服务化和上下游集成，推进各产品的互联互通，打造良好技术生态，促进行业健康发展。再次，建立基础软件开放生态体系，推动开源建设。应鼓励有研发实力的厂商基于国产开源数据库做发行商，有运维能力的厂商基于优质的国产数据库打造适用于自主可控要求的数据库解决方案。数据库厂商和合作伙伴应基于数据库代码开源、产品开放等形式，使数据库产业从封闭商业生态走向产业共赢的开放生态，共同打造开放的数据库生态体系。最后，进一步推进政产学研合作，加强人才储备。明确人才发展战略，梳理多层次行业人才资源地图。加强厂商与各科研院所合作，推进高校在包括数据库在内的基础软件方面专业投入，鼓励有条件的厂商和高校开展课程共建、实践共建，为联合推进分布式数据库关键技术在理论和实践层面的难点问题攻关储备智力资源。（三）全面拥抱云，开展行业可持续发展的尝试与探索数据库上云已逐步成为产业共识。发展云数据库，不仅是对技术和产品的重要升级，更是对数据库良性健康发展的商业模式有益探索，对于实现主体可控、支撑行业长期稳定发展具有重要的现实意义。分布式数据库与单机数据库不同，需要更大的集群规模才能实现资源的更有效利用。分布式数据库与云计算是天然伴生关系，通过云化部署，能够帮助分布式数据库扬长避短，充分发挥分布式数据库在扩展性、资源调度方面的灵活性和优势，在提升资源利用效率同时，显著降低运维成本，实现真正业务价值。一是云化基础设施可以通过智能调度、运维系统高效管理更为丰富的应用，并通过多云及边缘计算将应用扩展到多种场景中。二是软硬协同可为应用提供更好的性能，提升应用隔离性等。三是云数据库和云基础设施结合，如利用云基础设施本身的能力实现数据库的跨数据中心访问等，可使存储具备理解、预处理数据库语义的能力。基于以上，一是建议扩大云数据库在金融行业的应用规模。云数据库已经在互联网、电子政务等各行业得到了广泛应用，在金融行业的应用及推广也在稳步推进中。应引导重点用户单位与厂商尝试在行业落地云数据库及云平台，鼓励技术共创，共同探索基于现代云平台的分布式数据库运维及业务开发体系。二是建议推进行业云发展以提高行业标准化程度。在满足合规营运的前提下，应实现底层基础设施共享，降低中小用户对于分布式数据库的使用门槛和人才需求，减少重复投资，实现集约化营运，充分发挥分布式数据库的规模化优势。厘清各参与主体运营职责与边界，依托业内现有的成熟云平台技术，形成一个或若干个云技术底座，鼓励传统非云数据库厂商根据自身产品技术特点完成与云平台的对接，最终形成行业的云上产品集市，逐步简化并统一运维及交付界面，降低行业应用门槛，提高行业标准化程度。

GaussDB 序列函数nextval(regclass)有两种调用方式，性能差异大吗？ gaussdb=# select nextval('seqDemo');   nextval ---------        2 (1 row) gaussdb=# select seqDemo.nextval;   nextval ---------        2 (1 row)