1. 介绍

1.1 图数据库

功能

图数据库是一个主要表示联系和对联系进行操作的数据库。
与普通数据库相比，图数据库更关注联系，并试图从联系中找到有用信息。

维克托·迈尔·舍恩伯格在《大数据时代》一书中这样写道：“我们没有必要非得知道现象背后的原因，而是要让数据自己发声。”
以及“相关关系能够帮助我们更好地了解这个世界。”他认为，建立在相关关系分析法上面的预测是大数据的核心。
在书中提出的“大数据三原则”：要全体不要抽样，要效率不要绝对精确，要相关不要因果。
-- 或许这些表示联系在大数据时代的重要性，而图数据库正是存储和表示联系的好帮手。

neo4j是一种NoSQL, 下面是各种NoSQL特性对比：

目前业界应用的主流数据库还是关系型数据库，图数据库相比关系型:

图数据库在处理关联关系上具有完全的优势，特别是在我们这个社交网络得到极大发展的互联网时代。例如我们希望知道谁LIKES（喜欢）谁（喜欢可以是单向或双向），也想知道谁是谁的FRIEND_OF（朋友），谁是所有人的LEADER_OF（领导）。除了在关联查询中尤为明显的优越性，图数据库还有如下优势：

• 用户可以面向对象的思考，用户使用的每个查询都有显式语义；
• 用户可以实时更新和查询图数据库；
• 图数据库可以灵活应对海量的关系变化，如增加删除关系、实体等；
• 图数据库有利于实时的大数据挖掘结果可视化。

图数据库虽然弥补了很多关系型数据库的缺陷，但还有一些不足地方，如：

不适合记录大量基于事件的数据（例如日志条目）；

• 二进制数据存储。
• 并发性能要求高的项目。
• 目前相关图查询语言比较多，尚未有很好统一。
• 图数据库相关的一些书籍文档偏少，相关生态还在不断完善。
  图数据与关系数据库相比，在常规查询面前，基本没有特别大的差异，在复杂查询对比中，高下立判，图数据库更加言简意赅，快速满足用户需求。

图模型

目前使用的图模型有3种，分别是属性图（Property Graph）、资源描述框架（RDF）三元组和超图（HyperGraph）。现在较为知名的图数据库主要是基于属性图，更确切得说是带标签的属性图（Labeled-Property Graph），当然标签不是必须的。

是带标签的属性图有如下特征：

• 包含节点和联系
• 节点上有属性(键值对)
• 节点可以有一个或多个标签
• 联系(边)有名字和方向，并总是有一个开始节点和结束节点
• 联系（边）也可以有属性

图领域

可以分为：

• 主要用于联机事物图的持久化技术，通常直接实时被应用程序访问 -- 这类技术被称为图数据库
• 主要用于离线图分析的技术，通常按一系列步骤执行 -- 这类技术被称为计算引擎，常用于数据挖掘和联机分析处理(例如spark的系统组件graphX)

图分析和图查询的区别在于：图分析往往是整张图的操作，而且可能是多次迭代；而图查询只涉及图的一部分，且只需一次。对用户而言最直观的感受是：图分析很慢，图查询很快。

图数据库

是一个使用图结构进行语义查询的数据库，支持对图数据模型的增删改查(CRUD)， 在设计时通常考虑了事务完整性和操作可用性。
图数据库将将节点和联系对简单抽象组装为相互关联的结构，使我们能够建造任意复杂的模型。

图数据库有两个技术特性：

• 图存储引擎：一些图数据库使用原生图存储，另外一些则把图数据库信息保存到关系型数据库中（例如MySQL）或其他数据库中
• 处理引擎：主要指的是通过各种图算法解决大规模分布式图计算问题。大部分的分布式图计算引擎都是基于Google发布的Pregel白皮书
  图本质上是一种递归的数据结构，其顶点的属性值依赖于其邻接顶点，而其邻接顶点属性又依赖于其邻接顶点，许多重要的图算法通过迭代计算每个顶点的属性直到到达定点条件，这些迭代的图算法被抽象成一系列图并行操作。
  大部分图数据库使用 免索引邻接: 每个节点包括它所有边Edge的指针列表，因此避免了查找。

对比

与其他类型数据库对比：

• 关系型数据库不擅长处理数据之间的关系(存储关系方法与图数据库不一样，参见上面的免索引邻接说明)。
  联系仅出现在关系数据库的建模阶段，用于连接表关系；
  传统数据库处理join 查询的性能会随着数据集的扩大而降低； 数据增加后会造成大量表连接、稀疏行和非空检查逻辑，阻碍性能；
  难以响应变化的业务需求。

• 与NoSQL数据库对比
  存储的都是无关联的文档/值/列，很难用于关联数据和图；
  一种添加联系的策略是在某个聚合数据中嵌入另外一个聚合数据标识符，即添加外键，但这需要在应用层连接聚合数据，代价增加；
  聚合没有反向指针，丧失了其他有趣查询能力，例如反向查询关系。

• 在图数据库中，关联数据被存储为关联数据。增加新的节点或联系不影响已有的网络，也不用进行数据迁移 - 原始数据和其意图都保持不变。

优势

• 灵活性: 图的扩展只要增加新的联系、新的节点、新的属性、新的标签、新的子图而不会破坏已有的查询和应用程序功能。
  可以减少数据迁移，从而降低维护的开销和风险。

• 敏捷性: 由于图数据库天生不需要模式，所以可以用更可见、可操作的管理方式。

1.2 建模

和基于关系的建模方式对比

建模过程类似：

• 先建立实体-联系（ER）图
• 然后把角色变成标签，特性变成属性
• 与邻近实体的关系转换为联系
• 为支持快速查找节点，允许用标签和属性组合创建索引，索引是唯一的
• 标签是属性图中的一等公民。

怎么时候使用节点，怎么时候使用联系

• 用节点表示事务，用联系表示结构
• 使用节点表示实体，即我们感兴趣的事物，它们可以被标签和分组。
• 使用联系表示节点间的关联，并为每个实体建立语义上下文，从而建立领域
• 使用有向联系进一步阐明语义联系。属性图中常存在有向联系，原因是联系的不对称性。如果是对称联系应使用一个联系，查询时忽略方向。
• 使用节点属性以及其他任何必要的实体元数据，例如版本号、时间戳等等，来表示实体的属性。
• 使用联系属性以及任何必要的关系元数据，如时间戳、版本号等等，来表达联系的强度、权重、质量。

建模陷阱

1. 电子邮件例子
   邮件中收件人、cc、bcc是联系吗？邮件正文存哪里？
   解决方法除了联系人节点外，另外建立一个email节点。

2. 当有回复或转发时
   回复邮件也是新邮件节点，它与原来的邮件节点有replay联系

3. 避免反模式
   实体不能建模为联系
   应该使用联系表示实体是如何相连的，及这些联系的性质

2. 安装

这里使用 docker 方式运行：

docker pull neo4j

docker方式运行时相关目录:

• /conf
• /data
• /import
• /logs
• /metrics
• /plugins
• /ssl

运行，并且允许ipv4 https访问(必须设置NEO4J_dbms_connectors_default__listen__address 要不默认是ipv6):

docker run -it --rm -d -p 7473:7473 -p 7687:7687 --env=NEO4J_dbms_connectors_default__listen__address=0.0.0.0 -v /home/neo4j/data:/data -v /home/neo4j/logs:/logs --name neo4j neo4j

通过cyper shell执行命令:(auth info: neo4j/neofj)

docker exec -it neo4j bin/cypher-shell

通过web访问(169.254.0.1 is neo4j's host IPv4 address):

https://169.254.0.1:7473/

web 是它的控制界面，在web上面可以执行 cyper shell 指令，可以查看 neo4j 状态
最上面是cyper shell 命令行, 中间是数据库状态，下面是一些常用命令链接:

• "Start Learning": neo4j简单介绍
• "Write Code": 几个图数据库例子代码, 双击代码, 会自动复制代码到上面的 cyper shell, 然后点 cyper shell 右边的运行(三角形按钮)，就可以执行
  中间就会显示结果
• "Monitor": 系统状态

3. 使用

桌面版的 neo4j只支持一个数据库。 如果想清除当前数据库，在 web 左边有 "Clear local data", 或是执行:

MATCH (n) DETACH DELETE n;

CyperSQL语法:

清除数据库

MATCH (n) DETACH DELETE n;

查询数据库(RETURN)

MATCH (n) RETURN n 

MATCH 表示查询条件
RETURN 表示返回的内容
还可以像 SQL 那样加 WHERE

CREATE

create用于创建节点或是联系,创建时指定名字：标签{属性} 标签可以有多个，之间使用：隔开，每个标签也可以也多个属性，都放在{} 内 联系的名字可以省略，联系的两个节点间有方向

建立节点:

CREATE (ee:Person { name: "Emil", from: "Sweden", klout: 99 })

建立节点和边:

CREATE (js:Person { name: "Johan", from: "Sweden", learn: "surfing" }),
(ee)-[:KNOWS {since: 2001}]->(js),(ee)-[:KNOWS {rating: 5}]->(ir),

DELETE

用于删除节点或联系

删除联系：

MATCH (:Person {name: "Emil"})-[r:KNOWS]-(:Person {name: "Johan"}) 
DELETE r

删除没有联系的节点：

MATCH (n:Person { name: "Emil" } ) delete n

删除节点和它所有相关的联系：

MATCH (n:Person { name: "Emil" } ) detach delete n

REMOVE

删除节点或联系的属性或标签

SET

向现有节点或联系添加新属性， 或修改属性值

应用

应用例子

社交网络应用

社交是人与人之间的连接，以图数据模型为内在的图数据库天生适用于明显的以联系为中心的领域。在社交网络中使用图数据库可以方便得识别人/群组和他们交流的事物之间的直接或间接的联系，使用户能够高效地对其他人或事物进行打分、评论、发现彼此存在的关系和共同关系的事情。可以更加直观得了解社交网络中人与人之间如何互动、如何关联、如何以群组的形式来做事情或选择。

实时推荐

在零售、招聘、情绪分析、搜索和知识管理领域，社交网络和推荐引擎可以提供关键的差异化能力，有很多种办法可以实现推荐，但使用图数据库在实时性和效率上有其特有的优势。推荐算法在人和事物之间建立联系，而联系建立的基础是用户的行为，比如购买、生产、消费、打分或评论有关资源等行为。推荐引擎可以识别出某些资源会吸引特定个人或群体，或者某些个人或群体可能对特定资源感兴趣。

一个有效的推荐依赖于对事物之间关联的理解，同时也依赖于这些关联的质量和强度，而属性图是所有这些关系密切、关联紧密的数据结构的最佳表达方式。用图数据库存储和查询这些数据使得应用程序可以为最终用户呈现实时结果，反映数据最新的变化，而不是返回给用户那些预计算的状态结果。

地理空间管理

地理空间类的应用程序包括公路网、铁路网等，地理空间操作依赖于特定的数据结构，简单的加权带方向的联系，复杂到空间索引如R树。和索引一样，这些数据结构天生就以图的形式呈现，尤其是层级结构，非常适合图数据库。

总的来说，通信、物流、旅游已经路由计算相关领域的地理空间应用经常会使用图数据库。

主数据管理（Master Data Managerment）

主数据管理(MDM)包括的数据涉及用户、客户、产品、供应商、部门、区域、站点、成本中心和业务单元等。这些数据来源可能是多种多样的，MDM用来识别、清洗、存储和管理这些数据。其关键问题包括谁组织结构的变化、企业合并和业务规则的变化来管理这些变化；融合新的数据源，用外部源数据补充已有的数据；解决报告需求、鉴定需求和商业智能客户的需求；当数据的值和模式变化时对数据进行版本管理。图数据库的数据模型高效匹配MDM的快速演变和不断变化的业务需求。

网络和数据中心管理

图数据库已经成功地使用在了电信、网络管理和分析、云平台管理、数据中心和IT资产管理以及网络影响分析等领域。在这些领域里，他们将影响分析和问题解决的时间时间从数天数小时减少到了分钟级甚至秒级。面对不断变化的网络模式，图数据库的性能和灵活性都是它适合这些领域应用的重要因素。

授权和访问控制

图数据库可以存储那些复杂的、高度关联的、跨越数十亿参与者和资源的访问控制结构。尤其适用于内容管理、联合授权服务、社交网络偏好已经软件服务化提供。将这些系统从关系型数据库切换到图数据库后，性能从分钟级提升到毫秒级。

其他

还广泛用在金融和保险行业反欺诈、风控，电商和社交类产品防机器人作弊等领域。

其他图数据库

JanusGraph源于Titan，最新版本0.3.1于2018年10月发布，基于Apache 2开源协议，是最有前景的开源图数据库，可支持数十亿级别的顶点和边规模，与Neo4J一样也使用Java开发，由IBM主导并提供云服务。

JanusGraph可以为不断增大的数据和用户量提供了弹性和线性的扩展能力，通过数据多点分布和复制来提高性能和容错能力；支持ACID特性和最终一致性。与Neo4J不同，JanusGraph不是原生的图数据库，相反的，其将数据存储到通用的存储系统上，支持的后端存储包括：Apache Cassandra、Apache HBase、Google Cloud Bigtable和Oracle BerkeleyDB。其中BerkeleyDB一般只做例子演示用。

JanusGraph依托于Apache社区构建了完整的图数据库和图计算能力，通过跟Apache中其他组件相配合，提供了一整套完整的图计算生态系统。其中就包括了Apache TinkerPop所提供的图查询语言Gremlin。