知识图谱的核心是由实体、关系和属性组成的三元组结构，实体代表现实中的具体事物或抽象概念，关系描述实体之间的关联，属性则补充实体或关系的特征信息。要让这些结构能够被高效存储和查询，存储方案的选择至关重要。Neo4j作为目前应用最广泛的原生图数据库，其底层存储模型从设计之初就适配图结构数据，不需要像关系型数据库那样通过复杂的表关联来模拟实体间的关联，因此成为了知识图谱实体关系存储的首选方案。
Neo4j存储实体关系的基础模型
Neo4j的存储模型中，最核心的两个概念是节点（Node）和关系（Relationship），刚好对应知识图谱中的实体和关系。节点用来存储实体，每个节点可以有一个或多个标签（Label），标签相当于实体的分类，比如人物、地点、组织等，同时节点可以附带多个属性（Property），属性以键值对的形式存在，用来存储实体的具体特征，比如人物的姓名、年龄，地点的经纬度等。关系则用来连接两个节点，是有方向的，每个关系也有一个类型（Type），比如“出生在”“任职于”“位于”等，关系同样可以附带属性，用来描述关系的具体特征，比如任职的开始时间、关系的置信度等。
这种模型和知识图谱的三元组结构完全匹配，一个三元组“实体A-关系R-实体B”在Neo4j中就可以存储为一个标签为A类型、带A属性的节点，一个标签为B类型、带B属性的节点，以及一条从A节点指向B节点、类型为R、带R属性的关系。不需要额外的关联表，也不需要外键约束，所有关联都通过关系直接体现，读取时只需要沿着关系的方向遍历就能拿到关联的实体，不需要做表连接操作。
比如我们要存储“张三毕业于北京大学”这个三元组，在Neo4j中可以先创建两个节点，一个标签为“人物”，属性包含name: "张三", age: 25；另一个标签为“学校”，属性包含name: "北京大学", rank: "985"。然后创建一条从“张三”节点指向“北京大学”节点的关系，类型为“毕业于”，属性可以包含degree: "本科", year: 2023。整个存储过程只需要三次操作，不需要预先建表，也不需要定义表结构，灵活性非常高。
实体关系存储的具体操作步骤
在实际项目中，我们通常会使用Neo4j的Cypher查询语言来完成实体和关系的创建、存储操作。Cypher是Neo4j专用的声明式图查询语言，语法接近自然语言，很容易理解。创建单个实体节点可以使用CREATE语句，比如创建上面提到的人物节点，语句如下：
CREATE (p:人物 {name: "张三", age: 25})
RETURN p
这条语句中，括号内的p是节点的变量名，冒号后面的“人物”是节点的标签，大括号里的是节点的属性键值对，RETURN p表示返回创建的节点。如果要同时创建两个实体和它们之间的关系，可以使用更简洁的语句，比如创建“张三毕业于北京大学”的三元组：
CREATE (p:人物 {name: "张三", age: 25})
-[:毕业于 {degree: "本科", year: 2023}]->
(s:学校 {name: "北京大学", rank: "985"})
RETURN p, s
这里的中括号部分就是关系的定义，冒号后面是关系类型，大括号里是关系属性，箭头表示关系的方向，从p指向s。如果需要批量导入大量的实体和关系，比如从已有的CSV文件或者知识抽取结果中导入，可以使用Neo4j的LOAD CSV功能，这个功能可以高效读取外部文件数据，批量创建节点和关系，比逐条执行CREATE语句效率高很多。比如我们有一个包含人物和学校对应关系的CSV文件，路径为C:\data\graduate.csv，内容包含person_name, school_name, degree, year四个字段，批量导入的语句如下：
LOAD CSV WITH HEADERS FROM "file:///C:\data\graduate.csv" AS row
MERGE (p:人物 {name: row.person_name})
MERGE (s:学校 {name: row.school_name})
MERGE (p)-[:毕业于 {degree: row.degree, year: row.year}]->(s)
这里的MERGE语句和CREATE的区别是，MERGE会先检查数据库中是否已经存在满足条件的节点或关系，如果存在就不会重复创建，避免导入数据时产生重复实体，非常适合批量导入场景。如果是第一次导入，也可以用CREATE，但如果有重复数据的话就会产生冗余节点，一般推荐用MERGE来保证数据唯一性。
存储方案的对比与优化建议
很多人会疑惑，为什么不直接用MySQL这类关系型数据库存储知识图谱的实体关系？我们可以对比两种方案的差异。用关系型数据库存储的话，通常需要至少三张表：实体表（存储所有实体的ID和属性）、关系类型表（存储所有关系的类型）、关系表（存储关系的起始实体ID、结束实体ID、关系类型ID和关系属性）。查询“张三的同学”这样的多跳关系时，需要先查张三的毕业学校，再查这个学校的所有毕业生，再过滤掉张三本人，需要两次表连接操作；如果要查二度同学，就需要更多次连接，查询性能会随跳数增加急剧下降。而Neo4j存储时，只需要沿着“毕业于”关系找到学校节点，再反向遍历所有“毕业于”这个学校的节点就能拿到结果，不需要任何表连接，查询速度会快很多。
当然Neo4j的存储也不是完全没有优化空间，在实际存储知识图谱的实体关系时，有几个常见的优化点。首先是标签和属性的索引，Neo4j默认不会对节点的属性建索引，如果经常需要根据属性查询节点，比如根据姓名查人物节点，就需要给对应标签的属性建索引，否则会全图遍历，速度很慢。比如给人物标签的name属性建索引的语句是：
CREATE INDEX person_name_index FOR (p:人物) ON (p.name)
其次是关系的方向设计，Neo4j的关系是有向的，设计的时候要根据查询场景确定方向，比如“毕业于”关系从人物指向学校，那么查“某学校的所有毕业生”就很方便，但如果经常需要查“某人所在的学校”，这个方向也刚好适配，不需要反向查询。如果有些关系是双向的，比如“结婚”，可以创建两条方向相反的关系，或者只在关系属性里标记双向，根据查询频率决定。另外，对于知识图谱中大量的实体，如果有些实体属于同一大类，比如都是地点，可以给它们统一加一个父标签，方便后续做分类查询。最后要注意节点和关系的属性不要存储过多无用信息，属性过多会增加存储开销，也会影响遍历速度，只存储查询和分析需要用到的属性即可。