说到人工智能技术，首先会联想到深度学习、机器学习技术;谈到人工智能应用，很可能会马上想起语音助理、自动驾驶等等。实际上，人工智能要在行业中得到应用的先决条件是首先要对行业建立起认知，只有理解了行业和场景，才能真正智能化。简单的说，就是要建立行业知识图谱，才能给行业AI方案。
机器通过人工智能技术与用户的互动，从中获取数据、优化算法，更重要的是构建和完善知识图谱，认知和理解世界，进而服务于这个世界。
那什么是知识图谱呢?
知识图谱
知识图谱本质上是语义网络的知识库，从实际应用的角度出发其实可以简单地把知识图谱理解成多关系图。
那什么是多关系图呢? 回忆在数据结构中的“图”。图是由节点和边来构成，通常用来描述某些事物之间的某种特定关系。图用点代表事物，用连接两点的边表示相应两个事物间具有某种关系，但这些图通常只包含一种类型的节点和边，在IOTA,物联网区块链?一文中就谈到了有向无环图。多关系图一般包含多种类型的节点和多种类型的边。 图的数学基础是图论，本身是应用数学的一部分，在往下大概要涉及到拓扑学的领域了。
在知识图谱里，通常用“实体”来表达图里的节点、用“关系”来表达图里的“边”。实体指的是现实世界中的事物，关系则用来表达不同实体之间的某种联系，实体和关系也会拥有各自的属性。知识图谱的构建是后续应用的基础，而且构建的前提是需要把数据从不同的数据源中抽取出来。数据抽取的难点在于处理非结构化数据，这回涉及到NLP中的相关技术，例如实体命名识别、关系抽取、实体统一、指代消解等等。
知识图谱工程本身还是业务为重心，以数据为中心。不要低估业务和数据的重要性。
知识图谱最重要的核心在于对业务的理解以及对知识图谱本身的设计。要从业务逻辑出发，并且通过观察知识图谱的设计也很容易推测其背后业务的逻辑，而且设计时也要想好未来业务可能的变化。让知识图谱尽量轻量化、并决定哪些数据放在知识图谱，哪些数据不需要放在知识图谱，在于把知识图谱设计成小而轻的存储载体。
知识图谱主要有两种存储方式：RDF和图数据库。它们之间的区别如下图所示。RDF一个重要的设计原则是数据的易发布以及共享，图数据库则把重点放在了高效的图查询和搜索上。其次，RDF以三元组的方式来存储数据而且不包含属性信息，但图数据库一般以属性图为基本的表示形式，所以实体和关系可以包含属性，这就意味着更容易表达现实的业务场景。
那为什么要用图数据库呢? 核心在于“关系”。
重新认识“关系”
关系是指人与人之间，人与事物之间，事物与事物之间的相互联系。
不同事物按着各种不同类型的关系而彼此联系在一起，例如，空间与时间的关系，整体与部分的关系，原因与结果的关系，内容与形式的关系以及遗传关系、函数相依关系、内部关系与外部关系等等。 数据结构中的关系指的是集合中元素之间的某种相关性。关系的运算包括集合的子，交，并，补等等。
在数学中，相关关系是一种非确定的相互依存关系：
- 按程度：完全相关、不完全相关和不相关
- 按影响： 正相关和负相关
- 按形式：线性相关和非线性相关
- 按变量数目：单相关、复相关和偏相关
- ......
事物之间的关系也是复杂的、无限多样的。
在现实生活中，每一个实体都和周围的其他实体有着千丝万缕的关系，这些关系里面所存储的信息甚至要大于实体本身的属性。
但是数据库有很多，为什么需要图数据库呢?关系型数据库和众多的NoSQL为什么不能完全拥有知识图谱的构建呢?
“关系”的数据库存储与表达
世界是由关系组成的，关系型数据库能够处理好关系吗?
关系型数据库
传统的关系型数据库更注重刻画实体内部的属性，实体与实体之间的关系通常都是利用外键来实现，将所有的数据用竖立的堆栈表示，并且保持它们直接的关系，在求解关系的时候通常需要join操作，而join操作通常又是耗时的。常常被优化用于聚合数据，而非高度关联的数据。
互联网尤其是移动互联网的爆发式增长本来就使得传统关系型数据库不堪重负，再加上诸如社交网络等应用对于关系的高需求，关系型数据库显得力不从心。
从应用开发的角度上看，不增加关系型数据库复杂性就不能建模和存储数据和关系。随着关系数量和层次的增加，数据库尺寸的增加，性能降低。当增加新类型的数据和关系的时候，需要重新设计，增加了时间成本，这些导致传统数据库不适用于有实时价值的数据关系。
既然这样，对于高度关联的数据存储与分析就需要求助于NoSQL了。
NoSQL
在NoSQL之于大数据一文中将NoSQL分为了4类：key-value，文档型，列存储和图数据库。
Key-Value模型适合用于简单的数据或者列表。当数据之间不断交互关联时，实际上更需要一张图。文档型NoSQL用来管理文档。在传统的数据库中，信息被分割成离散的数据段，而在文档数据库中，文档是处理信息的基本单位。文档可以很长，可以很复杂，可以是无结构的，与字处理文档类似。一个文档相当于关系数据库中的一条记录。文档型NoSQL用文档进行层次划分，而自由的数据规划也很容易被表示成一颗树。成长为一张图的话，文档之间的关联需要更有代表性的数据结构来存储，列存储的NoSQL也是如此。
从应用开发的角度看，这些NoSQL数据库不处理关系，没有数据结构建模或存储数据关系，没有查询结构支持些数据关系。而且，在应用中连接数据同样需要JOIN操作， 对事务没有 ACID 的支持。
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。
因此，这三种 NoSQL 数据库也不适用于有实时价值的数据关系。
图数据库终于登场，它作为重点描述数据之间关系的数据库应运而生，最适合处理关系，能够制作从简单到到复杂的数据结构且互相连接的数据。图数据库成为了NoSQL中非常重要的一部分。
图数据库
图数据库是基于数学里图论的思想和算法而实现的高效处理复杂关系网络的数据库。图形数据库善于高效处理大量的、复杂的、互连的、多变的数据，计算效率远远高于传统的关系型数据库。
图中每个节点代表一个对象，节点之间的连线代表对象之间的关系。节点可带标签，节点和关系都可以带若干属性。关系可以将节点组织成任意的结构，允许一张图被组织成一个列表，一棵树，一张地图，或者一个复杂的实体。这个实体本身也是由复杂的，关系高度关联的结构组成。
以图数据库Neo4J为例，用 Cypher 创建节点和关系的示意如下：
- CREATE (:Person { Name:“Abel Cao”} )-[:Love]-> (:Person { Name:“Andy Cao”} )
查询也很简单：
- MATCH (:Person { Name:“Abel Cao”} ) -[:Love]-> (:Person { Name:“Andy Cao”} )
一个节点可以从单属性开始，成长为成千上亿，虽然会有一点点麻烦。从某种意义上讲，将数据用关系连接起来分布到不同节点上才是有意义的。对于通过某一给定的属性值来找到节点或者关系，对比遍历图查找，用索引将会更加高效。
用图来存储数据，是最接近高性能的一种用于存储数据的数据结构方式之一。图数据库也有很多，常用且比较闻名的应该是Neo4j了。
图数据库中的Neo4j
图数据库中的 Neo4j 是专为数据关系而生的，模型维护容易，白板模型即物理模型，查询也较简单，表映射关系变成了图关系,使用较少的资源就可以获得较高的性能。
用图来表示社交网络中人与人的关系
实际上，Neo4j最适合一个完整的企业部署或者用于一个轻量级项目中服务器的一个子集，有以下几个显著特特性:
ACID支持
ACID操作是保证数据一致性的基础。Neo4j确保了在一个事务里面的多个操作同时发生，保证数据一致性。不管是采用嵌入模式还是多服务器集群部署，都支持这一特性。
高可用性
图存储可以非常轻松的集成到任何一个应用中。随着应用在运营中的不断发展，性能问题肯定会逐步凸显出来，而Neo4j不管应用如何变化，只会受到计算机硬件性能的影响，而不受业务本身的约束。
轻松扩展
可以扩展到上亿级别的节点和关系，部署一个neo4j服务器便可以承载上亿级的节点和关系。当单节点无法承载数据需求时，可以进行分布式集群部署。通常来讲，对于10亿节点以下规模的图谱来说Neo4j已经足够了。
高速检索
通过Neo4j提供的遍历工具，可以非常高效的进行数据检索，每秒可以达到上亿级的检索量。
Neo4j的用户包括电子港湾、必能宝、沃尔玛、德国汉莎航空公司、思科、惠普、埃森哲等很多知名企业。
Neo4j编程概要
Neo4j是是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎。主要有三种访问Neo4j数据库的方式：
嵌入式
通过指定数据库地址直接访问数据库。
- new GraphDatabaseFactory().newEmbeddedDatabase(DB_PATH);
REST API
通过请求API访问数据库。
- curl -D - -H Accept:application/json "http://neo4j:123456@localhost:8474/db/data/"
JDBC
通过Java API的方式访问数据库。
- DriverManager.getConnection("jdbc:neo4j:123456//localhost:8474/");
人生苦短，我用Python
应用Python完成基于Neo4j的应用，需要从http://py2neo.org/v3/安装py2neo:
- 连接Neo4j
- mygraph = Graph(host='localhost', http_port=8474, https_port=8473, bolt_port=8687, username='Abel_Cao', password='xxxxxx')
- 创建节点和关系
- abel = Node('Person', name='Abel')
- zmx = Node('Person', name='Zmx')
- abel_love_zmx = Relationship(abel, 'Love', zmx)
- graph.create(abel_love_zmx)
- 修改属性
- abel.properties['age'] = 47
- andy.properties['age'] = 17
- abel.push()
- andy.push()
- 查找节点或关系
- abel = graph.find_one(label='Person', property_key='name', property_value='Abel')
- zmx = graph.find_one(label='Person', property_key='name', property_value=’Zmx')
- abel_love_zmx= graph.match_one(start_node=abel, rel_type='Love’, end_node=zmx)
- 删除节点、关系
- graph.delete(alice_knows_bob)
- graph.delete(alice)
- graph.delete(bob)
自定义查询
- cursor = graph.run(Cipher_statement)
Cipher 简要
简单的类比一下，可以把Cipher查询语言理解为SQL语句。
- 删除节点、关系
- MATCH (abel:`Person` {name:"Abel"})-[abel_love_andy:`Love`]->(
- 查找路径
- MATCH p=(abel:`Person` {name:"Abel"})-[]->(andy:`Person` {name:"Andy"}) DELETE p;
- 查找最短路径
- MATCH p=shortestPath((abel:`Person` {name:"Abel"})-[*..5]->(zmx:`Person` {name:"Zmx"})) DELETE p;
Cipher中的其他操作指令包括：
- 删除标签和属性 REMOVE
- 遍历节点 FOREACH
- 过滤条件 WHERE
- 使用索引 START
- 排序 ORDER BY
- 分页 LIMIT SKIP
- 索引 INDEX
- 唯一性约束 UNIQUE
- 聚合函数 COUNT SUM AVG DISTINCT 等等
在Neo4j的集群部署中，一般使用zookeeper来负责neo4j server的心跳检测。
需要注意的是，在 zookeeper master选举期间，write请求不可处理，会直接返回异常，最好在客户端提供一种故障切换的重试机制进行控制。
各种的图数据库
在db-engines.com上，可以看到图数据库的市场排名。
市场有着较大的变化，曾经的记忆好像是这样的：
- AWS使用titan，分布式图形数据库。
- titan不是数据库，而是客户端库，依赖于下面的存储引擎，例如Cassandra或者Hadoop，也依赖于索引引擎，比如Lucene、ElasticSearch或Solr，来执行相关的查询。
- arangoDB支持灵活的数据模型，比如文档Document、图Graph以及键值对Key-Value存储。
- OrientDB的主要特点是支持多模型对象，支持不同的模型，如文档，图形，键/值和真实对象。
- GUN是一个实时的、分布式的、嵌入式图形数据库引擎。
曾经关注的几种图数据库部分属性对比：
由于Neo4j没有缓存层，将无法支持读取QPS量，也不能满足分布式巨量数据存储的需要。许多大厂都有着自己图数据库，例如百度就开源了他的HugeGraph，可以存储海量的节点对象和复杂的关系。
图数据库的应用
对于在数据捕获设计之后，追求数据驱动运营和决策的组织而言，图分析可能是最有效的竞争优势.因此，图形数据库在社交网络、征信系统等诸多领域有着广泛的应用，例如：
- 实时推荐
- 主数据管理：组织架构，社交网络，产品订购，IT网络
- 欺诈检测，合成身份诈骗环
- 基于图的搜索
- IT网络管理
- 身份和访问管理
- 地理信息系统
其中重要的是，图数据库能够将大数据洞察付诸于行动，是构建知识图谱的基石之一，在人工智能极其应用中有着重要的一席之地。
参考资料
https://neo4j.com/developer
https://www.jiqizhixin.com/articles/2018-06-20-4
https://db-engines.com/
Ian，Robinson、Jim，Webber、Emil，Eifrem 著，刘璐，梁越 译 《图数据库(第二版)》，人民邮电出版社，2016
【本文来自51CTO专栏作者“老曹”的原创文章，作者微信公众号：喔家ArchiSelf,id:wrieless-com】
