第一期w3：知识存储

知识存储解决如何管理大量的结构化数据。我们可以用不同的数据库工具。现代的关系数据库可能可以解决大多数需要知识图谱的场合。某些特殊场合，我们需要图数据库。

当我们经过知识提取得到了结构化的数据，并选择了适当的知识表现语法后，下一步就是如何持久化存储这些数据。这里我们不讨论高大上的T级别、P级别的“企业级”知识存储。实际情况是，很少有真正的“知识图谱”能达到那种规模——肯定有，但是绝大多数人是遇不到的。大多数情况下，我们只需要几G、几十G、几百G规模的数据，甚至更少，纯内存处理都可以。不需要去想“大数据”问题。

在一些场合，我们甚至不需要数据库做这些事情。如果你的数据只需要按“key”来查找而不是按值查找，也不需要“join”，那用文件系统就可以做数据后端。不过由于太多的小文件会影响查询效率，可能需要把key做哈希，并把头几个字符拿出来分子目录。这种做法并不少见。

稍稍复杂的处理是把key放在redis这样的键值数据库里来管，把具体的数据还是放在文件里。这可以综合数据库和文件系统的优点。

更复杂的情况下我们需要更其他的数据库。主要有三种选择：带JSON扩展的关系数据库、图数据库和RDF数据库。我强烈推荐用带JSON扩展的关系数据库。

知识链接的方式：字符串、外键、URI

知识图谱之所以是图谱，是因为一些节点会被另一些节点“引用”。各种数据库有不同的引用方式，会有不同的成本和收益。

上面我们说到用“key”做数据查找，就是按“字符串”来引用数据的例子。有一些用redis实现的图数据库，其实就是这种方法。字符串可读性很好，实现成本最低，但可能会出现歧义的情况。如果能把歧义控制在可接受的范围内，字符串是很不错的选择。

在关系数据库里我们可以用“外键”来关键数据。其实这也是一种很灵活的方式，可以在一个context下面解释一个“key”，很容易扩展。

URI是语义网的思路，在整个web的context下来解释一个字符串，也就是URI网络资源定位。好处是数据互联性好，坏处是可读性不好，扩展性不好，和现有技术栈差别太大，最终实施成本很高。

如果我们有很好的“entity resolver”（实体解析器），那字符串就是很好的工程选择。没有的时候，关系数据库的外键也是不错的

PostgreSQL及其JSON扩展

关系数据库 + JSON 是最好的（小规模）知识图谱存储选择。可用工具多、稳定性好、速度快、可join、容易演化。

优先推荐使用PostgreSQL 9.3以后版本，直接支持JSON https://www.postgresql.org/docs/9.4/static/datatype-json.html

用Psycopg包操作PostgreSQL http://initd.org/psycopg/docs/

建议玩下这里面说的例子，试试写几个JSON查询的例子 http://initd.org/psycopg/docs/usage.html

PostgreSQL FDW 外部数据通道也值得看看

• https://yq.aliyun.com/articles/53760

不推荐使用mongodb做知识图谱存储，因为它缺少“join”。知识如果没有链接就不是知识了。

图数据库 Neo4j和OrientDB

绝大多数情况下，我们只需要短程关系（两层以下）的查询。某些应用会需要更长程的甚至不定长度的关系查询，这时候可能就需要图数据库了。

Neo4j 是目前用的最多的图数据库

• https://neo4j.com/
• Python接口 https://neo4j.com/developer/python/

两个查询语言

• Cypher https://neo4j.com/developer/cypher-query-language/ Neo4j自己的查询语言，更符合图的特点
• Gremlin http://gremlindocs.spmallette.documentup.com/ 图数据库的“标准”查询语言

Neo4j可以方便一些图的可视化。

我个人最喜欢的是OrientDB，我认为完美达到我需要的知识图谱数据库的基本功能要求 1）用类SQL查询语法，降低学习成本 2）直接读写JSON，方便和Web API导入导出 3）支持图的遍历和gremlin查询 4） 支持blueprints标准 5）部署简单 6）还在积极维护

OrientDB

• http://orientdb.com/orientdb/
• pyorient 二进制Python接口 https://github.com/mogui/pyorient
• compass HTTP Python接口 https://github.com/emehrkay/Compass 项目已经停止维护了，不过还能用

OrientDB的查询语言就是SQL，加一些图的扩展，非常容易入手。

但是OrientDB性能调优需要比较多的经验，由于用的人比neo4j少，出现问题不太容易解决。

排名上，去年11月图数据库的排名是

 21 Neo4j （图）
 32 MarkLogic （XML，RDF）
 42 Titan （图）
 46 OrientDB （图，文档）
 61 Virtuoso （RDF，关系等）

半年后的今天是 http://db-engines.com/en/ranking

 21 Neo4j （图）
 33 MarkLogic （XML，RDF）
 44 Titan （图）
 41 OrientDB （图，文档）
 76 Virtuoso （RDF，关系等）

OrientDB保持上升势头 （2013年的时候OrientDB排名是80， Neo4j那时候24 http://weibo.com/1932835417/A07hewQIZ ）

我的两篇旧文

• 2012-12-03 关于Graph Database http://baojie.org/blog/2012/12/03/graph-databas/
• 2014-02-20 图数据库2013 http://baojie.org/blog/2014/02/20/graph-database-2013/

RDF数据库Stardog

如果需要查询RDF，或者某些SPARQL比SQL更好使的场合，试试Stardog

• http://stardog.com/

一个不错的SPARQL教程

• http://www.cambridgesemantics.com/semantic-university/sparql-by-example

不推荐用Virtuoso， Sesame，Jena这些。都是上一代的老产品，复杂不好用。

Stardog也支持图数据库查询语言Gremlin

作业

用PostgreSQL存储自己的电子邮件JSON

线下聚会的时候带笔记本来实战。

知识图谱学习小组第三次线下活动：

• 特邀嘉宾：段清华，文因互联，讲解PostgreSQL的JSON插件
• 课件与资料：PPT与相关代码