分布式图库系列—— 图模型和 Cypher

我是做图数据库内核开发的，而市面上靠谱的中文图数据库资料相对较少，因此结合我的一些经验和网上一些英文材料，新开了一个图数据库系列。本篇主要分为两部分，第一部分讲图模型的概念和挑战，第二部分讲 Cypher 的基本语法。

图数据模型的概念和挑战

图数据模型是一种对数据进行建模的方式。当下图数据模型中用的最多的建模方式是：属性图（Property Graph）。本文会探讨下属性图模型的基本概念和所面临的一些挑战。

属性图主要包括三种元素：点（Node），边（Edge），和属性（Properties），其联系是：

1. 用点和边表达拓扑关系。
2. 在点和边上附着属性来存储数据。

当下最流行的图查询语言是 Cypher[1]，Cypher 和图模型的概念关系，就如如 SQL 和关系模型间的关系。在点边之外，Cypher 引入了对点和边的标记（Label）。

下面，从学术角度，重新梳理一遍这几个元素的关系，并继续给出一些图中需要、但主流图查询语言还没有的元素。

Labeled Graph Data Model

基本的图数据模型：

Labeled Graph Model

从上图可以看出其基本特点是：

• 有向（directed）图
• 点（nodes）和边（edge）都是实体（entities）
• 实体可以有标记（label）

Property Graph Data Model

属性图数据模型：

Labeled Property Graph Model

其基本特点是：

• 有向（directed）图
• 点（nodes）和边（edge）都是实体（entities）
• 实体可以包含
  1. 标记（label）
  2. 属性名、属性值对（<property, value> pairs）

属性图的一些挑战

市面上现有的图模型基本都是属性图，但在处理图问题上，存在一些挑战。

挑战一：没有可组合性

属性图不是可组合的（composable），所谓可组合性是指，经过查询语句处理返回的数据不再是图。以关系模型对照来看就很容易理解，在关系模型中，一切基于表（也就是关系）：存储数据是按表存，经过查询处理后，返回的结果仍然是表。

但在属性图模型中，存储的是图，查询之后返回的却是属性表，或者点边列表。

SQL vs GQL in composable

如果不满足可组合性，坏处有：

1. 不支持视图（子图）和嵌套查询（Sub-queries）。
2. 查询结果失去了原图的表达能力（毕竟不是图了）。

挑战二：不支持原生路径

也即，在属性图模型中，路径（Paths）不是一等公民。就跟传统面向对象的语言中，函数不是一等公民差不多（如：不能作为参数传递）。

由于路径是二等公民，因此没有办法直接返回一个路径，而只能返回以某种形式表达的、组成路径的点集和边集。

由于路径在图模型中非常基础，有大量基于路径查询的需求，如果不原生支持路径，会极大限制图查询语言的表达能力。

挑战三：缺少易处理性

属性图模型很难处理：

1. 对路径进行迭代
2. 返回没有环的路径（即简单路径）
3. 支持针对路径的任意过滤条件
4. 可选的模式匹配

为此 LDBC GraphQL 工作组提出了 G-Core 模型，是一种路径属性图模型。

Path Property Graph Data Model

Path Property Graph Model

其特点是：

• 有向（directed）图
• 路径（paths）、点（nodes）和边（edge）都是实体（entities）
• 实体可以包含
  1. 标记（label）
  2. 属性名、属性值对（<property, value> pairs）

路径是图中连续边组成的序列。

小结

以后有人问你，属性图模型是什么？你就可以说，点边搭架子、属性附其上。

如果他们再问，属性图模型有什么缺点？你可以继续说，没有组合性、不原生支持路径。