您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
Nebula Graph 概览
 
作者:图图

  90  次浏览      1
 2021-3-10
   
 
编辑推荐:
本文主要详细介绍 Nebula Graph的数据模型和系统架构设计 ,希望对您的学习有所帮助。
本文来自于NebulaGraph社区,由火龙果软件Alice编辑、推荐。

本篇导读

有向属性图

(Directed Property Graph)

Nebula Graph 采用非常容易理解的有向属性图的方式来建模。也就是说,在逻辑上,图由两种图元素构成:

顶点(vertex)、顶点的类型(tag)和对应的顶点属性:在 Nebula Graph 中,顶点的类型称为标签(tag)。一个顶点必须至少有一种类型(标签),也可以有多种类型(标签)。每种标签有一组相对应的属性,称为 schema。

例如上图示例中,有两种类型的顶点:player 和 team。 player 的 schema 有三种属性 id(vid),Name(string)和 Age(int);team 的 schema 有两种属性 id(vid)和 Name(string)。

和 Mysql 一样,Nebula Graph 是一种强 schema 的数据库,属性的名-称和数据类型都是在数据写入前确定的。

边(edge)、边的类型(edgetype)和边上的属性:Nebula Graph 中的边均是有向边,表明了一个从起点(src)指向终点(dst)边的关联关系。每个关系都有一个 edgetype,每种 edgetype 定义了关系的属性。

例如,上图中有两种类型的边,一种为 player 指向 player 的 like 关系,属性为 likeness (double);另一种为 player 指向 team 的 serve 关系,两个属性分别为 start_year(int) 和 end_year(int)。

需要说明的是,起点和终点之间,可以同时存在多条相同或者不同类型的边。

图分割

(Graph Partition)

由于超大规模关系网络的节点数量高达百亿到千亿,而边的数量更会高达万亿,即使仅存储点和边两者也远大于一般服务器的容量。因此需要有方法将图元素切割,并存储在不同逻辑分片(Partition)上。Nebula Graph 采用边分割的方式,默认的分片策略为哈希散列,partition 数量为静态设置并不可更改。

数据模型

(Data Model)

在 Nebula Graph 中,每个顶点被建模为 key-value,根据其 vertexID(或简称 vid)哈希散列后,存储到对应的 partition 上。

一条逻辑意义上的边,在 Nebula Graph 中建模为两个独立的 key-value,分别称为 out-key 和 in-key。out-key 与这条边所对应的起点存储在同一个 partition 上,in-key 与这条边所对应的终点存储在同一个 partition 上。

关于数据模型的详细设计会在后续的系列文章中介绍。

系统架构

(Architecture)

Nebula Graph 包括四个主要的功能模块,分别是存储层、元数据服务、计算层和客户端。

存储层

存储层对应进程是 nebula-storaged。其核心为基于 RAFT 协议的分布式 Key-value Storage。目前支持的主要存储引擎为 Rocksdb 和 HBase。

Raft 协议通过 leader/follower 的方式,来保持数据之间的一致性。Nebula Storage 主要增加了以下功能和优化:

1.Parallel Raft. 多台机器上的相同 partiton-id 组成一个 Raft group。通过多组 Raft group 实现并发操作。

2.Write Path & batch:Raft 协议的多机器间同步依赖于日志 id 顺序性,这样的 throughput 较低。通过批量和乱序提交的方式,来实现更高的吞吐量。

3.基于异步复制的 learner:当集群中增加新的机器时,可以将其先标记为 learner,并异步从 leader/follower 拉取数据。当该 learner 追上 leader 后,再标记为 follower,参与 raft 协议。

4.Load-balance:对于部分访问压力较大的机器,将其所服务的 partition 迁移到较冷的机器上,以实现更好的负载均衡。

元数据服务层

Meta service 对应的进程是 nebula-metad,其主要的功能有:

1.用户管理:Nebula Graph 的用户体系包括 God user,Admin,User,Guest 四种。每种用户的操作权限不一。

2.集群配置管理:支持上线、下线新的服务器。

3.图空间管理:增加、删除图空间,修改图空间配置(Raft 副本数)。

4.Schema 管理:Nebula Graph 为强 schema 设计。

1)通过 Meta service 记录 Tag 和 Edge 的属性的各字段的类型。支持的类型有:int, double, timestamp, list 等;

2)多版本管理,支持增加、修改和删除 schema,并记录其版本号;

3)TTL 管理,通过标识到期回收(time-to-live)字段,支持数据的自动删除和空间回收。

Meta Service 层为有状态的服务,其状态持久化方法与 Storage 层一样通过 KV Store 方式存储。

Query Engine &

Query Language (nGQL)

计算层对应的进程是 nebula-graphd,它由完全对等无状态无关联的计算节点组成,计算节点之间相互无通信。

Query Engine 层的主要功能,是解析客户端发送 nGQL 文本,通过词法解析(Lexer)和语法解析(Parser)生成执行计划。并通过优化后将执行计划交由执行引擎。执行引擎通过 Meta Service 获取图点和边的 schema,并通过存储引擎层获取点和边的数据。

Query Engine层的主要优化有:

异步和并发执行:由于 IO 和网络均为长时延操作,需采用异步及并发操作。此外,为避免单个长 query 影响后续 query,也为每个 query 设置单独的资源池以保证服务质量 QoS。

计算下沉:为避免存储层将过多数据回传到计算层,占用宝贵带宽,条件过滤(where)等算子会随查询条件一同下发到存储层节点。

执行计划优化:关系数据库 SQL 中的执行计划优化已经经历了长时间的发展,但业界对于图查询语言的优化研究较少。Nebula Graph 对图查询的执行计划优化也进行了一定的探索,包括执行计划缓存和上下文无关语句的并发执行。

API 和 console

Nebula Graph 提供C++, java, Golang 三种语言的客户端,与服务器之间的通信方式为 RPC,采用的通信协议为 Facebook-Thrift。用户也可通过 linux 上 console 实现对 Nebula Graph 操作。Web 访问方式也已在开发过程中。

 
   
90 次浏览       1
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...