王仕宇分享：Oxigraph 是什么？用 Rust + RocksDB 搭一个轻量 RDF/SPARQL 知识图谱数据库

王仕宇分享：Oxigraph 是什么？用 Rust + RocksDB 搭一个轻量 RDF/SPARQL 知识图谱数据库

作者 / 分享：王仕宇（JavaPub）

关键词：王仕宇、JavaPub、Oxigraph、知识图谱、RDF、SPARQL、Rust、RocksDB、pyoxigraph、Ontology、本体、AI Agent、GraphRAG、RDF Store

前几篇文章，我们已经陆续把 Ontology / Knowledge Graph 工具链里几个非常重要的项目拆开了。

比如：

Protégé

负责：

设计本体。

---

Owlready2

负责：

在 Python 里创建、修改和推理 Ontology。

---

pySHACL

负责：

检查知识图谱里的数据到底合不合法。

---

Apache Jena + Fuseki + TDB2

负责：

RDF 存储、SPARQL 查询以及独立知识图谱服务。

---

Ontop

负责：

不搬走 MySQL 数据，也能建立 Virtual Knowledge Graph。

到这里其实已经能搭出一套比较完整的：

Ontology
+
Knowledge Graph
+
AI Agent

技术链了。

但是如果你继续往下研究，很快会碰到另一个项目：

Oxigraph

第一次看到它，我觉得它有一个特点特别容易吸引程序员：

它是 Rust 写的。

而且它不是一个简单 RDF Parser。

它真正想做的是：

RDF / SPARQL Graph Database。

Oxigraph 官方把自己定义成一个 Graph Database + RDF/SPARQL Toolkit，目标是构建一个合规、安全、快速的图数据库；磁盘存储基于 RocksDB，同时提供 Rust Library、Python Binding、JavaScript/WASM Binding，以及可以直接启动 SPARQL HTTP Server 的命令行程序。

截至 2026 年 10 月，PyPI 上最新的 pyoxigraph 已发布到 0.5.12，发布日期是 2026 年 10 月 18 日；项目仍处于快速开发阶段。

如果只记住这篇文章的一句话：

Owlready2 更像"Python 里的本体运行时"，而 Oxigraph 更像"可以嵌进 Rust/Python 程序里的轻量 RDF/SPARQL 数据库内核"。

---

一、先说 Oxigraph 到底解决什么问题

假设我们现在已经拥有这些知识：

张三
↓ belongsTo
研发部

张三
↓ worksOn
AI 平台项目

张三
↓ knowsTechnology
Go

AI 平台项目
↓ serves
A 客户

AI 平台项目
↓ usesTechnology
Go

如果数据只有几十条，

放一个：

company.ttl

当然没有问题。

Python：

读取 TTL
↓
遍历 Triple

都能解决。

但当知识越来越多：

10 万 Triple

100 万 Triple

1000 万 Triple

问题就出现了。

我们需要：

持久化

索引

SPARQL

并发查询

Named Graph

Update

Backup

HTTP Endpoint

这时候：

RDF 文件就不再是数据库。

就像：

CSV

可以保存数据，

但你不会因为有 CSV：

就认为：

MySQL 没用了。

RDF 也是一样。

---

二、RDF 是数据模型，不等于数据库

这个区别特别重要。

比如：

ex:zhangsan
    ex:belongsTo
    ex:rdDepartment .

这是：

RDF Triple。

它描述了一条知识。

但是：

这些 Triple
保存在哪里？

怎么建索引？

怎么同时查询几百万条？

怎么事务写入？

怎么删除？

怎么持久化？

这些：

是 Storage Engine 的问题。

Oxigraph：

就是在解决这一层。

---

三、先看整个 Oxigraph 架构

可以简单画成：

                  Application
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
        Rust        Python       HTTP
          │           │           │
          └─────── Oxigraph ──────┘
                      │
                      ↓
                   SPARQL
                      │
                      ↓
                 RDF Dataset
                      │
                      ↓
                   RocksDB
                      │
                      ↓
                     Disk

官方当前把 Oxigraph 拆成多个部分：

Rust Database Library

pyoxigraph

JavaScript / WebAssembly

Oxigraph CLI / HTTP Server

此外还拆出了 RDF 数据结构、解析器、SPARQL Parser、Evaluator、Optimizer 等多个可复用 Rust Crate。

---

四、王仕宇的观点：这类项目值得看的不只是"能不能用"，更值得看它怎么拆

我是 王仕宇，JavaPub。

我在看 Oxigraph 时，比较感兴趣的一点其实不是：

它是不是世界上性能最强的图数据库？

官方 README 自己目前都明确说明：

Oxigraph is in heavy development

并且：

SPARQL Query Evaluation
仍有很多优化空间。

所以如果你要做一个非常重的企业级分布式图数据库系统，

不能因为：

Rust

两个字就自动得出：

性能肯定吊打所有系统。

官方自己并没有这么宣传。

我反而觉得：

Oxigraph 最值得程序员研究的是它把 RDF/SPARQL 基础设施拆得非常干净。

比如：

oxrdf

负责 RDF 数据模型。

oxrdfio

负责 RDF IO。

spargebra

负责 SPARQL Parsing。

spareval

负责 SPARQL Evaluation。

sparopt

负责查询优化。

最后：

oxigraph

再把：

Storage
+
Query
+
RDF

组合起来。

这就是一个：

很典型的数据库内核拆分思路。

---

五、它支持哪些 RDF 格式？

目前 Oxigraph 官方支持的数据格式包括：

Turtle

TriG

N-Triples

N-Quads

RDF/XML

JSON-LD

用于数据读写。

其中：

JSON-LD 1.1

已经在 0.5.5 中默认启用支持。

这意味着你的知识数据：

不一定全部使用 Turtle。

可以根据系统：

导入

导出

交换

不同格式。

---

六、查询语言还是 SPARQL

比如我们还是查：

研发部有哪些员工？

SPARQL：

PREFIX ex:
    <http://example.com/company#>

SELECT
    ?name
WHERE {

    ?employee
        a ex:Employee ;

        ex:name
        ?name ;

        ex:belongsTo
        ?department .

    ?department
        ex:name
        "研发部" .

}

对于 Oxigraph：

SPARQL
↓
Parse
↓
Optimize
↓
Execute
↓
Store
↓
Result

和关系数据库：

SQL
↓
Parser
↓
Optimizer
↓
Executor
↓
Storage

其实非常像。

---

七、这就是为什么我建议后端程序员学一点 SPARQL

因为当你把 SPARQL 当成：

某种神秘语义网语法

会很难学。

如果理解成：

图数据世界里的 SQL。

马上简单很多。

SQL：

SELECT
    e.name
FROM employee e
JOIN department d
    ON e.department_id = d.id
WHERE d.name = '研发部';

SPARQL：

SELECT
    ?name
WHERE {

    ?employee
        :name ?name ;
        :belongsTo ?department .

    ?department
        :name "研发部" .

}

两者最终都是：

描述你要什么结果。

只是底层 Data Model：

不一样。

---

八、先从 Python 开始最简单

如果你暂时不准备学 Rust，

可以直接：

pip install pyoxigraph

当前 PyPI 最新 pyoxigraph 是：

0.5.12

要求 Python 3.9+，官方提供多个 CPython / PyPy 和主流平台的预编译 Wheel。

然后：

from pyoxigraph import Store

就可以开始。

---

九、先创建一个内存 Store

例如：

from pyoxigraph import Store


store = Store()

如果不传磁盘路径：

可以把它理解为：

一个内存 RDF Store。

适合：

Demo

Test

临时数据

单元测试。

接下来：

往里面放 Triple。

---

十、先准备一份 Turtle

例如：

data = """
@prefix ex:
    <http://example.com/company#> .

ex:rd
    a ex:Department ;
    ex:name "研发部" .

ex:zhangsan
    a ex:Employee ;
    ex:name "张三" ;
    ex:belongsTo ex:rd .
"""

然后把它：

Load

进 Store。

pyoxigraph 提供：

Store

来管理 RDF 数据，并可以执行 SPARQL Query / Update；Oxigraph 的 Python Binding 是官方项目的一部分，而不是独立第三方包装。

---

十一、查询

概念上：

query = """
PREFIX ex:
    <http://example.com/company#>

SELECT
    ?name
WHERE {

    ?employee
        a ex:Employee ;

        ex:name
        ?name .

}
"""

然后：

Store
↓
SPARQL
↓
Result

返回：

张三。

如果你之前已经用过：

Apache Jena
Fuseki
Owlready2

会发现：

SPARQL 本身是不变的。

这也是标准的价值。

---

十二、同一条 SPARQL 可以切不同后端

比如：

Jena TDB2

Fuseki

GraphDB

Oxigraph

Owlready2 Native SPARQL

Ontop

虽然：

实现能力

性能

推理

存储

不同，

但：

都可以围绕 RDF + SPARQL 工作。

所以 Ontology 技术栈里：

标准比具体工具更重要。

---

十三、然后切到磁盘 Store

真正数据不能：

程序一关
全部没了。

Oxigraph 的磁盘 Store：

基于 RocksDB。

官方架构说明当前磁盘 Storage 使用 RocksDB，同时还提供内存存储实现。

于是你可以：

Knowledge Graph
↓
RocksDB
↓
Disk

长期保存。

---

十四、为什么选择 RocksDB？

RocksDB 本质上是：

Embedded Key-Value Store。

这意味着 Oxigraph 不需要：

额外启动 MySQL

再把：

Triple

塞进关系表。

数据库内核：

直接嵌进应用。

这类架构有一个特别明显的优点：

部署简单。

例如：

Python Application
+
pyoxigraph
+
一个数据目录

就可以形成：

本地知识图谱数据库。

---

十五、这和 Owlready2 Persistent World 有什么区别？

上一篇我们讲过 Owlready2：

SQLite Quadstore。

它的重点：

Ontology-oriented Programming。

你可以：

class Employee(Person):
    pass

然后：

创建 OWL Class

创建 Individual

调用 HermiT

做 Reasoning。

Oxigraph：

重点不是：

Python Class 映射 OWL Class。

而是：

RDF Storage + SPARQL Engine。

所以：

Owlready2

更偏：

本体应用开发。

而：

Oxigraph

更偏：

RDF 数据库基础设施。

---

十六、它和 Jena TDB2 又是什么区别？

Apache Jena：

Java Ecosystem。

TDB2：

Jena 自己的 RDF Store。

Fuseki：

成熟 SPARQL Server。

还有：

Inference

SHACL

Ontology API

Text Search

GeoSPARQL

整套生态。

Oxigraph：

Rust Core

RocksDB

Python Binding

JS/WASM

CLI/HTTP Server。

更加：

轻量和可嵌入。

所以我不会说：

Oxigraph 替代 Jena。

更准确：

两者定位侧重点不完全一样。

---

十七、如果是 Java 企业系统

我可能优先考虑：

Jena / Fuseki。

因为：

Java

生态：

天然融合。

---

十八、如果是 Python AI 项目

比如：

FastAPI

Agent

GraphRAG

数据流水线

又希望：

内嵌一个速度不错的 RDF Store。

那：

pyoxigraph 就很有意思。

不用：

再启动一个 Java Fuseki Server。

Python：

直接调用。

部署：

很轻。

---

十九、如果本身就是 Rust 项目

那就更直接。

Oxigraph：

本体就是 Rust Library。

你可以：

直接把 RDF/SPARQL 能力
嵌进自己的 Rust Application。

例如：

桌面软件

Edge Agent

本地知识库

CLI Tool

数据处理系统。

这其实是 Oxigraph 很有吸引力的一点。

---

二十、为什么"Embedded RDF Store"在 AI Agent 时代很有意义？

假设你做一个：

本地 AI Agent。

它有：

10000 个联系人

5000 个项目

20000 篇笔记

大量关系

你不一定希望：

用户安装 Java

再启动 Fuseki

再维护独立数据库服务器。

可能只希望：

应用安装
↓
创建本地知识库
↓
直接运行。

这时候：

Embedded Database

就很适合。

---

二十一、例如一个桌面 AI 助手

结构：

Desktop Agent
      │
      ├── Vector Store
      │
      ├── SQLite
      │
      └── Oxigraph
              │
              ↓
          Knowledge Graph

用户资料：

Document

放：

Vector Store。

用户设置：

普通结构化数据

放：

SQLite。

实体关系：

Person
Project
Company
Event
Technology

放：

RDF Graph。

这其实很合理。

---

二十二、王仕宇的观点：未来很多 Agent 不一定需要"一个巨大的知识图谱平台"，而是需要一个小而快的本地图数据库

这是我觉得 Oxigraph 特别值得关注的原因。

过去我们一讲 Knowledge Graph：

马上想到：

企业级集群

几十亿节点

分布式图数据库

大型 Semantic Platform。

但今天 Agent 时代出现了另一种需求：

一个用户

一个项目

一个 Workspace

一个 Agent

需要：

一份自己的结构化关系记忆。

例如：

用户
认识
张三

张三
负责
AI 项目

AI 项目
依赖
MySQL

MySQL
部署于
Server-A

这里可能只有：

几万

几十万

几百万

Triple。

完全不一定需要：

一套超重集群。

这种场景：

我------王仕宇（JavaPub）------认为：

Embedded RDF Store 可能会重新变得非常重要。

---

二十三、这和"Agent Memory"有什么关系？

现在很多 Agent Memory 其实就是：

Conversation
↓
Embedding
↓
Vector DB。

然后问：

我上次提到张三是什么时候？

向量搜索：

很好用。

但是问：

张三负责哪个项目？那个项目依赖哪些数据库？数据库运行在哪些服务器？

这开始变成：

多跳结构关系。

向量搜索：

可以尝试。

但：

Graph Query 更自然。

---

二十四、所以 Agent Memory 可以拆成两类

第一：

Semantic Text Memory。

Conversation

Document

Notes

↓

Vector DB。

---

第二：

Structured Relationship Memory。

Person

Project

Company

Technology

Service

Server

↓

RDF / Knowledge Graph。

这两种：

不冲突。

---

二十五、GraphRAG 也是一样

GraphRAG 的核心之一：

就是：

从非结构化文档
抽实体和关系。

例如：

文档：
张三是 AI 平台项目负责人，
该项目采用 Go 和 PostgreSQL。

LLM 抽取：

张三
↓ manages
AI 平台项目

AI 平台项目
↓ usesTechnology
Go

AI 平台项目
↓ usesDatabase
PostgreSQL

这些 Triple：

总得放一个地方。

Oxigraph：

就可以成为其中一种：

RDF Store 选择。

---

二十六、再接上一篇 Owlready2

你甚至可以：

Owlready2
↓
设计/运行 Ontology

pySHACL
↓
校验候选数据

Oxigraph
↓
长期保存 Triple

形成：

                Ontology
                    │
                    ↓
               Owlready2
                    │
                    ↓
Document → LLM → Candidate RDF
                    │
                    ↓
                 SHACL
                    │
                    ↓
                 Oxigraph
                    │
                    ↓
                  SPARQL
                    │
                    ↓
                  Agent

这已经是一套：

Python AI Semantic Stack。

---

二十七、Oxigraph 支持 SPARQL Update

除了：

SELECT

还可以：

INSERT

DELETE

官方当前实现 SPARQL Query、SPARQL Update 和 Federated Query。

比如新增：

PREFIX ex:
    <http://example.com/company#>

INSERT DATA {

    ex:lisi
        a ex:Employee ;

        ex:name
        "李四" .

}

现在 Knowledge Graph：

可以动态修改。

---

二十八、这对 Agent 写记忆很重要

比如用户说：

记一下，李四现在负责支付系统。

Agent：

解析：

李四
↓ manages
支付系统。

然后：

SPARQL Update

写入。

下一次：

支付系统负责人是谁？

SPARQL：

直接查李四。

这就是：

Structured Agent Memory。

---

二十九、但是 Agent 不应该直接拥有无限 Update 权限

这和前面讲 Fuseki 一样。

如果模型能够随便：

DELETE WHERE { ?s ?p ?o }

那一个错误 Tool Call：

整张图没了。

所以生产里：

LLM

最好不要直接：

自由生成并执行 SPARQL UPDATE。

更合理：

LLM
↓
Intent

Tool
↓
add_project_owner(
    person,
    project
)

Application
↓
校验

SHACL
↓
Update

让代码：

决定真正写什么。

---

三十、Named Graph 非常值得利用

RDF Dataset 不只是：

一堆 Triple。

还可以有：

Quad。

也就是：

Subject

Predicate

Object

Graph。

例如：

graph:hr

保存 HR 数据。

graph:github

保存 GitHub 数据。

graph:llm

保存 AI 抽取数据。

这样：

张三 worksOn AI项目

还可以回答：

这条知识来自哪里？

---

三十一、这是企业知识图谱特别重要的一层

同一个事实可能有多个来源。

HR：

张三
Department
研发部。

项目系统：

张三
Department
AI 平台组。

LLM 从文档里：

张三
Department
技术中心。

如果全部：

直接混到一个 Graph

马上：

冲突。

Named Graph：

可以：

保留来源。

然后：

上层再做可信度和融合。

---

三十二、Oxigraph 还支持 Federated Query

也就是 SPARQL：

SERVICE

可以：

从另一个 SPARQL Endpoint
查询数据。

官方当前明确实现 SPARQL Federated Query。

这意味着理论上：

本地 Oxigraph
+
远端 Fuseki
+
公开 SPARQL Endpoint

可以：

做联邦查询。

---

三十三、比如

本地：

公司人员知识。

远程：

DBpedia / 其他 RDF Endpoint。

一条 Query：

把企业数据
和公共知识
连接起来。

这就是 Semantic Web：

原本很经典的能力。

---

三十四、不过 Agent 场景不要随便开放任意 SERVICE

原因还是：

安全和性能。

如果用户能控制：

SERVICE URL

你的服务器就可能：

请求任意外部地址。

这会产生：

SSRF

慢查询

远程依赖

等问题。

所以：

规范支持，不等于生产必须全部开放。

---

三十五、Oxigraph CLI 也很有意思

项目除了 Library，

还有：

oxigraph

命令行程序。

它可以：

Load RDF

Query

Update

Dump

Backup

Optimize

Serve HTTP。

项目自 0.3.14 起就提供了 Query、Update、Backup、Optimize、Read-only/Secondary Server 等命令，后续还持续增加 Bulk Load、Timeout 等能力。

所以你完全可以：

不写代码先玩。

---

三十六、甚至可以直接启动 SPARQL Server

Oxigraph CLI 可以启动一个：

SPARQL 1.1 HTTP Server。

并支持：

SPARQL Protocol

Graph Store Protocol。

架构马上变成：

Application A
      │
      ↓
    HTTP
      │
      ↓
  Oxigraph Server
      │
      ↓
    RocksDB

这时候它和：

Fuseki

看起来：

就开始像了。

---

三十七、那它和 Fuseki Server 怎么选？

如果你已经在：

Java / Jena

世界里，

Fuseki：

成熟

功能完整

Jena 生态丰富。

自然。

如果你更关注：

Rust

轻量

Embedded

Python Binding

Oxigraph：

更值得研究。

不要总想着：

谁赢谁输？

开源项目选型更应该问：

哪个和我的系统更匹配？

---

三十八、它还有 Read-only / Secondary 模式

Oxigraph 早期版本就加入：

serve-read-only

serve-secondary

等模式，可以打开只读数据或跟随 Primary Store。

这个思路很适合：

Primary
负责写

Secondary
负责读。

特别是 AI Agent：

通常读远多于写。

未来做：

Read-only Query Node

会很有意思。

---

三十九、Backup 也必须重视

只要：

Oxigraph

开始保存：

真正业务知识。

它就不是：

一个 Demo Library。

而是：

Database。

所以必须考虑：

Backup

Restore

Disk

Monitoring

Version Upgrade。

CLI 已经提供：

backup

dump

optimize

这类数据库维护能力。

---

四十、这里要特别注意磁盘格式升级

数据库项目最危险的一种升级：

就是：

直接换版本

但底层：

On-disk Format

可能变化。

Oxigraph 历史版本中就出现过 Disk Data Format 迁移。

所以生产：

不应该看到 pip install -U 就直接升级。

至少：

Backup

Read Changelog

Staging Test

Restore Test

都值得做。

---

四十一、最新版为什么值得关注？

当前 PyPI 的 pyoxigraph 已到：

0.5.12

时间：

2026-10-18。

而 0.5.x 系列已经持续加入：

JSON-LD 1.1

Parallel Loading

Query Preparation

SPARQL 1.2 部分能力

RDF Dataset Canonicalization

等特性。

这说明：

项目还在非常活跃地迭代。

---

四十二、但官方仍然标记 Alpha / Heavy Development

这点文章一定要写清楚。

PyPI 当前 Development Status：

3 - Alpha。

官方 README：

也仍然写明：

heavy development

以及 SPARQL Query Evaluation：

还没有完全优化。

所以我不会建议：

银行核心系统现在立刻全迁 Oxigraph。

这不是负面。

而是：

正确理解项目成熟度。

---

四十三、王仕宇的观点：开源项目文章一定要把"能跑"和"适合生产"分开

这是我特别想强调的一点。

现在很多项目介绍文章：

GitHub Star 很高
+
Hello World 能跑

然后结论：

可以上生产。

这个逻辑：

很危险。

评估数据库至少要看：

版本成熟度

Backup

Crash Recovery

Concurrency

Query Performance

Upgrade

Monitoring

Security

社区

生产案例。

所以在我------王仕宇（JavaPub）------看来：

Oxigraph 现在特别值得学习、做 Demo、做 Embedded Semantic Application 和新型 Agent Memory 实验，但大型核心生产系统仍然应该认真压测和评估成熟度。

这比单纯一句：

Rust 写的，所以快。

靠谱得多。

---

四十四、不过它特别适合个人 AI 项目

比如：

个人知识库

桌面 Agent

本地 Second Brain

代码知识图谱

项目依赖关系

联系人关系。

原因：

数据规模可控

部署简单

本地优先

需要结构关系

Python/Rust 都方便。

这种场景：

和 Oxigraph 非常匹配。

---

四十五、例如做代码知识图谱

可以存：

Repository
↓ contains
Package

Package
↓ contains
Class

Class
↓ calls
Method

Service
↓ usesDatabase
MySQL

Service
↓ deployedOn
Kubernetes。

然后 Agent：

payment-service 调用了哪些外部服务？

SPARQL：

直接查图。

再：

哪些服务依赖 payment-service？

这是：

Reverse Relationship Query。

Graph：

很自然。

---

四十六、再结合 GitHub

Agent 可以：

扫描 Repository
↓
AST 分析
↓
生成 Entity / Relation
↓
写 Oxigraph

例如：

main.go
defines
UserService

UserService
calls
UserRepository

UserRepository
usesTable
user

然后：

代码知识开始结构化。

这就比：

只把整个 Repository
丢进 Embedding

多了一套：

精确关系层。

---

四十七、向量检索仍然保留

比如用户问：

登录模块为什么这么设计？

这个问题：

涉及代码语义和文档上下文。

Vector RAG：

很好用。

而：

LoginService 调了哪些 Repository？

Graph：

更精确。

所以：

Vector
+
Graph

组合：

比二选一好。

---

四十八、可以设计一个 Hybrid Retrieval

                 User Question
                       │
                       ↓
                      LLM
                       │
                       ↓
                  Query Router
                  /           \
                 ↓             ↓
              Vector          SPARQL
                 │             │
                 ↓             ↓
            Document DB     Oxigraph
                 │             │
                 └──────┬──────┘
                        ↓
                      LLM

这就是：

GraphRAG 更成熟的一种实现方式。

---

四十九、甚至可以让 Oxigraph 存"记忆关系"

用户告诉 Agent：

王仕宇做 JavaPub，最近在研究 Ontology 和知识图谱。

可以存：

王仕宇
operates
JavaPub

王仕宇
researches
Ontology

Ontology
relatedTo
KnowledgeGraph

以后：

JavaPub 最近研究什么？

Agent：

直接查结构关系。

这就是：

Personal Knowledge Graph。

---

五十、但敏感信息一定要考虑

如果 Personal Agent：

把联系人

工作关系

家庭关系

财务关系

都写进图谱，

那：

Knowledge Graph 本身就是敏感数据库。

因此：

加密

权限

备份

删除

本地优先

都必须考虑。

"本地知识图谱"：

不自动等于安全。

---

五十一、Docker 怎么部署？

Oxigraph CLI 本身提供 Docker 使用方式，项目官方仓库把 Docker 支持放在 CLI 部分。

真正部署时：

应该把：

程序

和：

RocksDB Data Directory

分开。

结构：

Container
│
└── Oxigraph

Persistent Volume
│
└── RocksDB Data

Container：

可以重建。

数据：

不能跟着消失。

---

五十二、这又回到了 Docker 系列

如果 Container 化 Oxigraph，

一样要考虑：

Volume

CPU

Memory

NOFILE

Log Rotation

Health Check

Backup

Disk IO。

尤其：

RocksDB 是磁盘数据库。

磁盘：

IOPS

Latency

Space

一定会影响。

不要：

把它放一个极慢磁盘

然后怪：

SPARQL 性能差。

---

五十三、RocksDB 还特别值得注意 NOFILE

前面 Docker 系列刚写过：

Too many open files。

很巧，

Oxigraph 0.5.5 的 Changelog 就专门修复过：

当 ulimit -n 设置得非常大时
RocksDB Panic

相关问题。

这正好说明：

数据库和 OS Resource Limit 永远是连在一起的。

技术文章如果把：

RDF

SPARQL

只讲到语法，

不讲：

磁盘

FD

资源

Backup

其实离生产：

还很远。

---

五十四、批量导入也有专门优化

如果一次导入：

1000 万 Triple。

不能：

Python for 循环
一条一条 insert。

Oxigraph 当前持续优化 Bulk Loading，0.5.x 已加入 Parallel Load，以及 CLI 非原子批量 Load 等能力。

所以：

初始化导入

和：

在线小批量 Update

应该：

使用不同策略。

这和 MySQL：

INSERT 一行

LOAD DATA

是一个道理。

---

五十五、Query Timeout 也很重要

0.5 系列 CLI 已加入：

--timeout-s

用于 Query Timeout。

为什么？

因为 Agent：

特别容易生成重查询。

比如：

SELECT *
WHERE {
    ?a ?b ?c .
    ?c ?d ?e .
    ?e ?f ?g .
}

在大 Dataset：

可能很恐怖。

所以 AI + Database：

一定要有：

Timeout

Limit

Query Budget

Read-only Boundary。

---

五十六、不要让 Agent 默认 SELECT *

这和 SQL Agent 一模一样。

LLM 很喜欢：

SELECT *

因为：

简单。

但 Dataset：

几千万 Triple

一个错误 Query：

结果集巨大。

所以 Tool 层最好：

强制 LIMIT

超时

Query Review。

甚至：

只允许 predefined query。

---

五十七、我更推荐 Agent 用模板 Query

例如：

def find_projects_by_employee(
    employee_iri
):
    ...

而不是：

def execute_any_sparql(
    query
):
    ...

前者：

权限可控。

后者：

万能，但风险更高。

在 Demo：

any_sparql

很爽。

生产：

要谨慎。

---

五十八、SPARQL Injection 同样存在

用户输入：

张三

不要直接：

query = f'''
?x ex:name "{user_input}"
'''

和 SQL 一样：

字符串拼接就是风险点。

应该：

参数绑定

安全构造 RDF Term

Tool 参数校验。

不要觉得：

SPARQL 不是 SQL

就没有 Injection。

---

五十九、Oxigraph 也在往 SPARQL 1.2 走

目前官方说明：

RDF / SPARQL / JSON-LD
主要实现仍以 1.1 Recommendation 为基础

同时已经：

初步支持部分 RDF 1.2 和 SPARQL 1.2 Draft 能力。

比如 0.5.3 已加入：

SPARQL 1.2 VERSION declaration

等能力。

对于研究 RDF 新标准的人：

很值得跟。

---

六十、RDF Dataset Canonicalization 也值得注意

当前 Oxigraph 还实现：

RDF Dataset Canonicalization。

为什么需要 Canonicalization？

因为 RDF 中：

Blank Node

的内部标识：

不天然稳定。

如果要：

签名

Diff

Hash

验证两个 Dataset 是否等价

就需要：

Canonical Form。

这和：

供应链签名

知识图谱版本管理

其实很有关系。

---

六十一、未来 Knowledge Graph 也会需要版本管理

现在我们对代码：

Git。

对 Docker Image：

Digest。

对 Artifact：

Hash / Signature。

那知识图谱呢？

未来也会逐渐需要：

Graph Version

Dataset Hash

Provenance

Diff

Signature。

不然：

今天 Agent 查到这个答案，明天为什么变了？

很难解释。

所以：

RDF Canonicalization

这种看起来很底层的能力，

以后：

可能越来越重要。

---

六十二、Oxigraph 还提供 JavaScript / WASM

这也非常有意思。

官方项目当前通过 WebAssembly 提供 JavaScript Binding，可以用于 Node.js / Bundler 场景。

这意味着：

Rust
Python
JavaScript

三个生态：

都能碰到同一个 RDF/SPARQL Core。

甚至未来：

Web Application

本地运行小型 RDF Store，

也是：

很有想象空间的。

---

六十三、比如浏览器本地知识库

想象：

用户上传文档
↓
浏览器解析
↓
LLM / Local Model 抽实体
↓
WASM Oxigraph
↓
本地 RDF Graph

数据：

不离开设备。

然后：

SPARQL

直接：

浏览器里查。

这种：

Local-first AI

架构会越来越有意思。

---

六十四、为什么 Rust 项目越来越值得 AI 开发者关注？

因为越来越多：

Python Package

表面：

pip install

底下：

已经是 Rust。

比如：

Parser

Database

Tokenizer

Inference Runtime

Vector Engine

原因很简单：

Python
负责开发效率

Rust
负责底层性能与安全。

Oxigraph：

就是一个非常典型的例子。

---

六十五、这对 Python 开发者其实是好事

因为你不用：

先学 Rust
才能使用。

直接：

pip install pyoxigraph

就行。

真正有兴趣：

再：

下源码
↓
看 Rust 实现。

这其实是一条很好的：

Rust 学习路径。

不是：

先背 Ownership 100 页

而是：

从一个真实数据库项目往下看。

---

六十六、如果准备读源码，先看哪些模块？

我建议顺序：

oxrdf

先理解：

RDF Term。

---

然后：

oxrdfio

看：

Turtle / NTriples 怎么 Parse。

---

然后：

spargebra

看：

SPARQL AST。

---

再：

sparopt

看：

Query Optimization。

---

最后：

oxigraph Store

看：

RocksDB 索引怎么组织。

这比：

一上来打开整个 Repo

舒服很多。

---

六十七、数据库最值得学的是索引

RDF Triple：

S P O

如果只存一种顺序：

Subject
Predicate
Object

那么：

按 Object 查

会很痛苦。

所以 RDF Store：

通常需要：

不同排列的 Index

来服务不同 Triple Pattern。

例如概念上：

SPO

POS

OSP

甚至 Quad：

Graph

加入以后：

组合更复杂。

这是 RDF Database 内核特别值得研究的一点。

---

六十八、这和 MySQL B+Tree 是完全不同、但又非常相似的问题

MySQL：

WHERE user_id = ?

有没有 Index：

差很多。

SPARQL：

?s
    ex:belongsTo
    ex:rd .

其实也是：

Predicate 固定

Object 固定

Subject 未知。

Storage Engine：

必须快速找匹配 Triple。

所以数据库不管：

SQL

SPARQL

底层最终都绕不开：

索引。

---

六十九、Query Optimizer 也特别有意思

比如：

?employee
    ex:worksOn
    ?project .

?employee
    ex:belongsTo
    ex:rd .

?project
    ex:serves
    ?customer .

应该：

先查哪一条？

如果：

研发部员工只有 20 个

先：

belongsTo rd

很合理。

如果：

几百万员工

但某个 Project：

只有 3 人

可能：

另一种 Join Order 更好。

这和 SQL Optimizer：

完全一样。

---

七十、Oxigraph 自己也在持续优化这一层

项目 0.5.x 持续增加和调整：

SPARQL Optimizer

Join Ordering

Prepared Evaluation

Profiling

相关能力，而最新主分支还在继续暴露 Join / Variable Elimination Order 给外部执行引擎使用。

所以如果你想研究：

图查询优化器，

Oxigraph：

是一个很好读的真实项目。

---

七十一、王仕宇的观点：学习开源项目最好的方式不是只跑起来，而是找它最难的那一层

很多教程：

docker run
↓
浏览器打开
↓
结束。

这种当然适合入门。

但是我------王仕宇------更建议：

跑起来以后继续问：

数据到底怎么存？

索引怎么建？

SPARQL 怎么 Parse？

Join 怎么优化？

事务怎么做？

RocksDB 怎么交互？

Backup 怎么做？

这样：

一个开源项目能拆出十篇真正有价值的文章。

否则永远只是：

"又发现一个 GitHub 项目"。

长期内容价值：

很有限。

---

七十二、Oxigraph 适不适合 Ontology Reasoning？

这里一定要说清楚。

Oxigraph 的核心定位：

RDF/SPARQL Store 和 Toolkit。

它不是像：

Owlready2 + HermiT

那样把：

OWL DL Reasoning

作为核心卖点。

所以如果系统非常依赖：

复杂 OWL 推理

你可能还是需要：

专门 Reasoner

或者其他 Semantic Framework。

Oxigraph 更擅长：

存和查。

---

七十三、这也是为什么技术栈可以组合

例如：

Protégé
↓
设计 Ontology

Owlready2 / Reasoner
↓
推理

pySHACL
↓
验证

Oxigraph
↓
存储与查询

Agent
↓
自然语言入口

不是：

找到一个项目，然后其他项目全部删掉。

真正的工程系统：

通常是组合。

---

七十四、一个完整 AI Ontology 项目可以这样

                Business Docs
                      │
                      ↓
                     LLM
                      │
                      ↓
               Candidate Entities
                      │
                      ↓
              Entity Resolution
                      │
                      ↓
                   SHACL
                      │
                 Pass / Fail
                      │
                      ↓
                  Oxigraph
                      │
                     RDF
                      │
                      ↓
                   SPARQL
                      │
                      ↓
                    Agent

Ontology：

定义整个语义世界。

这已经：

非常完整。

---

七十五、如果加上 Vector RAG

                 Documents
                /         \
               ↓           ↓
          Embedding       LLM
               │           │
               ↓           ↓
          Vector DB     RDF Triple
                           │
                           ↓
                        Oxigraph
               \           /
                \         /
                 ↓       ↓
                    Agent

用户一个问题：

Agent：

需要原文语义
→
Vector

需要结构关系
→
SPARQL。

这就是：

Hybrid RAG。

---

七十六、我认为这一类架构会越来越多

因为单纯：

向量相似度

解决不了所有知识问题。

比如：

A 项目依赖哪个系统？这个系统的负责人是谁？负责人还维护哪些项目？

这是：

Project
↓ dependsOn
Service
↓ ownedBy
Employee
↓ owns
Project

天然：

Graph Traversal。

如果文档中：

这些关系散在几十篇文章里

Vector RAG 每次都重新拼：

成本很高。

Knowledge Graph：

可以直接维护关系。

---

七十七、但也不要走到另一个极端

看到 Knowledge Graph：

就想：

所有文档

所有句子

所有 Chunk

所有 Token

全部变成 Triple。

那：

系统也会失控。

我的建议：

结构明确、长期稳定的：

实体

关系

状态

归属

放 Graph。

需要原文理解的：

文档

描述

上下文

放 Vector / Search。

这是：

分工。

---

七十八、如果只做 Demo，我建议这样开始

第一：

pip install pyoxigraph

---

第二：

做五个实体：

张三

研发部

AI项目

A客户

Go。

---

第三：

建立关系：

张三 belongsTo 研发部

张三 worksOn AI项目

张三 knowsTechnology Go

AI项目 serves A客户。

---

第四：

写五条 SPARQL。

例如：

查员工

查部门

查项目

查技术

做两跳查询。

---

第五：

切磁盘 Store。

---

第六：

启动 HTTP Server。

---

第七：

接 FastAPI / Agent。

这一遍跑完：

Oxigraph 基本就理解了。

---

七十九、然后做一个小工具

比如：

JavaPub Knowledge Graph

接口：

POST /facts

GET /person/{name}

GET /project/{name}

POST /query

底层：

FastAPI
+
pyoxigraph。

数据：

RocksDB。

然后加：

LLM。

立刻：

就是一个最小 Knowledge Agent。

---

八十、再加 SHACL 就更完整

写入之前：

Agent
↓
Candidate Triple
↓
SHACL Validation

例如：

Person
必须有 name。

worksOn
对象必须是 Project。

belongsTo
对象必须是 Department。

通过：

才写 Oxigraph。

这样：

LLM

不能：

随便把图写烂。

---

八十一、再加 Provenance

每一条 AI 抽取的知识：

放：

graph:llm-extracted

人工确认：

转到：

graph:verified。

原始系统同步：

graph:system-of-record。

于是：

同一条知识

有：

信任等级。

这就比：

LLM 抽到就直接当事实

成熟很多。

---

八十二、最后再说一次它不是什么

Oxigraph：

不是 Neo4j 的 Rust 平替这么简单。

因为：

Neo4j

核心：

Property Graph

Cypher

Graph Algorithms / Ecosystem。

Oxigraph：

核心：

RDF

Dataset

IRI

Named Graph

SPARQL

Semantic Web Standards。

两种 Graph Model：

本来就不一样。

---

八十三、如果你真正做 Ontology

我反而更偏：

RDF / OWL / SPARQL。

因为：

Ontology Standard

本来就围绕：

RDF

RDFS

OWL。

这时候：

Oxigraph

Jena

Fuseki

GraphDB

这类 RDF Stack：

更自然。

---

八十四、如果只是社交网络推荐

比如：

好友

关注

推荐

最短路径

社区发现。

Property Graph：

可能更自然。

所以：

Knowledge Graph 也不是只有一种数据库。

关键：

先看你的语义模型。

---

八十五、整个系列到现在可以这样整理

Protégé
│
└── Ontology Design

Owlready2
│
└── Python Ontology Programming

pySHACL
│
└── RDF Validation

Apache Jena
│
├── RDF
├── SPARQL
├── TDB2
└── Fuseki

Ontop
│
└── Virtual Knowledge Graph

Oxigraph
│
├── Rust RDF Store
├── RocksDB
├── SPARQL
└── Python / JS / HTTP

现在：

每个项目的位置已经越来越清楚。

---

八十六、王仕宇的判断：Ontology 真正值得关注的地方已经不是 Semantic Web 本身，而是 Agent 需要"可计算的业务世界"

以前讲 Ontology：

容易让程序员想到：

Semantic Web

RDF/XML

学术论文。

但今天再看：

环境已经不同。

LLM：

能理解语言。

Agent：

能调用工具。

RAG：

能找到文本。

真正缺的一层越来越明显：

企业自己的世界结构。

比如：

人

公司

项目

系统

服务器

接口

客户

产品

之间：

到底怎么连接？

这些关系如果永远散落在：

Wiki

数据库

代码

人的脑子里

Agent：

永远需要现场猜。

而 Ontology + Knowledge Graph：

就是把：

这些关系变成机器可以查询的东西。

---

八十七、Oxigraph 的价值正是在"执行层"

Protégé：

告诉我们世界怎么设计。

Owlready2：

告诉 Python 怎么操作世界。

SHACL：

告诉系统哪些事实合法。

Oxigraph：

把这些事实真正存下来，并提供 SPARQL 查询。

可以简单理解：

Ontology
=
地图规则

RDF
=
地图数据

Oxigraph
=
地图数据库

SPARQL
=
地图查询语言

Agent
=
用户入口。

---

总结

Oxigraph 是一个用 Rust 构建的：

RDF / SPARQL Graph Database + Toolkit。

它目前使用：

RocksDB

作为主要磁盘存储，并提供：

Rust Library

pyoxigraph

JavaScript / WASM Binding

CLI

SPARQL HTTP Server

等多种使用方式。官方当前实现 SPARQL Query、SPARQL Update、Federated Query，并支持 Turtle、TriG、N-Triples、N-Quads、RDF/XML、JSON-LD 等 RDF 格式，同时开始支持部分 RDF/SPARQL 1.2 草案能力。

截至 2026 年 10 月 18 日：

pyoxigraph
=
0.5.12。

不过项目目前仍处在：

快速开发 / Alpha

阶段，官方也明确说明 SPARQL Query Evaluation 仍有进一步优化空间，因此学习和新项目试验非常值得，但核心大型生产系统应根据真实数据和 Query Pattern 做完整压测与风险评估。

我是 王仕宇，JavaPub。

在我看来，Oxigraph 真正值得关注的地方，并不只是：

"Rust 又写了一个图数据库"。

而是它代表了一类越来越有价值的基础设施：

Embedded Semantic Database。

以前一说知识图谱：

大家想到的是：

一套独立大平台。

但随着：

AI Agent

Local-first AI

GraphRAG

Personal Knowledge Graph

代码知识图谱

这些应用越来越多，

未来大量应用真正需要的可能只是：

一个本地 Store

支持 RDF

支持 SPARQL

能嵌入 Python / Rust

能持久化

足够轻量。

这种需求：

Oxigraph 正好非常值得研究。

如果把整个 AI Knowledge Stack 拆开：

LLM
↓
负责理解自然语言

Vector DB
↓
负责找相关文本

Ontology
↓
负责定义业务世界

SHACL
↓
负责约束数据质量

Oxigraph
↓
负责保存和查询实体关系

Agent
↓
负责把这些能力组合起来

你会发现：

向量数据库只是 AI 知识系统的一部分。

真正复杂的企业知识：

还需要：

结构

关系

约束

来源

推理

查询。

这也是我------王仕宇------目前越来越关注 Ontology 和 Knowledge Graph 的原因。

如果只记住一句话：

Oxigraph 最有意思的地方，不是"它用 Rust 写，所以一定很快"，而是它让 RDF/SPARQL 从一套偏语义网的标准，变成了一个可以直接嵌进 Python、Rust、JavaScript 和 AI Agent 应用里的轻量知识数据库内核。

---

本文由王仕宇（JavaPub）整理与分享。

持续关注方向：

AI Agent

Ontology

知识图谱

GraphRAG

RDF

SPARQL

Rust

Python

Java

Docker

开源项目

后续我会继续把：

Ontology → Knowledge Graph → GraphRAG → AI Agent

这一整条技术链，站在程序员和真实工程落地的角度，一篇篇拆开。