图数据库介绍与浅谈

 

Nebula Graph 技术分享野谈———不得不说,世界是很奇妙的。这次能有幸参加Nebula Graph的技术分享,大概是源自于在前一段时间参加的“中国开源年会”上的接触,借着这次技术分享,也在我的认知图谱里点亮了“图数据库”。这篇文章,主要是总结自己对图数据库理解的总结。

1. 什么是图数据库


我们先来wiki一下 what is the ‘图数据库’?
图数据库:Graph Database 一个使用图结构进行语义查询的数据库

可以看到,在中文维基百科上,关于图数据库的介绍篇幅,相比于其他技术,还是比较小的,这也从侧面说明,这部分技术还在发育期。

一般技术的发展,可以分为婴儿期、发育期、成熟期和衰退期

传统的数据库,包括Sql和其他NoSql对于数据之间的关系,是隐式存储的,图数据库则明确列出了数据间的关系,使其对于高度互连的数据非常有用。

现有的数据库都是基于某一种数据模型而建立起来的, 数据模型是定义数据如何输入和与输出的一种模型。简单来说,就是定义数据的格式。
这种格式要满足三方的需求:表达的需求(能直观、简便的模拟现实世界),计算机的实现需求,以及人们的理解需求。
需求典型的数据模型有:层次模型,网状模型、关系模型,面向对象模型。
每一种数据模型都有三要素(和普通的数据结构一样):

  • 数据结构
  • 数据操作
  • 数据约束条件
- 层次模型:有向树   
- 网状模型:关系网,结构复杂  
- 关系模型:二维表结构,
- 面向对象模型:代码+数据=对象,通过逻辑包含维护联系

可见,网状模型数据库和图数据库是有些类似的,他们都是图结构的。那么,它们有什么区别呢?
一般而言,网状模型是在较低层次抽象上运行,整体结构复杂,很难遍历得到某一节点数据的所有关系。
相对的,图数据库以简单快速地检索难以在关系系统中建模的复杂层次结构。

说到这里,我们大概清楚,图数据库在数据库界的定位了,不可否认,它不是必须的,同样的问题,可以通过传统的数据库解决,虽然解决的不够好。图数据库作为传统数据库的辅助,可以更高效地应用于高度互联的数据。

2. 图数据库的应用


在此之前,我以为,图数据库是一个新生儿,但是具体了解后,才发现,它由来已久,而且很多大公司都会用的到,虽然没有独立到自成一派,但也起着不小的作用。那么图数据库到底应用在哪些方面呢?其实上面我们已经说了最关键的地方了——它适用于高度互联的数据。

  • 自然语言:自然语言查询、实体识别消除歧义、知识图谱
  • 大数据:社交网络
  • 预测:供应链的风险预测、建议引擎、药物开发
  • 金融:网上银行、欺诈检测

深入了解发现,图数据库的应用还紧密联系了另一个领域——语义网。所幸,我对它不陌生甚至还很熟悉,又减少了我的学习成本。(我曾经上了一学期研讨语义网的课程,对此方面还是有一定的了解,有时间会专门写一篇关于语义网的文章。)

下面,我们通过几款较为完善的图数据库进行深入了解。


A. Allegro Graph

https://allegrograph.com/

技术点:语义+图

Allegro Graph为开发复杂的语义图应用程序提供了一个全面的生态系统。它的开发团队是Franz Inc.,基于全球财团和行业标准组织,供给很多500强的大公司解决方案,提供高级数据查询,使企业能从高度复杂的分布式数据库中提取复杂的决策见解和预测分析(常规数据库无法解决的问题)。

大规模语义———— Hadoop + AllegroGraph

目标:处理TB级别的名称和数据,解析作者、共同作者、TB相关出版物以及共享的存储关系。

遇到的问题:

  • 无法消除任命歧义:变体、昵称、拼写错误、缩写
  • 半结构化数据
  • TB级内容
  • 传统名称匹配无法发现
#补充,数据量
1B(Byte字节)=8bit
1KB (Kilobyte 千字节)=1024B,
1MB (Mega byte 兆字节 简称“兆”)=1024KB,
1GB (Giga byte 吉字节 又称“千兆”)=1024MB,
1TB (Tera byte 万亿字节 太字节)=1024GB,其中1024=2^10 ( 2 的10次方),
1PB(Peta byte 千万亿字节 拍字节)=1024TB,
1EB(Exa byte 百亿亿字节 艾字节)=1024PB,
1ZB (Zetta byte 十万亿亿字节 泽字节)= 1024 EB,
1YB (Yotta byte 一亿亿亿字节 尧字节)= 1024 ZB,
1BB (Bronto byte 一千亿亿亿字节)= 1024 YB
1NB(Nona byte )= 1024BB
1DB(Dogga byte)= 1024NB

说实话,TB级的数据量并不大,这个问题的难点不是数据量的问题,而是数据结构的问题

解决方案:

Hadoop Allegro Graph
大型数据集处理 RDF、三重存储和本体平台
半结构化数据处理 解析不明确的名称、缩写
数据存储和处理的经济可扩展性 识别隶属关系
Map-Reduce框架 基于阈值的人际关系匹配
创建语义三元组 分析联系性、人群和中心性
Mahout机器学习平台:
从大型XML字段中提取元数据块、
机器学习领域信息、
输入流式传输到Hadoop文件系统(HDFS)、
Map-Reduce框架
 


B. Amazon Neptune

Amazon Neptun是亚马逊的图数据库,应用于亚马逊云计算。 下表是Amazon的数据库服务:

数据库类型 使用案例 AWS服务
关系 传统应用程序、ERP、CRM、电子商务 Amazon Aurora、Amazon RDS、Amazon Redshift
键值 高流量web应用、电子商务系统、游戏应用程序 Amazon DynamoDB
内存 缓存、会话管理、游戏排行榜、地理空间应用程序 Amazon ElastiCache for Memcached/Redis
文档 内容管理、目录、用户配置文件 Amazon DocumentDB
宽列 用于设备维护、队列管理和路线优化的大规模工业应用程序 Amazon Managed Apache Cassandra Service
图形 欺诈检测、社交网络、建议引擎 Amazon Neptune
时间序列 Iot应用、开发运营和工业遥测 Amazon Timestream
分类账 系统记录、供应链、注册、银行事务 Amazon QLDB

从这里可以大致窥探出图数据库的定位和地位。Amazon的服务是商业化的,也是较为稳定的,它有高性能、高可扩展、高可用性和持久性等等,最重要的,还是安全性。(毕竟是amazon,要可靠稳定很多)

传统数据库一样,neptune支持了传统数据库服务的基本功能:

  • 托管
  • 克隆
  • 监控
  • 修复
  • 快照
  • 批量加载
  • 权限
  • 加密
  • 数据库快照

然后又有其本身的特性:

  • 高性能:高吞吐量、低延迟
  • 支持Gremlin或SPARQL执行强效查询

(感觉还是有些单薄)

3. 查询语言


SQL/Gremlin/Sparql/RDF/Neo4j/Cypher/MonoDB/ElasticSearch

在查询语言方面,传统数据库有统一的SQL,但是图数据库在这方面,极度分裂,颇有五代十国的气势,然后作为平民老百姓的我们身如浮萍。

我们举一个例子来说明(明确地说,这里我是copy大佬的博文,然后我发现那篇博文也是copy的,然后我没有找到原版在哪儿~~~为原创默哀1秒钟)

问题:非洲国家的首都有哪些?

建两张表,一张表记录国家和洲;另一张表记录国家的具体情况

Table:continent type comment
id int 一般是自增的id,本应用中无意义
country_id int 国家id,外键
name varchar 洲的名字
Table:country type comment
id int 自增的id,表国家的id
capital varchar 国家的首都
name varchar 国家的名字

传统SQL是这样的

SELECT
   country.capital 
FROM
   continent 
   JOIN
      country 
      ON continent.country_id = country.id 
WHERE
   continent.name = 'Afica'

(感觉原例子给出的表是有问题的:应该是洲表中,一个记录表示一个洲,然后再国家表中记录洲id,但这里为了下面的举例,我没有作改变,只是强行理解)

  • SPARQL:面向RDF(Resource Description Framework)的三元组数据,W3C标准,无schema,在研究中应用非常广泛。SPARQL的查询与RDF是一致的,RDF是图,SPARQL查询是子图匹配。

SPARQL是这样的

PREFIX ex: <http://example.com/exampleOntology#>
SELECT ?capital
       ?country
WHERE
  {
    ?x  ex:cityname       ?capital   ;
        ex:isCapitalOf    ?y         .
    ?y  ex:countryname    ?country   ;
        ex:isInContinent  ex:Africa  .
  }

  • Gremlin:数据以属性图的形式存在,可以认为是上面两种的混合体,属性仍然在表中,但是联接关系是直接以链接(比如指针)的形式存在的。查询的本质是图遍历,擅长解决求图的直径、点到点之间的路径,比如刘德华连接奥巴马需要几度关系。

Gremlin是这样的

g. --graph start , always!!
  V().has('continent', 'name', 'Afica') --The continent node,which name is Africa
  .out('capital') --Instead of an id foreign key, it just added a capital edge
  .values('name') --take the name of the country node

参考链接


1.维基百科:图数据库
2.跨越鸿沟——图数据库查询语言的八个先决条件
3.Amazon Neptune
4.Allegro Graph

字数:4858     

赞助我

一饮一啄 / 皆为因果
WeChat 微信
Alipay 支付宝

评论区