图数据模型：选型的第一道门槛

图数据模型，说白了就是你用什么方式把业务里的实体（节点）和关系（边）存到图数据库里。

主流的就两种：属性图模型（Property Graph Model） 和RDF图模型。

这两种模型思路完全不同，选错了后面会很痛苦。我自己就在一个知识图谱项目里踩过这个坑——一开始想省事用RDF，结果发现查询性能怎么都上不去，最后不得不重写数据模型。

属性图模型：我习惯叫它“轻量级选手”

属性图是Neo4j、JanusGraph、TigerGraph这些图数据库的核心模型。你想想看，一个实体，属性直接挂上去，是不是比拆成三元组更直观？

• 节点（Vertex）：可以带任意多个键值对属性。
• 边（Edge）：也带属性，而且必须有一个标签（Label）表示关系类型。
• 遍历（Traversal）：通过指针直接从一个节点跳到相邻节点，速度快到飞起。

举个例子，我要存“张三”这个人的信息：

{
  "label": "Person",
  "properties": {
    "name": "张三",
    "age": 28,
    "city": "北京"
  },
  "edges": [
    {"label": "KNOWS", "target": "李四", "properties": {"since": 2020}}
  ]
}

嗯，这种格式，做开发的兄弟一眼就能看懂。属性直接挂在节点上，查询时不用做额外的关联操作，性能优势很明显。

属性图的优点：

• 查询性能高：边是物理指针，遍历时走内存指针，速度极快。
• 建模灵活：模式不强制，可以随时加属性。
• 适合事务型（OLTP）场景：比如实时推荐、社交图谱、欺诈检测。

属性图的缺点：

• 标准不统一：各家接口语法不太一样，迁移成本高。
• 不适合大批量结构化查询：比如做复杂的数据联合分析。
• 没有内置推理能力：你需要自己写逻辑处理数据间的隐含关系。

RDF图模型：语义网的老祖宗

RDF（Resource Description Framework）来自语义网领域。它的核心思想是万物皆可表示为三元组：

（主语，谓语，宾语）

举个例子：张三（主语） 知道（谓语） 李四（宾语）。

所有数据都被打散成这种最小的原子单元，然后通过SPARQL语言去查询。

我最初接触RDF时，觉得这东西太碎了。一个简单的人物信息，在属性图里一个节点搞定，在RDF里可能要拆成七八个三元组：

<张三> <名字> "张三" .
<张三> <年龄> 28 .
<张三> <所在城市> <北京> .
<北京> <城市名称> "北京" .
<北京> <省份> <河北省> .
...

是不是很啰嗦？但这么做的好处是——数据互操作性极强。

RDF的优点：

• 语义丰富，适合做知识图谱和本体推理。
• 数据天然可链接，不同数据集可以相互引用（Linked Data）。
• 查询语言SPARQL是W3C标准，易上手，迁移成本低。

RDF的缺点：

• 查询性能慢：三元组的存储结构让遍历变慢，特别是多跳查询。
• 数据膨胀严重：做个JOIN查询要处理大量中间结果。

一张图看懂两种模型的区别

下面这张SVG图展示了一个简单的“张三认识李四，张三28岁，李四25岁”的场景，分别用属性图和RDF的方式建模。

优缺点深度对比

我这里有个表格，把两种模型的主要差异列了出来，你对比着看会更清楚：

维度	属性图模型	RDF图模型
存储结构	节点+边（均带属性）	三元组（主语-谓语-宾语）
查询语言	Gremlin、Cypher、GQL（未完全标准）	SPARQL（W3C标准）
互操作性	较低，不同产品接口差异大	高，可跨数据集链接
推理能力	弱，需自行实现	强，支持OWL、RDFS本体推理
OLTP性能	强，单次遍历时间非常短	弱，多跳查询耗时长
典型应用	社交网络、实时推荐、欺诈检测、主数据管理	知识图谱（如Wikidata）、数据湖链接、生物医学图谱

怎么选？给个自用的决策思路

我自己做选型时，会问自己三个问题：

1. 我需要频繁做图遍历吗？（例如：找某人的朋友的朋友的朋友）
   如果“是”，选属性图。
2. 我的数据需要跨系统集成吗？（例如：我的图和另一个机构的知识图谱联合查询）
   如果“是”，选RDF。
3. 我需要做本体推理吗？（例如：自动推导出“所有哺乳动物都是动物，猫是哺乳动物，所以猫是动物”）
   如果“是”，选RDF。