OceanBase开发者大会DevCon归来

今天参加了OceanBase开发者大会DevCon，还是有蛮多的收获的，整篇文章我分为两个部分。第一部分是会议的议程情况，让没有参加的同学可以有一个简单的了解，第二部分是我个人对于一些问题的思考，均是个人观点。

第一部分：

疫情以来，这算是我第一次正式参加的一个技术大会了。

签到后在二楼有一面很有新意的技术墙，都是用乐高一样的小块拼接而成的。

早上的议程还是比较满的，比较期待的是阳振坤老师的第一个分享《我眼中的数据库技术》。

依然还记得上一次阳老师在去年发布小鱼4.0版本时对于数据库的热爱和真诚。

华东师范大学周校长分享的《未来，中国需要什么样的数据库？》

Keith Chan分享的《云原生技术趋势解读》

日照分享的《打造开发者友好的分布式数据库》，这一页是精华部分。

在这次大会上也公布了四项“开发者友好”实践，包括4.1版本发布，升级工具，场景化文档和统一企业版和社区版代码分支。

我参加了现场圆桌对话的部分，讨论了单机-分布式一体化架构、研发关注的数据库、HTAP数据库讨论。

这个环节还是很有新意的，在数据库大赛中邀请了获奖同学，他们来自国内知名高校，都是未来数据库方向的人才。

第二部分：个人的一些感受，我分为4个问题来展开讨论。

问题1：关于数据库近些年来的变化情况

这里我就不具体讨论数据库的发展趋势了，我补充一些我观察到和我感受到的信息。

1）目前数据库在垂直细分领域的变化越来越快，随着业务需求的多样化，数据库的多品类支持，原本大数据4V模式下，数据规模增长这个维度的问题使用分布式数据库是一个很好的切入点，在另外3个维度也是这些年有一定发展的新型数据库体系，比如图数据库，众包数据库等。

2）业务模型简化，这些年来可以明显感受到研发的业务模型设计会趋向于简化，一个直观的感受就是业务逻辑中很少能够看到存储过程，这对于分布式数据库的发展有大有帮助，减轻了原有的一些包袱。

3）打破边界。比如Oracle数据库在2018年左右就提出了自治数据库的概念，这个概念已经打破了原本DBA的边界，是一种巨大的挑战；智能运维这个体系已经不光覆盖数据库方向，在运维体系中都开始有了场景化的落地；单机-分布式架构一体化，这个概念是蛮颠覆原有的生态体系的。

4）对于数据库稳定性和性能的追求有一些模糊，可以看到现在国产化数据库发展也很快，有时候面对大量数据库时，研发和DBA都会有一种茫然，换句话说，我们有时候也不知道自己需要什么，而数据库的稳定性和性能是很核心的关注点，我们这些被更丰富的功能和更好的用户体验占据了心智。

问题2：如何看待OB,你是否会将OB作为选型参考

对于这个问题我是相对开放的，有几点供参考。

1）首先我看重的是数据库生态，这个数据库生态不光是包括SQL数据库技术栈，NoSQL数据库技术栈，还包括大数据等。我是需要在数据资源体系去看待这个事情。那么是否引入OB,是否考虑，对我来说，现在的MySQL技术栈已经远不是原本的主从标准版模式了，我们已经通过MySQL协议兼容的方式引入了多种数据库技术，所以具备了基础兼容性的基础上，我觉得对于研发没有额外的接入成本，那么我需要考虑的就是这个产品本身是否匹配业务需求。

2）资源性价比，自从OB 4.0版本发布之后，我是比较关注的，因为低配版的模式是符合我对于MySQL技术栈纯PC路线的规划的，这也算是打开了一个口子，可以让原本的资源接入和配置管理部会有明显的变化，但是如果性能收益更高，接入的动力会更高。

3）资源布局，对于数据库的整体布局，我有自己的一些认知和思考。大体来说，在私有云方向我是按照6:4（标准版集群和分布式集群的配比），对于公有云体系配比是8:2(RDS和云原生数据库）甚至9:1

4）业务对于数据库的在线迁移能力是很关注的，我们近期会发布的一个调研报告中能够探查到业务对于在线迁移的可容忍停机时间60%以上在2个小时以内，这就需要在数据库生态工具如迁移工具等方面具备一定的支持。

5）多集群融合，数据库集群技术是各有优劣，至少在不同的业务场景下存在即合理，共存本身也说明了技术栈之间的一种动态平衡情况。比如NewSQL,中间件集群，OB等，我是希望通过一些异步的数据同步实现集群在特定业务场景中的互补，所以从这个视角，我可能又多了一个选择，而不是负担。

问题3：关于HTAP的一些感受和想法

HTAP是这些年来比较火的概念，从我的认知来看，我觉得技术方向分久必合，合久必分，HTAP也是应运而生，是一种很自然的演进，或者说重新定义。

其中的焦点主要在OLAP方向，从系统视角来看待，可以通过空间换时间来实现，换另外一种思路OLAP的需求其实是不追求数据库的精确性的，它和OLTP对于数据的准确性是有显著差别的。 从算力视角来看，主要追求的是快，但是这个快会存在一些歧义，都是快，但是意义不同。比如执行部分本身就有时间消耗，可能从3秒到1秒也是很大的提升；对于OLTP我们可能追求的是毫秒级的延迟，而在OLAP中可能是秒级甚至更大一些；对于数据库的准确性，T+1的需求是一种相对固化的需求，OLAP在追求实时性方面本质不是准确性需求，仅仅是将近实时的数据作为一种参考依据。

HTAP在我的理解中，主要有三类实现模式。

第一种思路是像Oracle ,SQLServer这种本身单机性能就很不错的数据库，因为自身性能强大，所以可以自动适配OLAP的部分需求。

第二种思路是以OLTP为主，辅助OLAP的支持能力，其中的设计点主要在于资源隔离，这就带来了两面性，一方面是因为需要不影响OLTP而需要做资源隔离，另一方面则是因为独立的数据副本维护带来的复杂度，如果这个问题能够找到一个平衡点，也是一种创新。

第三类思路是以OLAP作为切入点，如果OLAP足够强大，同时有深厚的OLTP底子，这种演进方式是一种降维打击。比如探索性业务，业务模型复杂多变，如果在OLAP支持方面有明显的优势，那么可以很自然的把OLTP的业务整合集成起来；另外一类则是OLAP的需求是强需求，如果通过硬件资源优化就能够解决，或者说现在的OLAP方式支持在低配的情况下也有很大的提升，那么这个事情的性价比还不错。

问题4：对于研发和DBA同学的一些学习建议

对于研发同学和DBA同学的一些通用建议，可能还是老三篇，没有什么新意，不过这几样坚持下来我相信是又收获的。

1）多总结。好记性不如烂笔头，手底下不能偷懒。多总结成案例，让自己看到问题就能够完整的回放整个问题处理过程。

2）建立自己的知识体系，不要把攻略当法宝。建立自己的知识体系尤其重要，你处理的问题多了就有了更多的感悟，可能存在的一个误区是我们可能解决了一个问题之后，会得出错误的结论，甚至从网络中搜索得到的也是错误的结果，那么你把这种攻略当做法宝路就会很窄，不断完善自己的知识体系，就会不断找到自己的边界。

3）社区连接，多参加一些社区的互动，有精力和能力多做一些技术分享，多参加一些活动，线下见见技术圈的朋友，总归是有一些收获的。