图形数据库Neo4J简介.pdfVIP

图形数据库 Neo4J 简介 最近我在用图形数据库来完成对一个初创项目的 支持。在使用过程中觉得这种图形数据库实际上挺有意思的。 因此在这里给大家做一个简单的介绍。 NoSQL 数据库相信 大家都听说过。它们常常可以用来处理传统的关系型数据库 所难以解决的一系列问题。通常情况下，这些 NoSQL 数据 库分为 Graph ，Document ，Column Family 以及 Key-Value Store 等四种。这四种类型的数据库分别使用了不同的数据 结构来记录数据。因此它们所适用的场景也不尽相同。 其中最为特别的便是图形数据库了。可以说，它和其它的一 系列 NoSQL 数据库非常不同：丰富的关系表示，完整的事 务支持，却没有一个纯正的横向扩展解决方案。 在本文 中，我们就将对业界非常流行的图形数据库 Neo4J 进行简单 的介绍。 图形数据库简介 相信您和我一样，在使用关 系型数据库时常常会遇到一系列非常复杂的设计问题。例如 一部电影中的各个演员常常有主角配角之分，还要有导演， 特效等人员的参与。通常情况下这些人员常常都被抽象为 Person 类型， 对应着同一个数据库表。 同时一位导演本身也 可以是其它电影或者电视剧的演员，更可能是歌手，甚至是 某些影视公司的投资者（没错，我这个例子的确是以赵薇为 模板的）。而这些影视公司则常常是一系列电影，电视剧的 资方。这种彼此关联的关系常常会非常复杂，而且在两个实 体之间常常同时存在着多个不同的关系： 在尝试使用关 系型数据库对这些关系进行建模时，我们首先需要建立表示 各种实体的一系列表：表示人的表，表示电影的表，表示电 视剧的表，表示影视公司的表等等。这些表常常需要通过一 系列关联表将它们关联起来：通过这些关联表来记录一个人 到底参演过哪些电影，参演过哪些电视剧，唱过哪些歌，同 时又是哪些公司的投资方。同时我们还需要创建一系列关联 表来记录一部电影中哪些人是主角，哪些人是配角，哪个人 是导演，哪些人是特效等。可以看到，我们需要大量的关联 表来记录这一系列复杂的关系。在更多实体引入之后，我们 将需要越来越多的关联表，从而使得基于关系型数据库的解 决方案繁琐易错。 这一切的症结主要在于关系型数据库 是以为实体建模这一基础理念设计的。该设计理念并没有提 供对这些实体间关系的直接支持。在需要描述这些实体之间 的关系时，我们常常需要创建一个关联表以记录这些数据之 间的关联关系，而且这些关联表常常不用来记录除外键之外 的其它数据。也就是说，这些关联表也仅仅是通过关系型数 据库所已有的功能来模拟实体之间的关系。这种模拟导致了 两个非常糟糕的结果：数据库需要通过关联表间接地维护实 体间的关系，导致数据库的执行效能低下；同时关联表的数 量急剧上升。 这种执行效能到底低下到什么程度呢？就 以建立人和电影之间的投资关系为例。一个使用关联表的设 计常常如下所示： 如果现在我们想要通过该关系找到一 部电影的所有投资人，关系型数据库常常会执行哪些操作呢？ 首先，在关联表中执行一个 Table Scan 操作（假设没有得 到索引支持） ，以找到所有 film 域的值与目标电影 id 相匹配 的记录。接下来，通过这些记录中的 person 域所记录的 Person 的主键值来从 Person 表中找到相应的记录。 如果记 录较