趣码乐园 Ai时代对数据库可观测性的新要求

无论是PostgreSQL/MySQL这些开源数据库还是Oracle，都不是为Ai时代设计的RDBMS，传统的烙印很深，其底层架构和核心里为Ai时代准备的特性并不多。因此面对Ai时代，都有快速进化的需求。

作为企业级商用数据库 ，Oracle一直面对高昂的售后服务成本，因此在20多年前，Oracle就在不断完善其可观测性体系 ，一方面可以让其用户能够更加透明地了解数据库正在发生什么，从而自行解决运维中的大多数问题；另外一方面通过强大的可观测性，让超过99%的用户侧故障的诊断工作可以通过MOS平台远程解决，并且通过制度让O记的用户为这种机制埋单，从而让O记的售后部门从公司的利润负担变成了盈利金矿。

因此虽然Oracle原本并没有为Ai提前设计，但是其数字化基础是在目前所有的数据库中是最好的。因此在进入Ai时代后，Oracle与其他数据库的技术差距很可能会进一步拉大。

没有数字化就没有智能化这个观点在我以前的很多文章中都有表达，这里就不展开讲了，为了让本文的读者更好理解，我简单说一说这里的基本原理。我们用大模型去分析推理某个CASE的时候，大模型会利用其掌握的各种知识去分析其可能的原因，如果在获得的数据和材料不够充分的情况下，很可能无法抓住关键因素，只能依靠假设去完善一条逻辑推理链条，这时候幻觉的出现几率就相当高了，而如果在出现幻觉的路径上存在十分明确的数据，就能够纠正幻觉。因此数字化能力对于基于大模型的推理分析是相当重要的。

反观开源数据库，因为不需要考虑商业上的售后服务，因此开源数据库在可观测性能力方面的重视程度就不高，虽然PostgreSQL比起MySQL来在 这方面强的不是一点半点，但是与Oracle比起来，差距是相当大的。一方面是开源社区与商业化的O记在运作模式上的差别，使得远程诊断、故障防范的需求对于PG核心开发来说的重要性不是那么高。PG用户遇到问题可以在PG内部去分析与调整的东西并不多，大多数问题最终都是通过SQL优化去解决。再加上以前PG的大型企业级应用场景也比较少，能够反馈到PG社区的这方面的需求也比较少。

最根本的愿意就是大家使用PG的方法一般就是装好之后，调整好基础的参数就开始用了，如果出了问题就就解决一下慢SQL问题，大部分系统也就能跑起来了。不过随着PG承担的大型企业级应用越来越多，只依靠优化优化SQL可能不太够用了，并且随着一个企业中使用的PG数据库实例越来越多，依靠人去做这些事情，成本也过高了。

未来是Ai赋能的时代，想让Ai赋能PG运维，那么PG首先就要做好准备，为Ai提供更多的可观测性数据。比如说我想优化一条SQL，那最好我能够知道SQL的实际执行计划，而不是通过Explain去模拟，因为模拟出来的执行计划很可能与实际执行的不同。如果我发现当前数据库内存使用量过高，我就需要知道是因为HASH JOIN过多引起的，还是SORT排序使用的内存过多引发的 ，从而快速定位存在问题的SQL，这时候我就必须知道当前这两种SQL执行的数量，或者说当前这两种内存被使用的总量，如果没有这些数据，专家也只能一点点去摸索，更不要说交给大模型去推理了。

Ai时代来临，想要让Ai赋能DB，DB需要做的事情还很多，传统的模式下，一切都需要人工，Ai时代里，很多时候，Ai是能够定位根因，并且提出解决方案的。比如说，当某一类SQL语句（可以提前约定，比如来自某个IP，某个用户，某种特征的查询语句）被发现对系统健康运行造成巨大威胁，需要进行限流的时候，数据库是否具有接口，限流某条SQL？类似的问题有很多，这些都是数据库内核设计者需要去为自己未来的产品考虑考虑的。