从一到无穷大 #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

相关文章

Go标准库常见错误分析和解决办法

《Go标准库常见错误分析和解决办法》Go语言的标准库为开发者提供了丰富且高效的工具,涵盖了从网络编程到文件操作等各个方面,然而,标准库虽好,使用不当却可能适得其反,正所谓工欲善其事,必先利其器,本文将... 目录1. 使用了错误的time.Duration2. time.After导致的内存泄漏3. jsO

SpringBoot实现数据库读写分离的3种方法小结

《SpringBoot实现数据库读写分离的3种方法小结》为了提高系统的读写性能和可用性,读写分离是一种经典的数据库架构模式,在SpringBoot应用中,有多种方式可以实现数据库读写分离,本文将介绍三... 目录一、数据库读写分离概述二、方案一:基于AbstractRoutingDataSource实现动态

C# WinForms存储过程操作数据库的实例讲解

《C#WinForms存储过程操作数据库的实例讲解》:本文主要介绍C#WinForms存储过程操作数据库的实例,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、存储过程基础二、C# 调用流程1. 数据库连接配置2. 执行存储过程(增删改)3. 查询数据三、事务处

Spring事务中@Transactional注解不生效的原因分析与解决

《Spring事务中@Transactional注解不生效的原因分析与解决》在Spring框架中,@Transactional注解是管理数据库事务的核心方式,本文将深入分析事务自调用的底层原理,解释为... 目录1. 引言2. 事务自调用问题重现2.1 示例代码2.2 问题现象3. 为什么事务自调用会失效3

mysql数据库重置表主键id的实现

《mysql数据库重置表主键id的实现》在我们的开发过程中,难免在做测试的时候会生成一些杂乱无章的SQL主键数据,本文主要介绍了mysql数据库重置表主键id的实现,具有一定的参考价值,感兴趣的可以了... 目录关键语法演示案例在我们的开发过程中,难免在做测试的时候会生成一些杂乱无章的SQL主键数据,当我们

找不到Anaconda prompt终端的原因分析及解决方案

《找不到Anacondaprompt终端的原因分析及解决方案》因为anaconda还没有初始化,在安装anaconda的过程中,有一行是否要添加anaconda到菜单目录中,由于没有勾选,导致没有菜... 目录问题原因问http://www.chinasem.cn题解决安装了 Anaconda 却找不到 An

Spring定时任务只执行一次的原因分析与解决方案

《Spring定时任务只执行一次的原因分析与解决方案》在使用Spring的@Scheduled定时任务时,你是否遇到过任务只执行一次,后续不再触发的情况?这种情况可能由多种原因导致,如未启用调度、线程... 目录1. 问题背景2. Spring定时任务的基本用法3. 为什么定时任务只执行一次?3.1 未启用

Spring Boot 整合 MyBatis 连接数据库及常见问题

《SpringBoot整合MyBatis连接数据库及常见问题》MyBatis是一个优秀的持久层框架,支持定制化SQL、存储过程以及高级映射,下面详细介绍如何在SpringBoot项目中整合My... 目录一、基本配置1. 添加依赖2. 配置数据库连接二、项目结构三、核心组件实现(示例)1. 实体类2. Ma

SpringCloud之LoadBalancer负载均衡服务调用过程

《SpringCloud之LoadBalancer负载均衡服务调用过程》:本文主要介绍SpringCloud之LoadBalancer负载均衡服务调用过程,具有很好的参考价值,希望对大家有所帮助,... 目录前言一、LoadBalancer是什么?二、使用步骤1、启动consul2、客户端加入依赖3、以服务

SpringCloud负载均衡spring-cloud-starter-loadbalancer解读

《SpringCloud负载均衡spring-cloud-starter-loadbalancer解读》:本文主要介绍SpringCloud负载均衡spring-cloud-starter-loa... 目录简述主要特点使用负载均衡算法1. 轮询负载均衡策略(Round Robin)2. 随机负载均衡策略(