你知道国产数据库的AIOPS困境吗？
Oracle的自治数据库技术很强大，也有不少国产数据库想跟进。最近这段时间里我和很多国产数据库厂商都探讨过如何学习Oracle的自治数据库技术，利用AI技术让国产数据库的运维与优化变得更加简单。因为最近我和DBAIOPS社区一起在利用大模型做智能化分析方面做了一些探索，在Oracle数据库上取得了不错的效果。因此刚开始的时候，我觉得利用在Oracle上做智能运维的方法论复制到国产数据库上应该不是特别难的事情。
不过经过这段时间的探索，我越来越觉得难度很大。目前的数据库智能诊断与分析依旧是对人类专家的一种模仿，而并没有创造出新的方法，可以绕过数据库的基础原理与专家经验去实现强大的AI运维。既然是模仿人类专家的工作方法和思维方式，通过大模型的数据分析、数据处理和推理能力去做AI分析，那么其天花板就是人类专家的能力极限。有人说既然AI分析无法突破人类专家的极限，那么还有什么意义呢？实际上有没有意义并非这么简单的，首先是AI推理的效率要远远高于人类专家，人类专家可能需要通过数个小时去分析和推理的工作，AI可能只需要数分钟。另外一点是AI推理是可以固化到系统中去复制的，而人类专家是无法复制的。
虽然AI推理的价值很大，但是面对国产数据库的时候，依然面临巨大的挑战。首先是可观测性的问题，这方面PG系的国产数据库稍微好一点，PG的客观性能力虽然与O记相比，还有很大差距，不过基础的数据大多数还是有的，再加上以PG为内核研发的国产数据库在PG的系统视图上又模仿Oracle做了一些增强。因此目前看来PG系的国产数据库的可观测性还是最为丰富的。MySQL本身的可观测性能力就比较弱，不过因为MySQL足够简单，也凑合用了。反而是一些自研比例比较高的国产数据库产品的可观测性能力挺令人崩溃的。
虽然各大国产数据库都推出了类似Oracle AWR/ASH报告的诊断报告，号称可以像Oracle一样给DBA提供最直接的帮助。但是我目前看到的国产数据库的AWR报告，没有一个真正能像Oracle一样，让人能够从中分析出数据库存在的各种问题。有朋友说，这是因为国产数据库没有类似Oracle的MOS，其实这只说出了一个方面。除了缺乏Mos这样的知识库之外，国产数据库指标体系的不完善，是一个更大的问题。从国产数据库的AWR报告中，我们唯一能够看到的类似Oracle的数据就是TOP SQL，除了TOP SQL之外，其他的数据的价值差距太大。
对于这个问题，以前没有做AI诊断的时候还没有特别关注，因为我们对这些数据库产品的使用和研究也比较粗浅，看到某些数据库中的指标数量也不少，就以为可能也够用了。当我们要把问题交给AI去分析的时候，我们必须给AI输入足够丰富的数据，以便于实现自动化诊断。这个时候我们就会发现，分析某些问题所需要的指标缺失得比较多。比如我们如果想要在某个数据库中分析是否存在较多的全表扫描问题的时候，在Oracle和PG数据库中我们可以根据每秒表扫描/每秒大表扫描等指标来粗略地判断。而在某些国产数据库中无法找到类似的指标，或者说某些指标被定义了，但是里面并没有输出统计数据，有些是需要开启一些非默认的采集才能看到数据，有些则压根儿就是个摆设，仅仅是为今后提供这些数据预留了接口。
我曾经就这个问题咨询了某个国产数据库厂商，他的回答很干脆，目前这些指标都有，但是实际上内核都没有统计。我就问他，那么我如何去发现数据库中的表扫描问题比较严重呢？他说，那不是很简单的事情，分析SQL的执行计划不就知道了。
当然，分析SQL的执行计划我们肯定可以发现SQL中存在的不合理的表扫描，进一步发现索引设计不合理等问题。但是一竿子直接打到SQL，是不是有点过于简单粗暴了呢？如果我事先并不知道哪些SQL有问题，难道我还得一个个SQL去分析？
事实上，在目前的的大多数国产数据库用户那边，现在的绝大多数国产数据库运维仅仅限于分析数据库日志和优化SQL。除此之外的运维分析手段是十分有限的。如果现场运维人员无法从日志和SQL中解决问题，那么就比较麻烦了，非原厂工程师无法处置这样的故障，甚至有时候原厂工程师来了也解决不了。
过节期间，我们在测试一个某国产数据库的锁阻塞场景的时候，阻塞锁已经模拟出来了，但是在会话状态的阻塞标志中，就是查不到这个阻塞的存在。而几天前这个场景是能够轻松模拟出来的，可能是我们这两天调整了一些数据库参数，就出问题了。这很可能是某个BUG，也可能是某种特殊状态，但是对于我们来说，这个是一个黑盒子，完全无从分析。这种情况是国产数据库可观测性问题的第二种问题，那就是可观测性接口不能够比较准确地反映出国产数据库的运行情况。
第三种常见的问题是与运维经验缺失有关的。前几天我们在调试一个故障模型的时候发现调整某个参数有助于提升数据库并发处理的能力。但是我们在咨询某些用户和原厂工程师的时候，他们都认为这个参数是不建议调整的。要提升并发处理能力，一般都是建议给某个租户分配更多的资源，而不是通过调整这个参数，但是为什么必须这么做，谁都说不清楚。在官方文档中我看到了不建议调整该参数的警告，说是如果调得太小，影响性能，调得太大，消耗过多的CPU和内存资源，都会引发数据库运行的不稳定。能够在官方文档里有这样得说明，在国产数据库得文档里算是不错了，起码在文档里包含了一定的运维经验。不过这还不够，需要有几篇类似MOS文档的知识库来专门阐述这个问题。既然这个参数存在，那就肯定不是当摆设用的，怕用户调错出问题，这个出发点是好的，不过不够好，如果能够让用户学会通过调整这个参数来优化自己的系统，那才是真的好。
数据库原厂可能都不知道如何维护和调整数据库，这是目前我们在使用国产数据库的时候面临的一个更加尴尬的场面。国产数据库，想让用户用好并不容易，除了稳定性和性能之外，可观测性能力是国产数据库厂商急需补课的地方，如果搞不好这方面的技术问题，数据库就会变成一个黑盒子，想用好数据库产品，必须依赖于原厂研发辅助分析，这样的业务模式在目前阶段服务于少量头部客户的时候，还凑合能顶得住，用户多了，数据库厂商首先就支撑不住了。
