排行
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
活动
大会
学习
课程中心
推荐优质内容、热门课程
学习路径
预设学习计划、达成学习目标
知识图谱
综合了解技术体系知识点
课程库
快速筛选、搜索相关课程
视频学习
专业视频分享技术知识
电子文档
快速搜索阅览技术文档
文档
问答
服务
智能助手小墨
关于数据库相关的问题,您都可以问我
数据库巡检平台
脚本采集百余项,在线智能分析总结
SQLRUN
在线数据库即时SQL运行平台
数据库实训平台
实操环境、开箱即用、一键连接
数据库管理服务
汇聚顶级数据库专家,具备多数据库运维能力
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
我的订单
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
资讯
活动
大会
课程
文档
排行
问答
我的订单
首页
专家团队
智能助手
在线工具
SQLRUN
在线数据库即时SQL运行平台
数据库在线实训平台
实操环境、开箱即用、一键连接
AWR分析
上传AWR报告,查看分析结果
SQL格式化
快速格式化绝大多数SQL语句
SQL审核
审核编写规范,提升执行效率
PLSQL解密
解密超4000字符的PL/SQL语句
OraC函数
查询Oracle C 函数的详细描述
智能助手小墨
关于数据库相关的问题,您都可以问我
精选案例
新闻资讯
云市场
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
专家团队
智能助手
精选案例
新闻资讯
云市场
微信扫码
复制链接
新浪微博
分享数说
采集到收藏夹
分享到数说
首页
/
看清一枚硬币的两个面
看清一枚硬币的两个面
白鳝的洞穴
2022-10-11
549
三十年前,我刚开始学习Oracle数据库的时候领我入门的张传锋老师和我说过,你永远无法同时看到一枚硬币的两个面。这句话让我受益无穷,后来互联网上也时不时出现这句话,不过这句话被篡改过了,变成了“你永远无法看到一枚硬币的两个面”。少了“同时”这两个字,这句话的意思就完全不同了。搞IT技术的总是在和是是非非打交道,就很容易绝对化了。“党同伐异”是人的天性,因此我们也更愿意听到自己喜欢听的观点。
实际上并不是我们无法看到一枚硬币的两个面,甚至我们也并不是不能同时看到一枚硬币的两个面。我们无法同时看到一枚硬币的A/B面,是因为我们所处的立场不同,因此我们看问题的角度错了。如果我们站在一个合适的角度,比如眼光从竖立的硬币的中间往两边看,从这个中间的角度是能同时看到这枚硬币的两个面的。
这两天我在梳理SQL SERVER指标的知识图谱,我发现有些时候判别立场的不同,会让我对同一个指标做出不同的标注。仅仅把CPU使用率标注为CPU是不够的,因为我们从这样的知识图谱中只能得出CPU问题导致了CPU使用率异常这样的荒诞结论。因和果这两个面都必须标注出来了,才能真正的实现脱离人的思维模式的数字化推理。但是因和果的关系太复杂了,次因、次生结果是不是也要标注出来,这一点十分难以把握。一旦标注错误,就会导致智能诊断衍生过于泛滥,为结果收敛埋下祸根。我顺便看了看一两年前我给其他数据库做的梳理数据,我发现其中多处存在这样的问题。
DBA在分析问题的时候,也总是喜欢纠结于因和果的问题。总是喜欢用自己的推理去驳倒别人的推理。我经常看到很多写的头头是道的问题诊断报告实际上里面破绽百出,不过我很少能和作者辩出个所以然来。中间大量的数据缺失让推理无法证真,同样也无法证伪。不过有时候抛弃成见,综合双方的观点,往往能够获得更加靠近事实的结果。多年的事实证明,向中看齐往往能够获得更多,而向左向右看,看到更多的是自我而已。
前两天谈到异常检测指标化的问题,也是我多年向中看齐的思维模式的结果。在评估风险时做指标异常检测,Monitor受不了,而如果把这个工作放到指标采集任务里,Collector又受不了。不过解决问题的方法并非非此即彼,采用中间路线,在5分钟定期任务里做评估,并且把一部分计算任务放到每天一次的任务里算好,那么这个问题就不难解决了。
很多人看待数据库产品的方法也存在类似的问题,喜欢分布式数据库的人就认为数据库一定得是分布式的;而喜欢集中式数据库的人就一定认为分布式数据库不好维护不好用。实际上我看到的很多关于此类的评价,都是先把硬币平放在桌子上,然后再去看这枚硬币,那样的话,他就只能看到硬币的一个面了。集中式数据库与分布式数据库的优点与缺点都是十分明显的,如何选择取决于应用场景的特点,以及使用者的技术能力特点。市面上有很多数据库的测试报告,我一般来说也就是看看而已,并不会把报告的结论当成选择数据库的依据。因为这些报告的立场就是向左向右看的,这种视角只会把自己看成一朵花,把竞品看的一文不值。
我们的数据库厂商在研发数据库的时候也是如此,喜欢Oracle数据库的,那就是全面照抄,也不管Oracle的一些设计是三四十年前的,和现代硬件已经脱节,目前还在使用是迫于无奈。Oracle数据库是宇宙间最强大的数据库产品,因此它的一切都是好的,能打好小抄,自己的产品就差不到哪去。全然不顾自己是否有能力理解好Oracle数据库产品的核心技术点,能否把Oracle数据库的最关键的核心技术学到手。事实上,Oracle数据库最强大的是SQL引擎这些年面对数百万用户,在几十年中积累的优化经验,而不是那些比较显而易见的架构特点。实际上,Oracle在对待现代硬件方面,已经暴露出了不少问题,有些问题因为历史包袱的问题,还是不容易解决的。反而是SQL SERVER这样的后起之秀,在NUMA,非易失性硬盘等现代硬件的支持上,有很多亮点,在这些方面,我们的数据库厂商更应该去学习这些,而不是完全照搬Oracle。
而否定Oracle数据库的人和上面的观点正好相反,他们认为Oracle的架构设计太老了,新的数据库产品可以轻松实现弯道超车。完全没有考虑清楚,一个数据库产品的好坏,不仅仅在于架构是否现代化,更重要的是真金白银的投入。数据库产品的性能与可靠性是从大量的优化中得来的,而不仅仅是从总体架构的先进性中得来的。我在做D-SMART研发的时候,经常感到研发经费的不足,很多想法,需要时间和成本去实现的。甚至有很多东西光有钱有资源还不够,还需要大量的用户实际案例来磨合才能逐步完善。我们的数据库厂商应该也会遇到类似的困境。从高处立意,从低处用功,方可成大事。
实际上看清楚硬币的两个面这个问题,用一个俗得不能再俗的词就可以描述了,那就是“
换位
思考
”。哪怕我们的角度不够好,看不清硬币的两个面,我们勤快一点,调整个角度再去看,或者把硬币翻过来再认真看一看,再下结论,不就行了吗?
文章转载自
白鳝的洞穴
,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
领墨值
有奖问卷
意见反馈
客服小墨