知识图谱的本质是一张由实体和关系构成的大网，而这张网最基本的组成单元就是三元组：主体-谓词-客体。很多人一想到知识图谱存储，第一反应就是Neo4j这样的图数据库，但实际项目中，如果数据规模在千万级以内、查询以固定模式为主，用SQLite实现一套三元组存储完全够用，而且零部署、零运维，单文件数据库随项目一起分发。本文将完整讲解如何用SQLite设计和优化一套知识图谱三元组存储方案。
一、三元组模型与表结构设计
三元组的存储有两条路线：一是直接用一张大宽表，每行存一个字符串形式的三元组；二是把实体和谓词抽出来单独建表，用整数主键关联。第一种方案实现简单，但字符串重复存储会造成严重的空间浪费，而且字符串匹配的速度远不如整数比较。
推荐的做法是三表结构：实体表存储所有实体并为每个实体分配一个自增ID，谓词表同理，关系表只存三个整数外键。这样即使实体名称长达几十个字符，关系表中每行也只需要十几个字节。对于一个拥有百万实体的图谱，这种设计能轻松把存储体积压缩到宽表方案的十分之一左右。
CREATE TABLE entity (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
type TEXT DEFAULT '',
UNIQUE(name, type)
);
CREATE TABLE predicate (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL UNIQUE
);
CREATE TABLE triple (
subject_id INTEGER NOT NULL,
predicate_id INTEGER NOT NULL,
object_id INTEGER NOT NULL,
weight REAL DEFAULT 1.0,
FOREIGN KEY (subject_id) REFERENCES entity(id),
FOREIGN KEY (predicate_id) REFERENCES predicate(id),
FOREIGN KEY (object_id) REFERENCES entity(id),
UNIQUE(subject_id, predicate_id, object_id)
);关系表上的UNIQUE约束很关键，它一方面防止重复导入相同三元组，另一方面会自动创建一个以subject_id开头的复合唯一索引，为最常见的“查某实体所有出边”查询提供加速。weight字段留给置信度或关系强度使用，做知识融合时非常有用。
二、索引设计与多跳查询实现
三元组查询最常见的三种模式是：给定主体查客体、给定客体查主体、以及给定一对实体查关系。默认的唯一索引只覆盖了第一种，另外两种需要补充索引。
-- 加速反向查询：已知客体找主体 CREATE INDEX idx_triple_object ON triple(object_id, predicate_id); -- 加速谓词筛选：按关系类型批量查询 CREATE INDEX idx_triple_predicate ON triple(predicate_id, subject_id);
索引不是越多越好。每多一个索引，写入时就要多维护一棵B树，批量导入速度会明显下降。经验做法是：导入阶段先删除次要索引，数据落库后再统一重建，重建一千万行的索引通常只需要几十秒，远比边插边维护快。
知识图谱真正体现价值的是多跳查询，比如“某人的朋友的同事做过哪些项目”。这类查询在SQLite里要用递归CTE实现。SQLite从3.8.3版本开始支持WITH RECURSIVE语法，完全够用。
WITH RECURSIVE related(entity_id, depth) AS (
-- 起点：从实体 张三 出发
SELECT id, 0 FROM entity WHERE name = '张三'
UNION
-- 递归：沿三元组扩展一跳，最多三跳
SELECT t.object_id, r.depth + 1
FROM related r
JOIN triple t ON t.subject_id = r.entity_id
WHERE r.depth < 3
)
SELECT DISTINCT e.name, r.depth
FROM related r
JOIN entity e ON e.id = r.entity_id
ORDER BY r.depth;需要注意的是，递归查询必须限制深度。知识图谱中高度连接的节点（比如“中国”这种枢纽实体）如果不设深度上限，递归可能把整张图都遍历一遍。实际业务中两到三跳已经能覆盖绝大多数关联挖掘场景，深度越大，返回结果的相关性反而越差。
三、批量导入性能优化
用Python的sqlite3模块导入数据时，新手常犯的错误是在循环中逐条执行INSERT并commit，这样每次提交都会触发一次磁盘fsync，导入一百万条数据可能要跑半个小时。正确的做法是把整个导入过程包在一个事务里，或者用executemany批量执行。
import sqlite3
conn = sqlite3.connect('kg.db')
cur = conn.cursor()
# 开启预编译缓存，提升重复语句执行效率
cur.executescript('PRAGMA cache_size = -64000; PRAGMA temp_store = MEMORY;')
# 批量插入实体，一次提交
entities = [('张三', '人物'), ('李四', '人物'), ('某科技公司', '组织')]
cur.executemany('INSERT OR IGNORE INTO entity(name, type) VALUES (?, ?)', entities)
# 建立名称到ID的映射缓存，避免反复查询
name_map = {name: eid for name, _ in entities
for eid in [cur.execute(
'SELECT id FROM entity WHERE name = ?', (name,)
).fetchone()[0]]}
# 批量插入三元组
triples = [(name_map['张三'], 1, name_map['某科技公司']),
(name_map['李四'], 1, name_map['某科技公司'])]
cur.executemany(
'INSERT OR IGNORE INTO triple(subject_id, predicate_id, object_id) VALUES (?, ?, ?)',
triples)
conn.commit()除了批量提交，还有几个PRAGMA参数值得调整。PRAGMA journal_mode = WAL能让读写不再互相阻塞，Web应用场景下尤其重要；PRAGMA synchronous = NORMAL在WAL模式下兼顾安全与速度；PRAGMA foreign_keys默认是关闭的，如果需要外键约束生效，每次连接后要手动打开，不过导入阶段建议保持关闭以提升速度。
另外要善用INSERT OR IGNORE。知识图谱的数据源往往来自多个渠道，重复三元组很常见，配合前面的UNIQUE约束，OR IGNORE能保证幂等导入，同一份数据导入多次结果一致，这在定时增量更新场景中至关重要。
四、实体消歧与数据质量维护
三元组存储只是基础，真正影响图谱可用性的是数据质量。最典型的问题是实体消歧：不同数据源里“苹果”可能指水果也可能指公司，“张伟”更是重名重灾区。前面实体表设计中的type字段就是为消歧预留的，UNIQUE(name, type)的组合约束允许同名不同类型的实体共存，但如果同一类型下也有重名，就需要引入额外的消歧策略。
一种轻量做法是给实体加别名表，把各种变体名称统一映射到标准实体ID上。查询入口先经过别名表归一化，再进入三元组查询，这样“腾讯”“腾讯公司”"Tencent"都能命中同一个实体。
CREATE TABLE alias (
entity_id INTEGER NOT NULL,
alias_name TEXT NOT NULL,
PRIMARY KEY (entity_id, alias_name),
FOREIGN KEY (entity_id) REFERENCES entity(id)
);
CREATE INDEX idx_alias_name ON alias(alias_name);对于冲突三元组，比如两个来源给出了矛盾的出生日期，可以在导入时用weight字段记录来源置信度，查询时取权重最高的一条。也可以建立审核表，把低置信度的冲突数据隔离出来等待人工确认，避免脏数据直接污染线上图谱。
总结一下，用SQLite做知识图谱存储的核心思路是：整数外键压缩存储、针对性索引覆盖查询模式、递归CTE支撑多跳遍历、事务批量导入保证写入吞吐、别名表和权重字段兜底数据质量。这套方案在单机千万级三元组规模下表现稳定，数据库文件可以直接拷贝分发，非常适合嵌入式场景、原型验证以及中小型知识库项目。当数据规模增长到亿级以上、查询模式变得高度动态时，再考虑迁移到专业图数据库也不迟。