当下数据库的产品发布的时候如果不说自己是面向AI时代的，那就是落伍的标志。不过现实是，有些数据库已经真正面向AI时代了，而有些只是嘴上说说而已。大多数数据库产品在宣传自己的AI能力往往是向量、算法 、索引等有限的几个维度。难道数据库的AI特性只有向量、索引和算法这几个维度吗?面向AI的数据库需要在AI4DB和DB4AI两手都要硬才行。

不少国产数据库在面向AI方向十分积极，在数据库中积极引入面向AI应用开发的新特性，在DB4AI方向做得挺不错，不过在AI4DB方向上并不重视。也就是说，未来的AI时代里，我可以为AI做很多事，但是运维我还是要依靠传统的人肉模式。

大家都标榜面向AI，凭空也不能说哪个数据库在AI方面做得不好。不过这几天我突然发现了一个评价一个数据库在AI4DB方面做得好不好的维度，那就是知识库标注。最近我都在做国产数据库的新版本知识图谱标注，也就是针对国产书库的各种特性、指标、等待事件、日志等要素做知识点标注。前阵子做国产数据库标注的时候，觉得十分费劲，每个知识点都被搅合得头昏脑涨，主要是让一个知识能够逻辑闭环十分困难，我们可以标注出一些问题场景，但是无法从数据库的各种监控数据、状态和日志去做闭环。

比如说OB，经常运维OB的朋友可能已经习惯了，遇到什么问题，要么从日志去搜，要么要开启某些诊断功能，甚至有些问题必须依赖火焰图这样的大杀器。最简单的方式也是需要查一堆系统表或者视图，然后从几个维度进行综合分析才行。一通分析之后可能还不一定能定位问题，还必须把分析中的发现反馈到原厂，由原厂的开发同学去做最终定位。

这两天需要把Oracle的老图谱通过重新标注生成新一代的图谱。目前这个图谱中有2000多个Oracle的知识点需要重新标注，本来我以为这是一个十分痛苦和漫长的工作，因为春节前重新标注OB的2000多个知识点整整花了我将近一个月时间，每天标注几十个知识点都会让我疯狂。没想到这回的工作一开始就让人觉得十分轻松，几乎所有的问题，都可以直接找到验证是否存在的METRIC，或者轻松找到验证的方法。这也说明了，Oracle的可观测性体系十分完善，利用内部的可观测性能力，实现自我诊断，自我优化，自治运行的基础十分扎实。

在未来时代，Oracle可以很放心地交给AI去做自治运行。不过到了国产数据库头上，就不好说了。人肉运维都十分费劲的数据库，何谈自治?