知识图谱及图数据库 Neo4J vs OrientDB

21世纪技术官导读：

知识图谱是 Google 2012年提出的，目的是利用实体间语义关系优化搜索效果，它可以作为搜索及推荐算法中NLP的基础，完善服务效果。

作者以多年实际经验入手，为大家介绍知识图谱底层当前热门的两个图数据库Neo4j和Orientdb的新版，介绍使用层面二者各自优缺点，让用户可以自行构建知识图谱，选择合适技术方案。

本文主要包括以下4部分内容：

1.知识图谱前世今生
2.Neo4j 及使用
3.Orientdb 及使用
4.Neo4j VS Orientdb
 
1 知识图谱前世今生

知识图谱技术渊源已久，只是在不停地换名字而已——从上世纪70年代的“专家系统（Expert System）”，到万维网之父Berners-Lee提出“语义网（Semantic Web）”，再到他后来提出的“链接数据（Linked Data）”，都是知识图谱的前身。

知识图谱（Knowledge Graph）正式被Google于2012年5月提出，其目标在于改善搜索结果，描述真实世界中存在的各种实体和概念，以及这些实体、概念之间的关联关系。紧随其后，国内外的其它互联网搜索引擎公司也纷纷构建了自己的知识图谱，如微软的Probase、搜狗的知立方、百度的知心。知识图谱在语义搜索、智能问答、数据挖掘、数字图书馆、推荐系统等领域有着广泛的应用。

知识图谱（Knowledge Graph）旨在描述客观世界的概念、实体、事件及其之间的关系。近年知识图谱的升温，是AI对数据处理和理解需求逐日增加所导致的必然结果，而其发展有赖于专家系统、语言学、语义网、数据库，以及信息抽取等众多领域，是一个交叉融合的产物。

图1 搜狗智立方“姚明“关系

如图1为搜狗智立方中“姚明”关系图，知识图谱可以看成是一张巨大的图，图中的节点表示实体或概念，而图中的边则构成关系。在知识图谱中，每个实体或概念都使用一个全局的确定ID来标识，这个ID对应目标的标识符；这种做法与一个网页有一个对应的URL、数据库中的主键相似。归根结底，知识图谱的意义在于在盘根错节的数据海洋中进行梳理和串联，让以前模糊的世界变得更加清晰。

知识图谱离不开存储，就目前而言，知识图谱热门的存储当属接下来要给大家介绍的两个图数据库：Neo4J和OrientDB，二者都有社区版和企业版，这里只给大家介绍社区版，因为企业版都是要收费的（好像程序猿天生对收费有一定排斥）。
 
2 Neo4J及使用
2.1 基本介绍

Neo4j是一个java开发的图数据库，官方地址：https://neo4j.com，当前新relase版：neo4j-community-3.3.1，它将结构化数据存储在网络(从数学角度叫做图)上而不是表中。相对于关系数据库来说，图数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询——在关系数据库中，这些查询会导致大量的表连接，因此会产生性能上的问题。Neo4j重点解决了拥有大量连接的传统RDBMS在查询时出现的性能衰退问题。Neo4j还提供了非常快的图算法、推荐系统和OLAP风格的分析，而这一切在目前的RDBMS系统中都是无法实现的。它提供了广泛使用的REST接口，能够方便地集成到基于JAVA、PHP、.NET和JavaScript的环境里。

Neo4j 是目前流行的图形数据库，支持完整的事务，在属性图中，图是由顶点（Vertex），边（Edge）和属性（Property）组成的，顶点和边都可以设置属性，顶点也称作节点，边也称作关系，每个节点和关系都可以由一个或多个属性。Neo4j创建的图是用顶点和边构建一个有向图，其查询语言cypher已经成为事实上的标准。

2.2 图形查询语言Cypher

“Cypher”是一个描述性的图形查询语言，允许不必编写图形结构的遍历代码对图形存储有表现力和效率的查询。Cypher设计目的是一个人类查询语言，适合于开发者和在数据库上做点对点模式（ad-hoc）查询的专业操作人员。其构念是基于英语单词和灵巧的图解。

Cyper通过一系列不同的方法和建立于确定的实践为表达查询而激发的。许多关键字如like和order by是受SQL的启发。模式匹配的表达式来自于SPARQL。正则表达式匹配实现使用Scala programming language语言。

Cypher是一个申明式的语言。对比命令式语言如Java和脚本语言如Gremlin和JRuby，它的焦点在于从图中如何找回（what to retrieve），而不是怎么去做。这使得在不对用户公布的实现细节里关心的是怎么优化查询。

图2 Neo4J查询实例(Java客户端生成)

图2就Cypher查询由下面实例中Java客户端生成的实体节点及关系图。有关cypher详细介绍和使用可以参考官网：https://neo4j.com/docs/develop ... pher/。
 
2.3 Java客户端使用
1>. Maven引用

2>. Java调用
1）初始化数据图引擎"graphDB"

2）创建实体及关系

如上图所示，利用“graphDb"创建了以我个人家庭成为原型的三个实体节点“firstNode"、“secondNode"和“thirdNode"，并分别为其创建了关系“Father_Son"、“Mather_Son"和“夫妻"，终执行后如图2所示。图中我们可以看到每个实体可以有多个标签，也即实体类型，相当于多个角色。

3）根据实体ID返回紧邻边和节点

如图所示代码，为根据指定实体ID找出该实体紧邻关系相关实体。当然也可以根据方法"findNodes"传递标签名或标签名+属性及属性值具体查找某一类实体列表。
 
3 OrientDB及使用
3.1 基本介绍

OrientDB是用Java语言实现的，运行在JVM之上，其官方地址：http://orientdb.com/，当前新relase版：orientdb-community-importers-2.2.31。OrientDB是个多模型开源NoSQL DBMS，是兼具文档数据库的灵活性和图形数据库管理链接能力的可深层次扩展的文档-图形数据库管理系统。

目前支持Graph, Document, Key/Value, 和Object四种模式，支持许多特性，诸如ACID事务、快速索引，原生和SQL查询功能。可以JSON格式导入、导出文档。若不执行昂贵的JOIN操作的话，如同关系数据库可在几毫秒内可检索数以百记的链接文档图。本节我们主要关注它的Graph模式。

3.2 集群配置
Multi-Master Replication： OrientDB集群部署时每个点都是Master，每个Master上都有完整的数据。一旦一个Master上的数据发生变更，会将发生变更的数据同步通知其它Master。

OrientDB社区版也支持集群模式，主要在{$OrientDB_HOME}/config/hazelcast.xml中调整配置如下：

两个节点先后启动后，后控制台中显示如下图所示：

这样一个由2个节点组成的双Master组成的OrientDB就组建成功了，使用时，不管连接那个节点，操作行为都会自动同步给另一个节点。当然也可以设置一主多从模式。

3.2 查询语法

Extended SQL : OrientDB支持大部分标准的SQL，同时在标准的SQL之上扩展了部分功能以方便图的操作。详细官方介绍：http://orientdb.com/docs/last/SQL.html。 

图3 OrientDB查询实例(Java客户端生成)

上图就OrientDB控制台查询由Java客户端生成的实体节点及关系图。
 
3.3  Java客户端使用
  1>. Maven引用

  2>Java调用
1) 初始化图引擎“graph“

2).创建实体类型及关系类型

OrientDB创建实体或关系前，需要事先存在相应实体类型或关系类型，所以线上使用时应该先根据实际业务需求创建相应实体类型或关系类型。如上图所示，先后创建了实体类型"Person"、"Company"、"Address"和"School"以及关系类型"lives"和"fatherSon"，每个实体类型或关系类型，还可以根据需要设定其具有的属性即属性值类型。

3).创建实体及关系

如上图代码所示，分别创建了实体"vPerson"和"company"以及二者的关系对象"jobs"，还创建了实体"vAddress"、"v1Person"和"school"以及相关关系"eLives"和"fatherSon"及"jiudu"，分别展示使用相关方法的多种情景。其终执行结果如图3所示。

4). 根据实体类型(或再增加属性及属性之)返回相关实体

如上图所示既可以根据实体类型，也可以根据实体类型结合属性集返回相关实体，还可以进一步对返回的每个实体直接关联的相关实体。这样就可以根据一个点遍历完所有与之有直接过间接关系的所有实体。
 
4 Neo4J vs OrientDB

需要说明的是：这里我们只是针对社区版做的比较，从以下多个角度出发：
1>. DBRanks图数据库近年影响趋势：

2>. 是否支持集群： 前者不支持，后者支持，这点对线上运维很重要；
3>. 是否支持多库
    - 前者不支持，后者支持；
    - 前者想支持多库，就需要启动多个实例，通过辅助开发完成；
4>. 标签和实体类型及关系类型认识
    - 前者没有实体类型说法，一个实体可以有多个标签；
    - 后者没有标签说法，一个实体只能有一个实体类型；
    - 前者不需要事先创建标签，后者需要事先创建好实体类型
    - 前者的标签等同于后者的实体类型，现实中一个实体有多个标签或角色更符合实际。
5>. 根据属性查找实体
    - 前者需要限定在某个标签下；
    - 后者不需要限定某个标签，可以直接根据属性及属性值查找实体；
6>. 资源消耗
   - 前者进行了CPU的密集计算，对RAM和硬盘的占用率不高，遍历性能较高，消耗较低，运行比较稳定；
   - 后者侧重文档数据库，主要还是SB树索引导致，空间浪费比较大，遍历性能也较低，使用过程中即使存放内容不大，也经常出现OOM。

综上所述，二者各有其优点和劣势，实际情况根据自己业务需要选择技术方案即可。

作者：王成光（21原网易、一点资讯推荐系统架构师，现中东出海项目首席架构师）

来源：21世纪技术官（21CTO.com）