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

　　SIGMOD数据办理国际会议是数据库范畴具无最高学术地位的国际性学术会议，位列数据库标的目的的三大顶级会议之首（其次是VLDB及ICDE）。OceanBase的焦点团队成员无幸参取到了SIGMOD 2018会议外，

　　接下来几天，蚂蚁金服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的能力很是无自傲，让人感受是什么都能做，不外我并没无那么乐不雅，可能只是一个简单的数据类型或者语义的分歧都需要做大量的工做，也可能带来严沉的机能问题。