本系列博文用于记录《Neo4J权威指南》[1]的学习过程

1. Neo4J Introduction 图数据库基础

1.1 图数据库的产生背景

里程碑事件

  • 1962年,出现Database一词
  • 1970年,IBM公司的Edger Frank Codd发表了”A Relational Model of Data for Large Shared Daya Banks”的,论文,奠定了关系模型的理论基础,被誉为”关系型数据库之父”, 并获得1981年的图灵奖。
  • 1974年,IBM公司创建了RDBMS System R原型
  • 1983年,IBM公司发布了其第一款自主研发的关系型数据库DB2
  • 1995年,瑞典MySQL AB公司发布了第一款开源关系型数据库MySQL
  • 1998年,James Gray 因在数据库和事务性处理方面的突出贡献获得图灵奖
  • 2005年,受Google公司的Map、Reduce和Google File System的启发,Apache基金会所开发的分布式系统基础架构Hadoop发布
  • 2007年,Neo4J公司推出第一商用NoSQL图数据库
  • 2009年,分布式文件存储数据库MongDB发布
  • 2010年,Hbase发行,采用列式存储而非行式。
  • 2013年,被称为“大数据元年”,“数据即资源”受到广泛认可

关系型数据库与非关系型数据库

非关系型数据库简易对比

分类 数据模型 优势 劣势 应用场景
键值数据库 散列表 查找速度快 数据无结构化,通常只被当作字符串或者二进制数据 内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统
列存储数据库 列式数据库架构 查找速度快,支持分布横向扩展,数据压缩率高 功能相对没有很丰富,受限 分布式文件系统
文档型数据库 键值对扩展 数据结构要求不严格,表结构可变,不需要预定义 查询性能不高 web应用
图数据库 节点和关系组成的图 利用图的机构和相关算法 可能需要对整个图做计算,不利于图数据的分布式存储 社交网络,推荐系统,意向图,消费关系图,兴趣图

图数据库的发展

1.2 图数据库基础

1.3 图数据库与关系数据库的对比

关系型数据库的弊端

  • 外键约束来实现表与表之间的关系
  • 多对多关系需要中间表来保存两张表外键的对应关系
  • 搜索,匹配计算是计算密集型,内存密集型

图数据库模型的优势

1.4 图数据库与其他NoSQL数据库的对比

1.5 Neo4J概述

1.6 Neo4J体系结构

传统数据图更加注重实体内部的属性,实体与实体之间的关系主要通过外键来实现。在查询实体的关系时需要join操作,尤其是深层次的关系查询时需要大量的耗时的join操作。随着现实世界数据量的急剧增加,以及数据分析行业的发展,关系变得尤其重要。特别是海量数据,深层次关系,需要大量的数据库表操作,运算复杂度进一步提升。而图数据库则非常适合这样的场景。

免索引邻接

Neo4j的重要特点使用了免索引邻居接属性,来保证关系的查找速度。每个节点都会维护与它相邻节点的引用,比使用全局索引代价要小很多。查询时间与图的整体规模没有关系,只与附近节点的数量呈正比。

免索引邻接对关系型数据库的查询做了两个改进:

  • 免索引邻接使用遍历物理关系的方法查找,比全局索引来说代价要小很多。查询一个索引一般的时间复杂度为O(log(n)),而遍历物理关系的时间复杂度仅为O(1)
  • 当索引建立后试图反向便利时,建立的索引就不起作用了。一般会对反向遍历场景创建反向查找索引,或者使用原索引暴力查找。这都会影响时间和空间的复杂度。

Neo4j底层存储结构

Neo4j底层存储结构的设计实现了免索引邻接。

宏观来讲,Neo4j只有两种数据类型:

  • 节点 (Node)
    • 类似E-R图中的实体
    • 每个节点可以有多个属性(Property),以键值对的形式存在
    • 每个节点可以有多个标签用于区分不同类型的节点
  • 关系 (Relationship)
    • 一个关系有起始节点和终止节点
    • 多个键值对的属性
    • 唯一的类型

几个问题

原生(Native)图数据库是怎样存储数据的?

在某些方面,图数据库就像新一代的关系数据库,但图数据库提供对“ 关系”的最高级别支持,而传统关系型数据库则通过外键表示隐含的关系连接 。 图数据库模型中的每个节点(来自实体或属性)直接在物理存储上包含一系列关系记录,这些记录表示该节点与其他节与其他节点的关系。 这些关系记录按类型和方向进行组织 ,并可以包含其他属性。

在图数据库中,无论何时运行类似JOIN的操作,数据库都会使用 此列表并直接访问连接的节点,而无需进行昂贵的搜索和匹配计算。 这种将关系预先物理存储在数据库中的能力使得像Neo4j这样的图 数据库能将查询性能由原先的数分钟提高到数毫秒,特别是对于JOIN频 繁的查询,这种优势更加明显。由此产生的数据模型比使用传统关系数 据库或其他NoSQL数据库生成的数据模型要简单得多,而表现力更强。

怎样将关系模型转换到图模型?

将一个关系数据库的模型转换为图数据库模型,可以通过以下步骤来进行:

  • 每个实体表(Table)由节点(Node)上的标签(Label)表示;
  • 实体表中的每一行(Record)都是一个节点;
  • 这些表上的列成为节点的属性(Property);
  • 删除技术主键,但保留业务主键;
  • 为业务主键添加唯一性约束,并为需要频繁查找的属性添加索引;
  • 将外键转换成节点间的关系(relationship),然后删除它们;
  • 删除存储默认值为NULL的属性,因为不需要存储这些数据;
  • 扁平化(Denormalized)和重复的表数据需要提取出来成为单独的节点,以得到更清晰的模型;
  • 一些列需要被定义成数组类型的属性,例如email1,email2,email3;
  • 连接关系表(通常用来描述多对多关系)中的每条记录转换为关系,并且这些表上的列成为关系的属性。

为什么不用SQL实现对图的查询操作?

在谈到数据库查询语言时,语言效率很重要。 使用SQL查询关系数据库很容易。作为一种声明式查询语言,SQL允许在 数据库工具中轻松地进行随机的查询,或者在应用程序代码中指定与用例有关 的查询。即使是对象关系映射也可以使用底层的SQL与数据库通信来实现。

但是,在试图浏览关联的数据时,SQL遇到了主要的性能瓶颈。对于数据关联类查询问题,SQL查询语句会比实现同样功能的Cypher查询语句多出很多行。 冗长的SQL查询不仅需要更多的时间来运行,而且由于其复杂性,它们也更可能包含人为的编码错误。另外,较短的查询简化了整个开发团队的理解、 提高了维护的便利性。

必须指出的是,查询语言不仅仅是要求(即查询)数据库中的一组特定结果,它也影响数据建模结果的首要原因。 图数据库的数据建模就像连接白板上的圆点一样简单。在白板上草拟的内容就是在数据库中存储的内容。 就其本身而言,这种建模简单性有许多实际的好处,其中最明显的是业务用户可以了解数据库开发人员实际创建的内容。更重要的是:使用正确的查询语言构建的直观模型,可确保构建数据模型的方式与分析方式之间不存在任何不匹配。

Neo4j的Cypher查询语言

就像SQL是关系数据库的标准查询语言一样,Cypher是一种开放的、多供应商支持的图查询语言。 openCypher项目的出现扩大了Cypher的覆盖范围,使其获得接受的程度远远超过了其最初的创造者Neo4j。 Cypher也是一种声明式查询语言,它建立在SQL的基本概念和子句之上,但增加了图特有的功能,使得在应用 到含义丰富的图模型时,查询语句不会过分冗长。

Cypher旨在让开发人员、数据库专业人士和业务领域专家都能轻松阅读和理解查询逻辑。它很容易使用,因为它与我们使用图直观地描述关联数据的方式相匹配。 由于查询结果以直观的可视化方式表达,Cypher的查询可以保持简洁并让开发人员专注于领域概念。

Cypher的基本概念是允许在数据库中查找与特定模式匹配的数据。通俗地说,可以要求数据库“找到像这样的东西”。而描述“类似这样的东西”的方式,使用特定的ASCII符号。

下面是使用Cypher语言来描述的朋友关系:

(emil:Person {name:'Emil'}) <-[:KNOWS]-(jim:Person {name:'Jim'}) -[:KNOWS]->(ian:Person {name:'Ian'}) -[:KNOWS]->(emil)

其中括号()中的内容是节点及其标签,其中花括号{}中则包含了节点的属性。方括号[]中是关系类型名,以冒号:后的内容表示。关系名左右的减号和大于号>或小于号<则代表关系的方向。

参考

  1. Neo4j 权威指南.清华大学出版社[引用日期2017-09-13]

本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!

RANSAC 算法介绍 上一篇
Golang使用Redis 下一篇