从CAB到PAB Oracle的AI 23.6(之二)

书接上回

第二天在参会的途中就遇到了公司OGG的延迟问题。通过我快速的判断,我认为应该重启抽取进程。最终我的判断正确,这个问题得以解决。而我也把我的思路发给了昨天官方讲演OGG的老师。他也基本认可我的分析。

我个人觉得这些如果能融合到数据库专有大模型的知识库中,数据库在不少场景中就可以免运维了。数据库自动化程度越高,DBA的低级操作也就越少。而可以把有限的精力开从源头开始管理开发和业务。

比如故障自愈是可以的,但是也不能一小时自愈一次。DBA要去看看为什么这么频繁的自愈?减少自愈的次数。不能因为他是可以自愈的就一直自愈。打个比方,皮肤被划破了可以再愈合,但是我们不能好了伤疤忘了疼,全上下没一块是好的,那也不行。

23AI的技术全景图

复制代码
看到这些不得不佩服。大家交流下来不少是去年会议上提过,只是当时还是概念或者不完善。而今年至少在演示上都可以有成功的实现了。即PPT上的和实际的趋于一致。而不像有些我们日常见到的永远仅仅停留在PPT上。我就曾经见过有人的PPT上写 贝叶斯分类,而到现在还是只能做报表(还没做好) 

ALL in one

不少从事架构的人认为,系统越复杂越好,将来是自己的成绩也是自己的护城河。我恰恰相反,我觉得最好的是我做好以后就没什么问题,这样有精力去挑战新的。而不是只在自己的城堡中防守一辈子。

所以我一向觉得越简单越好。而ALL in one对开发,对运维,对DBA都利大于弊。我这个观点被不少人嗤之以鼻。但是当2021年信通院的《国产数据库发展趋势》的白皮书出来,我觉得我不是孤单的。而Oracle在2019年基本都做到了大部分in one。而现在是ALL in one。事实上这个时代并没有过去,反而是加快的到来了。

我们应该感谢ALL in one。让我们本来只处理单一关系型的人,能主动和被动、直接或间接扩展了自己的知识面和自己的权力范围。OLTP、OLAP、数仓还是数据湖或者区块链、物联网、图、向量、搜索引擎等等全访问去学习和掌握。

各抒己见

在高手云集的大会上会有一些碰撞,也带给我一些思考。Oracle的全球分布式,我自己就是了解了,但是没有深入。但是白老师就提出了,能不能用他当一个简易版的RAC+ADG?官方思考了一下说可以。我当时就开始反思,自己为什么没有去考虑?还是思维固化了。

期望

我以期望明年的CAB和PAB能让我们更多的实操掌握这些技能,这样有利于推广和传播。官方几乎不假思索的说这个没问题,可以安排。

数据库是我的后援

数据库越稳越简单,我就可以有时间去压制前置不合理的流程。从而使得底层的数据库更加稳定形成良性循环。

相关推荐
1***t8274 分钟前
MySQL 8.0安装
数据库·mysql·adb
c***69308 分钟前
使用mysql报Communications link failure异常解决
数据库·mysql
t***q3313 分钟前
关于Mysql 中 Row size too large (> 8126) 错误的解决和理解
数据库·mysql
马克学长34 分钟前
SSM贫困区教育资源捐赠平台m6y9w(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面
数据库·ssm 框架·教育资源捐赠·贫困区帮扶
@游子3 小时前
SQL注入语法和介绍(一)
数据库·oracle
蒋士峰DBA修行之路6 小时前
实验十三 WDR诊断报告
数据库
杂亿稿6 小时前
数据库的约束
数据库
u***32436 小时前
使用python进行PostgreSQL 数据库连接
数据库·python·postgresql
Codingwiz_Joy6 小时前
Day44 盲注、报错注入 & 实战复现
数据库·安全性测试
7***99878 小时前
GaussDB数据库中SQL诊断解析之配置SQL限流
数据库·sql·gaussdb