顶会 关于数据库顶级会议 SIGMOD 2018看这一篇就够了!

  原标题:顶会 关于数据库顶级会议 SIGMOD 2018,看这一篇就够了!

  SIGMOD数据管理国际会议是数据库领域具有最高学术地位的国际性学术会议,位列数据库方向的三大顶级会议之首(其次是VLDB及ICDE)。OceanBase的核心团队成员有幸参与到了SIGMOD 2018会议中,本文由蚂蚁金服OceanBase研究员日照为大家带来最专业、最前沿的大会独家报道。

  接下来几天,蚂蚁金服OceanBase数据库官方微信号将为大家持续带来SIGMOD系列论文解读,以下是精彩预告:

  现任蚂蚁金服OceanBase研究员,OceanBase初创成员之一,负责OceanBase 0.5 / 1.0 / 2.0版本的技术架构,著有《大规模分布式存储系统:原理解析与架构实践》。

  今年的SIGMOD第一次在美国南部的石油城市休斯顿举办。提到休斯顿,大多数知道它以能源、航空和运河而闻名于世,当然,对于很多中国人来讲,最知名的还是姚明所在的休斯顿火箭队。如今,这座城市却因为SIGMOD这一数据库领域的顶级盛世而再次热闹非凡。

  这一次,来自全球各地的800名参会者,济济一堂,共襄盛会,于休斯顿,共同见证数据库行业的飞速发展,探讨业界最领先的数据库应用方向。

  本届SIGMOD和PODS会议合办,一共持续6天,其中3天为正会,其它时间是PODS和workshop。今年总共有90篇学术论文和15篇工业论文,参会的中国人众多,而发表论文的中国人数量也非常可观,阿里巴巴、蚂蚁金服和华为作为中国企业赞助了本次会议,中国已经在最前沿的数据库国际性学术会议中占据了重要的一席。

  SIGMOD会议包含2个主题演讲(keynote),15个学术报告会(research session)以及4个工业报告会(industry session)。数据库是一门侧重工程的实践类科学,而今年的会议安排和去年最大的差别在于增加了专门的industry session:来自Amazon、Microsoft、阿里巴巴等工业界的分享都极具含金量。

  阿里巴巴作为赞助商代表组织了一场主题为“数据驱动及机器学习赋能的自治数据库系统”的workshop,内容分为两个部分:第一部分由集团数据库技术负责人分别介绍了阿里巴巴数据库和计算平台等产品,如何依靠创新解决阿里巴巴业务场景中传统数据库面临的挑战,第二部分则是邀请了五位学术界知名教授作为嘉宾分享了他们在“AI+数据库”领域的工作。

  SIGMOD会议主题包括传统数据库事务和索引结构、查询处理和优化、并行数据库、图数据库、空间数据库、近似处理和相似度查询、数据集成与挖掘、安全与隐私以及最近几年比较热门的云数据库、新型硬件和机器学习。OceanBase参会人员关注的领域主要涉及事务和索引结构、查询处理和优化、并行数据库,云数据库、新型硬件和机器学习。本文旨在解读工业界论文,后续的文章将进一步解读这些领域的其它论文。

  本次会议的最佳论文是CMU的SuRF: Practical Range Query Filtering with Fast Succinct Tries”。布隆过滤器只适用于单行读取(Get)操作,实际业务场景中OceanBase可以通过对主键的前缀动态创建布隆过滤器来实现范围过滤功能。这种方法不够通用,论文中提出了一种新的数据结构,称为FST(Fast Succint Tries),除了用于过滤单行读取,还可以用来过滤范围扫描(Scan)。FST在之前的研究成果基础上做了进一步优化,很好地平衡了查询性能和内存占用,尤其适用于各种类LSM存储引擎。

  说实话,这两场keynote都没有给我留下特别深的印象。其中,Eric Brewer的演讲大部分是Kubernetes的产品介绍。听演讲的过程中,我在思考一个问题:阿里巴巴以及很多互联网公司也有类似的容器化产品,为什么Google最后成为了标准?是因为技术,是因为生态,又或者是因为Eric Brewer等Google研发人员的业界影响力。这个问题我没有答案,我们需要不断地探索,才能明白满足某个公司、某个行业、甚至多个行业的需求与成为全行业事实标准之间的巨大鸿沟。

  从数据库发展趋势的角度看,我认为今年SIGMOD主要体现在如下几个方面:云数据库、新型硬件,自治数据库、AI+数据库,图数据库。

  整体上看,传统关系数据库内核的突破性工作变得越来越少,大部分研究工作是多个领域相结合的成果。相对来讲,工业界的实践类论文对于工程人员更有借鉴意义。下面是我对本次大会industry session八篇论文的解读。

  Aurora数据库采用存储计算分离的技术架构,相比单机MySQL/PostgreSQL的主要优势有两点:一是无损容灾,将数据库容灾问题转化为更加成熟的分布式存储系统的容灾问题,而类Paxos协议在分布式存储中广泛使用;二是存储可扩展。存储单元是分布式的,可以很容易突破单机存储容量限制,而不需要涉及到复杂且性能更差的分布式事务。当然,事务是不可扩展的,Aurora团队正在开发的Multi-Master功能用于解决事务的扩展性问题。

  Aurora提出了“the logis the database”的设计理念,数据库实例往底层存储只写redo日志,将日志回放等操作下推到底层存储,从而大大降低网络开销。去年SIGMOD的Aurora论文侧重点在于设计理念和整体架构,而今年SIGMOD的Aurora论文侧重几个关键点的实现方案,包括写流程和宕机恢复,快照读取,如何避免读取操作访问多数派副本,以及成员变更。Aurora不需要使用两阶段提交协议,它的架构类似传统关系数据库的Oracle RAC,并在RAC基础上通过日志下推到存储层来进一步优化。建议读者结合去年的Aurora论文一起阅读这篇论文,去年的论文相当于总体设计方案,今年的论文相当于最核心的几个模块的概要设计方案。

  SCOPE是微软的大数据处理平台,类似阿里巴巴的MaxCompute。大数据平台一个常见的问题是有大量的重复计算,可能的原因包括schema设计不合理,用户互相拷贝脚本代码,等等。这篇论文提出了一个对重复计算进行在线物化的框架CloudView,有两个主要的特点:一个是在线创建物化视图,另外一个是借鉴了关系数据库的渐进式优化思路(progressive query optimization),实现了反馈回路(feedback loop),将运行时收集到的统计信息反馈到优化器。

  作为一篇工业界论文,这篇文章还给出了很多SCOPE的运行数据和一些经验教训,对于阿里巴巴和其它大数据平台都有不错的借鉴意义。当然,物化视图里面有一个经典的难题,即在线更新的处理,这篇论文简单地将物化视图直接失效,这种做法还不够精细。

  HTAP混合负载是工业界的一个热点,一般来说,B+树用于OLTP业务,列存用于OLAP业务。然而,真实的业务场景中很难区分workload到底是OLTP还是OLAP,主流的OLTP商业数据库都会有比较强的OLAP分析能力。这篇论文研究如何在同一个数据库中混合使用B+树和列存这两种不同类型的索引,它首先通过一个benchmark对这两种索引在各种读写场景下的性能做了一个量化对比,接着讲解SQL Server中使用的Database Engine Tuning Advisor来动态地选择和推荐索引。

  论文最后的测试表明,Hybrid方案的性能往往是优于单一的B+树或者列存的,不过这件事情最关键的点还在混合负载这一假设的适用范围,实际场景中我看到的OLTP业务往往只有很少一些分析型查询,而专门的OLAP业务往往几乎都是分析型查询。

  一般来讲,数据库的容量规划都是针对峰值压力,然而,每天高峰期和低峰期的压力差别非常之大,实际生产系统中在线服务的利用率也都很低。P-Store提出,可以通过动态预测负载来提前对数据库扩容或者缩容,而不是等到负载发生变化之后再弹性伸缩。这篇论文最关键的地方在于提出了一个很有意思的AI和数据库相结合的问题,当然,论文中也给出了算法思路,即如何寻找一条具有最小成本的路径,使得系统有效能力总是大于实际需求。弹性伸缩有一个经典的难题,扩容/缩容操作的代价,在share-nothing架构中因为拷贝大量数据实用性不佳,往往更加适合存储计算分离的架构。互联网在线服务一般都可以借鉴P-Store的思路,当然,对于极端的场景,例如一年一次的双十一,流量突增到平常的几十倍甚至上百倍,我和论文作者在Demo环节做了简单交流,他们无法解决也不准备解决。

  Pinot是Linkedin开源的一个大数据分析系统,类似Apache Druid。Pinot采用Lambda架构,将实时数据流和批处理数据分开处理,支持Kafka准实时数据写入以及Hadoop批量数据导入,支持类SQL查询。这篇论文介绍了Pinot的技术架构、查询执行流程、存储索引结构,等等。类似的产品比较多,包括Apache的Druid和Kylin,Google Dremel以及其开源实现Apache Drill,其中,我认为技术做得最好的是Google Dremel,值得深入研究,其它论文可以结合起来一起阅读。

  Eon Mode是Vertica的云版本,有两个主要的架构变化:一个是存储计算分离,抽象了一层通用的文件系统访问接口(UDFS API)支持本地文件系统或者S3、HDFS等通用分布式文件系统;还有一个是线性可扩展的分布式架构,支持动态扩容缩容,涉及的改造点包括数据划分、容错以及SQL优化和执行。采用存储计算分离架构后,Tuple Mover操作也需要相应调整,以前的Enterprise版本每个副本都需要执行Tuple Mover,现在只需要动态选择一个副本执行Tuple Mover即可。另外,Eon Mode不再支持WOS,不过我认为这是Eon Mode的实现问题导致的。

  这篇论文出自Azure SQL Database团队,提出了一个很好的问题:在公有云环境下预测一个数据库实例会在多久之后被删除,从而将数据库实例分成两类:short-lived(=30天)以及long-lived(30天)。

  论文中采用了机器学习中的随机森林算法,涉及的特征包括:实例创建时间(例如周末创建的实例很有可能由程序自动创建),数据库实例的名称(例如名字有意义的数据库实例存活时间相对更长),数据库大小,数据库版本升级频率,数据库实例类型(Basic / Standard / Premium),用户之前创建过的数据库实例存活时间,等等。这种分类对于云数据库的资源调度、用户隔离以及日常运营操作都有不错的指导意义。另外,这篇论文还给出了大量Azure SQL DB团队的运营数据,有很好的参考价值。

  数据库上云面临两个主要的问题:一个是数据库迁移,另外一个是应用程序迁移。对于第一点,各个云服务产商都有成熟的工具;对于第二点,目前没有成熟的解决方案。Hyper-Q是一个可以将不同数据库系统的SQL请求互相翻译的中间件,目标是应用代码无需修改直接上云。

  这件事情的难度很大,而且极其繁琐,论文中把SQL翻译分成三大类:1) Translation:简单的语法修改,例如关键词替换;2) Transformation:将用户查询转化为目标数据库类似的功能,并对结果做一定的处理,例如不同数据库的NULL列排序方式不同;3) Emulation:目标数据库没有类似的功能,需要在应用层模拟实现。演讲者对Hyper-Q的能力非常有自信,让人感觉是什么都能做,不过我并没有这么乐观,可能只是一个简单的数据类型或者语义的不同都需要做大量的工作,也可能带来严重的性能问题。

您可能还会对下面的文章感兴趣: