参加了几次DTCC大会，从历史记录中找到了几年前的文字，看起来依旧青涩。
DTCC第一天归来(r5笔记第8天)
DTCC 2015归来随感（r5笔记第10天)
DTCC大会归来(r12笔记第61天)
技术大会其实带给我们很多的启示，有些收获是技术上的，有些是业务发展上的，还有些是职业生涯上的。参加大会大家如果带着问题，看看行业里大家是怎么做的，然后横向对比，找到不足和改进之处，我觉得参加大会算是值了。
否则，你自己想想，一天将近8小时的场，几十个主题，你能够注意去听的肯定是少之又少。如果希望自己像海绵一样吸取了所有的精华是不可能的。我们必须要做减法，一定要有重点和目标。当然我们也可以去刷脸，或者参加大会就是老朋友聚会的头脑风暴，这个某种程度上来说，收获更加直接有效。
我选择性的听了一些场次，重点听了两个主题。一个是Oracle方向的，另外一个是阿里的CloudDBA，然后和韩锋老师做了头脑风暴，相聊甚欢。
Oracle的主题是杨长老分享的关于Oracle分区的，杨老师的主题内容很干，文字内容偏多，在技术大会的ppt中算是一种异类。杨长老的内容讲得很细，对于分区的理解引用了一些自己实践中的案例，自己是如何思考，如何做平衡的。比如分区性能从TP和AP的角度来说，TP层面会从hash的方式入手，消除热点来满足提高性能，而从AP角度而言，会从并行的思路来入手。
分区的设计是Oracle这种关系型数据库中很精华的一个概念，在集中式共享的架构方式中尤其明显，前前后后的版本迭代，你会看到Oracle的分区体系现在已经很庞大了，会多了很多看起来陌生的新特性。
在12c和18c里面，空间虽然没有那么大，但是在可用性和自动化方面是下足了功夫。
比如里面一个400T数据的分区方案，对Oracle来说，我个人理解其实缺少的是一个中间件，类似GDS的一套东西或者更纯粹一些的一个第三方组件，可以做到物理上的分离，同时逻辑上统一。从扩展的角度来说，自己前几天对一个大表的分区，MyCAT中的DDL，可以做到一个表一年的维度里被拆成5000多份，而且还能够基本满足扩缩容的需求。所以说尽管Oracle和MySQL的分区的方案虽然不同，但是这些思想作为逻辑上的设计来说确实有很大的帮助。
第二个分享是阿里的CloudDBA,这里的思路，给我的启示是对于离线分析的功能设计，其实能够以此作为发力点，给业务带来更多的价值。整个产品的设计分为离线分析和在线分析，如果说事务性的工作是支持业务，响应业务，那么更大的价值就是运维优化的部分，换个角度来理解可能更好一些，比如Oracle里面的两个报告，一个是awr，这个可以理解是离线分析，而ash是在线，CloudDBA实现的就是这个层面的一些方案，直白一点说，属于SaaS层。
所以说从云平台的设计来说，IaaS,PaaS的底子足够好，在大公司可能不需要每个层面都单独需要自己来做，有了架构的层级，可以确定好边界来关注自己需要层面的需求和优化。那么SaaS层就是应运而生。
有几个典型的小例子，比如查看性能抖动的历史信息回溯，如果没有全面的信息收集，我们是很难去分析的。这是离线数据分析的直接价值。
对我来说，整个离线的部分会产生相当的数据量，这个点如果对于中小的公司的实现倒是可以借鉴天兔的思路。然后基于这个来下钻满足定制需求。
另外做任何的平台，业务的属性要很明确，因为纯技术方向的价值很难被认可，那么业务的目标就是我们需要优先考虑的，从这个层面来说，设计上我们的业务目标可以对标SaaS层的方案，比如自助服务，性能分析工具等，尽管我们很不完善，还在建设，但是以这个为切入点，业务价值和导向会很明显，整个链条如果能够贯穿下来，主线是很明确的。这样就不会有窝在自己的视野里，只追求自己的效率。
运维的出路在哪里，这个问题其实很难回答，但是又不得不回答。。
我从服务，平台，产品的维度来解释：
服务:很多基础运维的工作，已经有大量的第三方服务公司可以满足，很多甲方单独去投入很大人力物力去做就不是一个更好的方式.
平台：很多的平台现在已经很成熟，我们可以参考借鉴的很多，甚至可以直接得到服务。
产品：我举个例子，就下午杨长老分享中提到的Oracle 18c里面实现的普遍表瞬间切换为分区表，你会发现运维的门槛越来越高，不是技术简单，而是对运维的要求会越来越高，可能几年前我们会琢磨各种丰富的功能和实现，但是现在已经集成为透明的解决方案，那么运维的价值和意义就需要再拔高一个台阶
1866
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
