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

数据库是我的后援

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

相关推荐
DBA小马哥1 小时前
时序数据库是什么?能源行业国产化替换的入门必看
数据库·时序数据库
爱可生开源社区3 小时前
某马来西亚游戏公司如何从 SQL Server 迁移至 OceanBase?
数据库
小瓦码J码5 小时前
PostgreSQL表名超长踩坑记
数据库·postgresql
yhyyht5 小时前
InfluxDB入门记录(三)flux-dsl
数据库·后端
IvorySQL1 天前
PostgreSQL 技术日报 (3月9日)|EXPLAIN ANALYZE 计时优化与复制语法讨论
数据库·postgresql·开源
stark张宇1 天前
MySQL 核心内幕:从索引原理、字段选型到日志机制与外键约束,一篇打通数据库任督二脉
数据库·mysql·架构
倔强的石头_1 天前
融合数据库架构实践:关系型、JSON与全文检索的“一库多能”深度解析
数据库
星辰员1 天前
KingbaseES数据库:ksql 命令行用户与权限全攻略,从创建到删除
数据库
华仔啊2 天前
千万别给数据库字段加默认值 null!真的会出问题
java·数据库·后端
随风飘的云3 天前
MySQL的慢查询优化解决思路
数据库