今天是国庆第一天，原本想休息的，没想到还得加班写点东西。这是因为昨天除了疲软多年的大A像吃了药一样暴涨20CM，还有一件十分重要的事情，最新一批数据库国测的结果发布了。原本老白以为这个结果要等到10月中下旬才会发，没想到在9月份的最后一天居然发布了。从这个事件也可以看出国家推进数据库国产化的紧迫程度。谈到国测结果必然要了解国测的目的是什么，它有什么作用？其实国测是为了确定哪些数据库产品是安全可靠的，可以应用于一些关键基础设施系统。国测的安全可靠级别有4级，第1级最低，第4级最高。通过国测可以给出一个国家层面认可的安全可靠数据库的清单。这个清单可以用于确定一些党政，国有企业等使用的数据库是否属于信创数据库；可以用于一些政府文件规定的表内产品的范围。如果您的企业或者单位对采购有一些政策规定要求，必须使用表内产品，那么这个表内指的就是国测的清单。有些财政补贴也是要根据清单上的产品才能合规，那这个清单也就是今天我们讨论的清单。对于大多数要做数据库信创的企业来说，这个清单可能是唯一的标准。如果说有人说他们拿到了某某评测结果，是安全可控的，那么他们的安全可控和国家层面的政策指的不是同一件事情。当然对于一些特殊行业，比如说军队，安全部门等等。他们的安全要求更高，会超出国测的标准。好了，前面我们介绍了国测以及国测清单的一些基本的概念以及如何来使用它。下面老白就带大家来解析一下这次国测清单的详细情况。首先说明的是国测的时间有效期是三年，因此去年发布的国测结果其有效期会到2026年的12月份。所以现在在表内的数据库产品应该包含了第1期的结果和本期结果，二者的合集是最终的结果。有些去年通过国测的数据库产品本次并没有参加测试，不过这些产品也应该在当前有效的清单里。而有些去年通过的产品，今年也送测了，但是大家可以看到有一个明显的特点，这些产品送测的版本和去年是不一样的，一般是拿出了最新版本去送测。本次的清单和上一次的清单有些不同。本次清单分为集中式和分布式两个部分，而去年都是集中式。大家可以看到有些厂商在本次测试中通过了多款产品，其中有有的是分布式，有的是集中式，大家应该把这些产品看成不同的数据库产品。另外一点大家要注意的是，本次测试的结果中级别有二级有一级，其中华为的集中式数据库获得了安全可靠二级认证，这是目前认证的最高级别。按照国家相关政策，国测结果是相当严格的，数据库产品厂商、数据库产品的名称、版本号都是十分严格的。比如阿里云PolarDB数据库管理软件（分布式版）V2.0通过了国测，有些人可能认为只要是PolarDB就安可产品，实际上，PolarDB有PolarDB-O、PolarDB-PG、PolarDB-M、PolarDB-X，这四个产品中只有PolarDB-X是正主，PolarDB-O是去年国测通过“阿里云PolarDB数据库管理软件（集中式版）V2.0”，而PolarDB-PG是PolarDB-O内核类似的近亲，PolarDB-M虽然和PolarDB-X是近亲，但是那是集中式数据库，和本次通过的产品明显不同。对于信创要求比较严格的单位在选择数据库产品的时候，一定要认真分析，别入了坑。如果大家已经明白了国测的一些基本情况以及结果的一些应用场景，那么下面我们就可以看具体的数据了。为了方便起见，我把去年和今年的结果合并在一起，给大家做一张表格参考。这张表格大家就可以获得全面的信息了。从版本上看，以OceanBase为例。目前OceanBase通过国测的版本是OB

我想国产数据库厂商肯定都很羡慕Oracle的售后服务体系，不仅有强大的知识库和原厂服务团队，还有更为强大的第三方服务体系。第三方服务大大减轻了原厂服务的压力，让Oracle变得更好用，使用成本也更低。因此现在国产数据库厂商都在考虑如何建立一个强大的，水平远高于竞争对手的第三方服务体系。现在很多国产数据库厂商在构建第三方服务体系时，也在学习oracle的经验。大多数国产数据库服务厂商学习oracle的主要是两个方面，一方面是考证，另外一方面是寻找第三方合作伙伴。但是这两方面学的都不太到位。先说考证，oracle在开始考证之前已经有了完整的产品文档，构建了完整的课程体系，完善了oracle大学培训体系，然后才开始进行收费的培训和考试。而目前的绝大多数国产数据库厂商的考证的培训课程十分粗糙，学习材料也十分简陋。oracle数据库的考证可以让学员通过系统学习掌握oracle数据库的各种技术，包括架构原理，技术特点，功能特点，运维和优化方面的要点。而国产数据库厂商的考证仅仅是让学员了解了数据库的一些基本概念，在教材的深度和实用性方面都存在很大的问题。因此国产数据库目前采用的考证这种模式，只是学了一个皮毛并没有学到他的精髓。在构建第三方服务生态方面，国产数据库的做法是找一些目前在做系统集成，服务外包或者数据库服务的企业，列出一些门槛，比如多少技术人员，多少拿到产品技术认证的工程师等等。通过认证的企业入选合作伙伴计划，并签订合作协议，在协议中为这些企业做保底，让客户放心选择这些企业。当用户需要买数据库服务的时候，数据库厂商会优先推荐这些合作伙伴给客户。这种做法似乎很科学，但是能够成功吗？我不大看好这种模式，因为这是一种传统的TOB销售服务模式。传统的系统集成商往往采用这种模式来开展业务。这种模式把合作伙伴当成低端的服务供应商提供给客户，而自己作为高端服务供应商作为兜底。数据库服务是一种与传统tob业务完全不同的业务，需要有大量的高水平的第三方服务人员为数据库厂商提供高端的支持服务。目前的数据库厂商所提供的这种第三方合作伙伴往往不具备高端服务能力，也很难从中产生数据库高手。因此用户从这些数据库厂商的合作伙伴那里无法获得令人满意的服务，最终压力还是会释放到原厂身上。不同于当年oracle在中国数据库市场的发展历程。国产数据库虽然诞生于竞争激烈的商业环境中，但是随着信创政策的不断优化，国产数据库厂商获得了相当肥沃的用户土壤。Oracle在中国的发展过程中，经历了中国信息化从无到有，从简单到复杂的整个完整的过程。初期的时候，用户群体并不多，用户需求也不复杂，因此oracle在中国发展其数据库产业的时候获得了极佳的口碑。同时也逐渐培养了一大批原厂的高水平工程师。与此同时，第三方服务生态也良性发展，出现了一批甚至比oracle原厂水平更高的技术高手。这些技术高手不断发展壮大，不断为oracle提供了优质的第三方服务，而且逐渐发展壮大，成立了一些规模相当庞大的服务公司。这些公司构建了完善的三线服务体系为oracle在中国的发展发挥了巨大的作用。而目前在国产数据库原厂认证下的数据库服务公司往往起源于一些系统集成商或者软件与服务外包商。他们在数据库服务领域最初的阶段是属于玩票性质的，技术水平并不高，而且对数据库服务业务的依赖程度也不高。因此企业内的资源倾斜也严重不足，导致服务团队能力普遍一般。他们往往习惯于提供质量不高，但是数量庞大的服务外包而无法提供数据库服务这样的高端的技术支持服务。这样的一些服务厂商占据了宝贵的市场资源，会使真正以数据库服务为核心业务，技术力量强大的专业数据库服务团队无法壮大，无法获得足够的订单，从而影响真正的数据库服务生态的构建。因为这种差距的存在，目前国产数据库的第三方服务企业缺乏保障数据库原厂高速发展的服务能力无法达到当年oracle服务生态的水准。目前的现状来看似乎印证了我的判断。目前国产数据库的培训体系没有真正培训出数据库服务方面的高手。第三方服务生态的技术力量也没有得到快速发展，没有出现一批围绕着国产数据库做服务并且赚到钱的企业。从一个旁观者的角度来看我对目前国产数据库构建服务生态体系的一些做法表示困惑，也表示担忧，不知道有没有朋友和我有同感。

最近问一个用户他们的国产数据库用得怎么样。他们从去年下半年做好了数据库选型，开始做数据库迁移工作。经过一年时间，已经迁移了三十多套系统了。他回答说：“还可以吧，迁移过去的系统现在运行得还算稳定。国产库小毛病挺多的，坑不少。如果早点了解这些坑，可以节约很多成本”。他感触最深的是如果数据库厂商能够在他们开始工作之初告诉他们，自己的产品存在哪些坑，需要在应用和数据迁移时注意些什么问题，那么他们的工作就好做多了。很多次他们遇到问题，找到原厂一问，马上就能得到回答，显然这些问题对于厂商来说应该都是已知问题。但是除非他们遇到了，厂商绝对不会提前告知他们产品存在的问题。数据库原厂的朋友也很无奈，他们不能主动把数据库存在的问题主动告诉客户，因为这会影响他们产品的口碑。有数据库选型决策权的领导一般不大懂数据库，因此如果领导知道某个数据库存在各种各样的缺陷或者限制的时候，就不会选择这个产品了。因为怕领导不大懂数据库，所以不向用户提示数据库产品的应用限制和已知的小问题，这件事怎么看怎么不靠谱，但是确实是目前广泛存在的现象。国产数据库不仅对客户而言比较陌生，连竞争对手都不知道如何去攻击竞品，再加上行业引导不足，就导致了领导眼里的评价体系十分不合理。但是对自己的产品存在的问题遮遮掩掩，这类顽疾不驱除，是会影响国产数据库的口碑的。但是我们能把一切责任都推到领导不懂数据库上吗？领导按理说就不应该太懂数据库。其实这个例子中不是领导出了问题，而是选型决策的方式出了问题。领导不懂数据库还有一个挺有意思的案例，领导要求更换国产数据库，技术团队通过各种测试与分析选择了合适的产品。但是领导没接受技术团队的建议，而是直接招标，选择了最便宜的数据库。技术团队看到招标结果，立马傻了，与原有数据库兼容性差异太大，应用必须做彻底改造才行。去和领导沟通，领导说，不都是数据库吗，都支持SQL语句，能差到哪去。最后领导终于搞懂了不同数据库是有差异的，但是已经骑虎难下了。不过领导还是有办法的，给开发商另外搞了一笔改造费用，搞定了这件事，最后皆大欢喜。这件事确实是领导不太懂数据库引起的，不过根源仍然不是领导懂不懂数据库，还是决策的程序不科学的问题。有点跑题了，还是回到开头的那个问题。因为怕领导不太懂数据库而不和盘托出自己产品的一些问题，这会给客户带来更多的问题。用户用上了国产数据库，运维的问题又出来了，遇到问题不知道怎么处理，只能去找原厂。原厂刚开始还能立马派人到现场，后来原厂也没办法维持这样的服务了，开始远程指导用户的DBA。DBA也挺聪明的，很快看出这个国产数据库和某开源数据库有点相似，于是下回遇到问题，原厂响应不够及时的时候也不会傻等了，会去网上找解决那个开源数据库的方法去处理，有时候还真能解决问题。久而久之，找原厂的次数就少了，运维效率也提升不少。DBA就问原厂工程师你们都产品是不是基于某开源数据库开发的？为啥不早说呢，害得我们瞎摸索了好长时间。原厂工程师也很无奈，如果你们领导知道我们数据库基于某开源产品，又要说我们不是真国产，不买我们的产品了。我想这个问题仅仅甩锅领导或者流程就不合适了，数据库国产化的产业引导的路数看样子也有问题。把安全可靠简单地和原创挂钩，本身就不够科学。这种不够科学的思想引导下，使用开源代码好像低人一等一样。所以大家就拼命去掩盖自己的出身，这反而给用户带来了很大的困扰，不利于国产数据库产业的发展。大多数开源数据库其实离企业级数据库还有很大距离。我一直有个疑问，如果不要花过多的精力去掩盖自己的出身，把更多的研发成本投入到把开源数据库变成一个安全可靠的企业级数据库上去，是不是更好一些呢？

因为“自研数据库”这个词比较敏感，几乎所有的国产数据库厂商都号称自己是自研的，所以今天的文章可能会有些争议。其实我眼中的“自研国产数据库”是指数据库核心代码走自主发展道路的数据库产品，可能最初某些数据库产品最初参考了某些开源数据库的设计思想，甚至使用或者参考了开源数据库的代码，但是公司的核心研发人员已经总体上掌握了代码，并且对这些代码进行改写，数据库产品已经脱离开源社区独立发展，今后内核升级不再跟随开源数据库的核心，那么就可以将此数据库归类为自研数据库。自研并不等同于每一行代码都是自己写的，我不太认同一些国产数据库厂商所宣称的每一行代码都是自己写的，因为这种做法太浪费有限的

很多朋友把国产数据库的起源设定到1977年的黄山会议，那是中国学术界对数据库这个专业技术的第一次广泛的讨论和交流，确实意义非凡，不过这次会议并不能真正算是国产数据库产业的起源，只能说是国产数据库技术的启蒙。

周六早上在高铁上匆匆忙忙写了一篇，有些地方考虑不周，因此很快撤回了。有朋友留言说他们挺关心我所谈的内容的，希望我能私发给他。我觉得还是重新编辑一下，再次发出吧。最近和信创相关的事件太多了。大到美联储降息，中美科技金融战进入新阶段。黎巴嫩发生的超限战争突破了人类罪恶的底线，也会让一些总是认为我们夸大了信息安全的必要性的人打肿了脸，国家战略下，啥事发生都不奇怪。其实十五年前的那场“震网行动”可能很多年轻的IT人都不大了解，那次被渲染成以色列特工兵不血刃达成了轰炸机、导弹都无法达到的战略目标的黑客行动的幕后是否像美国人透露出来的一样也已经不重要了，重要的是数字化安全领域的战争的残酷性已经暴露无遗。当事件发生的时候，我认为这是《超限战》在现实中的首战案例。从XC工作本身来看，近年来，一系列XC相关的鼓励政策也陆续出台，这也让用户侧的积极性大大增加。从数据库行业来看，2024年第一批国测的结果也很快要发布了。这回参测的企业涵盖了集中式、分布式、分析型数据库中的主流产品。新名单的出台，对于目前正在选型阶段的数据库用户来说，指导意义非凡。也会让一些在选型时拿不定主意的用户能更加精准地去选择。上面罗列的事件都是XC加速的催化剂，也是目前大多数人已经接受和认可的，当然还是会有一些朋友不大接受国产化替代的必要性问题。我的观点是如果你从事数据库这个行业，那么不管你是否接受国产化替代，国产化替代都是你必须去认真关注的。如果你有绝对的实力不去理会这个现实，那么你可以继续按照现有的轨道发展下去，否则你必须去改变你的观念，尽快融入到这个工作中去。我以前说过今年国测结果发布，可能国产数据库的竞争就进入下半场了。通过国测的产品将会在主战场上厮杀，而没有通过的，或者还没有报名参加的企业就必须考验资金和定力了。不是说没机会了，而是说路更难走了。国测其实也是一种产业引导的好手段，百库争雄的市场肯定不是一个好市场，大家都很难吃饱，强者也会饿得面黄肌瘦的。把通过国测比喻为拿到入场券并非夸大其作用，所有的政策肯定都只针对表内的产品。没拿到入场券的厂家要么抓紧融资，继续努力，争取吃到点残羹冷炙，补补身子，再去厮杀，争取在未来的市场中树立起自己的旗帜，用技术能力和产品力去获得重生。要么干脆将产品捐献给开源基金会，换个赛道继续找机会，不过这条路走下去会如何，实在不太好说。在中国搞开源数据库产品目前还没有看到特别成功的例子，除非产品力够强，能够出海，在全球的公有云市场上有所作为，否则这条路相当艰险。还有一条路就是兼并重组。在地主都没有多少余粮的情况下，我想很多大厂不一定会花钱去收企业，等着一些小厂熬不住时候收人可能更划算。因此当下半场正式开赛的时候，这条赛道里也将会充满了血雨腥风。这个下半场注定是血肉模糊的生死场，国产数据库的资本狂欢可能会告一段落，更加理性的投资和创业会逐渐回归。围绕数据库周边生态也将快速发展，一鲸落万物生，我看好涅槃后的国产数据库市场。幸运地走向下半场赛道的厂家也依然不能掉以轻心，未来的国产数据库市场的竞争者虽然只剩下一二十家了，与百库竞渡时有所不同。不过周边的对手都是非同一般的强者，竞争的残酷程度其实是更高了。想要在决赛中胜出除了自己要有十分强大的产品力之外，还有一个十分重要的因素就是生态力。产品力是企业自己练内功，加大投入就可以提升的。生态力的提升难度要大多了。国产数据库为什么需要建立强大的生态，这个问题可能不需要多说，周五晚上我和几个业内的大佬在上海小聚，大家谈得最多的两个字就是“生态”。Oracle数据库在中国乃至全球的成功，不仅仅是自己的产品做得好，其良好的生态是十分重要的助力。国产数据库厂商都在羡慕Oracle的生态，但是Oracle的生态是怎么建立起来的呢？用最简单的说法，那就是“让参与者都挣到钱”，换句话说就是Oracle数据库产品让Oracle数据库服务成为一个赚钱的买卖。我和国产数据库厂商交流生态建设的时候，经常会用这个观点去问他们，你们目前能让第三方服务厂商赚到钱吗？只有参与生态的厂商都赚到钱了，才会有更多的生态厂商加入到你的生态圈。随着数据库国产化替代工作的加速，原厂服务跟不上其实是数据库厂商和数据库用户都看得见的。不过现在广大的数据库用户还是希望最好能由原厂来提供服务，因为他们对第三方服务的能力表示怀疑。数据库厂商也只好硬着头皮强撑。目前国产数据库中，售后服务队伍最大的是达梦，它们有大约600人的售后服务团队。看似很多，但是如果在2-3年内大量的客户做数据库迁移，这几百人根本不够用的。想要发展第三方服务生态，就必须有足够多的可以赚到钱的项目交给第三方服务商，但是目前这一点还无法实现。国产数据库厂商也都在发展第三方服务合作伙伴，但是目前的做法是值得商榷的。他们会通过设置一些门槛找一些比较有实力的，愿意参与其中的企业进行合作。这些生态伙伴暂时无法通过和数据库厂商的合作盈利，不过他们有一定的实力，可以撑一段时间。这个方法看似不错，不过有个致命缺点。那就是这些厂商虽然目前可以不盈利，但是这块业务不是他们的主业，也有可能永远不会成为他们的主业，因此无论从技术能力，人员构成，组织架构，项目实施等方面，和当年的Oracle第三方服务商的本质是不同的。利用这种方式去复刻当年Oracle的成功，可能并不一定靠谱。无论如何，在国产数据库的下半场里，产品力和生态力将是决定某个数据库能否成功胜出的关键。加大投入，提升产品的能力和加大投入，加快生态建设，都是想有所作为的数据库厂商应该抓紧去考虑的问题了。

RAC，如果你的安装过程按照攻略，没遇到任何问题，那不是白学了”。后来我找出了2016年参加DTCC的时候的一份演讲材料发给他，这是我给当时正要进入Oracle

昨天刷到一个视频，说为啥排长队的奶茶店动不动就倒闭了，而门可罗雀的五金店反而活得好好的。看完之后颇受启发，感觉五金店的成功对数据库这个产业也是有所启发的。如果你仔细观察周边，你会发现周边的小超市都没了，而活得比较久的是那些大型商超和小区边上位置很不起眼的小五金店。大型商超能活下来的原因很简单，因为有丰富的商品和服务向周边庞大的用户群体提供。小五金店靠什么存活下来呢？首先是规模小，客单价低，利润率高。大部分小五金店是夫妻家庭店，而且选址都是周边最便宜的店面，店面也就十几二十个平方。而店里卖的东西进价极低，库存占用的资金也不大，因此经营成本被极致压缩。而大部分用户一次性购买的单价虽然不高，其利润率极高，都是在50%以上，因此在维持较小营业额的情况下，能够确保有比较好的利润。其次是客户目标导向高，交易成交率极高。大部分人跑到小五金店来，其目的性是很强的，只要这家店里有的商品

GROUP中，那么可以避免表分布过于分散，读放大影响太大，也有助于降低网络的延时，从而提高系统的响应速度。在上面一个表里还需要注意的是GTM

上面几行代码的实际执行效果如上图，对于某些能够梳理出来的问题分析场景，其分析结果对于稍微有经验的运维人员来说还是比较容易理解的。这个工具比泛路由工具更为精准，与泛路由工具结合，可以获得更好的效果。

周五PGCONF南京站的活动异常火爆，这让我对南京是DBA的沙漠这句话开始怀疑起来。期间也和一些DBA朋友做了些交流，其中有一个话题是未来的DBA需要些什么新技能。有很多DBA关注这个话题，我也有些意外，说明南京的DBA还不是那种想躺平的类型。实际上作DBA为一个专业职业群体也只有三十年的历史，不过回顾这三十年，DBA的职能和技能构成还是在慢慢变化的。我刚刚入行的时候，DBA的技能很简单，能把数据库装起来，能启停数据库，能做简单的参数调整，能帮开发商建个表，设计个索引，能把监听器玩明白就已经是顶级DBA了。数据库备份都不是DBA的专业技能，在RMAN都没有的时代里，能做个exp逻辑备份的企业都算是管理很好的企业了。而有钱的企业会购买专用的备份软件，因为这些软件早期主要是备份文件系统的，所以数据库备份的职责那时候是归系统管的，或者有些大企业有专职的备份工程师。那时候的普通DBA大多数都是从系统工程师或者系统集成工程师转行来的，大多数没有任何编程经验。写SQL也是为了管理数据库才开始学的，并不精通。如果能写一些SQL脚本工具，甚至一些shell脚本工具，那就无敌了。我是码农出身，还干过系统集成，C语言，SHELL，SQL，网络，服务器，操作系统都能搞一些，甚至还能破解被加了密的Oracle，因此能力比较全面，学各种新东西也比较快，因此很快我就在这个行业里拥有了一些死粉用户。随着应用系统日益复杂，对DBA的要求也越来越高，DBA除了安装部署与日常管理，还需要能够帮用户分析与定位故障，做性能优化。这些对于DBA来说要求就很高了，因此在这个阶段DBA的职能出现了分支，一些只擅长于安装部署和简单操作的DBA成为了一线的操作员和管理员，具有一定优化与故障分析能力的DBA成为了二线、三线专家。而我因为对操作系统和小型机硬件的理解比普通的DBA强一些，在解决复杂问题的方面拥有更广泛的视野，解决复杂问题的能力也高于那些不懂系统的DBA，因此在这个领域里的名气也逐渐大了起来。

明天我的分享还是PG可观测性方面的问题，很多DBA经常会混淆可观测性与监控的区别，前几天一个朋友和我说他们

7.4修改协议的事情这阵子一直很热门，大家都在讨论还有哪些开源软件有变更协议的可能性。实际上我前些年也写过多篇关于开源协议的文章，探讨过一些这方面的问题。当Redis

坊间传闻自行车变速器也是一个卡脖子项目。因为生产工艺要求极高，国内技术达不到要求，因此自行车王国的变速器80%非国产，其中1000块钱以上自行车使用的中高端变速器的自主率更是不到5%。原因是自行车变速器的材料特殊，加工精度要求极高，国内存在技术瓶颈。也有明白人指出自行车变速器并非国内做不了，而是比较少企业在做，投入也有限。一方面原因是国内的自行车生产企业大多处于产业链的低端，利润率较低，没有资金投入到变速器的研发中；另外一方面的原因是国外的头部企业已经在这个领域申请了大量的专利，把很多条制造自行车变速器的捷径都给堵住了。国内厂商只能选择加工难度大，制造成本较高的技术路线，因此很难做大做强。国内的自行车变速器产业想要发展壮大，必须找到能够绕开国外专利的低成本制造方法才有希望。我也大致了解了一下，头部的日本和欧美企业在国内申请了近3000个自行车变速器相关的专利，从专利壁垒上已经将中国企业超车的路线大部分堵死了。在2G/3G时代，通讯行业也存在过类似情况，因此全球最大的通讯用户市场变成了专利持有者杀戮的韭菜地。不过在4G/5G时代，中国的厂商提前预研，终于在这个巨大的蛋糕中分得了自己的份额。在数据库领域其实也存在类似的问题，截止到2021年7月，中国所有的数据库厂商的数据库领域核心专利数量不足4000个，而Oracle一家拥有超过14000个数据库领域核心专利。到2023年底，Oracle的数据库核心领域专利数量已经超过了19000个，其增长速度之快，令人惊讶。除了因为大量使用开源代码可能带来的一些许可证问题之外，数据库领域的专利壁垒可能会成为制约我国数据库产业发展的一个新的问题。前两年和一个国产数据库厂商交流的时候，他们就和我讨论过专利的问题，他们在实现某个数据库功能的时候发现要实现这个功能的很多技术方向都已经被Oracle注册了专利，因此他们想了很多方法，花费了比预期高一倍的研发投入，才避开了Oracle的主要专利。在一次数据库相关的活动中，我和多个国产数据库厂商的负责人交流过这个问题。有些厂商表示十分吃惊，并准备回去认真研究。而有些厂商对此不以为然，认为只要我们可以不出海，只在国内玩玩。实际上这种态度是不可取的，哪怕我们不出海，只是在国内卖一下数据库产品，就可以无视专利壁垒吗？这种态度也应该是国外的数据库专利持有者所喜闻乐见的吧。如果我们在国产数据库中不注重专利问题，那么当我们的国产数据库市场竞争尘埃落定，少量企业胜出准备赢者通吃的时候，也就是国际专利巨头收割之时。那时候他们只要聘请一些律师，就可以吃掉大量的国产数据库替代的市场红利，通讯行业的历史恐怕要再一次在数据库行业重演。

最近大疆推出的油车智驾系统的话题十分热门，似乎油车靠着大疆的7000块钱一套的便宜量又足的智驾解决方案再次实现弯道超车了。一些油车拥趸也因此欢欣鼓舞，觉得这个消息又狠狠地打脸了原来好几万起步的电车智驾解决方案。虽然我不太懂车，不过也算是开过车的，特别是开过电车后完全颠覆了我对开车的认知。原来汽车的动力延迟可以是这么低的，原来你可以想开多快马上就能获得无延迟的动力输出的，原来车机的丝滑程度可以和我的手机差不多的。从我对车的浅薄认知，我就觉得大疆号称7000块钱的L2级别的智驾套装可能不会比现在我的油车上的智能巡航定速功能强多少。也许智能跟车、道路保持的能力会比我现在开的车好一些，但是绝对达不到某些电车的智驾能力。电车的智驾能力不只是一套辅助系统加装在某辆车上就可以的，是一个高度集成的精密系统，从各种传感器、摄像头、超声波雷达、激光雷达在一个强大的车机系统的处理下实现的。而且还有一个必要条件，那就是电车的核心-动力系统。电车的动力系统的输出延时远超油车，因此在处置复杂应急场景的时延也很低。如果换了油车的发动机，发动机的动力输出延时有时候要达到秒级，因此其延迟要比电车高得多，因此在危机应对核心能力方面比电车弱很多。要想在油车上实现与电车同等级的智驾，其处理复杂度只会更高，不会更低，同等效果的智驾系统，其成本在油车上也不可能会大幅下降。基于此判断，你对大疆7000块钱的大礼包能干点啥也不要期望太高，大疆虽然积累了丰富的视觉避障和导航的经验，但是把这些技术下沉到油车上，受限于油车的基础能力，不可能有特别强大的能力输出。咱们是搞数据库的，所以谈到后半程还是回到国产数据库上来，我们总是在谈弯道超车，或者说换道超车，不管如何总的来说都是要超车。集中式数据库想要超越Oracle短期看不到希望，那么我们就换个赛道，用分布式数据库去打。这些年来，我们有点绝望地发现，分布式数据库也不见得能打得过O记。这一点上有点像油车想加装一个大礼包就能实现对电车的超越一样，因为核心动力不够强大而希望渺茫。

Model结构更是千差万别，运维诊断的思路更是差之千里。因此哪怕国产数据库想要做AWR报告，那也应该根据自己数据库的自身特点、指标体系、Time

Profile在指标选取上有点刻意学习Oracle了，实际上GaussDB的负载指标与Oracle有较大的不同，可以提供比Oracle还丰富的负载信息，包括select

昨天TechTalk公益社区的首场线上交流参加的DBA朋友很多，大家也很热情。昨天线上交流的时候因为时间有限，有些观点并没有表述得很完整。今天早上我就这几个问题重新思考整理了一下，分享给大家。讨论1：“随着运维越来越智能，DBA和AI的结合，未来DBA职业的发展”。AI的发展趋势是我们所无法左右的，英伟达的老黄甚至认为通用人工智能（AGI）将会在5年内出现，可能这个观点有点乐观，不过也不会太不靠谱。如果真的在5年左右产生AGI，那么在15年到20年左右，AGI将会逐渐成熟，并深度影响整个世界。因此DBA要做好与AGI共存的准备。不过大家也不用过于焦虑，AI可以成为DBA前所未有优秀的工具，而不会拿走DBA的工作。只不过那时候的DBA在技能和从事的工作内容上会有所不同，能够与AI更好融合的DBA具有更大的优势。如果我们想要拥抱这个趋势，现在开始可以从以下几个方面去做些准备。1）以更加开放的态度去接触AI，而不是出于恐惧或者其他原因故意远离它。现在的AI在DBA领域可能还很弱智，但是它的成长是很快的。今早认可它，接触他，使用它是更好的态度。2）有开发经验的DBA，除了会写SQL外，最好再去学会PYTHON编程，PYTHON很简单，我这个50多岁的人没有看任何书籍，仅仅依靠以前C语言那点功底，遇到问题问问同事，也可以写一些PYTHON脚本，改一些PYTHON代码了，所花的时间不到半个月。3）可以去尝试利用PYTHON和一些算法去分析你手头有的数据，哪怕是ASH，AWR数据都可以。从生产环境中导出这些数据，在自己的电脑上尝试用一些简单的AI算法去做异常检测，去做模式分析和归类分析，你会发现一个全新的世界。当然我这仅仅是给有兴趣的朋友的建议。

很多DBA朋友十分排斥AI，认为AI不靠谱，认为AI永远也替代不了DBA。其主要出发点并不是真的认为AI技术没有前途，而是出于一种畏惧，认为AI是DBA未来最大的敌人。其实这种畏惧是完全没必要的，因为AI不是DBA的敌人，而将会成为DBA的好帮手。数据库技术在不断的发展，DBA这个职业也在不断的进化，DBA的工具更是不断的在进化，而AI将会成为未来DBA最重要的工具之一。实际上很多DBA不仅仅排斥AI，甚至会排斥DBA工具。二十多年前甚至三十年前的DBA是排斥工具的。当时有一种观点是sqlplus和svrgmrl才是最好的数据库工具，高手

很多年轻的DBA总是羡慕老法师总是能够在复杂的问题现场中很快的抓到问题的关键，准确的定位问题解决问题。而到了自己的头上，总是像段誉刚刚学会六脉神剑一样，灵感忽有忽无。实际上这是知识积累的深度与厚度的差异导致的，老法师们经历过大量的实战案例，积累了丰富的运维经验，同时通过不断的学习掌握了足够的原理与技能方面的知识。因此在他们的脑子里已经构建出了一个十分庞大的知识图谱，因此能够面对任何问题的时候都游刃有余。而你则是因为知识与案例积累不够，学过的知识都是点状的，无法构成四通八达的图谱，因此总是在分析问题的时候卡住。帮DBA朋友们更加快速的构建运维知识突破，打通脑子里的任督二脉是我一直在做的事情，2010年左右编写的《DBA的思想天空》就是希望通过对Oracle基本原理的理解，实现原理与实战融合的目的。有不少DBA朋友第一次线下见到我的时候总是说我是看着这本书开始学习DBA的技能的，这总会让我很高兴，自己的思想能够给别人帮助，是最令人高兴的。以这个enq:

昨天有朋友留言为什么不讲讲国产数据库的优缺点，实际上我写《国产数据库百态》并不是去点评某个数据库的技术上的优缺点，而是把我了解的一些国产数据库的架构，模式，目前的应用情况和市场情况和大家分享一下。一个国产数据库替代项目的成败不取决于选用了某个最牛的数据库产品，事实上目前的国产数据库与Oracle等国外商用产品之间还存在较大的技术差距，这一点是业内大家都认可的，无需我多说。实际上数据库的先进与否与一个信息化项目的成败之间有十分本质的区别。前阵子有个朋友谈到最近某大行用国产软硬件和数据库替代了原来的大型机系统。替代大型机这么高大上的项目，数据库一定很牛吧，这个项目里使用的是GoldenDB。前两年我们更多的是在讨论各种数据库架构的优劣，各种数据库产品的优劣，实际上从今年开始，再过多的做这种讨论，意义已经不是很大了。国产数据库市场已经起步，而且已经显现出一定的趋势，这个趋势往往不是技术导向的。2024年很可能会出现云下销售超过十亿甚至二十亿的企业。而在被认为国产数据库市场小年的2024年，也已经出现了多个云下数据库产品销售额数亿元的企业，这些企业将会在今后的国产数据库市场的竞争中具有很大的优势。数据库产品的技术不是决定市场的因素，其企业的总体竞争力才是。因此从2024年起，作为DBA，对国产数据库的关注点需要有所转移了。很多企业的国产数据库选型已经尘埃落定，剩下的很多企业也会受到先行先试成功案例的影响。因此如果我们不是这件事的决策人，没必要过多地去纠结数据库产品的优缺点，而是应该更加关注市场上的领先者了。昨天晚上，我录了一段数据库嘉年华2024的祝福词，其中有一个是当前数据库领域最令人关注的话题，我认为是变革。我们处于一个变革的时代，我们面临着巨大的变革。数据库国产化替代、智能化运维、Serverless

国产数据库百态（2）分布式数据库篇分布式关系型数据库在国内发展得很快，在墨天轮上的186个关系型数据库中，分布式数据库占了将近一半，有八十多个。DB-ENGINE排行榜中，国产数据库收录不多，排名也比较靠后。这和DB-ENGINE对数据库流行度的评估标准有关。DB-Engines

去年我写过一篇文章《PG数据库离企业级数据库还有多远》，实际上对PG了解得越深入，这个问题就越值得我们去思考。前几天一个做数据库高可用架构的朋友在我的公众号上留言，说在PG数据库中，如果删除了某一个数据文件，PG数据库居然不报错，还能查出数据来，不过查出来的数据是错的。这一点我以前倒是没有注意到，数据库丢失数据文件不报错是正常现象，不过查询数据的时候，如果扫描到了这部分内容，按理说应该是会报错的，比如Oracle就是如此。昨天下班前我正好有点时间，就做了个小实验。实验内容有点长，我先讲一些结论性的东西，有兴趣了解细节的朋友看完结论性的分析后再去看实验的详情吧。数据文件的完整性检查是一个开销十分巨大的操作，因此几乎没有数据库会随时对数据文件的完整性做检查。连Oracle这种段页式结构，以表空间为组织模式的数据库都不会随时去检查数据文件的完整性和可用性。只有在访问某个数据文件的时候才会通过文件头去做一些校验。不过对于数据文件中的数据的一致性仍然不会去做检查。这是一种更大开销的操作。只有访问到相关数据的时候才会去做一致性和完整性的检查（并不是所有的访问操作都会做）。不过不管如何，RDBMS系统要尽可能保证查询出来的数据的逻辑一致性，确保数据一定是正确的。对于Oracle这样的数据库，文件的属性被记录在control

D-SMART高斯专版已经开发了几个月了，目前主要技术问题都已经解决，也能够初步看到大概的面貌了。有朋友问我，Gaussdb不已经有了TPOPS了，为什么你们还要开发D-SMART高斯专版呢？实际上TPOPS和D-SMART虽然都可以用于Gaussdb的运维监控，不过其分工还是十分明显的。TPOPS是华为GaussDB自带的运维工具，从数据库部署开始就一直可以使用。TPOPS+DBMind也具有一定的运维分析能力，不过这些功能都是基于传统的运维管理理念的。D-SMART是一个运维知识自动化系统，其目的是实现更加数字化的运维监控、故障预警、根因分析（RCA）、自动化巡检等，今后还会依托D-SMART的数据构建线上的SAAS生态。D-SMART是一个十分强大的知识自动化平台，可以不断沉淀用户自己的运维知识，包括各种健康模型、故障模型和诊断工具。这些都是TPOPS不具备的功能，因此D-SMART可以作为TPOPS的有效补充。另外一方面，D-SMART高斯专版会支持所有的高斯生态产品，包含华为GaussDB集中式/分布式，openGauss、南大通用GBASE

十年前在一个沙龙上我和一些DBA朋友讨论云技术发展对DBA的影响的时候，我觉得云是一种新的IT基础设施，因此对DBA这个职业会有一些影响，但是不会从本质上改变DBA这个职业。十年过去了，我发现当时我对云的理解还是过于片面了。事实上，云不仅仅是一种全新的IT基础设施，更是一种全新的IT文化和IT理念。大规模低成本、高可用可扩展、自治能力、自服务等云的基础特性不仅仅改变了IT基础设施，更大程度上改变了用户使用IT基础设施的理念，带来了一种全新的文化。这种文化对IT行业的冲击比一种全新的IT基础设施要凶猛得多。十多年前Oracle

有朋友总问我愿意不愿意去参加一些关于某个问题的网络辩论，不过我一直对此没有什么兴趣。因为我觉得辩论的并不是问题，而是话题。问题大多数是有一定的价值的，需要去分析剖析，去寻找解决的方案。而话题则是有时间聊两句，没时间不需要去理会的，因为大多数话题并不是为了解决问题而设置的。在这个浮躁的世界里，其实存在很多问题需要人们去思考，去探索解决的方案，不过似乎这些问题很难形成热点，注度也往往不高。大多数人不在乎如何通过解决问题而让这个世界更加美好。人们总是被各种各样的话题所吸引，对于无法产生话题的问题了无兴趣。而我则刚好相反，我更多的时候喜欢避开话题，直面问题。虽然我也时不时写一写当前比较热门的话题，不过大多数情况下，谈论话题的目的是为了引出一个需要解决的问题，然后去讨论如何解决这个问题。我不喜欢简单地争论某个话题，更喜欢的是讨论一些具体的问题。提出问题，分析问题，并且能够提出一些解决方案，是比较积极的，也是我们这个世界最为需要的。能够提出问题，并直指弊端的关键，虽然不一定找到答案，却也能起到让人警醒的作用。如果是为了引起话题而谈问题，就不太可取了。如果是为了流量而有意引发一些话题，那就更没意思了。面对国产数据库这件事，大家都喜欢把它当成一个话题，冷嘲热讽的多，提出真正问题的少，想着解决问题的就更是凤毛麟角了。实际上国产数据库目前还无法和ORACLE这样的领先产品相抗衡，这是不需要多谈的事情，虽然这个话题一直很吸引人。我们要做更多的事情是如何帮国产数据库厂商找到问题，甚至提出一些解决问题的建议。帮他们找到一些产品存在的缺陷与BUG也是极有价值的

数据库出现坏块在我干DBA的时候是常见的事情，处理各种各样坏块的案例可能经历过上百个。很多情况下坏块问题可通过数据库恢复来完成，像Oracle早就支持块级恢复，因此现在Oracle出坏块，只要有备份，通过块级恢复就可以了。如果有ADG那就更简单了，通过ADG的文件恢复就可以了。今天介绍的一个方法不仅可以在Oracle数据库上使用，也可以用于其他数据库。当数据库缺少可用备份或者不支持块级恢复，一张表出现一个坏块要恢复整个数据库比较麻烦的场景。处理方法比较简单，就是跳过坏的数据，把其他数据写入一张临时性的表，然后将存在坏块的表rename成old表，再把临时性的表rename成生产表就可以了。下面我们看这个案例。因为某种不可言状的问题，用户的某张十分重要的表出现了访问问题。访问这张表的应用报错ORA-08103。通过客户端去访问这张表也是报同样的错误。在该表的某个extent中，高水位下有个BLOCK对应的type是错误的，当对该表进行扫描或者访问到某个记录的时候，访问到这种块就会出现ORA-8103报错，操作无法正常进行。如果存在这种形式的坏块，无法对表进行全表扫描，也无法将该表exp出来。

NOTES中查找相似案例对于DBA来说是必备的技能。Oracle产品这些年越来越完善了，因此20年前的DBA的主要技能都已经变成屠龙技了，很少能够真正发挥作用。现在的Oracle

开车的朋友都知道，如果目的地在对侧，那么很多时候掉头可能是最快的驾驶路线。明明知道目的地在对面而不肯掉头或者无法掉头，那么会浪费很多时间。在一个大城市里，有时候错过了一个可掉头的路口，可能需要绕很远才能到达终点。这些在开车时很容易想明白的事情到了我们的工作生活中，就往往不那么容易想明白了。就以DBA这个行当来说吧，现在迎来了一个目的地肯定在对面的困境。传统的数据库市场正在颠覆，云计算、开源生态的快速发展让传统的数据库市场和DBA市场发生了翻天覆地的变化。再叠加中美科技战引发的数据库国产化替代浪潮，传统的DBA肯定会面临巨大的挑战。有些企业和DBA已经开始布局，做好了掉头的准备，不过还是有很多人依然沉浸在对历史的缅怀之中。Oracle是最好的数据库，这个观点是没错的，这么多年来，我一直认为Oracle数据库是最优秀的，而我掌握得最透彻的数据库还是Oracle，但是我不能死守着Oracle

整个索引扫描完毕后，就得到了该索引的集群因子。从上面集簇因子的计算方式我们可以看出，集簇因子反映了索引范围扫描可能带来的对整个表访问过程的开销情况，特别是IO开销。实际上哪怕所有的块都在DB

最近遇到几个案例，对一些以前感觉没啥问题的事情产生了一些新的想法。这周就要过年了，因此今天可能是春节前最后一篇讨论技术的文章。在春节期间，争取抽空写一些吃喝玩乐的文章。前阵子一个客户的一个关键系统出了一次大故障，这套系统是6年前从IOE架构迁移到云平台上的，整个云平台建设了7年多了，而系统上线也有6年多了，在此期间，云平台很好地支撑了系统的运行，没有出过什么比较大的故障。前阵子突然应用不可达，现场监控人员检查发现有几十台服务器的心跳失踪，云服务本身也出现了严重故障。最后对这几十台服务器做了强制性重启后，系统恢复正常了。因为故障发生时有些服务器已经无法在云平台上管理，因此必须通过BMC强制重启，整个过程持续了数个小时。这也导致了这套关键系统的大部分服务出现了2小时以上的断服。当这套系统在IOE架构上运行的时候，故障率肯定比上云后要高，基本上每年都会出一些故障。不过数据库有RAC和ADG备库，应用服务器有WLS集群，因此大部分故障都不会完全中断业务，顶多是部分业务短暂出现几分钟到几十分钟的故障。系统上云后，确实这种级别的故障少了很多，哪怕出现一些问题，大部分也可以在更短的时间内恢复了。出现如此大的故障，这6年里也只有这么一次。似乎上云后，系统更稳定了，但是这一次故障不免让人反思。对于特别关键性的系统，一旦出问题将会引发社会性的问题。对于这样的系统，这种用复杂性带来的整体可用性的提升是不是真的是一种比较好的选择。在上云之前，这套系统就是两台IBM小型机+一台集中式存储作为主系统，另外一台档次略低的小型机加一台档次略低的集中式存储作为备系统，运行Oracle

和一些朋友交流技术问题的时候，我很喜欢与经常问出“为什么会这样”的朋友沟通，因为这代表了一种希望了解和理解别人的想法的心态。而我最不愿意和经常说“为什么不这样”的人交流，因为在他的世界里，别人总是不大对的，自己的观点和立场才是正根。“为什么不如何如何，为什么非要这样”，可能经常说这样话的朋友自己都没有感受到，他在讨论和分析一个问题的时候，已经排除了大量的可能性了。为什么系统出问题了不能先去优化SQL，为什么非要去调整数据库的参数；IO不足了为什么不能去扩容IO能力，非要和数据库较劲；既然Oracle软件里没有强制要求许可证，为什么就不能随便用用。为什么不代表了某种自我的立场，而某些问题是可以在一个更为广泛的范围内去思考和探讨的。只有更广泛地探讨，才能把问题考虑得更加周到。就拿数据库优化来看吧，早期的用户往往连参数都设置不好，存储系统的条带设置也与数据库不匹配，在基础的底层出现的问题会导致数据库的负载稍微高一点就会出问题。这种情况下，如果非要揪着SQL不放，非要强调SQL优化，那么最终的结果不会太好。我这些年做优化工作，遇到过太多的喜欢说“为什么不这样”的人。十多年前有套系统的weblogic总是出现OOM的问题，当时我建议用户做个整体分析，找出OOM的根源再对症下药。用户那边的开发处处长就属于那种“为什么不这样”的人，他觉得JVM出OOM，那肯定是应用写得不好，你来做优化，只要把消耗内存比较大的应用模块和SQL找出来就行了，其他的问题他自然会找开发商去搞定，不需要我们费心。我和他沟通了几次没有效果，只能按照他的思路来，找了几十个比较消耗内存的模块和SQL去优化，不过依然没啥效果，该宕机还是宕机。后来他们上级的主任受不了了，直接把我叫过去骂了一顿，说为什么做了这么长时间优化还是不断宕机。我只好如实汇报，并说如果非得按你们给划下的道来做优化，那就只能修修补补。要想彻底解决问题，必须按照我们的方案，做一次全面排查才行。后来经过全面分析发现JVM的问题是OOM

23c中已经十分成功的将向量计算、图计算、文档处理与传统的关系型数据处理融为一体。融合计算会让大数据处理更加高效，大数据应用的成本更加低廉，这只会加快大数据价值的增值，而绝不会让大数据死亡。

前阵子听一个朋友吐槽他们搞运维数字化转型后，非但没有觉得工作轻松，反而被搞得整天筋疲力尽的。因为数字化转型，他们引入了普罗米修斯，又从网上找来一大堆插件，把公司里的各种可监控的组件都接入普罗米修斯监控了。又上了日志平台，接入了应用服务器、数据库等的日志。折腾了大半年，总算是告一段落了。这段时间的成果也是很喜人的，因为以前IT部门上监控的东西不多，完全靠人去管理。很多事情都要手工操作，因为系统数量比较多，因此管得也比较粗犷，只要业务部门不投诉，系统没宕机，也基本上没人去管。因此他们运维部门各个专业十来个人倒也还能应付过来。这段时间上监控，接入数千个运维对象，累了个半死，总算是弄消停了。系统都上了监控以后，确实比以前方便了不少，一些日常要做的手工检查工作也都可以借助系统完成了。不过好景不长，领导看到第一阶段成果后，立马开展了提质增效的工作。这下子问题大了，日志都采集过来了，你总要分析分析有没有问题吧，数据都采集上来了，告警基线也都搞好了，每天产生的告警总要分析分析吧，闭环管理肯定是领导喜欢的工作，当日对于运维人员来说，可能意味着写不完的报告。有个用户从上了我们的D-SMART后，他们的

今天的文章是一个讨论话题，希望朋友们不吝赐教，让我们也了解一下各位DBA，各个企业对数据库运维工具的需求，从而让给我们今年启动的D-SMART

新年的第一个工作日，似乎没有什么不同，不过心理上总觉得与一年中的其他日子是有所不同的。工作目录依然在使用2023，不过确确实实是已经进入了2024年。我会在每年的第一个工作日创建本年度的工作目录，不过刚开始的一段时间里并不愿意使用它，因为里面空空如也，想找个可参考的文档都要回到前一年的目录中去查找。如果把前一年的工作目录拷贝过来，那么几年之后，你的年度工作目录会变得十分臃肿，今后清理起来也十分麻烦，也不是一种好办法。工作是连续的，跨年只是一个仪式而已，为每年创建一个新的工作目录就像创建年度分区表一样，刚开始的几天总是容易出现执行计划错误，选错索引的情况。今天和未来的2024年中的任何一个工作日都差别不大，与上星期五也没啥特别的地方。只不过今天在每个人的脑子里都会多一些期许，大多数人都会在这一天会为自己做一些祈祷，希望新的一年是希望实现或者起航的一年。虽然跨年只是一个仪式，不过在年前的工作节奏也都会按照跨年仪式作为分界线不自觉地做了分割。在2023年的最后一周，我要求无论如何都要发布D-SMART

前阵子一个朋友和我讨论一个PG性能问题，他们最近把几个小的PG数据库整合为一个大系统，换了台新服务器，搞了超豪华配置，有512GB的物理内存。他们配置了一个128GB的SHARED_BUFFERS，然后应用就出问题了。因为这套系统中经常要用到临时表，他们的临时表都是物理表，一般是create/insert/select/drop，一串操作。系统升级后，系统就变得特别慢了，经过分析，发现主要问题出在drop

临近年底，这也是我今年的最后几篇文章之一了。今年冬天特别冷，穿啥衣服都不觉得暖和。翻了一阵子发现数据库厂商送的衣服大多比较厚实，适合这个寒冬穿。于是最近经常穿着各种数据库的衣服上班下班。前些天穿了一件IvorySQL的衣服坐飞机，空姐看了我半天后问我：“这件始祖鸟的衣服好像没见过别人穿过”。我笑着说：“这是高端品牌，一般人买不着”。上周一个朋友约我小聚，脱掉外套后发现俩人都穿了一件同款的PingCap蓝色厚T恤。看样子不止我一个人发现了国产数据库的这个好处。今天聊聊自研数据库的难点，在看到这个问题的时候肯定有些朋友会问：“为什么我们需要大型数据库，把自己的数据库拆小不就解决问题了吗？”，我也经常会听到：“为什么非要这样，为什么不那样”。每个企业的实际情况不同，其需求是不同的，作为一个用户你说不需要某个功能是完全没毛病的，不过作为数据库厂商，需要为各种各样的应用场景提供解决方案。进入正题，对于这个问题大家的观点可能比较一致，不管采用哪种方式，自研确实很难，因为关系型数据库发展这么多年，很成功的大型商用集中式通用数据库就那么几个，最成功的不外乎Oracle、SQL

pool，寻找一个既不被锁定，也没有被引用，但是是脏块的缓冲区。如果找到了，就将这个缓冲区的内容写入磁盘，然后返回这个缓冲区（这是代码中backend中另外一个写脏块的地方），并将其从victim

最近这二十多年时间做了不少项目，也接触过大量的用户。二十多年前，IT管理方面相对比较粗犷，到用户现场时候也没太多流程和管控措施，早期甚至把自己的笔记本电脑连到用户的网络上就开展工作了。自己带的各种工具用起来很方便。这种管理模式漏洞很多，不利于企业IT的安全管控，因此很快堡垒机、运维专区等纷纷建立。再去用户现场干活的时候只能用客户提供的运维终端了。经过十多年的发展，一些大企业的IT管理都完善了不少，从安全的角度上看，确实很有必要。不过我手头的一些不错的工具和脚本都没法用了，做事情麻烦了一些。虽然对我们这种做第三方服务的人来说不够友好，我还是比较认可企业在安全管控上的这些升级的

前段时间在灿灿的微信公众号（PostgreSQL学徒）上看到了PG数据库的孤儿文件的问题，文章名为《空前都去哪里了？》，讨论的是PostgreSQL数据库的孤儿文件的发现与清理的问题。PostgreSQL数据库的孤儿文件问题是指在数据库中存在一些没有被任何表或索引引用的文件，这些文件占用了磁盘空间，但是无法被清理或删除。这种情况可能是由于一些特殊的原因造成的。比如数据库崩溃或异常终止，导致文件系统和数据库之间的数据不一致；数据库升级或迁移时，没有正确地删除旧版本的文件等等。其实孤儿文件问题不只是PostgreSQL才有的问题，一些开源数据库，比如MongoDB，也会存在类似的问题。当分片集群中的数据块迁移失败或者清理不完全时，就可能导致一些文档在多个分片上重复存在，这些文档被称为孤儿文档。为了解决这个问题，MongoDB提供了一个cleanupOrphaned命令，可以删除指定集合的孤儿文档。MySQL、Oracle等使用表空间段页模式的数据库虽然不会产生孤儿文件，但是可能会产生表空间碎片或者垃圾数据段。因此这些数据库也需要通过表或者表空间的碎片整理来解决数据空间被垃圾占用的问题。早年我们运维Oracle数据库的时候就经常会发现某个表空间中没多少业务数据，但是已经无法分配空间了。分析之后发现是因为在很多perment的表空间中有很多大型的临时段。这是因为数据库在执行一些大规模的操作，如创建索引、CTAS、分区交换等，这些操作会在perment表空间中创建temporary

AIOPS概念被提出的时候，人们对此是寄予厚望的，因为传统运维已经进了死胡同，走不通也无法掉头。智能化运维的愿景被设计出来了，似乎是无所不能的，可以解决几乎所有的传统运维问题。不过在AIOPS落地的时候发现实际场景的复杂性远远超出预期，很多看似很高大上的算法与智能化系统都很难解决用户遇到的问题。最近和一个客户讨论AIOPS在大型数据库这种复杂度很高的IT基础设施上如何能真正实现，因为他也觉得他所见的AIOPS场景都是十分简单的，肉眼都可见的问题，而对于复杂一些的数据库问题，并没有见到特别有效的AIOPS解决方案。一些AIOPS表现出不错效果的场景，即使不使用AIOPS，以他们传统的技术手段可以轻松解决，而那些传统手段解决不了的问题，AIOPS似乎也束手无策。这就带来一个问题，AIOPS不是完全没用，在某些场景确实可以适当减少人力投入，但是又不明显，实施起来投入也很大。在这种情况下，是不是要投入巨资去实施AIOPS呢？对此我也一直在思考，今天和大家一起来探讨一下这个问题。这些年做运维自动化的感受是，AIOPS的上游是数据与指标，下游是定位到具体原因的运维知识。做AIOPS的人往往都不大看得起指标，他们认为算法可以解决一切数据质量的问题，因此没有必要在指标的质量上去花太多工夫，实际上目前做AIOPS的企业也缺乏做运维数据质量方面的专家，在这方面是天然存在缺陷的。我想可能有这样想法的人都没做过复杂系统的运维，或者来自于运维数据质量已经相当好的大型互联网企业吧，在这些企业里上游数据质量问题根本不需要做AIOPS的人去考虑。因此他们对算法充满了迷一样的自信，而对运维经验不屑一顾，认为那是传统运维时代的产物。实际上指标与运维经验是运维知识中的精华，上周四与一些电网自动化的朋友相遇，他们的观点是数据，指标，规则，自动处置，故障自愈是一条十分优秀的流程链。把问题的内在原因分析清楚了，就可以知道该如何自动处置，实现自愈。然后再往前推，找到定位问题的方法以及所依赖的指标集，再把这些指标精准地采集回来，那么一个复杂的问题就用自动化的方法解决掉了。再对这些方法做适度的泛化，就可以将一个自动化控制的方法适配到更广泛的场景中了。这个工作方法对于做AIOPS的人来说似乎很LOW，似乎已经过时了。确实，这种方法在自动化领域也全无新意，已经有上百年的历史了，在很多工业控制领域都被广泛应用。与信息化不同的是，自动化专业这些年里一直在把这些知识变成自动化装置，已经形成了体系化的行业解决方案和理论体系。在这种积累下，做什么项目都可以充分利用几十年来积累下来的标准件，从而实现稳定的技术迭代。而在信息化领域，这些知识往往只能不完整地沉淀在一些书籍中，能够开箱即用的标准件少之又少，无法广泛覆盖运维的常用场景。在IT运维领域，将运维经验做成标准件难度极高，成本巨大，因此大家对能够不需要这种积累，天生具有普适泛化能力的AIOPS寄予厚望，认为这才是运维的未来。可惜的是，这种完全依赖算法的泛化分析能力并不一定适合用于在复杂系统中做精准定位。比如说前几天我遇到的那个因为expression

低头走路，抬头看天。人总是要抬头看看的，但是抬头看天的目的是把低头走的路走得更好。不过有些时候，这些事情反过来了，我们总是在批评一些埋头走路的人走得不好，没有多抬头看看天。“外面的天都这样了，你还在用这种很挫的姿势走路，你应该多抬头看看天！”。走路的人说：“我已经走得很累了，不抓紧走，我就赶不上今天的早集了。”闷头走路的人大多数都是有一个行走的目标的，虽然这个目标在路人看来可能很LOW，不正确，而站在路边评论路人走姿的人往往没有啥目标，他们要做的只是评论而已，因此他们会更舒适，说出来的话也似乎更有道理。走路的人当然也需要听听路人的观点，兼听则明的道理永远都是对的。不过是不是自己要照着路人的点评去做，那就需要看自己的实际情况了。我从大学毕业到现在的这几十年一直在干IT技术工作，软件开发、系统集成、研发管理、数据库DBA、系统优化、架构师，这些工作都干过一段时间。在这三十多年时间里，有时候我是那个闷头走路的人，有时候是那个站在旁边评论路上人的人。仔细回顾一下会发现，站在路边的时候是很舒服的，只要偶尔抬头看看天，再利用自己看天的心得去评论别人就行了，而自己下去走走，很快也会累的，也不一定能比路上的人走得更好。2017年之前的几年时间里，我更多的是担任路边评论者的角色，对IT技术的发展，对数据库技术的发展，对运维优化技术都发表了很多看法，也经常出席一些规格不低的会议。不过这段时间越过越不踏实，说的话很多，出的成果很小，很多在某些高逼格的场面上说的话最后都变成了海市蜃楼。于是2017年底开始，我一直想把“运维知识自动化”这个概念的产品做好，围绕这个具体工作，我突然发现看问题的角度变了，我从一个站在高高的路边点评路人的人变成了艰难前行的人中的一员。从一个较低的角度去看我自己，看我的团队，看友商，似乎一切都有一些变化了。我能理解与容忍别人的LOW，别人的错误，别人在某些方面与我理念的差异，因为我也成为了他们的一员。现在我也经常写一些数据库相关的文章，里面也会有一些观点。对于数据库产品而言，我依然是个路人，一个门外汉。不过我现在不是低头在看他们的，而是在一个平等的平面上看他们的，甚至有时候我需要仰望才能看清他们。因此相对来说我会略微客观地去看他们。相比于站在高处侃侃而谈，我更喜欢走到这群疲惫的人中间，成为他们的一员。走在崎岖的山路上虽然累一点，但是心里更踏实。

昨天电机工程学会的信息化专业年会，做主题报告的郭剑波院士并不是信息化专业，而是一位电网控制论专家，这也是我第一次在信息化的会议上听到一位来自非信息化专业的人的主题演讲。认为很多企业的信息化专业的人总是固守在信息化领域，不愿意吸收来自其他专业的营养，甚至很多搞信息化的人认为在信息化领域其他专业的人都是土包子。不过我倒是挺喜欢和电力行业其他专业的人交流，每次听他们讲一些概念性的东西，都会觉得有所收益。这是因为除了信息化专业以外的其他专业，大家都在努力让业务变得更加简单更加容易处理，而信息化专业则反其道而行之，擅长把原本简单的事情变得复杂起来。电网其实是一个十分复杂的系统，仅仅是终端互动就涉及了很多的自动化专业的工作。更不要说大电网管理，源网荷储友好互动、成本与经济管理等更为复杂的范畴了。化繁为简是电网专业最为擅长的，将纷繁复杂的负荷梳理出可调配调度的数个分类，根据分类的不同要求去做不同的响应策略。只要确保秒钟级可中断负荷足够大，整个电网的调度就游刃有余了。郭院士不是个擅长演讲的人，他的声音平缓，没有那些在台上侃侃而谈的老手的那种抑扬顿挫，有些时候声音过小，听得不甚清晰。不过从他讲的内容上，我感受到了电网控制领域的一些值得信息化专业学习和参考的经验。今天让我感受最深的是郭院士关于新型电力系统是一个CPSS系统（信息物理社会系统，南瑞薛院士的CPSS框架）的阐述，因此它的数字化必须充分考虑CPSS系统的固有规律，在成本与效果之间获得平衡点。可用性与成本是密切相关的，追求极致的可用性就是一种不负责的态度，从CPSS系统的特点出发去考虑很容易在电网的可用性与成本之间找到一个合适的平衡点，从而找到确保全网安全运行的有效管理策略。郭院士在演讲中提到可用性是一个政治性指标，而不是一个技术性指标，因此针对系统的可用性必须从CPSS系统的特点去发现这个平衡点。实际上信息系统是人与数据打交道的，更符合CPSS系统的特点，郭院士的一些关于电网的观点，对信息化是有很强的参考价值的。在信息化领域，可用性被高度政治化了。系统设置的可用性目标并没有任何实际的意义，其成本也没有被可用性目标所保障。这就导致了信息化专业的业务连续性目标设置得很高，建设效果却很差。钱花了不少，但是很多钱滑下去并没有任何作用。某一天公司领导半夜要发一个会议通知，那么OA系统就成为了7*24的高保障要求的系统了。十年前我参与一个大型国企的一个系统故障调查的时候发现这个7*24的关键系统半夜做系统检修，因为人的脑子不清醒导致的误操作是引发本次故障的主要原因。因此我当时建议是不是可以把此类检修提前到下午6点下班后开始。设定每周或者每个月有一天可以做此类关键系统的检修，因为营业厅下班后，系统承担的业务已经很小了。当时这位运维部门的主管对此还十分感兴趣，说回去研究研究，不过最后这个提议也无疾而终了。在运维领域，自洽的系统往往会被一些不自洽的因素干扰，如果这个因素是可自愈的，那么就是自动化领域的工作，否则是信息化领域的工作，这是电网自动化专业简化电网管理的一贯做法。通过不断地把数据指标化，然后构建模型，设置规则，就会逐渐将信息化专业的工作剥离出来，变成自动化专业的工作，这种化繁为简的工作方法持续在电网自动化领域发挥作用。并不是电网不够复杂，而是电网把复杂的系统拆解为可管理的单元，从而让复杂的电网都可以使用自动化的手段来管理。反观信息化专业，我们总是喜欢把事情搞复杂了，数据做指标化干什么，不是有大数据、人工智能吗，还用这种落后的手段去处理数据干什么。于是大量复杂的IT基础设施出现了，大量复杂的业务系统出现了，IT的技术难度提升上去了，然并卵，解决问题的效率反而下降了。数据收敛为指标，指标用于分析与决策这么简单的道理现在在信息化领域被视为落后，而在自动化领域依然在发挥重大的作用。昨天郭院士的演讲给我的冲击是十分巨大的，到我现在坐在电脑前码字为止，很多东西我还没有想清楚。可能我今天写的东西也会让一些“信息化领域”的“专家”感到十分小儿科，不过信息化想要简化的东西往往最终都变复杂了，这难道不值得我们多思考一下吗？

12月7号要参加电力信创专委会的一个会，6号晚上同事都在加班赶OB专版，我负责帮忙测试，就一边测试一边写点东西。今天要发的内容有点散因为这是昨晚和在测试间歇和今早在地铁里写的，内容不是很连贯。从目前的

SERVER、Informix、DB2、PostgreSQL等都要有很好的兼容性才能满足各种各样的用户的需求。因为用户的现状是很复杂的，而且数据库厂商要为尽可能多的客户服务。

搞IT难免看英文资料，我的英文水平一般，虽然看技术资料没问题，不过比较费劲，比起看中文资料来，效率要低很多。因此我很喜欢使用chrome浏览器，主要是喜欢其自带的网页翻译功能。看到大段的英文的时候，我会打开一个新标签，然后用网页翻译功能翻译成中文，当中文看起来比较别扭的时候，才去看看另外一页里相同位置的英文。这样阅读效率就高了很多。因为谷歌一直有一个基于translate.google.cn的服务，因此网页翻译并不需要翻墙就可以使用，这一点尤其方便，省了动不动要启动VPN的麻烦。不过最近这段时间谷歌翻译经常出问题，到了9月30号好像不翻墙彻底用不了了，不过我也没太当回事，这种事情以前也常见，过几天就好了。昨天有个朋友给我发消息，说是看到了一个外网的推特，说谷歌停止了谷歌翻译的中文服务，所以他这几天用不了谷歌翻译了，十分麻烦。他也是一个我的同龄人，英文阅读存在较大障碍，这件事让他是十分苦恼。我在谷歌上搜索了一下，并没有发现谷歌官方有类似的声明。于是尝试了一下，翻墙后，谷歌中文翻译是能够正确使用的，说明谷歌关闭中文翻译服务的消息不实。只不过translate.google.cn的这个翻译服务出问题了。而translate.google.com则是正常的因为translate.google.com在墙外，因此如果不借助VPN就无法访问了。这确实带来了很大的不便。因为我平时经常要通过VPN连接公司的实验室做一些工作，这样的话，就无法在连接公司VPN的同时访问谷歌的服务了。中美科技战开打以来，美国的一些大型国际性公司做得还不算太出格，毕竟如此大的市场，国际性大型IT公司还是希望今后要做生意的，不能太离谱了。不过虽然如此，一些小动作还是不断的，既然你把我墙了，我也会让你有些不舒服。我想这种小动作，很可能在未来几年里也会越来越多。目前这种僵局不打破，那么形成东西方两个相对割裂和独立的IT技术堆栈的可能性也会越来越大。对于人类来说，这是巨大的资源浪费，不过对于中国来说，这是不得不干的事情。和一些朋友谈这件事情，他们大多数都觉得没有就不用呗，又不是什么大不了的事情，百度翻译不也挺好。不过对于我来说，把网页拷贝到百度翻译里看还是挺麻烦的事情，当务之急是找到一个可替代的工具。以前的百度浏览器的翻译功能也还可以，不过现在PC版的百度浏览器已经停止更新了，在手机上看资料对于老眼昏花的我来说也有点难受。幸运的是微软的EDGE里的百度翻译使用还是正常的，暂时也只能如此了吧。不知道如果EDGE不能用了，还能有啥好的选择。面对愈演愈烈的孤立与反全球化，走在全球化协作前列的信息产业，也确实只能放弃幻想，脚踏实地的做好当前应该做的工作了。虽然技术割裂非我所愿，但是如果现在不做准备，那么下一步就不是割裂，而是压榨了。

前几天团队聚餐，喝了点酒话就多了，最后聊到93、94年给电信做计费系统的往事。当时电信都是后付费业务，客户先消费，月底统一计费，然后收费。那时候每个月缴费是从15号开始，到下个月15号之前缴费就不收滞纳金。我93年第一次和泉州邮电局交流新一代计费系统的时候，就问他们，为什么要15号才开始收费呢？他们说收费时间肯定越早越好，他们也可以早点回收资金，同时降低欠费的成本。另外一方面，电总也有把C3本地网收费时间提早到5号的目标，只是因为技术原因，目前还无法实现这个目标。长市话的计费信息在各个县的交换机上产生，并可以写入工业磁带。一般是在下半月开始，各县会开始给C3数据中心送来第一批磁带，本地网开始处理磁带。等下个月1号的时候，各县会把最后一批磁带送到。本地网计费中心要做的第一步是通过读取工业磁带里的话单信息生成话单文件，等文件全部读完，开始做一次批价，等所有话单全部完成批价后，会对一些大客户根据协议进行统一优惠处理，并对一些政策性单位进行减免处理。最后形成长市话话费数据。根据号段分别归结到各个C4网。然后写入磁盘，由各县取回。县里拿到的是FOXBASE文件格式的磁盘文件，已经按照县里的营业收费点做了处理。各个营业点拿到收费文件后才能开始收费。而交费者也只能到其号段所在的营业厅缴纳话费。在这个过程中，每个环节都需要时间，因此一般来说要到下个月10号以后才能够完成收费的准备工作。我们分析了邮电局长市话计费的整个流程后，发现其中最耗时的是长话读带的过程。以前在使用国产的磁带机读取磁带的时候，完成一盘磁带的读取需要一个多小时。每个月处理100多盘磁带，哪怕加班加点，都需要10多天的时间。为此在93年这个新一代长市话计费系统的项目中，泉州电信采购了一台富士通的高速工业磁带机。用它替换了原来的磁带机后，我们测试了一下，速度确实比以前快了不少，不过仍然需要30多分钟。当时我们对计算机的认知十分浅，对高速工业带机的工作机制也不甚了解。因此刚开始的时候对如何提高读带性能也是一头雾水。不过基于一台几百万的小型机肯定比一台几万块钱的PC机性能更好的认知，我建议把磁带机接到小型机上试试。我们先把磁带机接到VAX

其实这篇文章是我周末开始写的，写这篇文章的这个周末，我的很多时候都是在思考一个数据库国产化替代的建设方案，翻阅了大量的资料。今年正好是我参加工作后的第31个年头，工作的最初十年，我写了十年代码，从汇编、COBOL到C语言，写了几十万行代码；随后的十几年，我一直在帮助用户用好数据库，也在帮助Oracle推广RAC技术；2015年开始，我一边继续从事数据库优化的工作，一边在帮助客户如何从Oracle迁移到成本更低的数据库系统上。所以对国产数据库我一直有一种十分特殊的情感，这是一种爱恨交织的情感。所以今天最后用“乱象”这个题目的时候，还是有些犹豫的，在国产数据库发展如火如荼的时候，泼这盆冷水合适不合适。根据工信部数据库发展白皮书2021的描述，截止2021年6月底，光是国产关系型数据库厂商就已经高达81家，估计马上要发布的2022版里突破100家甚至150家都是很有可能的。相对于十多年前的寥寥数家，这些年国产数据库产业的发展确实是十分迅猛，用野蛮生长来描述也不为过。这些新兴的国产数据库厂商里，也不乏具有相当强大基因，投资巨大，真正认真在做数据库产业的企业，不过大洪水下肯定也会泥沙俱下。原本就起步较晚，人才储备、资金投入都不太足够的国产数据库产业，再被割裂为这么多的细小单位，每个独立个体的真实能力就很值得怀疑了。无论是CPU，服务器，操作系统，中间件这些IT基础设施，投身于IT基础设施中的王冠的企业没想到有这么多，这不知道是中国数据库之幸还是中国数据库的灾难。上周五我在一个沙龙上分享了一些关于基于业务场景的国产数据库选型的演讲，并不是开门见山的去讨论业务场景和数据库选型，而是从对国产数据库厂商的分析开始的。这些分析都是基于工信部的产业发展白皮书的内容。从成立年限上看，我们的国产数据库企业还很年轻，不过成立20年以上的企业还是有十四家，只不过这些企业的这20年并不好过，以数据库产品销售为主业根本生存不下去。因此虽然有20年的历史，实际上真正的历史恐怕要打些折扣的。只看历史可能还无法直接感受到差距，而从从业人数上看，就可以看到国产数据库产业碎片化的恶果了。超过60%的数据库厂商不足100人，而超过500人的企业不足10%。对于想摘取IT基础设施王冠的中国数据库企业，最大的企业的规模可能还不如某个哪怕二三流的国外数据库厂商的一个小研发部门的规模。如果把人员再细化为管理、研发、产品、市场、销售、后勤等部门，恐怕研发人员就更是少的可怜了。据说目前国内最大的数据库厂商的研发人员不足500人，这就是中国数据库企业的现状。如果我们再来看看技术层面的东西，从专利数量上看，90%的数据库企业的数据库领域的专利数少于100件，所有的关系型数据库厂商的专利数加在一起不足4000件，而截止2020年，Oracle公司一家企业的专利数就超过1万4千件。在技术基础薄弱，人才匮乏的情况下，为什么一下子能涌现出如此多的数据库企业和产品呢？从国产数据库的技术来源分析上我们就可以看出一些端倪了。上面这个图表是我们根据收集到的资料自己做的，不一定十分准确，不过可以大体反映出国产数据库的技术来源。大多数是来自于开源项目。因此才会出现大量的规模较小的数据库企业。使用开源技术来发展自己的数据库产业并不是一件坏事，实际上我还是比较赞成的。充分利用开源技术能够加速国产数据库产业的发展，缩短与国外头部企业的差距。不过利用开源技术不等于完全依靠开源技术，而是应该在开源技术基础上进行大量的自主创新，加入自己的技术。比如国内有很多利用PG开源代码的数据库产品，有哪家公司对PG的源码的理解程度，对PG社区的贡献能够达到俄罗斯POSTGRESQLPRO的水平呢？可喜的是，在这种乱象后面我们已经看到了一些数据库厂商开始了自主化的创新，在开源代码的基础上已经走得很远了，我想再有几年的积累，一定会突破开源技术上的某些瓶颈，走出自己的自主化道路。数据库的代码自主化率一直是个迷，如果看工信部的代码自主化测试报告，那么绝大多数号称国产自研的数据库产品都能够拿出很高自主化率的报告来，而且动不动都是95%以上的。我曾经测试过一个号称代码自主化率超过95%的数据库产品，其SQL引擎是完全“兼容”MYSQL的，存储引擎用的不是INNODB。有一次一不小心我把一个不太常用的MYSQL原生态的参数调整了一下，没想到，SQL引擎的工作模式居然按照参数的要求调整了。如果仅仅为了保持MYSQL语法的兼容性的自主化代码，连这种细微之处都模仿的如此完美，那也太牛了吧。虽然国产数据库的专利很少，不过这不影响国产数据库弯道超车，如果不能把Oracle拉出来吊打一番都不好意思说自己是国产数据库。而真实的应用场景下却反映出来我们的国产数据库在CBO和SQL引擎方面与Oracle差距甚大。我也曾经和一些数据库研发人员做过深度交流，他们也承认，要在数据库上缩短与Oracle的差距是十分困难的。无论在人才积累、资金投入和实际应用案例的反馈等方面都存在巨大的差距。特别是第三点，导致Oracle可以不断从生产环境中发现优化器的问题加以改进，而我们甚至都不知道优化器改进的目标，更不要谈从架构上去规划优化器的发展路线了。虽然我们的国产数据库还无法解决用户迫切需要的SQL引擎和优化器的提升，不过并不妨碍我们在其他一些领域上进行创新。在各种宣传资料上，HTAP已经成为了国产数据库的标配功能，不过我想一些国产数据库厂商自己都没几个人真正的懂得什么是HTAP。他们号称的所谓HTAP大多数只是一个OLTP数据库上具有一定的批处理能力而已。OLAP的计算场景和OLTP是完全不同的，OLTP要求资源均衡分配，每次执行的延时稳定并且尽可能段。而OLAP要求的是小并发下的大型甚至巨型计算，利用并行执行充分利用服务器的资源，尽可能把CPU/内存/IO的能力都充分压榨出来，完成复杂的计算，大吞吐量的数据输入和输出。一个连资源隔离都做不好的数据库产品，如何支持HTAP中两种会互相伤害的计算场景呢？我见识过的大多数号称完美解决HTAP问题的数据库产品，实际上都不真正具备可实用的混合负载能力。仅仅是在某些测试环境可以表现出一些能力而已。虽然如此，也并不能阻止HTAP成为很多企业招标中的参数指标，我不知道是采购单位是真正需要这种计算能力，还是仅仅以此来党同伐异的噱头呢？最后一个乱象是评价体系的乱象，每年都会出台各种所谓的国产数据库排行榜，不过这种排行榜似乎有点排排坐吃果果的感觉，第一名和第二十名的评分不超过5分，前几天我看到一个榜单，第一名和第十名的分差只有1分多。如果我是一个企业的IT主管，会有一个感觉，这个榜上的产品，随便选都不会有多大的差别吧。墨天轮有个国产数据库流行度排名，是模仿DBENGINE的，算是目前比较全的常态化榜单了。不过墨天轮上的关于数据库的介绍资料仅仅也就是各个数据库厂商提供的宣传资料，并无相对客观的第三方评价。所有的评价体系和排行榜都是当好好先生的，这很不利用国产数据库的发展。国产数据库现在迎来了最好的发展机遇，我们已经看到了芯片，服务器、安全等领域都在这个机遇到来时显现出了勃勃生机。而在我相对熟悉的数据库领域，我看到的只是一种表面的繁荣，并没有看到一种良性的发展趋势，希望这种局面很快会有所改观，希望国产数据库产业能够异军突起。

十多年前，一个客户和我说，你们这些专家分析问题的水平很高，我们的DBA没有可能达到你们的水平。你们能不能把分析问题的思路做成一个知识库，当我们的系统遇到类似的问题的时候，能够按照你们提示的分析方法一点点去分析。后来有朋友就组织了开发人员，为这个客户开发了一套专家系统。里面的内容有点像是一张张的思维导图，外加一些触发条件。当时这个客户如获至宝，系统也确实发挥了一些作用。不过随着他们数据库系统的升级换代，以及运维要求的不断提升，这套专家系统早就过时了。前些年专家系统是比较高大上的，不过这些年已经没人提及了。这些年的运维自动化系统带上智能的越来越多了，好像做运维自动化系统的，不做出一个智能化的系统来都不好意思拿出来和大家见面似的。不过很多号称是智能化运维系统的，和传统的运维监控系统并没有本质上的区别，可能监控的内容更多一些，能够展示的数据也多了起来，展示数据的维度也比以前丰富。以前我们顶多用饼图折线图之类的来展示数据，现在我们可以把方差、标准差等以前大家不太看得到的数据也展现出来了。不过从本质上来看，这些依然还是数据的罗列。而事实上，运维人员更需要看到的不是这些数据，而是隐藏在这些数据之后的结论。比如说上面这个IO分析的案例，虽然我们通过异常检测算法发现了上述的指标存在问题，似乎带上了“智能化”，但是这种智能化能力其实对我们的运维是完全不够用的。因为我们哪怕知道了哪些指标异常，如果没有强大的分析能力，依然对此无能为力。作为运维人员，我们除了希望看到罗列的指标，发现的指标异常，更需要的是告诉我们问题出在哪里了。运维人员需要知道这些指标异常背后的知识，到底是什么引起了这些指标的异常。当然，要想十分准确地定位到上面的几个问题中的一个，还需要更深的智能化能力做支撑，我们的系统目前还达不到这个能力。不过从异常检测中发现系统问题的可能根因，已经可以为运维提供足够的支撑了。我们再来看一个例子，优化工具中心能够为需要优化的运维对象提供工具指导，这是一个很好的专家系统，对于需要做优化的运维人员也是很有帮助的。不过专家系统如果能够带上一些智能化的能力，那就更好了。同样是优化工具中心，智能化运维系统的实现方式是完全不同的，不仅仅能够根据专家系统预设的工具推荐PG可以使用的优化工具，并且能够自动根据当前的数据，自动对系统进行快速分析，发现其中可能存在的异常。当点击到某个运维对象的时候，可以根据专家系统推荐的优化工具，同时还会根据当前系统存在的问题，自动将可以用来检测这些异常的工具加亮后推荐给运维人员。虽然在界面上仅仅多了几个加亮的工具条，不过隐含在这些加亮的背后，默默发挥作用的是运维知识图谱、泛路由智能知识点、社区发现算法、指标异常检测算法等专家系统+智能算法的组合体。经常有用户问我，老白，你们号称是智能化运维工具，你们的工具的智能化体现在哪里？我怎么看不出来呢？我问他，什么样的系统才是他眼中的智能化系统。他说，你起码也得弄个卡通机器人，时不时的对上几句话，才更像是个智能化系统吧。实际上，我觉得智能化运维系统中没必要弄的满屏都是智能化UI，也没有在系统中拉出一大屏幕的知识图谱让人来顶礼膜拜。把这些自动化，智能化的算法隐藏在一些UI的后面，让智能化的能力服务于运维人员就够了，没必要让智能化霸气侧漏到系统的每个界面上。我和一些做投资的朋友聊过AIOPS，他们眼中的AIOPS都是以算法为核心的，而不是以专家系统为核心的。而我们建设AIOPS系统的途径和这些传统的AIOPS系统不同，我们的AIOPS系统是从专家系统起步的。首先我们把专家们积累了数十年的经验变成完全自动化的“运维知识自动化系统”，构建起第一张运维知识图谱。然后才逐渐在专家系统能力不足的地方用AI算法来补充，并通过“泛路由知识点”这种低代码的分析工具填充到知识图谱中，用以改善与提高智能诊断的能力。专家系统和AI算法解决问题的方法是不同的，在一个企业的IT运维需求中，单单依靠某一种都是不够的。专家系统具有较为准确的深度定位能力，不过分析覆盖面不足，AI算法可以覆盖更广泛的场景，但是精准定位能力又不足。二者相结合才能弥补各自不足，获得相得益彰的效果。基于专家系统去开发AIOPS系统，可以让AIOPS系统站在巨人的肩膀上，从更高的起点出发，就像是二级火箭一样，可以飞的更高。