分布式系统中的一致性模型的强弱和之前讲的事物的隔离级别层次有一些共通之处，比如在性能和隔离性/一致性间做取舍。

什么是分布式系统中的一致性？

时钟它为什么又是靠不住的。时钟（clocks）和时间（time）都很重要。

分布式系统中的麻烦事（中）：为什么时钟它不可靠？

我们在这篇文章中探讨了知识图谱，特别是图数据库 NebulaGraph，是如何结合 LlamaIndex 和 GPT-3.5 为 Philadelphia Phillies 队构建了一个 RAG。

7 种查询策略教你用好 Llama Index 和 NebulaGraph 探索知识图谱

分片，Partition，有很多别称。通用的有 Shard；具体到实际系统，HBase 中叫 Region，Bigtable 中叫 Tablet，等等。

DDIA精读｜分布式系统中的副本和分片、KV 分片、分片均衡，以及路由请求

单主模型一个最大问题：所有写入都要经过它，如果由于任何原因，客户端无法连接到主副本，就无法向数据库写入。

DDIA精读｜分布式数据之多副本的主从模型选择

*以下文章来源于木鸟杂记 ，作者穆尼奥*

![几种数据流模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231024-1.jpg)

上文[《性能好的编码如何设计？以常见的编码工具 JSON、CSV 等为例》](https://www.nebula-graph.com.cn/posts/encoding-serialization)中，逐一探讨了如何进行编码、如何进行多版本兼容。

在本篇文章中，会结合几个具体的应用场景：数据库、服务和消息系统，来分别谈了相关数据流中涉及到的编码与演化。

# 数据流模型

数据可以以很多种形式从一个系统流向另一个系统，但不变的是，流动时都需要编码与解码。

在数据流动时，会涉及编解码双方模式匹配问题，上文已经讨论，本文主要探讨几种进程间典型的数据流方式：

1. 通过数据库
2. 通过服务调用
3. 通过异步消息传递

# 经由数据库的数据流

访问数据库的程序，可能：

- **只由同一个进程访问**，则数据库可以理解为该进程向将来发送数据的中介。
- **由多个进程访问**，则多个进程可能有的是旧版本，有的是新版本，此时数据库需要考虑向前和向后兼容的问题。

还有一种比较棘手的情况：在某个时刻，你给一个表增加了一个字段，较新的代码写入带有该字段的行，之后又被较旧的代码覆盖成缺少该字段的行。这时候就会出现一个问题：我们更新了一个字段 A，更新完后，却发现字段 B 没了。

![经由数据库的数据流](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231024-3.png)

## 不同时间写入的数据

对于应用程序，可能很短时间就可以由旧版本替换为新版本。但是对于数据，旧版本的代码写入的数据量，经年累月，可能很大。在变更了模式之后，由于这些旧模式的数据量很大，全部更新对齐到新版本的代价很高。

这种情况我们称之为：**数据的生命周期超过了其对应代码的生命周期**。

在读取时，数据库一般会对缺少对应列的旧数据：

1. 填充新版本字段的默认值（default value）

2. 如果没有默认值则填充空值（nullable）

数据处理后，返回给用户。一般来说，在更改模式时（比如 alter table），数据库不允许增加既没有默认值、也不允许为空的列。

## 存储归档

有时候需要对数据库做备份到外存。在做备份（或者说快照）时，虽然会有不同时间点生成的数据，但通常会将各种版本数据转化、对齐到最新版本。毕竟，总是要全盘拷贝数据，那就顺便做下转换好了。

之前也提到了，对于这种场景，生成的是一次性的不可变的备份或者快照数据，使用 Avro 比较合适。此时也是一个很好的契机，可以将数据按需要的格式输出，比如面向分析的按列存储格式：Parquet。

# 经由服务的数据流：REST 和 RPC

通过网络通信时，通常涉及两种角色：服务器（server）和客户端（client）。

通常来说，暴露于公网的多为 HTTP 服务，而 RPC 服务常在内部使用。

服务器也可以同时是客户端：

1. 作为客户端访问数据库。

2. 作为客户端访问其他服务。

对于后者，是因为我们常把一个大的服务拆成一组功能独立、相对解耦的服务，这就是**面向服务的架构**（service-oriented architecture，SOA），或者最近比较火的**微服务架构**（micro-services architecture）。这两者有一些不同，但这里不再展开。

服务在某种程度上和数据库类似：允许客户端以某种方式存储和查询数据。但不同的是，数据库通常提供某种灵活的查询语言，而服务只能提供相对死板的 API。

## Web 服务

当服务使用 HTTP 作为通信协议时，我们通常将其称为 Web 服务。但其并不局限于 Web，还包括：

1. 用户终端（如移动终端）通过 HTTP 向服务器请求。

2. 同组织内的一个服务向另一个服务发送 HTTP 请求（微服务架构，其中的一些组件有时被称为中间件）。

3. 不同组织的服务进行数据交换。一般要通过某种手段进行验证，比如 OAuth。

有两种设计 HTTP API 的方法：REST 和 SOAP。

- **REST 并不是一种协议，而是一种设计哲学**。它强调简单的 API 格式，使用 URL 来标识资源，使用 HTTP 的动作（GET、POST、PUT、DELETE）来对资源进行增删改查。由于其简洁风格，越来越受欢迎。

- SOAP 是基于 XML 的协议。虽然使用 HTTP，但目的在于独立于 HTTP。现在提的比较少了。

## RPC 面临的问题

RPC 想让调用远端服务像调用本地（同进程中）函数一样自然，虽然设想比较好、现在用的也比较多，但也存在一些问题：

1. 本地函数调用要么成功、要么不成功。但是 RPC 由于经过网络，可能会有各种复杂情况，比如请求丢失、响应丢失、hang 住以至于超时等等。因此，可能需要重试。

2. 如果重试，需要考虑幂等性问题。因为上一次的请求可能已经到达了服务端，只是请求没有成功返回。那么多次调用远端函数，就要保证不会造成额外副作用。

3. 远端调用延迟不可用，受网络影响较大。

4. 客户端与服务端使用的编程语言可能不同，但如果有些类型不是两种语言都有，就会出一些问题。

REST 相比 RPC 的好处在于，它不试图隐去网络，更为显式，让使用者不易忽视网络的影响。

## RPC 当前方向

尽管有上述问题，但其实在工程中，大部分情况下，上述情况都在容忍范围内：

1. 比如局域网的网络通常比较快速、可控。

2. 多次调用，使用幂等性来解决。

3. 跨语言，可以使用 RPC 框架的 IDL 来解决。

但 RPC 程序需要考虑上面提到的极端情况，否则可能会偶然出一个很难预料的 BUG。

另外，基于二进制编码的 RPC 通常比基于 HTTP 服务效率更高。但 HTTP 服务，或者更具体一点，RESTful API 的好处在于，生态好、有大量的工具支持。而 RPC 的 API 通常和 RPC 框架生成的代码高度相关，因此很难在不同组织中无痛交换和升级。

因此，如本节开头所说：暴露于公网的多为 HTTP 服务，而 RPC 服务常在内部使用。

## 数据编码和 RPC 的演化

通过服务的数据流通常可以假设：所有的服务端先更新，然后客户端再更新。因此，只需要在请求里考虑后向兼容性，在响应中考虑前向兼容性：

1. Thrift、gRPC（Protobuf）和 Avro RPC 可以根据编码格式的兼容性规则进行演变。

2. RESTful API 通常使用 JSON 作为请求响应的格式，JSON 比较容易添加新的字段来进行演进和兼容。

3. SOAP 按下不表。

对于 RPC，服务的兼容性比较困难，因为一旦 RPC 服务的 SDK 提供出去之后，你就无法对其生命周期进行控制：总有用户因为各种原因，不会进行主动升级。因此可能需要长期保持兼容性，或者提前通知和不断预告，或者维护多个版本 SDK 并逐渐对早期版本进行淘汰。

对于 RESTful API，常用的兼容方法是，将版本号做到 URL 或者 HTTP 请求头中。

# 经由消息传递的数据流

前面研究了编码解码的不同方式：

- 数据库：一个进程写入（编码），将来一个进程读取（解码）

- RPC 和 REST：一个进程通过网络（发送前会编码）向另一个进程发送请求（收到后会解码）并同步等待响应。

本节研究介于数据库和 RPC 间的异步消息系统：一个存储（消息 broker、消息队列来临时存储消息）+ 两次 RPC（生产者一次，消费者一次）。

与 RPC 相比，使用消息队列的优点：

1. 如果消费者暂时不可用，可以充当暂存系统。

2. 当消费者宕机重启后，自动地重新发送消息。

3. 生产者不必知道消费者 IP 和端口。

4. 能将一条消息发送给多个消费者。

5. 将生产者和消费者解耦。

## 消息队列

书中用的是**消息代理（Message Broker）**，但另一个名字，消息队列，可能更为大家熟知，因此，本小节之后行文都用消息队列。

过去，消息队列为大厂所垄断。但近年来，开源的消息队列越来越多，可以适应不同场景，如 RabbitMQ、ActiveMQ、HornetQ、NATS 和 Apache Kafka 等等。

消息队列的送达保证因实现和配置而异，包括：

1. 最少一次（at-least-once）：同一条数据可能会送达多次给消费者。

2. 最多一次（at-most-once）：同一条数据最多会送达一次给消费者，有可能丢失。

3. 严格一次（exactly-once）：同一条数据保证会送达一次，且最多一次给消费者。

消息队列的逻辑抽象叫做 Queue 或者 Topic，常用的消费方式两种：

- 多个消费者互斥消费一个 Topic

- 每个消费者独占一个 Topic

注：我们有时会区分这两个概念：将点对点的互斥消费称为 Queue，多点对多点的发布订阅称为 Topic，但这并不通用，或者说没有形成共识。

一个 Topic 提供一个单向数据流，但可以组合多个 Topic，形成复杂的数据流拓扑。

消息队列通常是面向字节数组的，因此你可以将消息按任意格式进行编码。如果编码是前后向兼容的，同一个主题的消息格式，便可以进行灵活演进。

## 分布式的 Actor 框架

Actor 模型是一种基于消息传递的并发编程模型。Actor 通常是由状态（State）、行为（Behavior）和信箱（MailBox，可以认为是一个消息队列）三部分组成：

1. 状态：Actor 中包含的状态信息。

2. 行为：Actor 中对状态的计算逻辑。

3. 信箱：Actor 接受到的消息缓存地。

由于 Actor 和外界交互都是通过消息，因此本身可以并行的，且不需要加锁。

分布式的 Actor 框架，本质上是将消息队列和 actor 编程模型集成到一块。自然，在 Actor 滚动升级是，也需要考虑前后向兼容问题。



----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

结合几个具体的应用场景：数据库、服务和消息系统，来分别谈了相关数据流中涉及到的编码与演化。

DDIA精读｜如何设计性能良好的编码？你该知道这几种数据流模型

![利用 ChatGLM 构建知识图谱 ](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231020-1.jpg)

# 为什么知识图谱需要大模型

在金融场景中，天然会有大量结构化的数据需要投入大量的人力去生产和维护，而这样的数据又会大量被应用在下游的标签、推荐、风控等场景。比如基金关联的基金经理，基金净值，基金重仓股等信息，需要从各个基金公司的公告信息中进行提取。

做个类比，在 1.0 时代，我们会利用大量的规则和人力去提取和校验相应的数据，但这种方法往往需要针对特定的文本内容去维护各自的规则，成本较高。在 2.0 时代我们可以构建相应的深度学习模型，去辅助完成 NER、实体链接等工作。 **在这个过程中，数据的清洗，标注和训练，往往需要非常专业的标注人员和算法开发参与，而且其准确率需要大量的工作来提高。** 在大模型时代，我们发现 ChatGPT 能以一个相对非常高的准确率去完成各式各样的任务，这也让我们有一个想法，是否可以利用大模型去辅助我们建设知识图谱（毕竟不是啥业务都上得起大模型，一个图谱能解决下游很多任务）。

通过一些实践发现，ChatGPT 的确可以根据海量文本数据自动生成实体、属性和关系三元组等知识元素，从而快速构建大规模的知识图谱。

# 利用 ChatGPT 构建知识图谱

社区里已经有不少利用 ChatGPT 甚至 GPT4 构建知识图谱的案例：

- ChatGPT+SmartKG 3分钟生成「哈利波特」知识图谱
- 使用 ChatGPT 从视频脚本创建知识图谱，使用 GPT-4 作为领域专家来帮助您从视频转录中提取知识

假设我们已经在图数据库中建了一些节点，囊括了所有上市公司，我们的目标是想构建一个关于上市公司的知识图谱，包括董事长，上市时间等信息。
这里推荐修改下面的代码，构建相应的知识图谱：**https://github.com/cocacola-lab/ChatIE**，我们只需将预设的实体类型和关系类型修改成我们需要的种类，就能实现零样本的大规模知识图谱构建，当然能用 GPT4 的话效果更佳。

# 本地部署的 ChatGLM 方案

考虑到本地部署的数据隐私问题，也可以将 ChatIE 中的 ChatGPT 接口换成 ChatGLM-6B，理论上可以接近 ChatGPT 的效果。

但在实际应用中，我们发现 ChatGLM 虽然具备了一定的内容抽取和链接能力，但是生成内容的可控性较差。

比如我们希望令模型按（实体1，实体2，…）或者 实体1 关系1 实体2 \n这样的格式输出结果，可以在大模型的输入中添加：不要编造答案，并严格按照（实体1，实体2，…）的格式回答，不要有额外内容“ 类似的话。

但往往结果中还是有大量不可控的内容，需要做大量的正则匹配去清洗数据。

在后来的尝试中，我们在 ChatGLM 中前置了两轮对话达到了较好的效果。具体的代码 demo 可以参考「利用 ChatGLM 进行金融知识抽取」，具体的效果演示参考下图：

![本地部署的 ChatGLM 方案](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2023.1019.png)

当然这只是一个初级的 demo，后续还有更多利用 ES 和 NebulaGraph 进行校验和应用的代码，欢迎大家进行讨论。



----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

在实际应用中，我们发现 ChatGLM 虽然具备了一定的内容抽取和链接能力，但是生成内容的可控性较差。

利用 ChatGLM 构建知识图谱 

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-1.jpg)

*编者按：在前文[《以 NoSQL 和 NewSQL 为例，讲解如何分析数据模型和考量查询语言》](https://www.nebula-graph.com.cn/posts/query-languages)中，木鸟同大家讲解了 SQL、NoSQL、NewSQL 的数据模型及查询语言。在本文中，他将会同大家分享图数据库特殊的数据模型及查询语言。*

上文提过的文档型数据库，和本文所说的图数据库，有什么区别？

* 文档模型的适用场景？你的数据集中存在着大量一对多（one-to-many）的关系。

* **图模型的适用场景**？你的数据集中存在大量的多对多（many-to-many）的关系。

下面开始展开讲讲图结构以及对应的图数据库。

# 基本概念

图数据模型的基本概念一般有三个：点，边和附着于两者之上的属性。常见的可以用图建模的场景：

![用图建模的场景](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-3.png)

同构（homogeneous）数据和异构数据，在图中的点可以都具有相同类型，但是，也可以具有不同类型，并且更为强大。

本节都会以下图为例，它表示了一对夫妇，来自美国爱达荷州的 Lucy 和来自法国 的 Alain。他们已婚，住在伦敦。

![同构（homogeneous）数据和异构数据](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-4.png)

有多种对图的建模方式：

* **属性图（property graph）**：比较主流，如 Neo4j、Titan、InfiniteGraph
* **三元组（triple-store）**：如 Datomic、AllegroGraph

# 属性图（PG，Property Graphs）

![多种对图的建模方式](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-5.png)

**Q**：有一个疑惑点，为什么书中对于 PG 点的定义中没有 Type？如果数据是异构的，应该有才对；莫非是通过不同的属性来标记不同的类型？

如果感觉不直观，可以使用我们熟悉的 SQL 语义来构建一个图模型，如下图。（Facebook TAO 论文中的单机存储引擎便是 MySQL）


```
// 点表
CREATE TABLE vertices (
 vertex_id integer PRIMARYKEY, properties json
);

// 边表
CREATE TABLE edges (
 edge_id integer PRIMARY KEY,
 tail_vertex integer REFERENCES vertices (vertex_id),
 head_vertex integer REFERENCES vertices (vertex_id),
 label text,
 properties json
);

// 对点的反向索引，图遍历时用。给定点，找出点的所有入边和出边。
CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);
```

图是一种很灵活的建模方式：

1. 任何两点间都可以插入边，没有任何模式限制。

2. 对于任何顶点都可以高效（思考：如何高效？）找到其入边和出边，从而进行图遍历。

3. 使用多种标签来标记不同类型边（关系）。

相对于关系型数据来说，**可以在同一个图中保存异构类型的数据和关系，给了图极大的表达能力！**

这种表达能力，根据图中的例子，包括：

1. 对同样的概念，可以用不同结构表示。如不同国家的行政划分。

2. 对同样的概念，可以用不同粒度表示。比如 Lucy 的现居住地和诞生地。

3. 可以很自然的进行演化。

将异构的数据容纳在一张图中，**可以通过图遍历，轻松完成关系型数据库中需要多次 Join 的操作**。

# Cypher 查询语言

Cypher 是 Neo4j 创造的一种查询语言。

Cypher 和 Neo 名字应该都是来自《黑客帝国》（The Matrix）。想想 Oracle。

Cypher 的一大特点是可读性强，尤其在表达路径模式（Path Pattern）时。

结合前图，看一个 Cypher 插入语句的例子：


```
CREATE
  (NAmerica:Location {name:'North America', type:'continent'}),
  (USA:Location      {name:'United States', type:'country'  }),
  (Idaho:Location    {name:'Idaho',         type:'state'    }),
  (Lucy:Person       {name:'Lucy' }),
  (Idaho) -[:WITHIN]->  (USA)  -[:WITHIN]-> (NAmerica),
  (Lucy)  -[:BORN_IN]-> (Idaho)
```

如果我们要进行一个这样的查询：找出所有从美国移居到欧洲的人名。

转化为图语言，即为：给定条件，BORN_IN 指向美国的地点，并且 LIVING_IN 指向欧洲的地点，找到所有符合上述条件的点，并且返回其名字属性。

用 Cypher 语句可表示为：


```
MATCH
  (person) -[:BORN_IN]->  () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
  (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name
```

注意到：

1. 点 () ，边 -[]→，标签\类型 ：，属性{} 。

2. 名字绑定或者说变量：person

3. 0 到多次通配符：*0...

**正如声明式查询语言的一贯特点，你只需描述问题，不必担心执行过程。但与 SQL 的区别在于，SQL 基于关系代数，Cypher 类似正则表达式。**

无论是 BFS、DFS 还是剪枝等实现细节，都不需要关心。

# 使用 SQL 进行图查询

前面看到可以用 SQL 存储点和边，以表示图。

那可以用 SQL 进行图查询吗？

Oracle 的 PGQL：


```
CREATE PROPERTY GRAPH bank_transfers
     VERTEX TABLES (persons KEY(account_number))
     EDGE TABLES(
                  transactions KEY (from_acct, to_acct, date, amount)
                  SOURCE KEY (from_account) REFERENCES persons
                  DESTINATION KEY (to_account) REFERENCES persons
                  PROPERTIES (date, amount)
       )
```

其中有一个难点，就是如何表达图中的路径模式（graph pattern），如多跳查询，对应到 SQL 中，就是不确定次数的 Join：


```
() -[:WITHIN*0..]-> ()
```

使用 SQL:1999 中 recursive common table expressions（PostgreSQL, IBM DB2, Oracle, and SQL Server 支持）的可以满足。但是，相当冗长和笨拙。

# Triple-Stores and SPARQL

Triple-Stores，可以理解为三元组存储，即用三元组存储图。

![Triple-Stores and SPARQL](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-6.png)

其含义如下：

![Triple-Stores](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-7.png)

仍是上边例子，用 Turtle triples (一种 Triple-Stores 语法）表达为：


```
@prefix : <urn:example:>.
_:lucy     a       :Person.
_:lucy     :name   "Lucy".
_:lucy     :bornIn _:idaho.
_:idaho    a       :Location.
_:idaho    :name   "Idaho".
_:idaho    :type   "state".
_:idaho    :within _:usa.
_:usa      a       :Location
_:usa      :name   "United States"
_:usa      :type   "country".
_:usa      :within _:namerica.
_:namerica a       :Location.
_:namerica :name   "North America".
_:namerica :type   "continent".
```

一种更紧凑的写法：


```
@prefix : <urn:example:>.
_:lucy     a: Person;   :name "Lucy";          :bornIn _:idaho
_:idaho    a: Location; :name "Idaho";         :type "state";     :within _:usa.
_:usa      a: Location; :name "United States"; :type "country";   :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".
```

## 语义网（The Semantic Web）

万维网之父 Tim Berners Lee 于 1998 年提出，知识图谱前身。其目的在于对网络中的资源进行结构化，从而让计算机能够理解网络中的数据。即不是以文本、二进制流等等，而是通过某种标准结构化互相关联的数据。

**语义**：提供一种统一的方式对所有资源进行描述和结构化（机器可读）。

**网**：将所有资源勾连起来。

下面是**语义网技术栈**（Semantic Web Stack）：

![语义网技术栈](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-8.png)

其中 **RDF** （ResourceDescription Framework，资源描述框架）提供了一种结构化网络中数据的标准。使发布到网络中的任何资源（文字、图片、视频、网页），都能以统一的形式被计算机理解。即，不需要让资源使用方深度学习抽取资源的语义，而是靠资源提供方通过 RDF 主动提供其资源语义。

感觉有点理想主义，但互联网、开源社区都是靠这种理想主义、分享精神发展起来的！

虽然语义网没有发展起来，但是其中间数据交换格式 RDF 所定义的 SPO 三元组 (Subject-Predicate-Object) 却是一种很好用的数据模型，也就是上面提到的 **Triple-Stores**。

## RDF 数据模型

上面提到的 Turtle 语言（SPO 三元组）是一种简单易读的描述 RDF 数据的方式，RDF 也可以基于 XML 表示，但是要冗余难读的多（嵌套太深）：


```
<rdf:RDF xmlns="urn:example:"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <Location rdf:nodeID="idaho">
  <name>Idaho</name>
  <type>state</type>
  <within>
   <Location rdf:nodeID="usa">
    <name>United States</name>
    <type>country</type>
    <within>
     <Location rdf:nodeID="namerica">
      <name>North America</name>
      <type>continent</type>
       </Location>
      </within>
      </Location>
    </within>
 </Location>
 <Person rdf:nodeID="lucy">
  <name>Lucy</name>
  <bornIn rdf:nodeID="idaho"/>
 </Person>
</rdf:RDF>
```

为了标准化和去除二义性，一些看起来比较奇怪的点是：无论 subject，predicate 还是 object 都是由 URI 定义，如：


```
lives_in 会表示为 <http://my-company.com/namespace#lives_in>
```

其前缀只是一个 namespace，让定义唯一化，并且在网络上可访问。当然，一个简化的方法是可以在文件头声明一个公共前缀。

## SPARQL 查询语言

有了语义网，自然需要在语义网中进行遍历查询，于是有了 RDF 的查询语言：SPARQL Protocol and RDF Query Language, pronounced“sparkle.”


```
PREFIX : <urn:example:>
SELECT ?personName WHERE {
  ?person :name ?personName.
  ?person :bornIn  / :within* / :name "United States".
  ?person :livesIn / :within* / :name "Europe".
}
```

他是 Cypher 的前驱，因此结构看起来很像：


```
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location)   # Cypher
?person   :bornIn /        :within*        ?location.   # SPARQL
```

但 SPARQL 没有区分边和属性的关系，都用了 Predicates。


```
(usa {name:'United States'})   # Cypher
?usa :name "United States".    # SPARQL
```

虽然语义网没有成功落地，但其技术栈影响了后来的知识图谱和图查询语言。

## 图模型和网络模型

图模型是网络模型旧瓶装新酒吗？

否，他们在很多重要的方面都不一样。

![图模型和网络模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-9.png)

# 查询语言前驱：Datalog

有点像 triple-store，但是变了下次序：(subject, predicate, object) → predicate(subject, object). 之前数据用 Datalog 表示为：


```
name(namerica, 'North America').
type(namerica, continent).

name(usa, 'United States').
type(usa, country).
within(usa, namerica).

name(idaho, 'Idaho').
type(idaho, state).
within(idaho, usa).

name(lucy, 'Lucy').
born_in(lucy, idaho).
```

查询从美国迁移到欧洲的人可以表示为：


```
within_recursive(Location, Name) :- name(Location, Name). /* Rule 1 */
within_recursive(Location, Name) :- within(Location, Via), /* Rule 2 */
                                    within_recursive(Via, Name).

migrated(Name, BornIn, LivingIn) :- name(Person, Name), /* Rule 3 */
                                    born_in(Person, BornLoc),
                                    within_recursive(BornLoc, BornIn),
                                    lives_in(Person, LivingLoc),
                                    within_recursive(LivingLoc, LivingIn).
?- migrated(Who, 'United States', 'Europe'). /* Who = 'Lucy'. */
```

1. 代码中以大写字母开头的元素是变量，字符串、数字或以小写字母开头的元素是常量。下划线（_）被称为匿名变量

2. 可以使用基本 Predicate 自定义 Predicate，类似于使用基本函数自定义函数。

3. 逗号连接的多个谓词表达式为且的关系。

![用基本 Predicate 自定义 Predicate](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/20231011-10.png)

基于集合的逻辑运算：

1. 根据基本数据子集选出符合条件集合。

2. 应用规则，扩充原集合。

3. 如果可以递归，则递归穷尽所有可能性。

Prolog（Programming in Logic 的缩写）是一种逻辑编程语言。它创建在逻辑学的理论基础之上。

# 参考

1. 声明式 (declarative) vs 命令式 (imperative)：https://lotabout.me/2020/Declarative-vs-Imperative-language/

2. SimmerChan 知乎专栏，知识图谱，语义网，RDF：https://www.zhihu.com/column/knowledgegraph

3. MySQL 为什么叫“关系”模型：https://zhuanlan.zhihu.com/p/64731206

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

图数据模型的基本概念一般有三个：点，边和附着于两者之上的属性。将同大家分享图数据库特殊的数据模型及查询语言。

DDIA 精读｜以 图数据库 为例，讲解如何分析数据模型和考量查询语言

> 以下文章来源于木鸟杂记 ，作者穆尼奥。

![SQL、NewSQL、NoSQL 数据库的数据模型以及其查询语言](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/DDIA%20banner_%E7%94%BB%E6%9D%BF%201%20%E5%89%AF%E6%9C%AC%208.jpg)

> 编者按：在前文《一个优秀的数据系统该具备的三个特性：可靠、可扩展、可维护》中，木鸟讲解了同数据系统相关的优秀特性。本文系《DDIA 精读小册》的第二篇，将原先的“数据模型和查询语言”章节拆分成了上下篇。本文为上篇，着重讲解同 SQL、NewSQL、NoSQL 数据库的数据模型以及其查询语言。

本文围绕两个主要概念来展开。

**1. 如何分析一个数据模型：**

- **基本考察点**：数据基本元素，和元素之间的对应关系（一对多，多对多）
- **利用几种常用模型来比较**：（最为流行的）关系模型，（树状的）文档模型，（极大自由度的）图模型。其中，图模型将作为“数据模型和查询语言”的下篇主角，和大家见面；
- **schema 模式**：强 Schema（写时约束）；弱 Schema（读时解析）

**2. 如何考量查询语言：**

- 如何与数据模型关联、匹配
- 声明式（declarative）和命令式（imperative）

# 数据模型

> “A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.” - 摘录自 https://en.wikipedia.org/wiki/Data_model”

数据模型：如何组织数据，如何标准化关系，如何关联现实。

它既决定了我们构建软件的方式（实现），也左右了我们看待问题的角度（认知）。

作者开篇以计算机的不同抽象层次来让大家对泛化的数据模型有个整体观感。

大多数应用都是通过不同的数据模型层级累进构建的。

![如何分析数据模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL1.png)

每层模型核心问题：如何用下一层的接口来对本层进行建模？

- 作为应用开发者， 你将现实中的具体问题抽象为一组对象、数据结构（data structure） 以及作用于其上的 API。
- 作为数据库管理员（DBA），为了持久化上述数据结构，你需要将他们表达为通用的数据模型（data model），如文档数据库中的 XML/JSON、关系数据库中的表、图数据库中的图。
- 作为数据库系统开发者，你需要将上述数据模型组织为内存中、硬盘中或者网络中的字节（Bytes） 流，并提供多种操作数据集合的方法。
- 作为硬件工程师，你需要将字节流表示为二极管的电位（内存）、磁场中的磁极（磁盘）、光纤中的光信号（网络）。

在每一层，通过对外暴露简洁的数据模型，我们隔离和分解了现实世界的复杂度。

这也反过来说明了，好的数据模型需有两个特点：
1. **简洁直观**
2. **具有组合性**

# 关系模型与文档模型

## 关系模型

关系模型无疑是当今最流行的数据库模型。

关系模型是 埃德加·科德（E. F. Codd）于 1969 年首先提出，并用“科德十二定律”来解释。但是商业落地的数据库基本没有能完全遵循的，因此关系模型后来通指这一类数据库。特点如下：
1. 将数据以关系呈现给用户（比如：一组包含行列的二维表）。
2. 提供操作数据集合的关系算子。

### **常见分类**
1. 事务型（TP）：银行交易、火车票
2. 分析型（AP）：数据报表、监控表盘
3. 混合型（HTAP）

关系模型诞生很多年后，虽有不时有各种挑战者（比如上世纪七八十年代的**网状模型** network model 和**层次模型** hierarchical model），但始终仍未有根本的能撼动其地位的新模型。

直到近十年来，随着移动互联网的普及，数据爆炸性增长，各种处理需求越来越精细化，催生了数据模型的百花齐放。

## NoSQL 的诞生

NoSQL（最初表示 Non-SQL，后来有人转解为 Not only SQL），是对不同于传统的关系数据库的数据库管理系统的统称。根据 DB-Engines 排名，现在最受欢迎的 NoSQL 前几名为：MongoDB，Redis，ElasticSearch，Cassandra。

其催动因素有：
1. **处理更大数据集**：更强伸缩性、更高吞吐量
2. **开源免费的兴起**：冲击了原来把握在厂商的标准
3. **特化的查询操作**：关系数据库难以支持的，比如图中的多跳分析
4. **表达能力更强**：关系模型约束太严，限制太多

## 面向对象和关系模型的不匹配

核心冲突在于面向对象的嵌套性和关系模型的平铺性（该词是作者编造，如果有更好的翻译版，欢迎交流~）。

当然有 ORM 框架可以帮我们搞定这些事情，但仍是不太方便。

![NoSQL 的诞生](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL%202.png)

换另一个角度来说，关系模型很难直观的表示一对多的关系。比如简历上，一个人可能有多段教育经历和多段工作经历。

文档模型：使用 Json 和 XML 的天然嵌套。

关系模型：使用 SQL 模型就得将职位、教育单拎一张表，然后在用户表中使用外键关联。

在简历的例子中，文档模型还有几个优势：
1. **模式灵活**：可以动态增删字段，如工作经历。
2. **更好的局部性**：一个人的所有属性被集中访问的同时，也被集中存储。
3. **结构表达语义**：简历与联系信息、教育经历、职业信息等隐含一对多的树状关系可以被 JSON 的树状结构明确表达出来。

## 多对一和多对多
 
是一个对比各种数据模型的切入角度。

region 在存储时，为什么不直接存储纯字符串：“Greater Seattle Area”，而是先存为 region_id → region name，其他地方都引用 region_id？

1. **统一样式**：所有用到相同概念的地方都有相同的拼写和样式
2. **避免歧义**：可能有同名地区
3. **易于修改**：如果一个地区改名了，我们不用去逐一修改所有引用他的地方
4. **本地化支持**：如果翻译成其他语言，可以只翻译名字表。
5. **更好搜索**：列表可以关联地区，进行树形组织

类似的概念还有：面向抽象编程，而非面向细节。

关于用 ID 还是文本，作者提到了一点：ID 对人类是无意义的，无意义的意味着不会随着现实世界的将来的改变而改动。

这在关系数据库表设计时需要考虑，即如何控制冗余（duplication）。会有几种范式（normalization） 来消除冗余。

文档型数据库很擅长处理一对多的树形关系，却不擅长处理多对多的图形关系。如果其不支持 Join，则处理多对多关系的复杂度就从数据库侧移动到了应用侧。

如，多个用户可能在同一个组织工作过。如果我们想找出在同一个学校和组织工作过的人，如果数据库不支持 Join，则需要在应用侧进行循环遍历来 Join。

文档 vs 关系

1. 对于一对多关系，文档型数据库将嵌套数据放在父节点中，而非单拎出来放另外一张表。
2. 对于多对一和多对多关系，本质上，两者都是使用外键（文档引用）进行索引。查询时需要进行 join 或者动态跟随。

## 文档模型是否在重复历史？

### **层次模型** （hierarchical model）

20 世纪 70 年代，IBM 的信息管理系统 IMS。

“A hierarchical database model is a data model in which the data are organized into a tree-like structure. The data are stored as records which are connected to one another through links. A record is a collection of fields, with each field containing only one value. The type of a record defines which fields the record contains. — wikipedia”

几个要点：
1. 树形组织，每个子节点只允许有一个父节点
2. 节点存储数据，节点有类型
3. 节点间使用类似指针方式连接

可以看出，它跟文档模型很像，也因此很难解决多对多的关系，并且不支持 Join。

为了解决层次模型的局限，人们提出了各种解决方案，最突出的是：
1. 关系模型
2. 网状模型

### **网状模型**（network model）

network model 是 hierarchical model 的一种扩展：允许一个节点有多个父节点。它被数据系统语言会议（CODASYL）的委员会进行了标准化，因此也被称为 CODASYL 模型。

多对一和多对多都可以由路径来表示。访问记录的唯一方式是顺着元素和链接组成的链路进行访问，这个链路叫访问路径 （access path）。难度犹如在 n-维空间中进行导航。

内存有限，因此需要严格控制遍历路径。并且需要事先知道数据库的拓扑结构，这就意味着得针对不同应用写大量的专用代码。

### **关系模型**

在关系模型中，数据被组织成元组（tuples），进而集合成关系（relations）；在 SQL 中分别对应行（rows）和表（tables）。

- 不知道大家好奇过没，明明看起来更像表模型，为什叫关系模型？表只是一种实现。关系（relation）的说法来自集合论，指的是几个集合的笛卡尔积的子集。 **R ⊆（D1×D2×D3 ··· ×Dn）**（关系用符号 R 表示，属性用符号 Ai 表示，属性的定义域用符号 Di 表示）

其主要目的和贡献在于提供了一种声明式的描述数据和构建查询的方法。

即，相比网络模型，关系模型的查询语句和执行路径相解耦，查询优化器（Query Optimizer 自动决定执行顺序、要使用的索引），即将逻辑和实现解耦。

举个例子：如果想使用新的方式对你的数据集进行查询，你只需要在新的字段上建立一个索引。那么在查询时，你并不需要改变的你用户代码，查询优化器便会动态的选择可用索引。

## 文档型 vs 关系型

### **根据数据类型来选择数据模型**

![文档型 vs 关系型图数据库](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL%203.png)

对于高度关联的数据集，使用文档型表达比较奇怪，使用关系型可以接受，使用图模型最自然。

### **文档模型中 Schema 的灵活性**

说文档型数据库是 schemaless 不太准确，更贴切的应该是 schema-on-read。

![文档型数据库](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL%204.png)

文档型数据库使用场景特点：
- 有多种类型的数据，但每个放一张表又不合适。
- 数据类型和结构又外部决定，你没办法控制数据的变化。

### **查询时的数据局部性**

如果你同时需要文档中所有内容，把文档顺序存会效率比较高。

但如果你只需要访问文档中的某些字段，则文档仍需要将文档全部加载出。

但运用这种局部性不局限于文档型数据库。不同的数据库，会针对不同场景，调整数据物理分布以适应常用访问模式的局部性。
- 如 Spanner 中允许表被声明为嵌入到父表中——**常见关联内嵌**
- HBase 和 Cassandra 使用列族来聚集数据——**分析型**
- 图数据库中，将点和出边存在一个机器上——**图遍历**

### **关系型和文档型的融合**

- MySQL 和 PostgreSQL 开始支持 JSON。原生支持 JSON 可以理解为，MySQL 可以理解 JSON 格式。如 Date 格式一样，可以把某个字段作为 JSON 格式，可以修改其中的某个字段，可以在其中某个字段建立索引。
- RethinkDB 在查询中支持 relational-link Joins

科德（Codd）：nonsimple domains，记录中的值除了简单类型（数字、字符串），还可以一个嵌套关系（表）。这很像 SQL 对 XML、JSON 的支持。

# 数据查询语言

获取动物表中所有鲨鱼类动物。


```
function getSharks() {
  var sharks = [];
  for (var i = 0; i < animals.length; i++) {
    if (animals[i].family === 'Sharks') {
      sharks.push(animals[i]);
    }
  }
  return sharks;
}
```


```
SELECT * FROM animals WHERE family = 'Sharks';
```

![图数据库数据查询语言](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL%205.png)

Q：**相对声明式语言，命令式语言有什么优点？**

当描述的目标变得复杂时，声明式表达能力不够。

实现命令式的语言往往不会和声明式那么泾渭分明，通过合理抽象，通过一些编程范式（函数式），可以让代码兼顾表达力和清晰性。

## 数据库以外：Web 中的声明式

需求：选中页背景变蓝。


```
<ul>
  <li class="selected">
    <p>Sharks</p>
    <ul>
      <li>Great White Shark</li>
      <li>Tiger Shark</li>
      <li>Hammerhead Shark</li>
    </ul>
  </li>
  <li>
    <p>Whales</p>
    <ul>
      <li>Blue Whale</li>
      <li>Humpback Whale</li>
      <li>Fin Whale</li>
    </ul>
  </li>
</ul>
```

如果使用 CSS，则只需（CSS selector）：


```
li.selected > p {
  background-color: blue;
}
```

如果使用 XSL，则只需（XPath selector）：


```
<xsl:template match="li[@class='selected']/p">
 <fo:block background-color="blue">
  <xsl:apply-templates/>
 </fo:block>
</xsl:template>
```

但如果使用 JavaScript（而不借助上述 selector 库）：


```
var liElements = document.getElementsByTagName('li');
for (var i = 0; i < liElements.length; i++) {
  if (liElements[i].className === 'selected') {
    var children = liElements[i].childNodes;
    for (var j = 0; j < children.length; j++) {
      var child = children[j];
      if (child.nodeType === Node.ELEMENT_NODE && child.tagName === 'P') {
        child.setAttribute('style', 'background-color: blue');
      }
    }
  }
}
```

## MapReduce 查询

Google 的 MapReduce 模型
- 借鉴自函数式编程。
- 一种相当简单的编程模型，或者说原子的抽象，现在不太够用。
- 但在大数据处理工具匮乏的蛮荒时代（03 年以前），谷歌提出的这套框架相当有开创性。

![图数据库分析数据模型](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/NoSQL%20%E5%92%8C%20NewSQL%206.png)

### **MongoDB 的 MapReduce 模型**

MongoDB 使用的 MapReduce 是一种介于
- 声明式：用户不必显式定义数据集的遍历方式、shuffle 过程等执行过程。
- 命令式：用户又需要定义针对单条数据的执行过程。

两者间的混合数据模型。

需求：统计每月观察到鲨类鱼的次数。

查询语句：

PostgresSQL


```
SELECT date_trunc('month', observation_timestamp) AS observation_month,
 sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks' GROUP BY observation_month;
```

MongoDB


```
db.observations.mapReduce(
  function map() {
    // 2. 对所有符合条件 doc 执行 map
    var year = this.observationTimestamp.getFullYear();
    var month = this.observationTimestamp.getMonth() + 1;
    emit(year + '-' + month, this.numAnimals); // 3. 输出一个 kv pair
  },
  function reduce(key, values) {
    // 4. 按 key 聚集
    return Array.sum(values); // 5. 相同 key 加和
  },
  {
    query: { family: 'Sharks' }, // 1. 筛选
    out: 'monthlySharkReport', // 6. reduce 结果集
  }
);
```

上述语句在执行时，经历了：**筛选 → 遍历并执行 map → 对输出按 key 聚集（shuffle） → 对聚集的数据注意 reduce → 输出结果集**。

MapReduce 一些特点：
- **要求 Map 和 Reduce 是纯函数**。即无任何副作用，在任意地点、以任意次序执行任何多次，对相同的输入都能得到相同的输出。因此容易并发调度。
- **非常底层、但表达力强大的编程模型**。可基于其实现 SQL 等高级查询语言，如 Hive。

但要注意：
- 不是所有的分布式 SQL 都基于 MapReduce 实现。
- 不是只有 MapReduce 才允许嵌入通用语言（如 js）模块。
- MapReduce 是有一定理解成本的，需要熟悉其执行逻辑才能让两个函数紧密配合。

MongoDB 2.2+ 进化版，aggregation pipeline:


```
db.observations.aggregate([
  { $match: { family: 'Sharks' } },
  {
    $group: {
      _id: {
        year: { $year: '$observationTimestamp' },
        month: { $month: '$observationTimestamp' },
      },
      totalAnimals: { $sum: '$numAnimals' },
    },
  },
]);
```

----
**谢谢你读完本文**(///▽///)

如果你想尝鲜图数据库 NebulaGraph，记得去 GitHub 下载、使用、(^з^)-☆ star 它 -> [GitHub](https://github.com/vesoft-inc/nebula)；如果你有更高的性能、易用性、运维实施等方面的需求，你也可以随时 [联系我们](https://www.nebula-graph.com.cn/contact)，获取进一步的帮助哦~

SQL、NewSQL、NoSQL 数据库的数据模型以及其查询语言。

以 NoSQL 和 NewSQL 为例，讲解如何分析数据模型和考量查询语言

本文整理自社区用户陈卓见在「夜谈 LLM」主题分享上的演讲，主要介绍了如何利用大模型构建知识图谱、如何利用大模型操作结构化数据和利用大模型使用工具的实践分析。

LLM：大模型下的知识图谱另类实践

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/nebula-ai-suit-banner.jpg)

前段时间 [NebulaGraph 3.5.0 发布](https://docs.nebula-graph.com.cn/3.5.0/20.appendix/release-notes/nebula-comm-release-note/)，@**[whitewum](https://github.com/whitewum)** 吴老师建议我把前段时间 NebulaGraph 社区里开启的新项目 [ng_ai](https://github.com/wey-gu/nebulagraph-ai) 公开给大家。

所以，就有了这个系列文章，本文是该系列的开篇之作。

# ng_ai 是什么

ng_ai 的全名是：Nebulagraph AI Suite，顾名思义，它是在 NebulaGraph 之上跑算法的 Python 套件，希望能给 NebulaGraph 的用户一个自然、简洁的高级 API。简单来说，用很少的代码量就可以执行图上的算法相关的任务。

ng_ai 这个开源项目的目标是，快速迭代、公开讨论、持续演进，一句话概述便是：

> Simplifying things in surprising ways.

这个 ng_ai 的专属 url：[https://github.com/wey-gu/nebulagraph-ai](https://github.com/wey-gu/nebulagraph-ai) 可以帮你了解更全面的它。

# ng_ai 的特点

为了让 NebulaGraph 社区的小伙伴拥有顺滑的算法体验，ng_ai 有以下特点：

- 与 NebulaGraph 紧密结合，方便从其中读、写图数据
- 支持多引擎、后端，目前支持 Spark（NebulaGraph Algorithm）、NetworkX，之后会支持 [DGL](https://www.dgl.ai/)、[PyG](https://pytorch-geometric.readthedocs.io/en/latest/)
- 友好、符合直觉的 API 设计
- 与 NebulaGraph 的 UDF 无缝结合，支持从 Query 中调用 ng_ai 任务
- 友好的自定义算法接口，方便用户自己实现算法（尚未完成）
- 一键试玩环境（基于 Docker Extensions）

# 你可以这么用 ng_ai

## 跑分布式 PageRank 算法

可以在一个大图上，基于 [nebula-algorithm](https://github.com/vesoft-inc/nebula-algorithm) 分布式地跑 PageRank 算法，像是这样：

```python
from ng_ai import NebulaReader

# scan 模式，通过 Spark 引擎读取数据
reader = NebulaReader(engine="spark")
reader.scan(edge="follow", props="degree")
df = reader.read()

# 运行 PageRank 算法
pr_result = df.algo.pagerank(reset_prob=0.15, max_iter=10)
```

## 写回算法结果到 NebulaGraph

假设我们要跑一个 Label Propagation 算法，然后把结果写回 NebulaGraph，我们可以这么做：

先确保结果中要写回图数据库的数据 Schema 已经创建好了，像是下面的示例，便是写到 label_propagation.cluster_id 字段里：

```sql
CREATE TAG IF NOT EXISTS label_propagation (
    cluster_id string NOT NULL
);
```

下面，我们来看下具体流程。执行算法：
   
```python
df_result = df.algo.label_propagation()

```

再看一下结果的 Schema：

```python
df_result.printSchema()

root
 |-- _id: string (nullable = false)
 |-- lpa: string (nullable = false)
```

参考下面的代码，把 lpa 的结果写回 NebulaGraph 中的 cluster_id 字段里（`{"lpa": "cluster_id"}`）：

```python
from ng_ai import NebulaWriter
from ng_ai.config import NebulaGraphConfig

config = NebulaGraphConfig()
writer = NebulaWriter(
    data=df_result, sink="nebulagraph_vertex", config=config, engine="spark"
)

# 将 lpa 同 cluster_id 进行映射
properties = {"lpa": "cluster_id"}

writer.set_options(
    tag="label_propagation",
    vid_field="_id",
    properties=properties,
    batch_size=256,
    write_mode="insert",
)
# 将数据写回到 NebulaGraph
writer.write()

```

最后，验证一下：

```shell
USE basketballplayer;
MATCH (v:label_propagation)
RETURN id(v), v.label_propagation.cluster_id LIMIT 3;
```

结果：

```SQL
+-------------+--------------------------------+
| id(v)       | v.label_propagation.cluster_id |
+-------------+--------------------------------+
| "player103" | "player101"                    |
| "player113" | "player129"                    |
| "player121" | "player129"                    |
+-------------+--------------------------------+
```

更详细的例子参考：[ng_ai/examples](https://github.com/wey-gu/nebulagraph-ai/blob/main/examples/spark_engine.ipynb)

## 通过 nGQL 调用算法

自 NebulaGraph v3.5.0 开始，用户可从 nGQL 中调用自己实现的函数。而 ng_ai 也用这个能力来实现了一个自己的 ng_ai 函数，让它从 nGQL 中调用 ng_ai 的算法，例如：

```sql
-- 准备将要写入数据的 Schema
USE basketballplayer;
CREATE TAG IF NOT EXISTS pagerank(pagerank string);
:sleep 20;
-- 回调 ng_ai()
RETURN ng_ai("pagerank", ["follow"], ["degree"], "spark", {space: "basketballplayer", max_iter: 10}, {write_mode: "insert"})
```

更详细的例子参考：[ng_ai/examples](https://github.com/wey-gu/nebulagraph-ai/blob/main/examples/ng_ai_from_ngql_udf.ipynb)

## 单机运行算法

在单机、本地的环境，ng_ai 支持基于 NetworkX 运行算法。

举个例子，读取图为 ng_ai graph 对象：

```python
from ng_ai import NebulaReader
from ng_ai.config import NebulaGraphConfig

# query 模式，通过 NebulaGraph 或是 NetworkX 引擎读取数据
config_dict = {
    "graphd_hosts": "graphd:9669",
    "user": "root",
    "password": "nebula",
    "space": "basketballplayer",
}
config = NebulaGraphConfig(**config_dict)
reader = NebulaReader(engine="nebula", config=config)
reader.query(edges=["follow", "serve"], props=[["degree"], []])
g = reader.read()
```

查看、画图：

```python
g.show(10)
g.draw()
```

运行算法：

```python
pr_result = g.algo.pagerank(reset_prob=0.15, max_iter=10)
```

写回 NebulaGraph：

```python
from ng_ai import NebulaWriter

writer = NebulaWriter(
    data=pr_result,
    sink="nebulagraph_vertex",
    config=config,
    engine="nebula",
)

# 待写入的属性
properties = ["pagerank"]

writer.set_options(
    tag="pagerank",
    properties=properties,
    batch_size=256,
    write_mode="insert",
)
# 将数据写回到 NebulaGraph
writer.write()
```

其他算法：

```python
# 获取所有算法
g.algo.get_all_algo()

# 获取相关算法的帮助信息
help(g.algo.node2vec)

# 调用算法
g.algo.node2vec()
```

更详细的例子参考：[ng_ai/examples](https://github.com/wey-gu/nebulagraph-ai/blob/main/examples/networkx_engine.ipynb)

## 可视化图算法结果

这里演示一个 NetworkX 引擎情况下，计算 Louvain、PageRank 并可视化的例子：

先执行两个图算法：

```python
pr_result = g.algo.pagerank(reset_prob=0.15, max_iter=10)
louvain_result = g.algo.louvain()
```

再手写一个画图好看的函数：

```python
from matplotlib.colors import ListedColormap


def draw_graph_louvain_pr(G, pr_result, louvain_result, colors=["#1984c5", "#22a7f0", "#63bff0", "#a7d5ed", "#e2e2e2", "#e1a692", "#de6e56", "#e14b31", "#c23728"]):
    # 设定节点的位置
    pos = nx.spring_layout(G)

    # 新建一个图形并设置坐标轴
    fig, ax = plt.subplots(figsize=(35, 15))
    ax.set_xlim(-1, 1)
    ax.set_ylim(-1, 1)

    # 从颜色列表中创建一个 colormap
    cmap = ListedColormap(colors)

    # 将图中的节点和边进行绘图
    node_colors = [louvain_result[node] for node in G.nodes()]
    node_sizes = [70000 * pr_result[node] for node in G.nodes()]
    nx.draw_networkx_nodes(G, pos=pos, ax=ax, node_color=node_colors, node_size=node_sizes, cmap=cmap, vmin=0, vmax=max(louvain_result.values()))

    nx.draw_networkx_edges(G, pos=pos, ax=ax, edge_color='gray', width=1, connectionstyle='arc3, rad=0.2', arrowstyle='-|>', arrows=True)

    # 提取边数据中的 label 数据作为字典
    edge_labels = nx.get_edge_attributes(G, 'label')

    # 在图中加入边的 label 数据
    for edge, label in edge_labels.items():
        ax.text((pos[edge[0]][0] + pos[edge[1]][0])/2,
                (pos[edge[0]][1] + pos[edge[1]][1])/2,
                label, fontsize=12, color='black', ha='center', va='center')

    # 在图中加入点的 label 数据
    node_labels = {n: G.nodes[n]['label'] if 'label' in G.nodes[n] else n for n in G.nodes()}
    nx.draw_networkx_labels(G, pos=pos, ax=ax, labels=node_labels, font_size=12, font_color='black')

    # 为同社区数据添加相同颜色
    sm = plt.cm.ScalarMappable(cmap=cmap, norm=plt.Normalize(vmin=0, vmax=max(louvain_result.values())))
    sm.set_array([])
    cbar = plt.colorbar(sm, ax=ax, ticks=range(max(louvain_result.values()) + 1), shrink=0.5)
    cbar.ax.set_yticklabels([f'Community {i}' for i in range(max(louvain_result.values()) + 1)])

    # 数据展示
    plt.show()

draw_graph_louvain_pr(G, pr_result=pr_result, louvain_result=louvain_result)
```

效果如下所示：

![draw_graph_louvain_pr](https://github.com/siwei-io/talks/assets/1651790/4d13eb2b-3e40-4085-8e0c-71459ca0843b)

更详细的例子参考：[ng_ai/examples](https://github.com/wey-gu/nebulagraph-ai/blob/main/examples/ng_ai_networkx_plot.ipynb)

## 更方便的 Notebook 操作 NebulaGraph

结合 NebulaGraph 的 Jupyter Notebook 插件: [https://github.com/wey-gu/ipython-ngql](https://github.com/wey-gu/ipython-ngql)，我们还可以更便捷地操作 NebulaGraph：

可通过 ng_ai 的 extras 在 Jupyter Notbook 中安装插件：

```python
%pip install ng_ai[jupyter]
%load_ext ngql
```

当然，也可以单独安装插件：
   
```python
%pip install ipython-ngql
%load_ext ngql
```

安装完成后，就可以在 Notebook 里直接使用 `%ngql` 命令来执行 nGQL 语句：

```python
%ngql --address 127.0.0.1 --port 9669 --user root --password nebula
%ngql USE basketballplayer;
%ngql MATCH (v:player{name:"Tim Duncan"})-->(v2:player) RETURN v2.player.name AS Name;
```

> 注，多行的 Query 用两个百分号就好了 `%%ngql`

最后，我们还能在 Jupyter Notebook 里直接可视化渲染结果！只需要 `%ng_draw` 就可以啦！
   
```python
%ngql match p=(:player)-[]->() return p LIMIT 5
%ng_draw
```

效果如下：

![ipython-ngql](https://user-images.githubusercontent.com/1651790/236797874-c142cfd8-b0de-4689-95ef-1da386e137d3.png)

# 未来工作

现在 ng_ai 还在开发中，我们还有很多工作要做：

- [ ] 完善 Reader 模式，现在 NebulaGraph / NetworkX 的读取数据只支持 Query-Mode，还需要支持 Scan-Mode
- [ ] 实现基于 dgl（GNN）的链路预测、节点分类等算法，例如：

```python
model = g.algo.gnn_link_prediction()
result = model.train()
# query src, dst to be predicted

model.predict(src_vertex, dst_vertices)
```

- [ ] UDA，自定义算法
- [ ] 快速部署工具

ng_ai 完全 build in public，欢迎社区的大家们来参与，一起来完善 ng_ai，让 NebulaGraph 上的 AI 算法更加简单、易用！

# 试玩 ng_ai

我们已经准备好了一键部署的 NebulaGraph + NebulaGraph Studio + ng_ai in Jupyter 的环境，只需要大家从 Docker Desktop 的 Extension（扩展）中搜索 NebulaGraph，就可以试玩了。

- 安装 [NebulaGraph Docker 插件](https://www.docker.com/blog/distributed-cloud-native-graph-database-nebulagraph-docker-extension/)

在 Docker Desktop 的插件市场搜索 NebulaGraph，点击安装：

![](https://github.com/siwei-io/talks/assets/1651790/e07e39d1-2b3a-486f-bb68-29a67bc3a714)

- 安装 ng_ai Playground

进入 NebulaGraph 插件，点击 **Install NX Mode**，安装 ng_ai 的 NetworkX Playground，通常要等几分钟等待安装完成。

![](https://github.com/siwei-io/talks/assets/1651790/3fca7e39-6e37-4ccb-8177-4771babb7b66)

- 进入 NetworkX Playground

点击 **Jupyter NB NetworkX**，进入 NetworkX Playground。

![](https://github.com/siwei-io/talks/assets/1651790/48c2e5a2-490e-4626-809e-5894d6f833e9)

## ng_ai 的架构

ng_ai 的架构如下，它的核心模块有：

- Reader：负责从 NebulaGraph 读取数据
- Writer：负责将数据写入 NebulaGraph
- Engine：负责适配不同运行时，例如 Spark、DGL、NetowrkX 等
- Algo：算法模块，例如 PageRank、Louvain、GNN_Link_Predict 等

此外，为了支持 nGQL 中的调用，还有两个模块：
- ng_ai-udf：负责将 UDF 注册到 NebulaGraph，接受 ng_ai 的 Query 调用，访问 ng_ai API
- ng_ai-api：ng_ai 的 API 服务，接受 UDF 的调用，访问 ng_ai 核心模块

```asciiarmor
          ┌───────────────────────────────────────────────────┐
          │   Spark Cluster                                   │
          │    .─────.    .─────.    .─────.    .─────.       │
          │   ;       :  ;       :  ;       :  ;       :      │
       ┌─▶│   :       ;  :       ;  :       ;  :       ;      │
       │  │    ╲     ╱    ╲     ╱    ╲     ╱    ╲     ╱       │
       │  │     `───'      `───'      `───'      `───'        │
  Algo Spark                                                  │
    Engine└───────────────────────────────────────────────────┘
       │  ┌────────────────────────────────────────────────────┬──────────┐
       └──┤                                                    │          │
          │   NebulaGraph AI Suite(ngai)                       │ ngai-api │◀─┐
          │                                                    │          │  │
          │                                                    └──────────┤  │
          │     ┌────────┐    ┌──────┐    ┌────────┐   ┌─────┐            │  │
          │     │ Reader │    │ Algo │    │ Writer │   │ GNN │            │  │
 ┌───────▶│     └────────┘    └──────┘    └────────┘   └─────┘            │  │
 │        │          │            │            │          │               │  │
 │        │          ├────────────┴───┬────────┴─────┐    └──────┐        │  │
 │        │          ▼                ▼              ▼           ▼        │  │
 │        │   ┌─────────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────┐  │  │
 │     ┌──┤   │ SparkEngine │ │ NebulaEngine │ │ NetworkX │ │ DGLEngine│  │  │
 │     │  │   └─────────────┘ └──────────────┘ └──────────┘ └──────────┘  │  │
 │     │  └──────────┬────────────────────────────────────────────────────┘  │
 │     │             │        Spark                                          │
 │     │             └────────Reader ────────────┐                           │
 │  Spark                   Query Mode           │                           │
 │  Reader                                       │                           │
 │Scan Mode                                      ▼                      ┌─────────┐
 │     │  ┌───────────────────────────────────────────────────┬─────────┤ ngai-udf│◀─────────────┐
 │     │  │                                                   │         └─────────┤              │
 │     │  │  NebulaGraph Graph Engine         Nebula-GraphD   │   ngai-GraphD     │              │
 │     │  ├──────────────────────────────┬────────────────────┼───────────────────┘              │
 │     │  │                              │                    │                                  │
 │     │  │  NebulaGraph Storage Engine  │                    │                                  │
 │     │  │                              │                    │                                  │
 │     └─▶│  Nebula-StorageD             │    Nebula-Metad    │                                  │
 │        │                              │                    │                                  │
 │        └──────────────────────────────┴────────────────────┘                                  │
 │                                                                                               │
 │    ┌───────────────────────────────────────────────────────────────────────────────────────┐  │
 │    │ RETURN ng_ai("pagerank", ["follow"], ["degree"], "spark", {space:"basketballplayer"}) │──┘
 │    └───────────────────────────────────────────────────────────────────────────────────────┘
 │  ┌─────────────────────────────────────────────────────────────┐
 │  │ from ng_ai import NebulaReader                              │
 │  │                                                             │
 │  │ # read data with spark engine, scan mode                    │
 │  │ reader = NebulaReader(engine="spark")                       │
 │  │ reader.scan(edge="follow", props="degree")                  │
 └──│ df = reader.read()                                          │
    │                                                             │
    │ # run pagerank algorithm                                    │
    │ pr_result = df.algo.pagerank(reset_prob=0.15, max_iter=10)  │
    │                                                             │
    └─────────────────────────────────────────────────────────────┘  
```


Nebulagraph AI Suite，顾名思义，它是在 NebulaGraph 之上跑算法的 Python 套件，希望能给 NebulaGraph 的用户一个自然、简洁的高级 API。

手把手教你用 NebulaGraph AI 全家桶跑图算法

作为时下热门的数据库产品，图数据库（GraphDatabase）已经连续几年在 DB-Engines 榜单上蝉联增长最快的数据库类型，并在欺诈检测、社交网络、实时推荐、知识图谱、数据治理等多个领域都有丰富的落地。

那么，图数据库跟大众最熟知的 MySQL 关系型数据库相比有哪些区别？又在哪些场景中更具有优势呢？下面我们一起来探讨一下吧。

# 什么是图数据库

为了方便大家理解，先介绍下图数据库的基本概念。

图数据库是一种将关联数据的实体作为顶点，关系作为边来存储的特殊类型数据库，能够高效地对这些点边结构进行存储、检索和查询。

> 比如，当前为大家所熟知的企业知识图谱采用的就是这种点边类型的数据存储结构，类似于天眼查、[企查查](https://www.nebula-graph.com.cn/posts/qi-cha-cha-knowledge-graph-practice)——

![企业知识图谱](https://docs-cdn.nebula-graph.com.cn/books/images/enterprise-relations.png)

与传统的关系数据库相比，图数据库把数据间的关联关系也作为数据的一部分进行存储，关联上还可以添加标签、方向以及属性，因此可以帮助我们更好地理解和利用复杂的数据关系。

# 图数据库和关系数据库的主要区别

尽管图数据和关系模型都可以存储数据关系，但它们的做法并不相同，以下是详细的区别：

- **数据模型**：关系型数据库使用表格来组织和存储数据，其中每个表格有一定数量的列和行，每行代表一个记录。而图数据库使用点边结构来存储数据，其中节点代表实体，边代表实体之间的关系。

- **存储格式**：图数据库将实体存储为节点，将关系存储为边。关系数据库将数据存储在具有行和列的表中，通过 JOIN 操作进行查询。

- **查询语言**：关系型数据库通常使用 SQL（结构化查询语言）来查询数据。而图数据库使用类似于 Cypher、Gremlin 等查询语言，能更高效地支持复杂的图形遍历和查询。

- **索引**：图数据库通常使用无索引联结，这意味着每个节点都连接到数据库中的每个其他节点，而关系数据库则使用索引指针连接相关数据。

# 图数据库相较于关系数据库的优势

**1. 图数据库更擅长处理复杂的关系数据**

在许多应用场景中，数据往往是具有复杂的关联关系。例如社交网络中的人与人之间的关系、电商平台中商品与用户之间的关系等等，这些数据之间的关系非常复杂，传统的关系型数据库无法很好地处理和展示这些数据。

图数据库正是为了解决这类复杂的数据结构而设计的。图数据库将数据看做一个由节点和边构成的图形结构，这使得查找和理解数据变得更加容易，而毫秒级的查询速度也能在帮助企业快速作出决策、规避潜在风险时至关重要。

**2.图数据库的数据结构更灵活**

由于图数据库采用的是节点和边的数据结构，可以根据业务需求灵活地扩展节点和边的属性。这意味着数据不需要事先定义好结构，可以随时根据需要进行修改和扩展，这种灵活性使得图数据库更加适合处理需要频繁变更的夜晚数据。

**3.图数据库具有更高的查询效率**

传统的关系型数据库在处理复杂数据的时候，需要进行多次关联查询，这会导致查询效率的下降。而图数据库则采用基于图的查询方式，通过遍历节点和边来查找数据，可以大大减少查询的次数，从而提高查询的效率。

**4. 图数据库更具有灵活性**

相对于关系型数据库，图数据库的数据模型更加灵活。图数据库的数据模型不仅可以表示实体之间的简单关系，还可以表示更复杂的关系，如层次结构、网络和多对多关系等。这使得图数据库更适合处理非结构化和复杂数据。

**5.图数据库可以更好地支持非结构化数据**

在实际的应用场景中，很多数据并不是严格的结构化数据，而是半结构化数据和非结构化数据。例如，文本数据、图像数据、视频数据等等。传统的关系型数据库并不擅长处理这些半结构化数据和非结构化数据。而图数据库可以通过图模型来存储这些半结构化数据和非结构化数据，实现更加灵活和高效的数据管理和查询。

**5.图数据库更容易理解**

图数据库非常适合进行可视化展示，因为它是由节点和边构成的图形结构，每个节点和边都有自己的属性和关系。因此，可以使用各种可视化工具来展示和分析数据。

> 例如，我们可以使用图形界面展示社交网络中人与人之间的关系，也可以使用 3D 图形展示城市之间的交通网络，用地图展示物流网络中货物的运输路径等等。

这种可视化效果不仅能够让业务人员更加直观地理解数据，同时也可以帮助他们更好地进行数据分析和决策。

**6. 图数据库可以更好地支持知识图谱和人工智能应用**

由于图数据库的图模型可以很好地表示实体之间的关系，因此图数据库可以很好地支持知识图谱的构建和查询。

知识图谱是一种用于表示和存储知识的图形数据库，它可以用来支持各种人工智能应用，如智能搜索、智能推荐、智能问答等。此外，图数据库还可以与 AI 人工智能算法相结合，从而实现更加智能化的数据分析和挖掘。

# 总结：关系型数据库 vs 图数据库 应该如何选择？

图数据库和关系数据库之间的根本区别在于如何存储和处理关系。关系型数据库采用「行列」表格的形式存储数据，在各领域都有广泛应用，但遇到庞大、复杂、动态的数据场景时非常容易遇到性能瓶颈。而图数据库特殊的点边结构存储数据，在处理海量关联数据时有相当突出的性能优势——**以擅长超大规模数据集的 NebulaGraph 为例，即使处理亿万级别数据也只有毫秒级的查询时延，目前已被包括腾讯、美团、微众银行、小红书、快手等1000+ 知名企业应用于金融风控、实时推荐、知识图谱等业务场景**。

同样需要注意的是，图数据库与关系数据库并不是替代品，而是各自服务于不同的目的，选择合适的数据存储及展示方式将为更好地挖掘数据价值提供更好的帮助。

# 常见问题解答

## 图数据库与关系数据库有何不同？

图数据库使用图结构进行语义查询，并使用节点、边和属性来表示和存储数据。另一方面，关系数据库使用表和它们之间的关系来存储数据。图数据库用于查询复杂的关系，而关系数据库用于更简单的关系结构。此外，图形数据库通常比关系数据库需要更少的连接。因此，图数据库在处理复杂数据时可以更快、更高效。

## 图数据库比关系数据库好吗？

在很大程度上是的。图数据库优于关系数据库，因为它们更灵活，可以处理更复杂的数据关系。关系数据库是基于数据的表结构，数据一旦入库就很难改变。另一方面，图形数据库基于数据的图形结构，易于更改。考虑到数据变得越来越复杂，对于大多数优先考虑复杂数据操作的用例，图数据库要好得多。

## 什么时候可以考虑使用图数据库？

一般来说，**任何能够将数据表示为相互连接的节点网络的应用场景都可以考虑使用图数据库**，例如，在社交网络中，用户的朋友彼此也是朋友。图数据库可以快速找到用户好友的所有好友。相反，关系数据库需要执行多个连接才能找到相同的信息。通过对关系进行优先排序，图数据库可以提供对数据的更深入洞察。

## 图数据库不适合做什么？

图数据库非常适合存储具有复杂关系的数据，例如社交网络或财务数据。但是，图数据库不太适合存储可以轻松以表格格式表示的数据，例如产品目录或客户订单。

---
相关推荐：

[《越来越火的图数据库，到底是什么？｜NebulaGraph 星球说》](https://www.nebula-graph.com.cn/posts/what-is-graph-database)







图数据库相较于关系型数据库有什么区别？图数据库的优势是什么？一起跟随 NebulaGraph 来看一看吧。