会议 | 2017VLDB 参会总结&论文鉴赏

前言

2017年8月28日到9月1日，VLDB 2017在慕尼黑工业大学举行，作为数据库领域的三大顶级会议之一，吸引了领域内大量专家、学者以及产业界人士参加。阿里巴巴集团是本次大会的黄金赞助商之一。蚂蚁金服有多位同学参加这次大会，其中包括来自OceanBase的同学和来自GeaBase的同学。本文是同学们此次参会的学习摘要。

整体感受

在慕尼黑的一周时间里，除了赶场听报告，就是和论文作者以及同行从业者交流，每天的信息量都很大，除了自己关注的经典的关系数据库领域的进展外，也接触到了不少扩展的知识和应用，以及学术界最新的一些研究方向和思路，收货还是很大的。对本次会议，整体的感受有如下的几点：

1.本次VLDB会议内容涵盖范围很广，思路很开阔。除传统的优化器、引擎、分布式执行、事务并发控制等内容以外；还有大量的大数据处理、图数据、空间数据、文本及半结构化数据、流数据、数据挖掘和分析、众包、社交网络分析、可视化等方面的内容。可以说，凡是和数据存储和处理相关的热点内容，本次会议都涵盖了。

2.在学术界，两个方向的研究当前是比较热门的：一个是基于新硬件（比如NVM、flash、GPU、FPGA）特性的数据库原型系统，研究如何充分利用新硬件的特点来提升数据库的性能以及扩展性；另一个是将传统关系数据库技术应用到大数据处理平台（比如spark），提升处理性能同时降低用户使用门槛。会议的前两场keynote：一个是讲新硬件发展如何推动数据库发展的，另外一个是讲大数据处理平台Spark发展历程的。

3.除学术界外，传统数据库巨头的报告比较多，并且也有一些干货。Oracle在第一天的workshop和后面的会议阶段有好几场报告，讲的内容都还不错，印象比较深的一是FAD的一场报告，谈到了做产品过程中的几个失败决策；另外一个是讲Oracle自适应的统计信息方面的实现。或许因为主场因素，SAP HANA也有几场报告，其中谈到HANA采用NVM存储的实践，因为是第一个按照生产系统要求去做的系统，对后来者也有一定的借鉴意义。作为数据库领域的后来者，SAP HANA的整体表现还是可圈可点的，尤其是在采用新技术方面，前几年就有报告显示查询计划是用LLVM编译执行的。4.华人在数据库领域的力量持续加强。本次会议颁发的几项大奖都被华人夺得，包括10年最佳论文和优秀青年学者奖。多场报告的主持人或主讲人也都是华人，会场中、会后讨论及聚会中也随处都能看到华人身影，据说参加本次VLDB会议的华人超过200人。我们也在茶歇的时候，和不少华人进行了交流，了解他们的研究方向和进展，同时也介绍了蚂蚁的业务和OceanBase数据库等的发展，希望后续能有更多的合作机会。

议题分享

一周的会议，信息量很大。会议期间的讨论加上会后的论文阅读，收获还是挺大的。下面就笔者感兴趣的几个方向，分享一下相关的议题及个人感想。

FADS

FADS（Failed Aspirations in Database Systems），顾名思义，是数据库领域一些失败经历的总结，给从业者提供了非常有价值的参照。

Oracle在这个环节有两场报告，一场是关于XML和面向对象数据库发展历程的，这两个方向一度都非常热，无论是学术界还是数据库厂商，都投入了大量的人力进行这方面的研究。目前现状也很明确，始终也没有大规模应用，是一个无足轻重的特性。另一场是关于Cache相关特性和产品的。

• Cache的演进
  

无论是为了减少响应时间还是提高系统的吞吐率，在数据库系统之上增加一层cache都是一种有效的手段；但也意味着更高的成本。从8i时代起，Oracle就陆续推出了一系列的解决方案：

8i时代的i-cache，利用一个小型的Oracle数据库系统在应用层缓存表数据，并且周期性地和后端Oracle数据库进行数据同步。优点是缓存系统和后端数据库是完全兼容的，都是Oracle嘛！并且也提高了性能。缺点一是成本高；二是应用要改造，因为Cache中的数据很有可能不是最新的。
在这个方案失败后，Oracle又采用了结果集缓存的方案，包括客户端缓存和服务端缓存，可以缓存整条语句的结果集也可以缓存语句片段的结果集。结果集缓存方案的优点是简单、对应用透明。缺点是场景受限，对于OLTP等更新比较多且重复查询比较少的场景，没有效果。
当前Oracle对于OLTP系统的缓存解决方案，主要是采用Timesten。Timesten是Oracle通过收购获取的产品，凭借性能优势以及和Oracle的高度兼容性，获得了广泛的市场。Timesten的扩展性最初是通过sharding方案把数据分布到多个Timesten实例来实现的，用Oracle的集群管理软件来管理。在多个Timesten实例间用专用的全局数据共享协议来实现数据的互相访问，同时每个Timesten实例采用HA方案实现高可用。这种方案最大的问题是对应用不透明，应用需要针对sharding做改造，并且集群的管理成本高。看起来，这就是分库分表的方案啊！
和上面相比，最新方案（Velocity Scale）就是类似于OceanBase的方案了！Timesten整个集群对外表现为一个数据库，可以动态增删节点，自动数据负载均衡。在集群拓扑图中看不到Oracle作为底层存储，可能对常规应用，在线数据都可以存放在Timesten集群中了？
从Oracle Cache解决方案发展历程中可以看出：在数据库之上增加一层Cache，成本是关键，不仅仅是新增Cache的软硬件成本，还包括运维成本；比成本更重要的是，新增cache是否对应用透明，如果需要修改应用来使用缓存，比如容忍过期数据，则会大大增加业务系统的复杂性和可维护性。对业务来说，还是希望一个all in one的系统来解决存储的问题。
其他两个话题
一场是关于Oracle收购的BerkeleyDB产品的，由Margo Seltzer在哈佛的家中远程连线讲的。微软也有两场：一场是关于基于时间戳的并发访问控制的，另一场是关于一个叫Stream Insight的新特性。
对照BerkleyDB（最早的一种key-value store，目前也是Oracle旗下的产品）的发展历程，创始人Margo讲了三个产品发展过程中的错误决策：一个是关于底层存储格式的，由于缺乏长远的考虑，做出了错误的决定，后续付出了重大代价；另一个是关于设计合理API的，讲了一个锁的实现方式；还有一个是支持XML（ XML成了本次大会集中反思的对象），BerkleyDB的核心竞争力是作为一种高效的KV-store产品，XML支持和产品发展方向好不相关。
阅读原文