从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能让我们更多的实操掌握这些技能,这样有利于推广和传播。官方几乎不假思索的说这个没问题,可以安排。

数据库是我的后援

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

相关推荐
没书读了14 分钟前
ssm框架-spring-spring声明式事务
java·数据库·spring
i道i1 小时前
MySQL win安装 和 pymysql使用示例
数据库·mysql
小怪兽ysl1 小时前
【PostgreSQL使用pg_filedump工具解析数据文件以恢复数据】
数据库·postgresql
wqq_9922502771 小时前
springboot基于微信小程序的食堂预约点餐系统
数据库·微信小程序·小程序
爱上口袋的天空1 小时前
09 - Clickhouse的SQL操作
数据库·sql·clickhouse
聂 可 以3 小时前
Windows环境安装MongoDB
数据库·mongodb
web前端神器3 小时前
mongodb多表查询,五个表查询
数据库·mongodb
门牙咬脆骨3 小时前
【Redis】redis缓存击穿,缓存雪崩,缓存穿透
数据库·redis·缓存
门牙咬脆骨3 小时前
【Redis】GEO数据结构
数据库·redis·缓存
wusong9993 小时前
mongoDB回顾笔记(一)
数据库·笔记·mongodb