Nebula Graph 在大规模数据规模下的实践和定制开发是怎样的?

分类:编程技术 时间:2024-02-20 16:15 浏览:0 评论:0
0
本文将详细讲解大规模数据下Nebula Graph的实践和定制开发。文章内容质量很高,分享给大家,作为参考。我希望您能读完本文。读完本文,您将对相关知识有一定的了解。

图数据在社交推荐、多跳实时计算、风控和安全等领域具有广阔的前景。如何利用图数据库高效存储和查询大规模异构图数据是一个重大挑战。文章描述了开源分布式图数据库Nebula Graph在实践中遇到的问题,并通过深度定制实现:大数据集存储、小时级全量导入、多版本控制、秒级回滚、毫秒级访问等特性。

背景

大众所熟知的图数据库大多在大型数据采集方面没有解决方案。例如,Neo4j 的社区版本使用 Cypher 语言,由单台机器和单个副本提供服务。它广泛应用于图领域。互联网公司只能用小数据集合,还需要解决Neo4j多副本一致性和容灾问题。虽然JanusGraph通过外部元数据管理、kv存储和索引解决了大数据集合存储的问题,但其性能问题却广受诟病。我们发现,在比较性能时,大多数图数据库提到的性能提升是 JanusGraph 的数十倍。

面临大数据量挑战的互联网公司普遍走向自研。为了满足业务需求,仅支持有限的查询语义。国内主流互联网公司如何解决图的挑战数据库:

蚂蚁金服:

金融级图数据库通过自定义语言为业务方提供服务并下推全量计算,提供毫秒级延迟。主要应用于以下场景:

金融风控场景:万亿级边缘资金网络,存储实时交易信息,实时欺诈检测。

推荐场景:股票、证券推荐。

蚂蚁森林:万亿级图存储能力,低延迟、强一致的关系数据查询和更新。

GNN:用于小时级别的 GNN 训练。尝试动态图 GNN 在线推理。


iGraph是存储用户行为信息的图索引和查询系统,是阿里巴巴数据中心的四大支柱之一。通过Gremlin语言为业务方提供电商图谱实时查询。


ByteGraph在kv上增加了统一的缓存层,并对关系数据int进行了拆分o B+ 树来应对高效的边缘访问和挖掘。同样,Facebook 的 TAO [6]。

架构图

练习

从哪里开始?

我们选择从Nebula Graph[4]开始我们的图数据库之旅,它吸引我们的地方有以下几点:

数据集是分片的,每条边都是独立存储的。非常大的数据集存储潜力。

定制的强一致性存储引擎,具有计算下推和 MMP 优化的潜力。

创始团队拥有丰富的图数据库经验,模型的抽象思想在大数据集合下得到了验证。

实践中的问题

<跨度类="header-link octicon octicon-link">内存爆炸

本质上这是性能VS资源的问题。在数据规模较大的应用中,内存占用是一个难以忍受的问题。被忽视的问题。 RocksDB内存由三部分组成:块缓存、索引和布隆过滤器、iter pined块。

块缓存优化:使用全局LRU缓存来控制机器上所有rocksdb实例的缓存占用。

布隆过滤器优化:一条边被设计为一个kv并存储在rocksdb中。如果所有的key都保存在布隆过滤器中,并且每个key占用10位空间,那么整个过滤器内存占用远远超过机器内存。我们观察到我们大部分的请求模式都是获取某个点的边列表,所以我们使用前缀布隆过滤器;索引到点属性层实际上可以加速大多数请求。经过这样的优化,单机过滤器占用的内存在这个级别,大部分请求访问速度ds 没有显着降低。

多版本控制

在实际应用中,图数据需要快速处理回滚、定期全量导入、自动获取最新版本数据。我们可以将数据源大致分为两类:

周期性数据:例如每天计算相似用户列表,数据导入后生效。

历史数据+实时数据:例如历史数据每天刷新,与实时写入的数据合并,形成全量数据。

以下是rocksdb中数据的存储模型:

顶点存储格式

边存储格式

写入的数据版本实时 记录为时间戳。离线导入的数据版本需要自行指定。我们将该字段与离线导入模块结合使用,并使用三个配置项用于版本控制:reserve_versions(需要保留的版本列表)、active_version(用户请求的版本号)、max_version(保留某个版本之后的数据,并将历史数据和实时写入数据合并)。这样可以高效管理离线数据和在线数据,不再使用的数据会在下次compaction时从磁盘中清除。

这样业务代码就可以无缝更新数据版本,实现秒级回滚。

示例:

保留 3 个版本并激活其中一个:

alter edgefriend Reserve_versions = 1 2 3 active_version = 1

数据来源为历史数据+实时导入数据。

alter Edgefriend max_version = 1592147484

快速批量导入 h4>

在实践中,导入大量数据是一种常规操作。没有任何优化,它会将require导入的数据转换成请求发送到图数据库,不仅严重影响线上请求,而且导入大量数据需要一天多的时间。优化导入速度刻不容缓。业界一般采用SST Ingest来解决这个问题[5]。我们也采用类似的方法,通过例行调度spark任务来离线生成磁盘文件。然后数据节点拉取自己需要的数据并摄取到数据库中,然后进行版本切换控制以请求访问最新版本的数据。

整个流程导入速度非常快,几个小时内就可以完成。计算过程主要离线完成,对图数据库请求影响很小。

我在这里分享一下Nebula Graph在大规模数据下的实践和定制开发。希望以上内容能够对大家有所帮助。了解更多。如果你认为这篇文章是哦哦,可以分享一下,让更多人看到。

1. 本站所有资源来源于用户上传或网络,仅作为参考研究使用,如有侵权请邮件联系站长!
2. 本站积分货币获取途径以及用途的解读,想在本站混的好,请务必认真阅读!
3. 本站强烈打击盗版/破解等有损他人权益和违法作为,请各位会员支持正版!
4. 编程技术 > Nebula Graph 在大规模数据规模下的实践和定制开发是怎样的?

用户评论