聊聊图数据库和图数据库的小知识 Vol.02

简介: 在第二期的图数据库小知识中,我们回顾了图数据库的兴起契机,聊了聊【传统数据库通过设计良好的数据结构是不是可以实现图数据库的功能】、【图数据库会出于什么考虑做存储计算分离】等图数据库设计问题…
+关注继续查看

about graph database

2010 年前后,对于社交媒体网络研究的兴起带动了图计算的大规模应用。
2000 年前后热门的是 信息检索分析 ,主要是 Google 的带动,以及 Amazon 的 e-commerce 所用的协同过滤推荐,当时 collaborative filtering也被认为是 information retrieval 的一个细分领域,包括 Google 的 PageRank 也是在信息检索领域研究较多。后来才是 Twitter,Facebook 的崛起带动了网络科学 network science的研究。
图理论和图算法不是新科学,很早就有,只是最近 20 年大数据,网络零售和社交网络的发展, big datasocial networkse-commerce 、IoT让图计算有了新的用武之地,而且硬件计算力的提高和分布式计算日益成熟的支持也使图在高效处理海量关联数据成为可能。

上文摘录了#聊聊图数据库和图数据库小知识# Vol.01 的【图数据库兴起的契机】,在本次第二期#聊聊图数据库和图数据库小知识#我们将了解以下内容,如果有感兴趣的图数据库话题,欢迎添加 Nebula 小助手微信号:NebulaGraphbot 为好友进群来交流图数据库心得。

本文目录

  • 图数据库和图数据库设计

    • 传统数据库通过设计良好的数据结构是不是可以实现图数据库的功能
    • 图数据库会出于什么考虑做存储计算分离
    • 数据量小,业务量小的情况下,是否单机部署图数据库性能也不错。
    • 图数据库 shared-storage 和 shared-nothing 的比较
    • 图数据库顶点和边输出及超级顶点输出优化
    • 如何处理图数据库中大数据量的点?
  • Nebula Graph 实践细节

    • Nebula Graph 元数据(Meta Service)使用 etcd 吗?
    • Nebula Graph Cache 位于那一层
    • Nebula Graph 集群中的 Partition 多大
    • 如何理解 Nebula Graph Partition

图数据库和图数据库设计

在这个部分,我们会摘录一些图数据库设计通用的设计思路,或者已有图数据库的实践思考。

传统数据库通过设计良好的数据结构是不是可以实现图数据库的功能

图数据库相对传统数据库优化点在于,数据模型。传统数据库是一个关系型,是一种表结构做 Join,但存储结构表明了很难支持多度拓展,比如一度好友,两度好友,一度还支持,使用一个 Select 和 Join 就可完成,但是二度查询开销成本较大,更别提多度 Join 查询开销更大。图数据库的存储结构为面向图存储,更利于查询多度关系。特别的,有些图上特有的操作,用关系型数据库比较难实现和表达,比如最短路径、子图、匹配特定规则的路径这些。

图数据库会出于什么考虑做存储计算分离

存储与计算分离主要出于以下四方面的考虑:

  1. 存储和计算资源可以独立扩展,使资源利用更充分,达到缩减成本的目的。
  2. 更容易利用异构机型。
  3. 解耦计算节点,计算资源可以更大程度地做到线性扩展。基于之前的项目经历,存储计算不分离的分布式架构,计算能力的水平扩展会比较不方便。举个例子,在好友关系这种场景——基于好友关系查询再做一些排序和计算,在某个节点查询执行过程中需要去其他节点获取数据,或者将某个子计算交给其他节点,如果执行过程中需要的数据存储在本地,相较存储计算分离效率可能会高;但当涉及到和其他节点通信问题时,为了扩容计算资源而增加的机器会使得计算过程中的网络开销相应增加,抵消了相当一部分的计算能力。如果存储计算分离,计算和存储一对一,不存在节点越多网络通讯开销越大的问题。
  4. Nebula Graph在存储层提供基于图的查询接口,但不具备运算能力,方便对接外部的批量计算,比如 Spark,可以将图存储层当作为图索引存储,直接批量扫描、遍历图自行计算,这样操作更灵活。存储层支持做一些简单的过滤计算,比如找寻 18 岁好友等过滤操作。

数据量小,业务量小的情况下,是否单机部署图数据库性能也不错。

单机按分布式架构部署,有一定网络开销因为经过网卡,所以性能还行。一定要分布式架构部署的原因在于强一致、多副本的业务需求,你也可以按照业务需求部署单副本。

图数据库 Shared-storage 和 Shared-nothing 的比较

【提问】对于图数据库来说,是不是 shared-storage 相比 shared-nothing 方式更好呢。因为图的节点间是高度关联的,shared-nothing 方式将这种联系拆掉了。对于多步遍历等操作来说,需要跨节点。而且由于第二步开始的不确定性,要不要跨节点好像没法提前通过执行计划进行优化。

【回复】交流群群友 W:errr,单个 storage 能不能放下那么多数据,特别数据量增加了会是个比较麻烦的问题。另外第二步虽然是随机的,但是取第二步数据的时候可以从多台机器并发

【回复】交流群群友 W:主要的云厂商,比如 AWS 的共享存储可以到 64 T,存储应该够,而且这种方式存储内部有多副本。顺便提一句:AWS 的 Neptune 的底层存储用的也是 Aurora 的那个存储。网络这块的优化,可参考阿里云的 Polarstore,基本上网络已经不是什么问题了。

image.png

此外,“第二步虽然是随机的,但是取第二步数据的时候可以从多台机器并发吧”这个倒是,Nebula 有个 storage server 可以做这个事情,但逻辑上似乎这个应该是 query engine 应该干的。

【回复】交流群群友 W:“网络这块的优化,可参考阿里云的 polarstore,基本上网络已经不是什么问题了。” 网络这问题,部署环境的网络不一定可控,毕竟机房质量参差不齐,当然云厂商自己的机房会好很多。

【回复】交流群群友 W:这个确实。所以开源的创业公司走 shared-nothing,云厂商走 shared-storage,也算是都利用了各自的优势

【回复】交流群群友 S:其实,shared-storage 可以被看成是一个存储空间极大的单机版,并不是一个分布式系统

【回复】交流群群友 W:嗯嗯。不过 Neptune 那种跟单机版的区别在于计算那部分是可扩展的,一写多读,甚至 Aurora 已经做到了多写。不过就像前面所说的,开源的东西基于那种需定制的高大上存储来做不现实。想了下拿 AWS 的存储做对比不大合适,存储内部跨网络访问的开销还是一个问题,拿 Polarstore 这种 RDMA 互联更能说明。可能 2 种方案都差不多,本质上都是能否减少跨网络访问的开销。

图数据库顶点和边输出及超级顶点输出优化

【提问】请教一个问题。Nebula 的顶点和出边是连续存放的。那么在查询语句进行 IO 读取时,是顶点和出边会一起读出来呢,还是根据查询语句的不同而不同?

【回复】交流群群友 W:会一个 block 一起读出来

【回复】交流群群友 W:恩恩。对于 supernode 这种情况,有没有做什么优化?Titian/Janusgraph 有一个节点所有边的局部索引,Neo4j 应该有在 object cache 中对一个节点的边按照类型组织

【回复】交流群群友 S:Nebula 也是用 index 来解决这个问题

【回复】交流群群友 W:Neo4j 的 relationship group 是落在存储上的,请教下,Nebula 的这种 index 和 Janusgraph 的 vertex centric 索引类似麽,还是指存储格式里面的 ranking 字段啊

【回复】交流群群友 S:类似于 Janusgraph 的索引,但是我们的设计更 general,支持 multi-column 的索引

【回复】交流群群友 W:ranking 字段其实给客户用的,一般可以拿来放时间戳,版本号之类的。

如何处理图数据库中大数据量的点?

【提问】:Nebula 的存储模型中属性和边信息一起存储在顶点上,针对大顶点问题有好的解决方案吗?属性和关系多情况下,针对这种实体的查询该怎么处理,比如:比如美国最有名的特产,中国最高的人,浙江大学年龄最大的校友

【回复】交流群群友 W:如果可以排序,那分数可以放在 key 上,这样其实也不用 scan 太多了,ranking 字段就可以放这个。要不然还有个办法是允许遍历的过程中截断或者采样,不然很容易爆炸的。

【回复】交流群群友 B:在做实时图数据库的数据模型设计时,尽量避免大出入度的节点。如果避免不了,那至少避免此类节点再往后的 traversal。如果还是避免不了,那别指望这样的查询会有好的性能

【回复】交流群群友 H:单纯的大点如果不从它开始 traversal,其实问题也不大。load 的 unbalance 都是有办法解决的。数据的 unbalance 因为分 part 存储,在分配 part 到 host 时可加入 part 数据量的权重,而 load 的 unbalance,对于读,可通过拓展只读副本 + cache 解决,写的话,可做 group commit,client 也可以做本地 cache。

【回复】交流群群友 B:图数据库的一个查询的性能最终取决于 physical block reads 的数量。不同方案会导致最后 block reads 不一样,性能会有差别。任何一种方案不可能对所有查询都是优化的,最终往往就是 tradeoff。主要看你大部分实际的 query pattern 和数据分布式如何,该数据库实现是否有优化。拆边和不拆边,各有其优缺点。

Nebula Graph 实践细节

在这个部分我们会摘录一些开源的分布式图数据库 Nebula Graph 在实践过程中遇到的问题,或者用户使用图数据库 Nebula Graph 中遇到的问题。

Nebula Graph 元数据(Meta Service)使用 etcd 吗?

不是。Meta Service的架构其实和 Storage Service 架构类似,是个独立服务。

Nebula Graph Cache 位于哪一层

A:KV 那层。目前只有针对顶点的 Cache,顶点的访问具有随机性,如果没有 Cache,性能较差。Query Plan 那层现在还没有。

如何理解 Nebula Graph Partition

partition 是个逻辑概念,主要目的是为了一个 partition 内的数据可以一起迁移到另外一台机器。partition 数量是由创建图空间时指定的 partition_num 确立。而单副本 partition 的分布规则如下

image.png

通过算子:partID%engine_size,而多副本的情况,原理类似,follower 在另外两个机器上。

Nebula Graph 集群中的 Partition 多大

A:部署集群时需要设置 Partition 数,比如 1000 个 Partition。插入某个点时,会针对这个点的id做 Hash,找寻对应的 Partition 和对应 Leader。PartitionID 计算公式 = VertexID % num_Partition

单个 Partition 的大小,取决于总数据量和 Partition 个数;Partition 的个数的选择取决于集群中最大可能的机器节点数,Partition 数目越大,每个 Partition 数据量越小,机器间数据量不均匀发生的概率也就越小。

推荐阅读

相关实践学习
阿里云图数据库GDB入门与应用
图数据库(Graph Database,简称GDB)是一种支持Property Graph图模型、用于处理高度连接数据查询与存储的实时、可靠的在线数据库服务。它支持Apache TinkerPop Gremlin查询语言,可以帮您快速构建基于高度连接的数据集的应用程序。GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。 GDB由阿里云自主研发,具备如下优势: 标准图查询语言:支持属性图,高度兼容Gremlin图查询语言。 高度优化的自研引擎:高度优化的自研图计算层和存储层,云盘多副本保障数据超高可靠,支持ACID事务。 服务高可用:支持高可用实例,节点故障迅速转移,保障业务连续性。 易运维:提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能,大幅降低运维成本。 产品主页:https://www.aliyun.com/product/gdb
目录
相关文章
|
3小时前
|
存储 NoSQL 关系型数据库
浅谈图数据库
浅谈图数据库
13 0
|
4月前
|
存储 NoSQL 搜索推荐
图数据库有哪些:知名图数据库产品和应用场景介绍
图数据库是一种专门用于存储和处理图数据模型的数据库管理系统。图数据模型以节点和边的形式组织数据,用于表示实体之间的关系。相比传统的关系型数据库,图数据库更加适合处理复杂的关联关系,如社交网络、推荐系统、地理信息系统等领域的数据。图数据库的兴起,得益于现代应用场景对于数据处理和分析能力的不断增强需求。
|
12月前
|
存储 NoSQL Java
|
存储 SQL 算法
阿里云自研数据仓库 AnalyticDB 再捧 TPC 全球冠军
5月14日,TPC 官网正式公布,阿里云自研的 AnalyticDB 通过了TPC-DS全流程测试,将前世界纪录的性能提升了29%,并把单位成本降低了三分之二,成功夺得全球数据仓库的桂冠。
|
存储 NoSQL Apache
利用图数据库构建社交应用
图数据库覆盖的应用场景非常广泛,比较典型的有社交网络,欺诈检测,推荐引擎,知识图谱,网络/IT运营和生命科学等等。这些场景下,相对于关系型数据库或者NoSQL往往有数量级的访问能力提升。在数据爆炸性增长的今天,图数据库的优势会越发明显。
953 0
利用图数据库构建社交应用
|
存储 NoSQL 数据可视化
聊聊图数据库和图数据库的小知识
图数据库计算存储分离设计及该设计模式的考量原因、图数据库 0 标签的意义等图数据库相关问题
2440 0
|
存储 大数据 Apache
越来越火的图数据库究竟是什么?
如果把传统关系型数据库比作火车,那图数据库就是如今大数据时代的高铁。那究竟什么是图数据库呢?来不及解释了,先上车!~
3375 0
|
新零售 分布式数据库 数据库
图数据库HGraphDB介绍
一、HGraphDB概述图无处不在,社交和电商领域每天都会产生大量的实体连接数据,而描述图的方式往往是使用包括顶点和边以及丰富的属性的属性图来展现。在如今的2018年,社交网络和电商数据往往能够形成非常大的实体图,包括数十亿顶点和百亿条边这样的数据量。
6406 0
|
JSON 关系型数据库 数据库
图数据库:AgensGraph
非常流行的图数据库
3539 0
|
机器学习/深度学习 存储 NoSQL
图数据库浅谈
图数据库分为两大类:native graph和non-native graph native graph: 数据只能存放在一台机器上。不支持分片。如果你的数据量非常大,Neo4j是扛不住的。
1799 0
推荐文章
更多