nebulaGraph实践案例

文章目录

Nebula Graph 在oppo的OGraph云图平台的实战应用

一、图数据简介

1.什么是图

学过数据结构这么课程的同学脑海中应该或多或少有图的概念。
图由两个元素组成:节点和关系。
每个节点代表一个实体(人,地,事物,类别或其他数据),每个关系代表两个节点的关联方式。这种通用结构可以对各种场景进行建模 - 从道路系统到设备网络,到人口的病史或由关系定义的任何其他事物。

2.什么是图数据库

图数据库(Graph database)并非指存储图片的数据库,而是以图这种数据结构存储和查询数据。图形数据库是一种在线数据库管理系统,具有处理图形数据模型的创建,读取,更新和删除(CRUD)操作。与其他数据库不同,关系在图数据库中占首要地位。这意味着应用程序不必使用外键或带外处理(如MapReduce)来推断数据连接。与关系数据库或其他NoSQL数据库相比,图数据库的数据模型也更加简单,更具表现力。
图形数据库是为与事务(OLTP)系统一起使用而构建的,并且在设计时考虑了事务完整性和操作可用性。

3.图数据库重要属性

  1. 图模型
    属性图(Property Graphs)
    虽然属性图的实现中有一些核心的共性,但是没有真正标准的属性图数据模型,因此属性图的每个实现都有些不同。在下面,我们将重点讨论任何属性图数据库都常见的特征。
    节点(Nodes):是图中的实体,用表示其类型的0到多个文本标签进行标记,相当于实体。
    边(Edges):是节点之间的定向链接,也称为关系。其中对应的“from node”称为源节点,“to node”称为目标节点。边是定向的且每条边都有一个类型,它们可以在任何方向上导航和查询。相当于实体之间的关系。
    属性(Properties):是一个键值对,顶点和边都具有属性。

    资源描述框架图(RDF Graphs)
    RDF图使用标准的图数据模型,其技术栈的标准是由万维网联盟(W3C)管理的,这个组织也同时管理HTML、XML和许多其他网络标准。因此每个支持RDF的数据库都应该以同样的方式支持该模型。除此之外,RDF有一个标准的查询语言称为SPARQL。它既是一种功能齐全的查询语言,又是一种HTTP协议,可以通过HTTP将查询请求发送到端点。RDF图数据模型主要是由以下两个部分组成的:
    节点(Nodes):对应图中的顶点,可以是具有唯一标识符的资源,也可以是字符串、整数等有值的内容。
    边(Edges):是节点之间的定向链接,也称为谓词或属性。边的入节点称为主语,出节点称为宾语,由一条边连接的两个节点形成一个主语-谓词-宾语的陈述,也称为三元组。边是定向的,它们可以在任何方向上导航和查询。
    RDF的英文全称为Resource Description Framework,因为在RDF图中,一切都称为源。边和节点只是给定语句中资源所扮演的角色。基本上在RDF中,扮演边角色的资源和扮演节点角色的资源没有区别,因此一条语句中的边也可以是另一条语句中的节点。RDF数据模型相较于属性图更加丰富,也在语义上保持一致性。图2展示了如何将上面的图1由属性图表示为

nebulaGraph实践案例

  1. 图存储
    一些图数据库使用原生图存储,这类存储是经过优化的,并且是专门为了存储和管理图而设计的。并不是所有图数据库都是使用原生图存储,也有一些图数据库将图数据序列化,然后保存到关系型数据库或者面向对象数据库,或其他通用数据存储中。
    根据存储和处理模型不同,市面上图数据库也有一些区分。
    比如:Neo4J就是属于原生图数据库,它使用的后端存储是专门为Neo4J这种图数据库定制和优化的,理论上说能更有利于发挥图数据库的性能。
    而JanusGraph不是原生图数据库,而将数据存储在其他系统上,比如Hbase。
  2. 图处理引擎
    原生图处理(也称为无索引邻接)是处理图数据的最有效方法,因为连接的节点在数据库中物理地指向彼此。非本机图处理使用其他方法来处理CRUD操作。
  3. 图查询语言
    nebulaGraph实践案例

4.图数据,NoSQL,关系型数据库区别

分类 数据模型 优势 劣势 举例
键值数据库 哈希表 查找速度快 数据无结构化,通常只被当作字符串或者二进制数据 Redis
列存储数据库 列式数据存储 查找速度快;支持分布横向扩展;数据压缩率高 功能相对受限 HBase
文档型数据库 键值对扩展 数据结构要求不严格;表结构可变;不需要预先定义表结构 查询性能不高,缺乏统一的查询语法 MongoDB
图数据库 节点和关系组成的图 利用图结构相关算法(最短路径、节点度关系查找等) 高度结构化的数据处理能力不及关系型数据库 Neo4j、JanusGraph,NebulaGarph
关系型数据库 表结构 数据高度结构化,一致性强,软件成熟度高 面向多跳的关联关系查询低效或不支持 MySQL

nebulaGraph实践案例

5.图数据库架构

一个完整成熟的图数据库架构应该包含以下模块:

1.查询和计算:最终用户用于在此语言基础之上进行图的遍历和查询,最终返回运行结果,如能提供RESTful API则能给开发者提供不少便利之处。
2.操作和运维:用于系统实时监控,例如系统配置、安装、升级、运行时监控,甚至包括可视化界面等。
3.数据加载:包括离线数据加载和在线数据加载,既可以是批量的数据加载,也可以是流数据加载方式。
4.图数据库核心:主要包括图存储和图处理引擎这两个核心。
5.图处理引擎负责实时数据更新和执行图运算;
6.图存储负责将关系型数据及其他非结构化数据转换成图的存储格式;
7.HA服务负责处理处理数据容错、数据一致性以及服务不间断等功能。

nebulaGraph实践案例

6.图数据优势和应用领域

1.图数据优势
a.更好,更快速的查询和分析:图数据库为查询相关数据(无论大小)提供了卓越的性能。 图模型提供了固有的索引数据结构,因此它不需要为给定条件的查询加载或接触不相关的数据。这使得它成为更好、更快的实时大数据分析查询的绝佳解决方案。这与HDFS系统相反,HDFS系统具有为数据湖(Data Lake)、顺序扫描和追加新数据(不随机查找)而构建的架构。在这样的系统中,每个查询都涉及文件的大部分。使用图数据库,查询只能触及相关的数据。

b.更简单和更自然的数据建模:使用关系型数据库建模的人都需要了解数据库的规范化和参照完整性的严格规则。 一些NoSQL数据库则走向了另一个极端,将所有类型的数据放在一个大型表中。 另一方面,在图数据库中,可以定义任意类型的顶点类型来表示对象,并定义边类型来表示特定的关系。 图模型的语义和你想要的语义完全一样,没有标准化也没有浪费。 此外,图模型支持面向对象的思维,因为每个书面查询都需要明确的语义。 没有任何隐藏的假设,比如在关系型SQL中需要知道FROM子句中的表。

c.同时支持实时更新和查询:图数据库支持对大图形数据的实时更新,同时支持查询。

d.数据结构的灵活性:图数据库具有灵活的schema修改。用户可以不断添加或删除新的顶点、边和属性,扩展或缩小数据模型。这对管理不断变化的对象类型特别方便。大多数图数据库可以在线修改schema,同时继续提供查询。 相比之下,关系数据库不能轻易地支持在现代数据管理时代如此普遍的频繁schema变更。
2.应用领域:

社交领域:Facebook, Twitter,Linkedin用它来管理社交关系,实现好友推荐
零售领域:eBay,沃尔玛使用它实现商品实时推荐,给买家更好的购物体验
金融领域:摩根大通,花旗和瑞银等银行在用图数据库做风控处理
汽车制造领域:沃尔沃,戴姆勒和丰田等*汽车制造商依靠图数据库推动创新制造解决方案
电信领域:Verizon, Orange和AT&T 等电信公司依靠图数据库来管理网络,控制访问并支持客户360
酒店领域:万豪和雅高酒店等*酒店公司依使用图数据库来管理复杂且快速变化的库存

二、图数据选型

1.常用图数据库对比

nebulaGraph实践案例

nebulaGraph实践案例
nebulaGraph实践案例

我们自己调研测试结果
nebulaGraph实践案例

nebulaGraph实践案例

nebulaGraph实践案例

综合上述结果:
导入:
NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB
查询:
NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB
HugeGraph 后端存储使用 RocksDB 的时候性能更高,但是 RocksDB 只支持单机,所以实际只能使用 HBase 做后端存储,此时 HugeGraph 和 JanusGraph 差不多,nebulaGraph 的性能最好同时兼具一下特点:

2.Nebula Graph图数据库特点介绍

nebulaGraph实践案例

1.开源
Nebula Graph是在Apache 2.0和Commons Clause 1.0条款下开发的。越来越多的人,如数据库开发人员、数据科学家、安全专家、算法工程师,都参与到Nebula Graph的设计和开发中来,欢迎访问Nebula Graph GitHub主页参与开源项目。
2.高性能
基于图数据库的特性使用C++编写的Nebula Graph,可以提供毫秒级查询。众多数据库中,Nebula Graph在图数据服务领域展现了卓越的性能,数据规模越大,Nebula Graph优势就越大。详情请参见Nebula Graph benchmarking页面。
3.易扩展
Nebula Graph采用shared-nothing架构,支持在不停止数据库服务的情况下扩缩容。
4.易开发
Nebula Graph提供Java、Python、C++和Go等流行编程语言的客户端,更多客户端仍在开发中。详情请参见Nebula Graph clients。
5.高可靠访问控制
Nebula Graph支持严格的角色访问控制和LDAP(Lightweight Directory Access Protocol)等外部认证服务,能够有效提高数据安全性。详情请参见验证和授权。
6.生态多样化
Nebula Graph开放了越来越多的原生工具,例如Nebula Graph Studio、Nebula Console、Nebula Exchange等。nebulaGraph实践案例

此外,Nebula Graph还具备与Spark、Flink、HBase等产品整合的能力,在这个充满挑战与机遇的时代,大大增强了自身的竞争力。
7.兼容openCypher查询语言
Nebula Graph查询语言,也称为nGQL,是一种声明性的、兼容openCypher的文本查询语言,易于理解和使用。详细语法请参见nGQL指南。
8.灵活数据建模
用户可以轻松地在Nebula Graph中建立数据模型,不必将数据强制转换为关系表。而且可以*增加、更新和删除属性。详情请参见数据模型。
相较于 JanusGraph 和 HugeGraph,Nebula Graph查询性能有极大的提升
正是基于Nebula Graph的以上特点以及对我们使用场景和需求的恰好满足,因此最终选择Nebula Graph作为我们图平台的最终图数据库来使用,为相关业务打下良好的基础。

三、基于NebulaGraph的业务实践

项目:知识图谱

1.基于janusGraph -知识图谱和智能问答1.0 版本

知识图谱图数据库架构初期是基于 JanusGraph 搭建,在使用 JanusGraph 过程中,我们发现 JanusGraph 这块数据性能随着数据量增加性能无法满足需求,故我们希望新的图数据库能够满足以下要求:
1、能够支持2亿节点10亿边的大规模图谱。
2、导入导出时间小于10h。
3、QPS能够达到10000+
4、二度及二度以下查询响应平均时间不超过100ms

2.基于NebulaGraph-知识图谱和智能问答平台2.0 版本

  NebulaGarph
   集群配置: 2个机房高可用多活模式
      单个机房配置如下:
	      nebula 版本:2.0.1
	      部署方式(分布式 ):3个meta  6个stroage,6个graph
		 是否为线上版本:Y 
		 硬件信息
		 磁盘 2TB ssd 
		 CPU 32c 、内存128 GB

3.知识图谱整体框架和构建流程

1. 知识图谱平台整体框架和构建流程
整体框架
nebulaGraph实践案例
构建流程
nebulaGraph实践案例

2.现有知识图谱规模
已经包含9大领域,属性715,680,345,实体105,119,799,类别201
边435,860,318

nebulaGraph实践案例

4.知识图谱业务实战介绍

1.小布智能语言助手
小布智能问答是知识图谱应用的核心业务之一,通过KBQA问答模型查询图谱中你要的问题答案

nebulaGraph实践案例
nebulaGraph实践案例

nebulaGraph实践案例
nebulaGraph实践案例
问答:刘德华的老婆是谁
nebulaGraph实践案例
问答:姚明老婆的身高
nebulaGraph实践案例

2.智能推荐
通过图像和视频识别技术识别视频中的相关人物信息,然后通过知识图谱精确匹配人物和相关作品,再对视频打上相应标签,同时推荐系统根据你的浏览记录信息,帮你智能推荐你喜欢的相关作品

nebulaGraph实践案例

3.智能搜索
智能搜索主要通过知识图谱找出相关事物的相关联系,再通过分析懂察其中关联价值
nebulaGraph实践案例

nebulaGraph实践案例

四. 总结与展望

1.总结
通过知识图谱项目的实践落地,让我们对图数据库应用于相关领域重要性和前景充满了希望信心,我们会继续加油怒力,让图数据库继续开花结果。
2展望,
1)未来回进一步推荐知识图谱在搜索、推荐、智能助理、广告游戏等领域的广泛引用
打造公司在知识图谱领域的核心能力,为全公司业务赋能
2)同时我们打算基于去探索一下图学习、图计算的能力,给平台用户提供更多挖掘图数据价值的功能。

上一篇:对图数据库(Nebula)进行单元测试时的坑


下一篇:基于 KubeSphere 的 Nebula Graph 多云架构管理实践