<span id="bec97c9c1e"></span><address id="bf478aa19c"><style id="bgf9a705bd"></style></address><button id="bl82d5a9f7"></button>
                        

          • 博客访问: 14000493
          • 博文数量: 1495
          • 用 户 组: 普通用户
          • 注册时间: 2012-05-14 23:24
          • 认证徽章:
          个人简介

          每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1500多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

          文章分类

          全部博文(1495)

          文章存档

          2018年(136)

          2017年(320)

          2016年(356)

          2015年(346)

          2014年(270)

          2013年(46)

          2012年(21)

          分类: IT生活

          2018-05-13 00:10:12

          参加了几次DTCC大会,从历史记录中找到了几年前的文字,看起来依旧青涩。

          DTCC第一天归来(r5笔记第8天)

          DTCC 2015归来随感(r5笔记第10天)

          DTCC大会归来(r12笔记第61天)

          技术大会其实带给我们很多的启示,有些收获是技术上的,有些是业务发展上的,还有些是职业生涯上的。参加大会大家如果带着问题,看看行业里大家是怎么做的,然后横向对比,找到不足和改进之处,我觉得参加大会算是值了。

          否则,你自己想想,一天将近8小时的场,几十个主题,你能够注意去听的肯定是少之又少。如果希望自己像海绵一样吸取了所有的精华是不可能的。我们必须要做减法,一定要有重点和目标。当然我们也可以去刷脸,或者参加大会就是老朋友聚会的头脑风暴,这个某种程度上来说,收获更加直接有效。

          我选择性的听了一些场次,重点听了两个主题。一个是Oracle方向的,另外一个是阿里的CloudDBA,然后和韩锋老师做了头脑风暴,相聊甚欢。

          Oracle的主题是杨长老分享的关于Oracle分区的,杨老师的主题内容很干,文字内容偏多,在技术大会的ppt中算是一种异类。杨长老的内容讲得很细,对于分区的理解引用了一些自己实践中的案例,自己是如何思考,如何做平衡的。比如分区性能从TP和AP的角度来说,TP层面会从hash的方式入手,消除热点来满足提高性能,而从AP角度而言,会从并行的思路来入手。

          DTCC 2018大会归来

          分区的设计是Oracle这种关系型数据库中很精华的一个概念,在集中式共享的架构方式中尤其明显,前前后后的版本迭代,你会看到Oracle的分区体系现在已经很庞大了,会多了很多看起来陌生的新特性。

          DTCC 2018大会归来

          在12c和18c里面,空间虽然没有那么大,但是在可用性和自动化方面是下足了功夫。

          DTCC 2018大会归来

          比如里面一个400T数据的分区方案,对Oracle来说,我个人理解其实缺少的是一个中间件,类似GDS的一套东西或者更纯粹一些的一个第三方组件,可以做到物理上的分离,同时逻辑上统一。从扩展的角度来说,自己前几天对一个大表的分区,MyCAT中的DDL,可以做到一个表一年的维度里被拆成5000多份,而且还能够基本满足扩缩容的需求。所以说尽管Oracle和MySQL的分区的方案虽然不同,但是这些思想作为逻辑上的设计来说确实有很大的帮助。

          第二个分享是阿里的CloudDBA,这里的思路,给我的启示是对于离线分析的功能设计,其实能够以此作为发力点,给业务带来更多的价值。整个产品的设计分为离线分析和在线分析,如果说事务性的工作是支持业务,响应业务,那么更大的价值就是运维优化的部分,换个角度来理解可能更好一些,比如Oracle里面的两个报告,一个是awr,这个可以理解是离线分析,而ash是在线,CloudDBA实现的就是这个层面的一些方案,直白一点说,属于SaaS层。

          DTCC 2018大会归来

          所以说从云平台的设计来说,IaaS,PaaS的底子足够好,在大公司可能不需要每个层面都单独需要自己来做,有了架构的层级,可以确定好边界来关注自己需要层面的需求和优化。那么SaaS层就是应运而生。

          DTCC 2018大会归来

          有几个典型的小例子,比如查看性能抖动的历史信息回溯,如果没有全面的信息收集,我们是很难去分析的。这是离线数据分析的直接价值。

          DTCC 2018大会归来

          对我来说,整个离线的部分会产生相当的数据量,这个点如果对于中小的公司的实现倒是可以借鉴天兔的思路。然后基于这个来下钻满足定制需求。

          另外做任何的平台,业务的属性要很明确,因为纯技术方向的价值很难被认可,那么业务的目标就是我们需要优先考虑的,从这个层面来说,设计上我们的业务目标可以对标SaaS层的方案,比如自助服务,性能分析工具等,尽管我们很不完善,还在建设,但是以这个为切入点,业务价值和导向会很明显,整个链条如果能够贯穿下来,主线是很明确的。这样就不会有窝在自己的视野里,只追求自己的效率。

          运维的出路在哪里,这个问题其实很难回答,但是又不得不回答。。

          我从服务,平台,产品的维度来解释:

          服务:很多基础运维的工作,已经有大量的第三方服务公司可以满足,很多甲方单独去投入很大人力物力去做就不是一个更好的方式.

          平台:很多的平台现在已经很成熟,我们可以参考借鉴的很多,甚至可以直接得到服务。

          产品:我举个例子,就下午杨长老分享中提到的Oracle 18c里面实现的普遍表瞬间切换为分区表,你会发现运维的门槛越来越高,不是技术简单,而是对运维的要求会越来越高,可能几年前我们会琢磨各种丰富的功能和实现,但是现在已经集成为透明的解决方案,那么运维的价值和意义就需要再拔高一个台阶

          阅读(1962) | 评论(1) | 转发(0) |
          给主人留下些什么吧!~~

          lusklusklusk2018-05-14 13:40:51

          评论热议
          请登录后评论。

          登录 注册