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