图数据库与关系型数据库有什么区别？
网友回复
什么是图数据库GDB?
图数据库是一种“不仅仅是 SQL”（NoSQL，全程为Not Only SQL）的数据存储。它们旨在以图结构存储和检索数据。 使用的存储机制可能因数据库而异。一些 GDB 可能使用更传统的数据库结构，例如基于表，然后在顶部有一个图形 API 层。其他的将是“原生”GDB——从存储、管理和查询到数据库的整个构造维护数据的图形结构。许多当前可用的图形数据库通过将实体之间的关系视为“一等公民”来做到这一点。 不同类型的图数据库
广义上有两种类型的 GDB，资源描述框架 (RDF)/三重存储/语义图数据库和属性图数据库。 RDF GDB 使用三元组的概念，它是由三个元素组成的语句：主语-谓语-宾语。 主语将是图中的资源或节点，对象将是另一个节点或文字值，谓词表示主题和对象之间的关系。节点或关系上没有内部结构，一切都由唯一标识符以 URI 的形式标识。 这种结构背后的动机是交换和发布数据。 GDB 属性专注于存储接近逻辑模型的数据的概念。这反过来将基于数据本身所寻求的问题，并专注于使该表示尽可能高效地存储和查询。 与基于 RDF 的图不同，节点和关系上有内部结构，可提供丰富的数据表示以及相关的元数据。 属性图数据库剖析
Neo4j就是一个原生属性图数据库，让我们检查一下主要组件。 属性图数据库的主要组成部分如下： 节点：在图论中也称为顶点——构建图的主要数据元素
关系：在图论中也称为边——两个节点之间的链接。它将有方向和类型。没有关系的节点是允许的，没有两个节点的关系是不允许的
节点和关系
标签：定义一个节点类别，一个节点可以有多个
属性：丰富一个节点或关系，不可以为空值！
标签、类型和属性
图数据库与关系数据库不同
1.存储模型不同
关系型数据库在表中存储信息（行/列）。每个实体都有一个表（如：账户，人员等），在一个实际的应用中，关系型数据库通常会有几十甚至几百张表。在图数据库中，所有的信息存储为点和边的集合，而不是存在二维的表格中。这样每个点和边均可存储一系列属性，见下图：
2.查询模型不同
关系型数据库主要的计算模型是基于扫描行（select），连接行（join），过滤行（filter）等。
而图数据库的计算模型是从一系列的初始点开始，通过多步遍历图形。每一步从当前的节点开始，遵守一定的关联关系（边）到达相邻点。
3.分析模型不同
关系型数据库适合一两个表的简单数据查找以及描述性统计，他不太适用预测性和探测性的分析。例如：你很难编写SQL来回答一下的问题：“这三个用户如何关联？”，“点A和点B之间最短路线是什么？”
而在图数据库中，上述的问题都能得到自然，高效的表达和解决。
4.实时查询性能不同
在关系型数据库中，每个表采用物理分隔的方式存储，因此，建立两个表之间的关联慢而且需要中间表过度。大家都知道表和表之间，是不应该存在多对多的关系的。 一旦有了多对多的关系，是需要增加中间表来应对的。 而图数据库中，关于点的一切都已经有了关联性，因此，查询性能大大提高。
实例分析
我以电影与人为例来描述关系数据库与图数据库的不同
首先我们来看看我们各自数据库的数据模型。与所有数据模型一样，它们的外观最终取决于您提出的问题类型。所以让我们假设我们要问以下类型的问题：
一个人演过哪些电影？
一个人与哪些电影有关？
一个人曾经合作过的所有合作演员是谁？
基于这些，以下是相关的潜在数据模型：
电影图的实体关系数据模型
电影图的属性图数据模型 你会立刻发现一些东西——那些 ID 不见了！因为一旦我们知道那里有连接，我们就将数据连接在一起，我们不再需要它们，或者那些映射表来让我们知道不同的数据行如何连接在一起。 比较查询
现在让我们继续比较一些查询。从:PLAY movies示例中选取一些最初的查询，让我们看一下 Cypher 查询的一些并排比较，以及等效的 SQL 查询是什么样的。 什么是 Cypher，我听到你问？Cypher 是一种图查询语言，用于查询 Neo4j 图数据库。还有一个OpenCypher版本，许多其他供应商都在使用它。 随着我们进行查询，它应该开始变得更加清晰，图数据库以及一种帮助探索关系的查询语言是如何真正开始发挥作用的。让我们开始寻找汤姆汉克斯吧！ 如何找到汤姆汉克斯
Cypher写法
MATCH (p:Person {name: "Tom Hanks"})
RETURN pSQL写法SELECT * FROM person WHERE person.name = "Tom Hanks"
如何找到汤姆汉克斯的电影
Cypher
MATCH (:Person {name: “Tom Hanks”})-->(m:Movie)
RETURN m.titleSQLSELECT movie.title FROM movie INNER JOIN movie_person ON movie.movie_id = person_movie.movie_id INNER JOIN person ON person_movie.person_id = person.person_id WHERE person.name = "Tom Hanks"
如何找到汤姆汉克斯导演的电影
Cypher
MATCH (:Person {name: "Tom Hanks"})-[:DIRECTED]->(m:Movie)
RETURN m.titleSQL
SELECT movie.title FROM movie INNER JOIN person_movie ON movie.movie_id = person_movie.movie_id INNER JOIN person ON person_movie.person_id = person.person_id INNER JOIN involvement ON person_movie.involve_id = involvement.involve_id WHERE person.name = "Tom Hanks" AND involvement.title = "Director"
如何找到汤姆汉克斯的合作演员
Cypher
MATCH (:Person {name: "Tom Hanks"})-->(:Movie)<-[:ACTED_IN]-(coActor:Person)
RETURN coActor.nameSQLWITH tom_movies AS ( SELECT movie.movie_id FROM movie INNER JOIN person_movie ON movie.movie_id = person_movie.movie_id INNER JOIN person ON person_movie.person_id = person.person_id WHERE person.name = "Tom Hanks") SELECT person.name FROM person INNER JOIN person_movie ON tom_movies = person_movie.movie_id INNER JOIN person ON person_movie.person_id = person.person_id INNER JOIN involvement ON person_movie.involve_id = involvement.involve_id WHERE involvement.title = "Actor"
使用 Cypher 进行更多查询
现在，让我们看看您可以在:PLAY movies图表示例中找到的其他一些 Cypher 查询，并解释发生了什么。 没有典型的培根数问题，任何电影图表都是不完整的，我们的电影图表也不例外！ 到目前为止，我们看到的例子每次都遍历一个关系。我们可以轻松地利用这些“写入时连接”来遍历许多关系来回答有趣的问题。 所以，回到凯文培根的数字。以下查询将从 Kevin Bacon 人物节点开始，然后从该起点出发最多 4 跳，以带回所有连接的电影和人物。
MATCH (bacon:Person {name:"Kevin Bacon"})-[*1..4]-(hollywood)
RETURN DISTINCT hollywood我们可以通过使用*1..4查询模式的关系部分的语法来做到这一点： * 表示一切
1..4 表示范围 - 1 表示距离 1 跳，4 表示最多 4 跳
我们可以在这个电影数据集上做的另一件事是两个节点之间的最短路径。
在这个例子中，让我们找出Kevin Bacon 和 Meg Ryan 之间的最短路径。您会发现我们*再次将语法用于关系模式——指示一切。 对您来说可能是新的东西是p=. 您已经看到我们如何使用节点的引用（例如bacon或meg在我们当前的查询中），并且我们可以对关系执行相同的操作。 我们还可以对整个路径（即所有涉及的节点和关系）进行引用。我们为此使用的语法是refName =，在本例中是p=。 我们还使用 Cypher 函数shortestPath()——这是一个简单的最短路径函数，它将返回两个指定节点之间的第一个最短路径。请注意，可能还有另一条同样短的路径，但这个简单的函数只会带回遇到的第一个路径。 对于那些对其他路径相关功能感兴趣的人，请查看 APOC 和 GDS 中可用的功能。
MATCH p=shortestPath(
(bacon:Person {name:"Kevin Bacon"})-[*]-(meg:Person {name:"Meg Ryan"}))
RETURN p给大家一个警告：您可能会看到这一点，[*]并试图在没有shortestPath()函数或1..4范围约束的情况下运行您的图形。但这很可能会导致一些意想不到的事情。 在我们与 Kevin Bacon 和 Meg Ryan 的示例中，即使在这个非常小的数据集中只有 253 个关系，节点和关系之间的所有可能的路径组合也很容易遇到 Bacon 和 Ryan 之间的数百万条不同的路径。 当使用*在你的关系作为查询的一部分，非常谨慎使用！这个问题没有提出最短路径，因为当遇到比当前识别的最短路径更长的潜在路径时，它会立即被丢弃。 一个简单的推荐查询
这里有两个查询真正展示了图形数据库的强大功能，我们可以轻松地使用数据中的连接来提出一些建议。 在我们的第一个查询中，我们正在为汤姆汉克斯寻找新的合作演员，以与他尚未合作的人合作。查询通过以下方式执行此操作： 首先，找到他已经合作过的所有合作演员
然后，找出所有的co-actors的co-actors（简称co-co-actors）
接下来，我们要排除那些已经和汤姆合作过的合作演员，并确保合作演员不是汤姆本人
最后，我们返回建议的合作演员姓名，我们将对其进行排序，但与他们合作的合作演员的数量 - 与该合作演员合作的合作演员越多，建议越好。
MATCH (tom:Person {name:"Tom Hanks"})-[:ACTED_IN]->(m)<-[:ACTED_IN]-(coActors),
(coActors)-[:ACTED_IN]->(m2)<-[:ACTED_IN]-(cocoActors)
WHERE NOT (tom)-[:ACTED_IN]->()<-[:ACTED_IN]-(cocoActors)
AND tom <> cocoActors
RETURN cocoActors.name AS Recommended, count(*) AS Strength
ORDER BY Strength DESC太好了，所以我们找到了一些潜在的合作演员。在下一个查询中，我们想推荐汤姆克鲁斯作为汤姆汉克斯合作的潜在新合作演员。但是，谁来介绍这些汤姆斯呢？回到我们去的电影图表。 在这个查询中，我们找到汤姆汉克斯的合作演员，然后找出哪些合作演员也和汤姆克鲁斯合作过
然后我们将返回合作演员以及他们与汤姆汉克斯和汤姆克鲁斯共同出演的电影
MATCH (tom:Person {name:"Tom Hanks"})-[:ACTED_IN]->(m)<-[:ACTED_IN]-(coActors),
(coActors)-[:ACTED_IN]->(m2)<-[:ACTED_IN]-(cruise:Person {name:"Tom Cruise"})
RETURN tom, m, coActors, m2, cruise
