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

数据库是我的后援

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

相关推荐
云和数据.ChenGuang4 小时前
Django 应用安装脚本 – 如何将应用添加到 INSTALLED_APPS 设置中 原创
数据库·django·sqlite
woshilys5 小时前
sql server 查询对象的修改时间
运维·数据库·sqlserver
Hacker_LaoYi5 小时前
SQL注入的那些面试题总结
数据库·sql
建投数据6 小时前
建投数据与腾讯云数据库TDSQL完成产品兼容性互认证
数据库·腾讯云
Hacker_LaoYi7 小时前
【渗透技术总结】SQL手工注入总结
数据库·sql
岁月变迁呀7 小时前
Redis梳理
数据库·redis·缓存
独行soc7 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍06-基于子查询的SQL注入(Subquery-Based SQL Injection)
数据库·sql·安全·web安全·漏洞挖掘·hw
你的微笑,乱了夏天7 小时前
linux centos 7 安装 mongodb7
数据库·mongodb
工业甲酰苯胺8 小时前
分布式系统架构:服务容错
数据库·架构
独行soc9 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍08-基于时间延迟的SQL注入(Time-Based SQL Injection)
数据库·sql·安全·渗透测试·漏洞挖掘