最近有在海口幸亲临现场参加了 VLDB Summer School 2021，见到了不少（未来的）业内大佬，也蹭了四个上午的课程，感触良多，这里写一点我个人对未来的看法，所谈及的东西或与本次活动主题分布式事务有关、或是数据库相关的其他方面。这是一篇吹牛的文章，没啥参考价值，大家随便看看即可。
活动回顾
于向遥老师的课很好，课件里的内容覆盖了事务处理的大部分重要研究成果，于老师讲课也是娓娓道来，听完之后我感觉下午上台的压力很大。于老师讲了四部分，我听前两节课也当是补了补课，在工业界混久了，对一些基础内容的理解就变得模糊了，而因为对这些基础理论的疏忽，读一些文章，比如 Silo, TicToc 这种，就没有一个顺理成章的思路，这次换个方向去理解这些文章、增加的假设、方法论上的变量控制，深有感触。于老师的后两堂课就比较 high level 了，Cloud Native DB 我也不怎么懂，还有不少没听明白的地方，需要回去补补课的（Aurora 自己也没有把所有的技术细节公开）。在我看来，Aurora 这种架构的优势在于小规模用户，以相对低的成本（但是 Amazon 卖的并不便宜）获得小规模上的高性能服务；而一旦选择 NewSQL 路线，竞争优势则不在于这种规模下的单 TPS 费用（不过听说有 NewSQL 数据库单机能跑过 MySQL 还是很震撼的），InnoDB 与云盘的结合也是个有意思的话题，我不是专家就不过多展开了。最后一节课的 Deterministic 数据库我事前也专门研究过，当时和一些工业界的朋友讨论的结果就是因为这种技术的限制过多，所以暂时不大能想到合理的使用场景，不过这项技术的思路是很有意思的，越到下层的 log 越大，所以只要下层能有确定性的结果，将副本复制提前，就会有更大的优化空间。在课后提问时有人问了副本之间的追赶问题，这确实是我之前没有考虑到的缺陷，在传统的搭建在单机存储引擎之上的副本复制协议之间，当某个节点落后太多时，可以通过发送 snapshot 来快速追赶，但是在确定性数据库里，这种技术可能会有问题，因为他需要一个全局 sequencer，而让全局 sequencer 去发送一个很大的 snapshot 就可能让整个系统卡住。用广义的眼光来看，在单机引擎上加上 Raft/Paxos 和他们的日志引擎，也能看作一个确定性数据库。
英俊哥哥讲课的时候同事有急事找我，没有听到，很可惜，回头对着录像补补课，这里就不展开说了。不过英俊哥哥宣传的 RisingLight 项目我非常感兴趣，抓住机会跟迟老师学习。
魏星达老师的课我很喜欢，也是内容很扎实的课，我不大懂新硬件，但也在一些论文中看到过 HTM 和 RDMA 的优化，不过我所读的论文一般将这部分放在 future work 里面，所以之前对细节还不甚了解。数据库从内存模型学习了很多概念与技术，尤其是在一致性上，对于不同的一致性模型，我们往往也能够在内存操作之上找到对应的概念，而 HTM 将一些事务的特性反带到内存模型当中，配合上 RDMA，让内存模型与事务模型更好的对等起来。这个思路非常精彩，IPADS 围绕新硬件做的一系列研究可能会成为下一代数据库的技术基石。当然对于这些技术我还有一个很关心的点在于他们什么时候能够成为一种标准，云厂商像提供 s3 一样提供这些设备，这个想法短期内是看不到什么希望，但愿未来有一天我们能够享受这种便利。
我读论文
我读过的论文并不算多，而且是带着工程思维去读的，以前总抱着一种寻找银弹的心态在读，想着能不能在这篇论文里找到一些革命性的变更。读到后来，在某次论文分享直播时，有弹幕问了我一个问题 “你们 TiDB 里有用什么比较新的论文技术吗？”，确实把我问住了。现在来看，我们也在尽力的思考如何优化系统，但最后却和一部分学术研究擦肩而过。这里面也有很多原因，比如我们的架构设计与学术研究的方向并不是很吻合，存算分离固然给系统带来了极大的可扩展性和未来的想象空间，但也势必在性能有所损失，以及在优化上有限制。
所以现在读论文，多少会带着些批判的眼光去看，不只是看他好在哪，还会看他的 worst case 和所给出的假设能不能接受，比如一个需要存储过程的系统，在学术里是很常见的，在工业中如果加入这个假设，那就会失去一大批用户。
所以综合我读论文的一些经历，个人认为学术如何被工业界接受是一个需要思考的问题，这次活动有位老师说 Google 与 Facebook 对 researcher 的要求之一都是需要说服工程部门采纳，我觉得很好，当然当下不被采纳的研究成果也是很有价值的，这两个方向都需要有人研究。
Bottom-up Design
这是同事分享的观点，我觉得很好，所以把核心思想在这里也分享一下，学术中追求的是创新点，但工业界不是。我们所做的很多优化，其实并没有架构上的改进，例如在当今磁盘设备的速度越来越快时，以往大家认为瓶颈都在 IO 设备之上，所以尽力优化写盘的次数，但是当 IO 设备不再是一个性能瓶颈时，我们去提升系统性能的思路也需要随之改变，比如当硬盘能过提供比较大的 iodepth、拥有越来越好的随机读写性能时，我们的系统也需要随之优化。我们研究事务，如果忽视了底层的特性，在不是瓶颈的点上做了优化的工作，最后可能不能够得到满意的结果。
复杂系统
在一个复杂系统中，工程能力是非常重要的，在这次活动里，我看到很多同学在实现 Percolator 时遇到了困难。Percolator 的原理其实并不复杂，我相信大家都能说清楚，但如果加入了接口幂等性的要求，就变得难以想清楚了，一些 corner cases 的处理要求在写代码的时候能想到某些特定的时序，再加上需要操作多个 Column Family 以及考虑 MVCC，这个模型的实现就变的复杂起来了。
说这个的时候就想起了当时和同事一起尝试在 TiDB 里做 Aria 的实现（由于理解不正确，当时实现的很挫，也有不少错误），这实在是一件苦差事，尤其是我们最后为了让 TPC-C 能跑起来处理了许多 bug。
在一个复杂系统中，应用研究成果会有很多的限制，比如我看到的很多论文在事务性能优化上都做得很好，但是大部分时候却不提及 DML 与 DDL 并行的问题，但是 DDL 确实是一个工业界的大问题，即使有了 F1 Online Schema Change，实现流派也有好多种，也各有长处，如果能看到一些这种方面的研究，也是一件很令人开心的事。
有一个工作这次大家都没有谈及，但是是我个人觉得既有意思又重要的——测试。我之前专门做过一次事务测试的 talk，在我看来这个东西难做也难讲，但很多时候（事务）测试并不比代码实现简单。今天我们对事务在隔离性和一致性上都已经有了相对明确的定义，但这还未能完全与现实的系统对应起来，比如有 DDL 参与的情况下什么表现才是符合预期的，就是一个难以回答的问题了。这方面我觉得 elle 做了非常杰出的工作，但回过头来想他的思路也是 jepsen 这方面日积月累、水到渠成的结果，个人觉得 elle 目前的缺陷可能在于用于推算事务关系的结构体与真实场景不太一样，以及与 SQL 语义的兼容性不是非常好。
杂谈
去现场活动是一件很开心的事情，上台面对这么多优秀学生是件很让人激动的事，我之前虽然做了一系列的 talk，但都是线上直播，所以自然在氛围感上差点意思。这次发现有这么多同学听过自己的 talk 也令我意外和惊喜。我们这个领域的高速发展离不开开源精神，在知识分享上我秉持相同的态度，没有什么值得藏的。
最后聊一下本文的题目，前面说的都是一些个人实际的想法，而这个题目的话题我不敢说的太大声，所以在文末来小声聊聊。借用于老师上课所引用的一句话 “Are we polishing a round ball?”，这个说法很好，我们不知道自己是否处于空洞的丰饶海还是一片无边无际又值得探索暖海之中。本多繁邦寻找了一辈子的清显转世，最后发现自己所追求的却是一片空洞。
