从一到无穷大 #21 从基于多数据模型分析负载的Benchmark讨论多模数据库的发展方向

本文主要是介绍从一到无穷大 #21 从基于多数据模型分析负载的Benchmark讨论多模数据库的发展方向,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在这里插入图片描述本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作),由 李兆龙 确认,转载请注明版权。

文章目录

  • 引言
  • M2Bench测试结果
  • 从Lindorm看待多模的发展方向
  • 总结

引言

《M2Bench: A Database Benchmark for Multi-Model Analytic Workloads》阐述了一种测试多模型数据库系统的Benchmark方法,我理解对于Benchmark而言,核心点在于测试方法与数据生成。

测试方法的角度看,M2Bench基于E-Commerce,Healthcare,Disaster&Safety三个业务场景,总结出17种涉及 relational, document-oriented, property graph, 以及 array models 四个数据模型的操作集合,以此作为测试多数据模型分析负载的Benchmark主体。

从数据生成的角度看,M2Bench在不同的场景使用不同的已有公共数据集合:
在这里插入图片描述
这与[5]中的基于GAN(Generative Adversarial Network)+LSH(Locality-Sensitive Hashing)生成时序数据集的思路完全不一样。

作为同样以Benchmark的设计入选vldb2023的TSM-BenchMark[5],测试方法与数据生成是实际的创新点;而M2Bench则把可以用一个Benchmark测试多数据模型分析负载作为创新点,但是我认为因为其数据生成和测试方法固化以及几乎无法改变测试的数据模型,实际在业界大推广M2Bench基本没有太大价值,可以说就是一个小圈子内的狂欢。

于我个人而言,M2Bench的价值则另有所在:

  1. 从一个复杂业务的角度如何测试底层数据库的使用方式
  2. 文章的测试阶段选择使用 MySQL, MongoDB, Neo4j, SciDB作为对照组,与ArangoDB(json/graph/kv/search engine,测试中relational和array使用json模拟)/ AgensGraph(relational/graph) 同时执行现有的测试,我认为这从业务使用角度论证了多模数据库的发展方向

M2Bench测试结果

综前所述,我认为数据集,不同模型间表的设计以及测试本身内容都不重要,我们关注结果就可以
请添加图片描述
表1描述了M2Bench的17种任务操作所涉及的数据模型。

测试的环境为:a standalone machine with Intel i7-9700K CPU, 32GB RAM, and a 512GB SSD running Ubuntu18.04.4 LTS,比较理想化
请添加图片描述
时延对比当然不是衡量数据库整体质量的正确方式,而且看论文中的描述也是先导入写再测试读的离线场景,与实际运营场景不一致,这点瑕疵我们暂时不谈。上图描述了Polyglot( MySQL, MongoDB, Neo4j, SciDB)与ArangoDB / AgensGraph 在17个任务下的查询时延对比。

从上述结果我们可以得到以下结果:

  1. 在需要密集array计算的场景下 Polyglot 优于 ArangoDB / AgensGraph [T2, T9, T14, T15]。原因是 SciDB 的原生存储引擎以块为单位存储数组,从而保留了数组单元的locality。AgensGraph 和 ArangoDB 分别以table和collection的形式存储数组,其中每一行或每一个文档代表一个数组。因此矩阵乘法等数组操作将不得不访问随机分散的行,从而导致过多的磁盘 I/O 操作。但是T16是一个例外,虽然需要array操作,但是polyglot 系统的性能不是最好的,因为 T16 需要随机迭代访问数组单元。这种访问模式对 polyglot 系统并不有利。
  2. ArangoDB 拥有原生graph/json引擎,在 [T4, T8, T11, T12, T13]优于其他两者
  3. AgensGraph 拥有原生relational引擎,在 [T0, T1, T3, T5, T7, T10, T16]优于其他两者。虽然AgensGraph使用relational引擎支持图模型,并不是原生支持图引擎,但是在部分图操作中AgensGraph快于ArangoDB。
  4. 原则上 Polyglot 每一种模型都选择了对应数据模型的龙头产品,但是Polyglot并不是每一种负载都是最优的选择,原因是假如两张表存在于两个模态的数据库时,执行连接操作非常缓慢,需要频繁的调用一方的查询操作

基于上述结果我们可以得到如下结论:

  1. 结论1:基于统一kv/宽表底座的多模型数据库是错误的方向,只有不同模型拥有不同的存储引擎才可以带来最大的综合性能优势
  2. 结论2:哪怕是最优秀的存储引擎也只是在Trade-off,没有一种设计可以保证所有情况下的最优,所以需要智能化调优,并在项目选型之初选择最适合业务场景的引擎。
  3. 结论3:完全独立的多个不同模型数据库对于联合分析的场景性能较差

从Lindorm看待多模的发展方向

早在2019年,李飞飞老师在[4]中讨论了未来数据库的发展趋势将会集中在以下几个方面:

  1. 云原生与分布式
  2. 大数据与数据库一体化
  3. 软硬件协同
  4. 多模型
  5. 智能化运维,自治性与智能性
  6. 安全可信

对于其中的多模型分析,李飞飞老师在当年将其发展归结为两个方面:

  1. southbound multi-model access:底层存储支持不同的数据格式和数据源。存储的数据可以是结构化的,也可以是非结构化的,如图形、vector和文档存储。数据库提供统一的查询接口,如 SQL 或类似 SQL 的接口,以查询和访问各种类型的数据源和数据格式,形成数据湖服务。除此之外,许多云应用需要从异构来源收集大量数据,并进行联合分析
  2. northbound multi-model access:北向多模型访问表示使用单一数据模型和格式(如大多数情况下的键值模型)将所有结构化、半结构化和非结构化数据存储在单一数据库中。在这种单一存储模型的基础上,数据库根据应用需要支持多种查询接口,如 SQL、SPARQL 和 GQL

当时看这篇[4]论文的这个论点没有明白,结合[3]的实验结论,有一种豁然开朗的感觉。

五年过去了,我们回过头看下2024年Lindorm的产品架构文档设计图[7]:
在这里插入图片描述
官方介绍稿中点出了Lindorm顶层设计上的几个重点:

  1. 存储计算分离
  2. 其中云原生分布式文件系统LindormDFS为统一的存储底座,向上构建各个垂直专用的多模数据引擎,包括宽表引擎、时序引擎、搜索引擎、流引擎等。
  3. 在多模引擎之上,Lindorm既提供统一的SQL访问,支持跨模型的联合查询;又提供多个开源标准接口(HBase/Cassandra、OpenTSDB/InfluxDB、Kafka、HDFS),满足存量业务无缝迁移的需求。
  4. 数据通道服务(LTS)负责引擎之间的数据流转和数据变更的实时捕获,以实现数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等能力。

从现在的结果看,Lindorm的发展确实是按照着李飞飞老师的预期在走的。

总结

从目前的知识体系来看,Lindorm的顶层设计我认为没有明显的短板,这也许是Lindorm TSDB的设计可以入选vldb2023的原因。

但是也并不是毫无进步的余地,以本文得到的结论2看,数据库引擎自动化调优的方向还有极大的优化空间,尤其是是时序模态,因为目前主流的时序模态都允许按照时间粒度切分物理存储,这使得我们有机会去修改新存储的引擎结构。像kv,json这样的模态引擎基于物理数据的分裂合并去实现扩缩容就很难去修改引擎结构,只能做一些参数上的优化。

参考:

  1. Why Arrays as a Universal Data Mode
  2. 邻接矩阵的COO格式
  3. M2Bench: A Database Benchmark for Multi-Model Analytic Workloads vldb2023
  4. Cloud-Native Database Systems at Alibaba: Opportunities and Challenges vldb2019
  5. 从一到无穷大 #14 Online, realistic data, querying variable Time Series Database Benchmark
  6. 从历史见证未来,Distributed SQL?云原生数据库? 多模型数据库?
  7. Lindorm产品架构
  8. 从一到无穷大 #13 How does Lindorm TSDB solve the high cardinality problem?

这篇关于从一到无穷大 #21 从基于多数据模型分析负载的Benchmark讨论多模数据库的发展方向的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/633738

相关文章

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

uva 10916 Factstone Benchmark(打表)

题意是求 k ! <= 2 ^ n ,的最小k。 由于n比较大,大到 2 ^ 20 次方,所以 2 ^ 2 ^ 20比较难算,所以做一些基础的数学变换。 对不等式两边同时取log2,得: log2(k ! ) <=  log2(2 ^ n)= n,即:log2(1) + log2(2) + log2 (3) + log2(4) + ... + log2(k) <= n ,其中 n 为 2 ^

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

MOLE 2.5 分析分子通道和孔隙

软件介绍 生物大分子通道和孔隙在生物学中发挥着重要作用,例如在分子识别和酶底物特异性方面。 我们介绍了一种名为 MOLE 2.5 的高级软件工具,该工具旨在分析分子通道和孔隙。 与其他可用软件工具的基准测试表明,MOLE 2.5 相比更快、更强大、功能更丰富。作为一项新功能,MOLE 2.5 可以估算已识别通道的物理化学性质。 软件下载 https://pan.quark.cn/s/57

从戴尔公司中国大饭店DTF大会,看科技外企如何在中国市场发展

【科技明说 | 科技热点关注】 2024戴尔科技峰会在8月如期举行,虽然因事未能抵达现场参加,我只是观看了网上在线直播,也未能采访到DTF现场重要与会者,但是通过数十年对戴尔的跟踪与观察,我觉得2024戴尔科技峰会给业界传递了6大重要信号。不妨简单聊聊:从戴尔公司中国大饭店DTF大会,看科技外企如何在中国市场发展? 1)退出中国的谣言不攻自破。 之前有不良媒体宣扬戴尔将退出中国的谣言,随着2

衡石分析平台使用手册-单机安装及启动

单机安装及启动​ 本文讲述如何在单机环境下进行 HENGSHI SENSE 安装的操作过程。 在安装前请确认网络环境,如果是隔离环境,无法连接互联网时,请先按照 离线环境安装依赖的指导进行依赖包的安装,然后按照本文的指导继续操作。如果网络环境可以连接互联网,请直接按照本文的指导进行安装。 准备工作​ 请参考安装环境文档准备安装环境。 配置用户与安装目录。 在操作前请检查您是否有 sud

论文翻译:arxiv-2024 Benchmark Data Contamination of Large Language Models: A Survey

Benchmark Data Contamination of Large Language Models: A Survey https://arxiv.org/abs/2406.04244 大规模语言模型的基准数据污染:一项综述 文章目录 大规模语言模型的基准数据污染:一项综述摘要1 引言 摘要 大规模语言模型(LLMs),如GPT-4、Claude-3和Gemini的快

线性因子模型 - 独立分量分析(ICA)篇

序言 线性因子模型是数据分析与机器学习中的一类重要模型,它们通过引入潜变量( latent variables \text{latent variables} latent variables)来更好地表征数据。其中,独立分量分析( ICA \text{ICA} ICA)作为线性因子模型的一种,以其独特的视角和广泛的应用领域而备受关注。 ICA \text{ICA} ICA旨在将观察到的复杂信号