好数据库不需要运维这种话你信吗

2023年 9月 2日 32.9k 0

前阵子我向一个做通用关系型数据库的朋友吐槽,说他们的数据库产品给DBA的运维监控数据太少,除了看数据库日志没有什么好点的了解数据库运行状况的数据可用。他十分认真的和我谈了serverless database等新潮的概念,大谈数据库的自动化驾驶,最后他总结说:“好的数据库是不需要运维的,我们的产品目标就是如此。”对于这个观点,前半句我是十分认同的,但是对于后半句,我是不大相信的。

         

早期系统规模比较小,业务相对简单的时候,Oracle数据库也是不需要运维的,而且也没人懂得运维。90年代初的时候,我们给用户安装的Oracle数据库,连我们也不懂 如何去运维它,甚至启动了都不大敢关闭,生怕哪次重启就起不来了。不过那时候的数据库也确实不出问题,安装好以后跑上一两年,只要硬件不出问题,一般也不会有啥问题。

         

90年代末,我们初步掌握了一些Oracle数据库的运维和优化技术,找到一家银行去交流Oracle运维、优化。那家银行的IT部门老大说,我们的Oracle 数据库只需要做好备份就行了,不需要运维。我问他们是不是需要优化,他说依然不需要,当服务器CPU使用率超过20%,我们就升级硬件。

         

从上面的这两个案例看,Oracle数据库也曾经是不需要运维的。不过而从本质上说,并不是Oracle数据库不需要运维,而是当数据库规模小,业务相对简单的时候,哪怕超级复杂的Oracle数据库也可以在免运维的情况下比较平稳地运行。前些年,某企业搞去IOE,上了很多云平台上的MySQL数据库,这些数据库跑得相当稳定,云运维部门的运维人员顶多懂得在云管平台上启停RDS实例,不过系统用得也不错。这个企业的IT部门主管逢人就说,自从用MySQL换了Oracle,系统变得更稳定了,他现在终于明白了以前数据库用不好是没选对数据库。

         

MySQL数据库真的神奇到了免运维都跑得比Oracle好了吗?实际上那些跑在MySQL上的应用系统都很小,而且平时也没啥人用,而Oracle上承载的都是企业的核心应用,负载极高,三天两头出问题。相比较之下,领导眼中就形成了如此的错觉。这些年这些原本很小的MySQL数据库从几个GB发展到上百GB了,最近似乎也开始动不动出些问题了。

         

“不需要运维的数据库”一定是数据库厂家追求的目标,但是要实现这个目标,以目前的技术水平来看,还十分困难,这是为什么呢?数据库从本质上也是人写出来的软件。如果针对某个应用去开发一个数据库产品,那么数据库的研发人员可以针对应用特点去做很好的磨合,做到免运维,只要投入足够大,还是有可能出现的。

         

如果是开发一个通用数据库产品,那么你哪怕设计的再好,数据库架构师也不大可能能够把各种用户的各种复杂的业务场景,以及开发商超烂的SQL编写水平都考虑进去。因此数据库中虽然设计了大量的可以让用户根据应用场景去调整的参数,依然无法完全匹配广大用户的复杂需求。想要做到免运维十分困难,说不准啥情况就把数据库搞HANG了或者搞宕了。

         

既然目前的绝大多数数据库在本质上无法做到针对任何用户场景都免运维,那么提高数据库的可观测性能力,让DBA能够通过指标、等待事件、日志等多种手段去了解数据库的运行状态就十分关键了。三十年前的Oracle数据库和现在的很多国产数据库类似,除了v$sysstat里的几十个指标和alert log,没啥可以观察的数据。那时候运维Oracle十分简单,BUFFER CACHE命中率不低于80%,library cache命中率不低于90%,系统配置上就没啥可调整的了,剩下的工作就是优化SQL语句了。随着7.3.4推出OWI后,我们可以使用utlbstat/utlestat来生成一份数据库运行情况的报告,Oracle才真正需要运维了,而且DBA也能够利用Oracle提供的运维能力让数据库跑得更好了。Utlbstat工具在8.0就变成了更为强大的statspack报告,这也是AWR报告的前身。

         

现在很多国产数据库也学习Oracle的做法,搞了类似AWR的报告,不过AWR报告的基础是OWI,OWI实际上是通过在数据库中实现了十分精细的埋点,使数据库的运行状态可视化了,这需要数据库架构师对书库的指标体系和日志体系做十分精细的设计才能做好的。我们的国产数据库在内部埋点上做得还十分粗糙,统计出来的运行指标覆盖面也不足,质量也不够好。基于此做出来的AWR报告也就是个摆设而已。

         

既然无法很好的提供让DBA运维数据库的接口,那么就另辟蹊径,去做免运维的数据库产品吧。殊不知,数据库的自动驾驶也是基于这些可观测性能力的,而不是通过优秀的架构设计就能实现的。一个优秀的数据库架构师可以设计出一个充分利用了先进技术的、可扩展性优于Oracle的数据库产品来,但是设计不出一个可自动驾驶的数据库产品来。因为数据库运行的基础环境太复杂了,上面的应用太复杂了。能够在两个复杂条件下实现自动驾驶是十分困难的。Oracle数据库在自己的云环境下提供了一个强大自治能力,但是这个能力目前也还无法泛化到任意的用户平台。

         

文章的最后,我还是建议我们的数据库厂商先沉下心来把数据库的可观测性做做好,让DBA能够更加方便的运维数据库,至于自动化驾驶这种高级能力,还是慢慢搞吧,估计我退休前是用不上了。

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论