基于知识图谱的Postgresql深度分析

现在用PG的用户越来越多，不过PG数据库的运维就面临了很大的困难，今天老白和大家分享的题目就是“基于知识图谱的PostgreSQL数据库深度分析”，希望通过我们团队的一些工作成果，给大家一些PG运维工作上的新启示。

首先我们来分析一下PG数据库运维的难点有哪些。首先是和Oracle等传统商用数据库相比，甚至和目前流行度排名与Oracle几乎相当的MYSQL数据库相比，PG数据库的运维人员比较少，高水平的DBA更是缺乏，因此一旦企业内的PG数据库出问题，想要花钱找人来帮助解决都比较困难；其次是，PG数据库和其他开源数据库一样，在技术上依靠社区的力量，没有传统商用数据库的原厂支持，第三方的服务团队也相对较少；第三个方面是PG数据库自身的问题，PG数据库自身可用于监控、分析的指标数据也比Oracle等较为成熟的数据少，运维监控工具也相对比较简单，仅能监控一些简单的运行状态，真正系统出现问题，用于定位问题的分析手段也十分有限；第四是目前PG数据库的网上资源十分缺乏，无论是中文资料还是英文资料都十分缺乏，反倒是日文的资料相对丰富一些，这和PG数据库在日本大企业有较为广泛的应用有关；最后是，对于大多数实用PG数据库的企业来说，运维经验的积累几乎为0，大家都才从0开始积累自己的运维团队，运维能力与运维工具。

因为我今天要和大家探讨的就是一种构建PG运维经验，并利用运维经验的积累来实现运维能力提升的方法，我们把这个称之为“运维知识自动化”，这个运维知识自动化不同于“运维自动化”，运维自动化是实现运维中各种操作的自动化，比如部署自动化，变更自动化，迁移自动化，采集自动化，备份自动化等。这是一种“知识自动化”的应用模式，把各种知识，包括专家知识，AI能力等变成制动化的工具，用于日常的运维工作。

那么利用知识自动化的技术如何来做故障定位呢？我们用基于知识库的智能分析与传统的故障定位来做一个比较，不仅仅是针对PG数据库，针对Oracle等传统商用数据库也是如此的。传统的故障定位是依靠专家的经验，专家通过对日志，采集的各种报告与指标数据，并以某些运维工具作为辅助，进行人工分析；分析的结果与专家的水平有关，有时候好像分析出问题了，也不一定是正确的，特别是对于一些亚健康问题，表现出来的时间很短，等到专家到现场的时候，这个现象已经无法重现了，用于分析的指标，日志等也很少，往往会不了了之。甚至是一些数据库宕机等的严重故障，也往往缺少足够的数据，只能做一些猜测。有过MOS开SR经验的Oracle DBA都有过这样的经验，大多数的SR都因为故障无法重现，缺少分析所需要的资料，最终都属于SUSPEND状态了。

如果我们能够汇聚各类专家的经验形成一个知识库，并且在这个知识库的基础上构建一个自动化分析的工具，这样我们就不需要有专家到现场，就可以利用这些积累下来的经验进行深度分析了。而且随着时间的推移，这个知识库会积累的越来越完善，自动化诊断分析的能力也会越来越强。