1. 前言
VLDB 会议,全称 International Conference on Very Large Data Bases,是全球数据库体系范畴最负盛名的三大顶会之一。从 1975 年开端举行,每年一次,全球各地顶尖高校的很多研讨者、各大高科技公司都会将自己的学术研讨进展或工业界作用以论文形式投递到 VLDB 组委会,而组委会会审理并接纳其间最前沿、最具影响力的一批,并召开线下会议,供论文作者们同享、沟通。
本年的 VLDB 在 9 月 5 日到 9 日,在澳大利亚悉尼举行。作为在全球有广泛用户和海量数据应战的字节跳动公司,有三篇论文被 VLDB 接纳:其间两篇来自 Graph 团队 ,一篇 ByteHTAP 体系,应 VLDB 组委会邀请,字节相关团队来到了正值早春的悉尼,与来自世界各地的数据范畴专家学者,同享沟通,共襄盛举。
为了让咱们能对 VLDB 2022 有个快速的了解,咱们总结了 VLDB 的论文分类、研讨趋势以及工业界要点论文的摘要,当然啦,也包含字节跳动三篇论文简介。本文抛砖引玉,假如想深化了解学习,仍是十分主张找到论文原文来细心研讨一番。
2. 论文分类概览
本年的 VLDB 会议日程中,将一切参会评论的论文共区分红了以下几类:
- Database Engines(45篇)
- Database Performance(10篇)
- Distributed Database Systems(11篇)
- Novel DB Architectures(10篇)
- Specialized and Domain-Specific Data Management(20篇)
- Machine Learning, AI and Databases(50篇)
- Data Mining and Analytics(35篇)
- Information Integration and Data Quality(20篇)
- Data Privacy and Security(15篇)
- Graphs(45篇)
作为老牌体系会议,VLDB 既有传统的数据库办理体系的最新进展 80 篇左右,也有一些这些年来前沿的机器学习和体系结合范畴的最新内容。此外,Graph 范畴的论文仍然录入了 45 篇之多,VLDB 延续这几年对 Graph 的要点重视。能够看出,VLDB 所录入的论文内容,从传统的数据库底层技能、功用剖析,到机器学习、图、区块链这些新式的数据库运用场景,再到最上层的数据隐私安全、数据剖析,根本覆盖了数据的完整处理链路。
咱们将不同范畴的论文数量绘制成了饼状图,便利读者对不同范畴的热度有大致了解:
VLDB 历来重视学术界与工业界的融合和沟通。因而,VLDB 专门将工业界论文和学术界论文进行了分类,别离是 research track paper 和 industrial track paper。工业界论文 industrial track 共有 22 篇,其间校企协作的论文 12 篇,企业独立发表的论文有 10 篇;这些论文中,包含了 Google、Meta、微软、字节跳动、阿里、腾讯等多家国内外知名互联网企业的作用。比较于 research track,industrial track 更倾向于现已落地实用的技能或者体系,这些作用中有相当一部分与咱们在日常日子中所用到的运用息息相关,也是各大技能公司相关范畴人员重视的要点。
3. 2022 的趋势和启迪
从论文的散布范畴,以及工业界论文的要点,咱们能够剖析和洞悉出数据库业界的一些趋势,一家之言,欢迎咱们沟通评论。
3.1 机器学习与数据库的结合在不断加深
机器学习是现在核算机学界最为抢手的论题,这种热度自然也传导到了数据库范畴。本年 VLDB 最为火爆的论题便是 Machine Learning, AI and Databases,录入了足足 50 篇论文,且 Best Regular Research Paper 、Best Scalable Data Science Paper 均花落这个范畴,在悉尼的现场中,听众人数最多的也是这个方向,挤满了整个屋子。
详细来说,机器学习与数据库的结合点又首要包含三个部分:机器学习框架和渠道与数据库的深度融合、运用机器学习技能优化数据库功用以及自动化运维。其间,运用机器学习来优化数据库体系然后整个 infrastructure 体系是一个在工业界现已缓缓打开的方向,有明显的线上需求和收益,字节在这一方面也有团队在继续研讨探究。
3.2 新硬件,软硬一体
在传统的 CPU、内存硬件的处理功用无法坚持高速提高的大布景下,各大公司和学术界不约而同地将目光投向新硬件范畴,包含 FPGA、GPU、PMem 等。假如充分运用 FPGA、GPU 进行核算加快,以及如何充分发挥 PMem 比较于内存的优势,是未知范畴探究的低垂果实,自然成了近年研讨的抢手。本届 VLDB, 有多篇工业界论文专题研讨 FPGA 和 PMem,而且 SAP HANA 的 FPGA 加快论文荣获了此次工业界 best paper 的桂冠;学术界也有至少五篇论文评论 GPU、PMem 的相关论题,热度可见一斑。
3.3 NoSQL 范畴继续开展
曩昔十几年,随着互联网事务快速增长,丰富的事务场景和数据规划的爆破增长,催生了 NoSQL 范畴的蓬勃开展。关于出现的各种 NoSQL 产品品种,都继续有新的技能思路体现在每年的 VLDB 中。在 2022 年的 VLDB,NoSQL 范畴有工业界奉献的时空数据库、向量数据库和图数据库,也有关于 LSM 引擎的架构优化论文,继续坚持了 NoSQL 蒸蒸日上百花齐放的态势。
3.4 Graph 坚持高热度
在数据爆破年代,数据关联性的价值逐步突显,学术界 Graph 早已炽热多年。本年 VLDB 一共有 9 个 Graph Sessions,占到了全体份额的 20%,在论文数量上 Graphs 有 45 篇, 仅次于 Machine Learning, AI and Databases,与传统的 Database Engines 打平。在这 9 个 Graph Sessions 中,被接纳的论文方向覆盖了:时序图(体系与算法),动态图(体系与算法),概率图(算法),图查询优化,Graph AI (体系与运用),子图匹配(算法优化与运用),图数据库体系,图核算体系等方向。不难看出,对图算法的研讨远多于图体系,且图算法相关论文几乎都是各大学的独立研讨作用。作为学术论文,立异性是最重要的,从算法角度探究新办法新问题,会比体系角度取得立异性周期更短依靠条件更少,因而高校偏心算法也就不难理解了。其实,在咱们来看,场景、算法、体系是三个密切联动的环节,需要互相促进来完结螺旋上升。因而,图范畴需要加强工业界和学术界的进一步沟通协作。
4. 字节跳动论文介绍
字节本年共有三篇论文被录入,其间两篇关于图数据库 ByteGraph 以及 ByteGNN,一篇介绍了 ByteHTAP 体系,相信读者从名字就能看出论文介绍的体系类型。这些体系都广泛运用于字节事务丰富的事务场景,在实践中沉积打磨移风易俗,比较有更强的实际参阅意义,在悉尼现场,也吸引了很多研讨人员重视和沟通。
咱们在此,对这三篇论文做扼要介绍,也十分欢迎咱们找来原文阅读。
4.1 ByteGraph: A High Performance Distributed Graph Database in ByteDance
论文链接:www.vldb.org/pvldb/vol15…
本文介绍了在字节跳动内部广泛运用的图数据库体系 ByteGraph。在字节跳动内部,用户、视频、评论/点赞、产品等等多品种型元素及其之间联络能够用 Graph 模型来完美表达;这些图状数据上,有出度几亿的超级节点的存储查询应战,也有 TP、AP 乃至很多 Serving 流量的混合应战,ByteGraph 在多年支撑这些场景中不断演进和迭代,本篇论文就详细介绍了 ByteGraph 的全体架构和规划,以及多年沉积的一些场景问题及其办法探究。
表2 – 字节内部 Graph OLTP/OLAP/OLSP workloads 特点总结
ByteGraph 选用了核算存储别离的架构,支撑 gremlin 散布式查询,可分层水平扩展到几百个节点规划。面向字节内部广泛存在的超级极点问题、查询 workload 多样且常常变化的问题,选用了 EdgeTree 存储结构、自习惯 Graph 索引等针对性规划,并对工程实践做了很多优化以提高并发功用。现在 ByteGraph 在内部已有数百个集群、上万台机器的布置规划,是全球最大布置规划的图数据库之一。
图2 – ByteGraph 体系架构图
在查询层,ByteGraph 自研了 Gremlin 的查询引擎,支撑了常见的 Gremlin step 并针对字节事务做了不少扩展。在海量的数据与并发的打磨下,做了依据 RBO/CBO 战略的查询优化以及列式数据格局等履行优化。但坦率讲,比较联系型数据库经过几十年里很多工程师和研讨人员的努力建造,图数据库理论和实践都还有很多的路要走,也希望在未来能有时机 ByteGraph 能够继续经过顶会论文的办法作出自己的奉献,和咱们沟通学习。
图数据库的内存安排结构十分要害,不只需要表达 Graph 的数据模型还需要支撑高吞吐低推迟的拜访功用。如图 4 所示,ByteGraph 别离运用 Vertex Storage 和 Edge Storage 在内存中缓存极点和边。每个极点及其特点都存储为 KV 对,其间键由仅有的 ID 和极点类型编码,值是极点的特点列表。为了有用地履行图遍历查询,边被安排为邻接表。为了削减在图遍历中拜访超极点后发生很多中心结果的或许性,邻接表依据边类型和方向进一步区分。为了处理超极点和频频更新,削减边的刺进带来的写入扩大以及在整个列表扫描期间发生更少的磁盘 I/O。每个邻接表都存储为一个树结构,称为 edge-tree。edge-tree 由三品种型的节点组成,即 Root node、meta node 和 edge node,每一种节点都存储为 KV 对。
关于 ByteGraph 更多细节,欢迎咱们查阅论文或者联络 ByteGraph 团队同学沟通评论。
4.2 ByteGNN : Efficient Graph Neural Network Training at Large Scale
论文链接:www.vldb.org/pvldb/vol15…
Graph AI 方向是近几年大热的一个体系方向,比方上届 OSDI 会议接连有 4 篇GNN 相关的论文被发表,SOSP/EuroSys/ATC/MLSys 每年也有很多有关于如何高效规划 GNN 练习/推理体系的文章被接纳。本年 VLDB 上有关于 GNN 体系规划,优化以及运用的文章也不少。
图神经网络(GNN)作为新式的机器学习办法,广泛运用于字节的引荐、查找、广告、风控等事务场景中。面临字节海量的数据,选用散布式 GNN 体系提高练习的可扩展性和练习功率变得至关重要。可是,现有的散布式 GNN 练习体系存在各种功用问题,包含网络通信本钱高、CPU 运用率低和端到端功用差。ByteGNN 经过三个要害规划处理了现有散布式 GNN 体系的局限性:
(1)将 mini-batch based 图采样的逻辑笼统成核算图以支撑并发处理。
(2)粗粒度和细粒度的调度战略以提高资源运用率并削减端到端 GNN 练习时刻。
(3) 为 GNN workloads 量身定制的图分区算法。
试验表明,ByteGNN 的功用优于最先进的散布式 GNN 体系(i.e., DistDGL, Euler, GraphLearn),端到端履行速度提高了 3.5-23.8 倍,CPU 运用率提高了 2-6 倍,网络通信本钱下降了大约一半。
ByteGNN 为了明显下降网络开支,首要从体系架构层面将采样与练习这两个阶段作了解耦,让不同履行器别离担任一次 mini-batch 中的采样与练习:
一起,ByteGNN 供给了一套自定义的采样编程接口,不同 GNN 模型将一致用该接口来完结不同的采样逻辑。体系后端依据该接口自动地将采样逻辑解析成为一个核算图 DAG。采样核算图化的好处是能够充分运用 CPU 运用率,动态地将散布式采样进程笼统成更细粒度的小 task 并将其流水线化。
ByteGNN 也做了一层中心调度层,将采样核算图和练习核算图“软衔接”到了一起,经过一个调度器动态地平衡采样与练习这两个阶段的资源耗费和消费速率,方针使得体系的 CPU 运用率和内存开支到达最优:
4.3 ByteHTAP: ByteDance’s HTAP System with High Data Freshness and Strong Data Consistency
论文链接:www.vldb.org/pvldb/vol15…
近年来,在公司事务中,咱们看到越来越多的场景需要对新导入的数据进行杂乱的剖析,并一起强调事务支撑和数据强一致性。因而在论文中,咱们要点描绘了字节跳动的自研 HTAP 体系 ByteHTAP 的构建进程。ByteHTAP 是具有高数据新鲜度和强数据一致性的 HTAP 体系,选用别离引擎和同享存储架构。
- 其模块化体系规划充分运用了字节跳动现有的 OLTP 体系和开源 OLAP 体系。经过这种办法,咱们节省了很多资源和开发时刻,并答应将来轻松地扩展,例如用其他替代计划替换核算引擎。
- ByteHTAP 能够供给高数据新鲜度(数据从 OLTP 写入到 OLAP 查询可见,相隔不到 1 秒),这为咱们的客户带来了许多新的才能。客户还能够依据事务需求装备不同的数据新鲜度阈值。
- ByteHTAP 还经过其 OLTP 和 OLAP 体系的大局时刻戳供给强壮的数据一致性,减轻事务开发人员自行处理杂乱的数据一致性问题的负担。
- 此外,文中还描绘了咱们对 ByteHTAP 引进的一些重要的功用优化,例如将核算推送到存储层,以及运用删去位图(Delete Bitmap)来高效处理删去。
- 终究,依常规咱们在文中同享了出产环境中开发和运转 ByteHTAP 的经历教训和最佳实践。
ByteHTAP 的高层架构如下图所示,在同享存储体系上搭建了两个彼此别离的核算引擎。ByteHTAP 运用了字节的自研 OLTP 数据库 ByteNDB 作为 OLTP 负载的核算和存储引擎,并运用 Apache Flink 作为 OLAP 负载的核算引擎。ByteHTAP 支撑一个一致的,兼容 ANSI SQL 标准的用户入口,并具有一个智能代理层,DML,DDL 和 OLTP 负载的典型查询(如点查)会被发送给 OLTP 核算引擎,而杂乱查询(如多重联接,很多聚合)会被发送给 OLAP 的核算引擎。这样的安排架构将 OLTP 和 OLAP 负载发给更合适的处理引擎,并能够有用避免这两类负载之间的串扰。
图1 – ByteHTAP 体系架构图
作为 ByteHTAP OLTP 侧的核算和存储引擎,ByteNDB 遵循“log is database”的理念。用户数据的刺进,更新和删去的日志在其 LogStore 存储组件耐久化之后即完结提交,并经过一个散布式数据仿制框架可靠地按数据分区分发至各存储节点(PageStore)回放为行存数据页面。ByteHTAP 扩展了 ByteNDB 的仿制框架,已提交 的 DML 事务的逻辑日志(即 MySQL 二进制日志)依据用户表中定义的分区计划被接连分发到列存储节点,以构建列存格局的数据存储,该存储或许存储在与其对应的行存不同的存储节点上。ByteHTAP 的列存存储由内存中的 Delta Store 和耐久化的 Base Store 组成。OLAP 查询运用指定的 LSN 作为其快照版别来扫描基量存储和增量存储。集中式元数据服务 Metadata Service 担任为 OLAP 的查询优化器和存储节点供给元数据信息,会消费 DDL 信息并构建多版别元数据,耐久化并将元数据缓存在内存中供查询。
图2 – ByteHTAP 列存前后台数据操作及其一致性和谐示意图
上述的同享存储规划确保了从 OLTP 存储侧分发的逻辑日志能够立刻进入 OLAP 的内存存储 Delta Store,然后立刻对 OLAP 的用户查询可见,然后确保了 ByteHTAP 的高数据新鲜度。而 ByteHTAP 经过为其查询供给一致的数据快照来确保强数据一致性。每个 DML 和 DDL 句子都会在体系中生成一个大局仅有的 LSN(日志序号)。同一事务中的句子会被包装在一起并以原子办法分发到方针节点。元数据服务 Metadata Service 担任将最新的“大局提交 LSN” 发送给 OLAP 核算引擎,咱们的规划确保了 LSN 小于此“大局提交 LSN” 的一切日志都现已被 OLAP 列存接纳并耐久化。OLAP 查询引擎中的 Metadata Service客户端会定期从 Metadata Service 获取最新的大局提交 LSN 并缓存。OLAP 查询引擎将依据缓存了的大局提交的 LSN 为每个用户查询分配一个 read LSN,此read LSN 会被下发到各 OLAP 列存存储节点,并用以确定数据可见性。在 OLAP 存储内部存在着很多的并发前后台数据操作,他们之间的数据一致性也由这一套 LSN 体系来进行确保。在大多数情况下,ByteHTAP 数据更改之后不到一秒即可供给给 OLAP 侧的用户查询。
试验和线上数据均表明,ByteHTAP AP 侧的功用到达业界优异水平,并在 TP 侧数据吞吐量明显添加(客户衔接数 0-64,数据吞吐量 2k-60k tpmC)时坚持查询功用安稳(劣化小于5%)。同样的,ByteHTAP 在数据吞吐量较大的情况下(182MB/s) 仍然坚持着远小于 1 s (606ms)的数据新鲜度。
5. 部分工业界论文介绍
工业论文首要来自头部企业,这些企业具有超大规划的数据和体系,也聚集了高水平的体系开发人员,在多年的场景堆集下,能够继续探究新的办法处理有应战的问题,也自然是 VLDB 喜爱的方针。
5.1 Hardware Acceleration of Compression and Encryption in SAP HANA(Best Industrial paper)
运用 FPGA 等专有硬件进行加快是一个抢手的研讨课题,多家公司都尝试过类似的 approach 来加快各体系中的瓶颈环节。FPGA 的专项功用要强于 CPU,且削减了 CPU 与 I/O 链路中的损耗,能够为体系供给不错的功用优势。来自 ETH Zurich 和 SAP 的这篇论文,就来自这个范畴。
首要介绍了运用 FPGA 加快 SAP HANA 的紧缩与加密流程,有用提高了体系吞吐,并在试验中,详细展示了剖析型数据库引擎的运用场景和各个重要功用参数中的 trade-off。本文介绍了 FPGA 在 HANA 这样一个工业级内存数据库的落地情况,并对相关功用场景进行了进行了较为详细的测验,数据详尽,best paper 名副其实。
- 文中首要 offload 的部分是紧缩与解紧缩,加密与解密,全体的 pipeline 结构如下
- 详细的完结办法是,将 OpenCL 作为一个库整合到体系内核中以函数调用的办法供给支撑,紧缩部分现已现已整合到了 OpenCL 中,而加密部分则运用 VHDL 完结,即图中的 AES-256 算法。
- 经过测验,咱们发现 FPGA 的参加带来了几大优势:紧缩与加密流程被明显加快;CPU 核算资源部分释放;数据传输更加安全;加密进程由数据库引擎操控,而不是云服务供给商;存储空间和网络流量有所削减。详细测验数据能够参见论文。
5.2 Tair-PMem: a Fully Durable Non-Volatile Memory Database
本文出自阿里巴巴,首要介绍了依据傲腾的 Tair-PMem 内存数据库规划。Tair-PMem 处理了传统内存数据库不能胜任彻底耐久化的问题,并经过巧妙的规划缓解了 NVM 的功用开支,削减了 NVM 编程的杂乱性,取得了极低的尾部推迟以及更低本钱的优势。一起也满意了内存数据库对大数据存储等需求的负载。
傲腾的中心特性首要体现在与传统 DDR 内存比较,容量更大,且数据断电后不丢失,但全体的时延表现与内存比较是其数倍。又因为这些不同于传统内存的特性,其编程难度也有所提高。
- 关于此文,咱们能够着重看一下他的架构规划:
-
- 为了让傲腾供给与 DRAM 近似的功用,Tair-Pmem 规划了一个高可控的数据放置逻辑,其会依据数据的耐久性,拜访频次和巨细来决定数据和其对应的元数据的寄存位置。
- 在规划上运用了一致的 API 来处理 Pmem 的编程困难问题。
- 全体的模块化改造坚持了代码的低侵入性,提高了体系全体的安稳性。
- 运用 Pmem 的 byte addressable 特性增强了数据库的根本才能。例如经过 Pmem 的耐久化特性,Tair-Pmem 体系的 recovery 速度远超传统完结。
在整个 Toolkit 中,最重要的两个中心组件是 Allocator 和 Log & data pool:Allocator 的全体规划与传统的 jemalloc 类似,都运用了 slab 来办理内存,这儿比较特别的是尽量将元数据寄存在 DRAM 中。在实在分配内存的进程中,Allocator 会依据申请的内存类别和预定义的 DRAM-NVM 运用份额来分配。而关于 Log & data pool,其挑选了链表的变种 ES-linked list 来办理,并在其上构建了一些基础数据结构的支撑。
从试验的结果来看 Tair-Pmem 体系的全体吞吐和长尾时延表现都很优异,且从本钱角度考虑其供给的功用也十分惊艳。
5.3 CloudJump: Optimizing Cloud Database For Cloud Storage
近十年来,数据库范畴的一个重要的架构开展趋势便是存储核算别离。在存算别离的体系中,数据一般会放置在某种云存储中,而非传统的本地存储。阿里云的存算别离数据库 PolarDB 现已进行了多年的开展与探究,实践中堆集了很多考虑与经历,本文就介绍了在规划一个适用于存算别离数据库的云存储时,需要考虑的规划准则,值得一读。
- 首要,文中梳理了云存储比较本地 SSD 的功用指标差异,以及这些差异对不同品种的存储引擎(B-Tree,LSM Tree)所发生的技能应战和影响。
-
- 依据这些问题,文中提出了一些处理的思路和规划准则。例如,云存储场景应当尽量运用多机优势,将数据、大 IO 恳求和 recover 带宽打散到不同节点上;经过预读、数据聚合、紧缩、过滤等办法,尽量削减单次恳求途径上的 IO 次数;需要考虑恳求之间的资源阻隔性,等等。
-
终究,论文结合 PolarDB 和 rocksdb 在云上的完结,举例说明了上述规划准则如何付诸详细实践,因为篇幅约束,这儿只简略介绍 polardb 的相关内容。针对 redo log,polardb 将 redo log 按修改的 page 进行了分片,使得 redo log 被打散,能够取得写入功用优势;关于单个 redo log 分片,还会进一步拆分为多个物理 chunk,使得单个大的 log IO 使命能够被拆分开来,并发履行。得益于 redo log 的打散,recovery 进程也能够并发履行,另外 polardb 还会将元信息保护在一致的 superblock 中,削减读取次数。
除了 log 拆分之外,polardb 还引进了新的预取战略,下降恳求推迟;针对 innodb 的锁运用进行优化,避免加锁 IO,下降锁冲突;针对不同写入途径上的 IO 使命,区分优先级和多队列,确保高优先级使命(比方写 WAL)能够优先履行;IO 恳求进行对齐,等等。
5.4 Ganos: A Multidimensional, Dynamic, and Scene-Oriented Cloud-Native Spatial Database Engine
本文出自阿里巴巴,首要介绍了阿里巴巴出品的最新一代地理信息数据库引擎。在才智城市、电子地图、卫星遥感、物联网、车联网/智能交通、互联网出行、才智物流、传感网与实时 GIS 等很多范畴都有较为广泛的运用场景。
- Ganos 规划、完结上高度兼容 PostGIS 语法和接口,能够无缝对接支撑 PostGIS 的各类软件生态,架构上依据 PolarDB 完结主流的存储核算别离架构,完结核算/内存/存储组件解耦,形成可独立伸缩的资源池。
- 引进拓宽存储(Extended storage)规划 :时空数据是很杂乱的数据模型,比较于传统的联系型数据,数据结构更丰富、需要占用更多的存储资源,而且在运用进程中具有明显的冷热数据别离问题,为此 Ganos 选用了散布式同享存储+拓宽存储(OSS Alibaba Cloud Object Storage Service)的计划,很好的平衡了存储本钱、数据拜访功用需求。
- 支撑多级并行核算加快:跨节点并行(IQP intra-query parallelism)+节点内并行(IFP intra-function parallelism)加快核算。其间 IQP 将一个 query 要处理的数据切分红数据片,分发给多个 RO 节点进行独立的核算;而 IFP 将超大的单个时空数据片切分红一个个的小时空单元,然后经过多线程并行核算到达核算加快作用。在 benchmark 测验中比照 PostgreSQL,Ganos 经过多级并行核算取得明显的加快。
5.5 Magma: A high data density storage engine used in Couchbase
本文是 Couchbase 公司奉献,总结了 couchbase 作为文档数据库关于 KV 引擎的运用办法和痛点,并介绍了其下一代存储引擎 magma。magma 在规划上仍是依据 LSM Tree 结构的 KV 存储引擎,选用 KV 别离的规划,但做了很多有趣的立异规划,其间key 存储在 key SST 中,value 保护在依照 sequence id 有序摆放、切分为多个文件的 value log 中。
比较于经典的 WiscKey,这篇论文最大的奉献在于 GC 的规划,其不需要像 WiscKey 在 GC 时扫描整个 value log 并进行 point get 查询,而是首要对 key sst 进行 compact 发生 deleted key set,再依据 deleted key set 中记载的 value sequence id 核算得出每段 value log 对应的废物数据的份额,只需要对废物份额较高的 value log 段与邻接段进行 merge 即可。这样既能够避免 WiscKey GC 时的很多 point get,也能够依据废物份额对 value log 进行分段 compact,下降写入扩大。
5.6 Manu: A Cloud Native Vector Database Management System
Manus(Milvus 2.0版别产品代号)是 Zilliz 公司发布的一款 “面向向量数据办理而规划的云原生数据库体系”。向量数据办理体系是用于存储、检索向量数据的数据库体系。向量数据库广泛运用于现在 AI 各种体系中,例如人脸辨认、引荐体系、图片查找、视频指纹、语音处理、自然语言处理等场景,运用深度学习的办法将这些非结构化数据映射成向量表示,然后在运用时就需要到巨大的向量集合中检索和某个向量间隔(各种内积、欧氏间隔等类似度核算办法)最近的 top-k 个向量。这类体系的开山鼻祖是 Facebook 开发的 Faiss,之后各大公司都研制自己的向量检索体系,而 Milvus 则是业界专业广受认可的开源向量检索体系。该体系的规划首要针对以下几方面痛点 :
- 灵敏的一致性战略,体系供给可见性/时效性装备功用,用户能够依据事务的需求,来指定刺进数据在可被查询到前所能容忍的最大时延,然后平衡体系履行开支和事务时效性;
- 支撑组件级的弹性扩展才能,关于不同类型的使命,依据对不同组件运转开支的不同,针对性给体系瓶颈部分添加资源;
- 简略高效的事务处理模型,因为体系处理的是向量数据,不需要像联系数据库那样供给多表的杂乱事务支撑,能够对单表行上的事务做特定的功用优化。
体系的全体架构如下图所示,Manu 选用了一个四层的架构来完结对读/写、核算/存储以及有状况/无状况组件的别离:
- Access layer 是拜访层, 由若干个无状况的 proxy 组成,这些 proxy 担任接纳用户恳求,将处理过的恳求转发给体系内的相关组件进行处理,并将处理结果收集整理好之后回来给用户。
- Coordinator layer 使命和谐办理器,担任保护元数据以及和谐各个功用组件完结各类体系使命。其间 Root Coordinator 担任处理数据集创立/删去等数据办理类型的恳求;Data Coordinator 担任办理体系中数据的耐久化工作,和谐各个 data node 处理数据更新恳求;Index Coordinator 担任办理体系中数据索引的相关工作,和谐各个index node 完结索引使命;Query Coordinator 担任办理各个 query node 的状况,并依据负载的变化调整数据和索引在各 query node 上的分配情况。上面各种 Coordinator一般都有多个实例,然后提高组件的可靠性。
- worker layer 担任履行体系中的各类使命。一切的 worker node 都被规划成无状况履行的的,它们读取数据的只读副本并进行相关的操作,而且 worker node 之间不需要通信协作,然后完结 worker node 的数量能够依据不同场景的负载差异进行调整,弹性添加必要的技能资源。值得要点重视的是存储层(Storage Layer)规划,Manu 选用了“日志即数据(log as data)”的规划理念,将日志作为体系主干用来衔接各个组件。依据对推迟、容量和本钱等方面的考虑,Manu 完结了 WAL(write ahead log) 和 binlog 两类日志流,存量数据被被安排在 Binlog 傍边,而增量部分则被安排在 WAL 中。Data node 消费 WAL 中的内容并对数据进行处理后产出到 Binlog 中,query node、index node 则仅需消费处理 Binlog 日志流中的数据。然后各个 worker node 完结互相独立的联系。
5.7 SQLite: Past, Present, and Future
SQLite 的台甫在数据库范畴可谓是如雷贯耳,本篇论文由 SQLite 的开发者和威斯康辛大麦迪逊分校联合出品,介绍了 SQLite 的 workload、近二十年中所在环境的变化以及未来的展望。在硬件方面,近年来硬件范畴有了长足的前进,很难幻想现在的低端移动设备(树莓派 4)在功用上也远超 SQLite 最早运转的设备(Palm Pilot);在 workload 上 SQLite 的用户存在很多不同份额的读写混合的场景,以及类 KV 的 blob point get 运用场景,近年来随着数据剖析范畴的开展,还存在一些 OLAP 的查询,这些都与 SQLite 最早规划时的假设有偏差。
文中花较大篇幅,对 SQLite 在 OLAP 方面的功用和优化进行了评论,并与 DuckDB 进行了比照。在 OLAP benchmark 之后,作者对 SQLite 的履行情况进行了剖析,提出了针对 equijoin 运用预购建 bloomfilter 对原有的 nested loop join 进行优化的计划,并进行了完结;除此之外,还提出了对提取记载中特定列的流程的优化,可是因为杂乱度较高、涉及到兼容性问题,没有进行实践。
咱们以为,文章的美中不足之处在于,一切 benchmark 都是针对 duckdb 进行比照,包含写入相关的测验和 blob 运用场景的测验,可是 duckdb 针对这两种场景并没有什么独特的规划,因而文中也没有针对这两种场景对 SQLite 进行优化。
5.8Velox : Meta ‘s Unified Execution Engine
为了处理特定的,十分个性化的数据负载,事务常常需要暂时开发新的专用核算引擎,但这实际上创立了一个又一个孤立的数据环境。一般,这些引擎之间几乎没有同享,难以保护、开展和优化,终究导致数据用户供给了体会不一致。为了处理这些问题,Meta 创立了 Velox,一个新颖的开源 C++ 数据库加快库。Velox 供给可重用、可扩展、高功用且与程序方言无关的数据处理组件,用于构建履行引擎和增强数据办理体系。该库依靠于矢量化履行和自习惯性,并由 Meta 的工程师从头开端规划,以支撑对杂乱数据类型的高效核算,并习惯无处不在的现代核算负载。Velox 现在已与 Meta 的十几个数据体系集成或正在集成,包含 Presto 和 Spark 等剖析查询引擎、流处理渠道、音讯总线和数据仓库的数据吸取架构、用于特征工程和数据预处理的机器学习体系(PyTorch)等。它在以下方面供给了好处:(a) 经过泛用化曾经仅适用于单个引擎中的优化来提高功率,(b) 为用户提高数据一致性,以及 (c) 经过提高可重用性来加强工程功率。
5.9OceanBase : A 707 Million tpmC Distributed Relational Database System
OceanBase 是由蚂蚁金服自主研制的散布式联系数据库体系,现已规划开发了超过十年。OceanBase 是一个横向扩展的多租户体系,供给依据 shared-nothing 架构的跨地域高可用性。除了与其他散布式 DBMS 同享许多类似的方针,例如水平可扩展性、高可用性等,咱们的规划还受到其他需求的驱动,例如对典型 RDBMS 的兼容性,以及一起习惯客户内部和外部布置。OceanBase 完结了其规划方针。它完结了某些主流经典 RDBMS 的明显特性,这些 RDBMS 承载的大部分运用程序都能够在 OceanBase 上运转,只需稍加修改乃至不加改动。在支付宝等很多商业事务中现已布置了数万台 OceanBase 服务器。它还成功经过了 TPC-C 基准测验,并以超过 7.07 亿的 tpmC 夺得榜首。本文介绍了 OceanBase 的方针、规划标准、基础设施和要害组件,包含其用于存储和事务处理的引擎。此外,它详细介绍了 OceanBase 是如何在一个散布式集群中到达上述领先的 TPC-C 基准测验的结果的,该集群具有 1,500 多台服务器,散布在 3 个区域上。文章还描绘了蚂蚁团队十多年来在构建 OceanBase 中所学到的经历教训,这对构建工业级的散布式数据库来说,有十分宝贵的学习和借鉴价值。
6. 总结
在当时数据智能年代,数据存储核算技能现已成为社会信息化的中心引擎, VLDB 等顶会无疑是数据技能立异殿堂的明珠,继续聚集全世界的新办法新思路,指引和启迪学术界和工业界不断攀登打破。
服务全球用户的字节,既有数据立异技能的土壤也依靠技能赋能产品,然后更好的服务亿万用户。相信 VLDB 2022 录入的 Graph 和 HTAP 范畴论文只是一个开端,未来字节会有更多技能立异打破经过各种形式为技能立异社会前进做出自己的奉献。一起,也十分欢迎咱们参加咱们(job.toutiao.com/s/6snYofd),… NoSQL、数据库等相关范畴处理世界级应战,拓宽未知技能边界。
7.关于咱们
【Graph 团队】归于字节跳动基础架构,担任 Graph 数据存储核算和 ML 相关体系研制和事务支撑;其间,图数据库产品 ByteGraph 在全球范围布置了 1000+ 集群,支撑了今日头条、抖音、 广告、西瓜、火山、知识图谱、风控等绝大部分产品线;图核算/剖析产品 GraphGAP 支撑了海量图状数据的离线核算/剖析事务(例如 PageRank,LPA,Fast Unfolding 等算法);图练习引擎 广泛运用于风控、审核、游戏、社交、安全等事务上的 GNN/GE 离线练习场景。
【ByteHTAP 团队】归于字节跳动基础架构,从 0 到 1 构建了支撑亚秒级 data freshness + SI 阻隔等级 + 高功用杂乱查询的 HTAP 体系,团队协同查询优化器/履行器/存储范畴专家深化探究业界前沿中心技能,寻求极致性价比及一站式数据服务体会,为用户供给业界有竞争力的 HTAP 数据库服务。现在,HTAP 产品支撑了公司内广告、飞书、电商等事务;后续将经过字节跳动旗下的火山引擎服务于外部客户。