OntoDB — 本体内核嵌入的多模态语义数据库
English | 中文
全球首个将 OWL 推理引擎嵌入数据库内核的多模态语义数据库
支持 12 种数据类型统一存储，一次 INSERT 自动完成 7 步写入联动，嵌入式增量推理性能较外置方案提升 100 倍。
为什么选择 OntoDB
大多数团队的现状：关系型数据在 MySQL/PostgreSQL等、图谱在 Neo4j、向量在 Milvus、时序在 InfluxDB、推理在 Jena——查一个问题要跨 5 个系统，写入后还要 ETL 同步，分类知识硬编码在应用里。数据很多，知识很少。
OntoDB 用一个引擎解决这件事：
| 维度 | 传统方案 | OntoDB |
|---|---|---|
| 架构 | MySQL + Neo4j + Milvus + InfluxDB + PostGIS + Jena，6 个系统 | 1 个系统，12 种数据类型统一存储 |
| 语义 | 数据写入后需要 ETL 流程生成语义，延迟秒级到分钟级 | 写入即语义就绪，7 步联动管线原子完成，延迟微秒级 |
| 推理 | 推理引擎外置，跨系统数据搬运 | OWL 推理内嵌存储引擎，共享内存空间，零搬运 |
| 查询 | SQL + Cypher + SPARQL + 专用 API，4 种语言 | OntoQL，单一语法融合关系+图+向量+推理 |
| 语义元数据 | 元数据只描述表结构（pg_catalog），分类知识在应用代码里 |
本体即元数据：类继承/等价/互斥可推理，subClassOf 查询自动展开子类 |
| 部署 | 6 套独立系统，运维复杂 | 边缘三级部署，从 ESP32 到云服务器统一架构 |
| 多租户 | 应用层加 tenant_id，容易遗漏 | 命名空间作用域隔离，类名前缀路由零开销 |
| 数据生命 | TTL 固定过期，不懂数据价值 | 活数据衰减，数据越用越活，不用自动降级 |
| 可靠性 | 依赖运气和重启 | 块级 CRC + 哨兵校验，损坏数据确定性拒绝，堆损坏根因闭合 |
| 成本 | 6 套系统 × 6 份运维 × 6 份许可 | 1 套系统，运维成本降低 80%+ |
生产实测（生物医药知识图谱，12 核 / 32GB / NVMe）：
- 2,800 万+ 条知识记录（105 张实体/关系表）+ 245 万分子结构，7×24 在线零崩溃
- 607k 行 GROUP BY 123ms（90×）；大表扫描 2,546 rps（238×）
- 查"EGFR 抑制剂"自动命中所有子类药物，新增子类零代码
一句话：别的数据库存数据，OntoDB 让数据可理解、可推理、可校验。
语义元数据 vs 传统元数据
传统数据库的元数据（如 PostgreSQL 的 pg_catalog / information_schema）只描述表结构——表名、列类型、索引、约束。分类知识、关系语义、蕴含规则都在应用代码里，数据库本身"看不懂"数据。
OntoDB 把本体（Ontology） 内嵌进存储内核——它不只是 schema，而是可推理的领域知识。
逐项对比（以 PostgreSQL 为基线）
| 维度 | PostgreSQL 元数据 | OntoDB 语义元数据 | 差距本质 |
|---|---|---|---|
| 存储位置 | pg_catalog 系统表（独立命名空间） |
与数据同库、同事务 | PG 是"档案柜"，OntoDB 是"活知识" |
| 描述对象 | 表/列/索引/约束/权限 | 概念/属性/关系/继承/等价 | 结构 vs 语义 |
| 继承查询 | 表继承（INHERITS）不参与查询展开，需手动 UNION ALL |
subClassOf 查询自动展开子类 |
PG 靠应用层硬编码 |
| 约束类型 | NOT NULL / UNIQUE / CHECK / FK | 上述全部 + OWL：disjoint / inverseOf / transitive / equivalentClass | PG 管单表，OWL 管跨表语义 |
| 推理能力 | 无 | 写入即推理（增量不动点，50.8µs） | PG 存事实，OntoDB 推新事实 |
| 关系语义 | 外键只保证引用完整性 | inverseOf 自动对称、transitive 自动传递 |
PG 知道"引用了"，不知道"意味着什么" |
| 跨模态查询 | 需外挂 pgvector/pgRouting 等扩展 | 12 种模态原生统一查询 | PG 是拼装，OntoDB 是一体 |
| 标准兼容 | SQL 标准 | SQL + OntoQL + SPARQL / RDF | 语义网生态直接对接 |
| 数据质量门 | 写入时类型检查 | 必填 + 类型 + OWL 限制 + 逻辑一致性 | PG 拦截格式错误，OntoDB 拦截语义矛盾 |
| 元数据消费方 | 优化器、DDL、BI 工具 | 优化器 + 推理引擎 + 校验器 + 图谱 + AI | 服务工具 vs 驱动智能 |
一个具体例子
查"所有 EGFR 抑制剂"：
sql
-- PostgreSQL：必须自己维护子类列表，新药上市要改代码发版
SELECT * FROM drug
WHERE class IN ('EGFRInhibitor', 'FirstGenEGFR', 'SecondGenEGFR', 'ThirdGenEGFR');
-- OntoDB：本体声明 subClassOf，查询自动展开
SELECT * FROM kb.Drug WHERE class = 'EGFRInhibitor';
-- 吉非替尼、厄洛替尼、奥希替尼、阿美替尼……全部命中，新增子类零改动
为什么 PG 做不到：pg_catalog 记录的是"drug 表有 class 列"，不记录"EGFRInhibitor 是 KinaseInhibitor 的子类"。这个知识存在应用代码里，不在元数据里。
本体定义包含什么
sql
CREATE ONTOLOGY kb (
CLASS kb.Compound,
PROPERTY id DOMAIN kb.Compound RANGE STRING,
PROPERTY smiles DOMAIN kb.Compound RANGE STRING,
PROPERTY inchi_key DOMAIN kb.Compound RANGE STRING,
PROPERTY formula DOMAIN kb.Compound RANGE STRING,
PROPERTY mol_weight DOMAIN kb.Compound RANGE STRING
)
这不只是建表——它是可推理的知识定义：类可 SUBCLASS OF 父类形成分类体系，属性可声明 inverseOf（抑制↔被抑制）、transitive（传递性），类可声明 disjointWith（Drug 与 Disease 互斥）。
四项核心价值
- 查询语义自动展开——
subClassOf推理，查父类自动含子类，分类体系越深收益越大 - 写入即数据质量门——注册本体后，每次 INSERT 自动校验必填/类型/OWL 约束，语义矛盾进不了库
- 跨模态语义锚点——图、向量、文档、时序共享同一套本体，关系语义可推理、可演进，不硬编码在查询里
- 对接语义网与 AI 生态——SPARQL/RDF 兼容，可导入 ChEBI/HPO/GO 等标准本体，是 RAG/知识图谱/AI 的标准输入
一句话：普通元数据回答"表长什么样"，OntoDB 的语义元数据回答"数据是什么意思、彼此有什么关系、推得出什么新知识"。
向量检索 vs 传统向量库
传统方案把向量当孤立的浮点数组：Milvus / pgvector 存 embedding，做 Top-K，和业务表、知识图谱是两套世界——查完相似还要回业务库 join，元数据过滤要么提前跑 SQL 圈 ID，要么向量库自己做粗糙标量过滤。向量在，知识不在。
OntoDB 把向量索引内核级嵌进存储引擎：向量和文档、图、本体同库同事务，检索时 SQL 谓词、图关系、本体推理原生参与，不是外挂扩展。
逐项对比（以 Milvus / pgvector 为基线）
| 维度 | Milvus / pgvector | OntoDB 向量能力 | 差距本质 |
|---|---|---|---|
| 架构 | 独立向量库 + 业务库，写后 ETL 同步 | 与文档/图/本体同库同事务 | 拼装 vs 一体 |
| 二进制指纹 | 多按 float32 存，1024 维占 4KB | 1024-bit 打包 128B（8× 省空间），位运算加速 | 通用 embedding vs 为化学/二值特征特化 |
| 距离度量 | L2 / IP / Cosine 常见 | L2 / Cosine / IP / Tanimoto / Hamming | 化学相似、汉明距原生支持 |
| 过滤检索 | 先 SQL 圈 ID 再向量，或标量过滤近似 | VECTOR SEARCH … WHERE 谓词与相似度同计划下推 | 两次查询 vs 一次融合 |
| 知识推理 | 无 | 向量命中后可沿本体关系外推（子类/传递/等价） | 相似止于相似 |
| 增量维护 | 全量重建或第三方索引工具 | 增量 delta + 全量快照，bulk 与在线更新分路 | 运维脚本 vs 引擎内建 |
| 元数据一致性 | 两套系统，标量过滤视版本而异 | 向量节点与文档主键 {Class}::PK 同锚点 |
映射表风险 vs 零映射 |
一个具体例子：分子相似性检索
sql
-- 用 1024 位 Morgan 指纹查与阿司匹林最相似的分子
VECTOR SEARCH ON sembio.Compound (fp)
QUERY [1.0, 0.0, 1.0, ... ] -- 0/1 位向量
TOP 10
WHERE mol_weight < 500; -- 可选：SQL 谓词同计划下推
245 万分子生产实测：
| 查询分子 | 指纹位点 | 耗时 | 命中（节选） |
|---|---|---|---|
| 阿司匹林 | 24 bits | 21ms | 卡巴匹林、双水杨酯、苯阿司匹林 |
| 氯吡格雷 | 45 bits | 41ms | 硫酸氢盐、维卡格雷（同靶点类似物） |
| 紫杉醇 | 86 bits | 39ms | 紫杉烷侧链修饰、氯代类似物 |
检索 < 50ms，自匹配距离为 0；盐型、立体异构体、同骨架类似物一并召回。
能力清单
- HNSW 图索引——层级可导航小世界图，亿级扩展路径；支持 ef_search 查询期调节
- 二进制指纹特化——bit-packed 存储与 Tanimoto/Hamming 位运算快路径，避免 1024 维 float 展开
- 增量持久化——小批量写增量 delta，bulk 导入自动切全量快照，重启不丢、不全量重建
- 结构自愈——过期节点剪枝（
COMPACT VECTOR INDEX）、墓碑过滤、stale 重复 id 折叠 - 跨模态融合——向量 + SQL 过滤 + 图遍历 + 本体推理一条查询（OntoQL / 混合 API）
- 语义锚点统一——向量文档键、图顶点、三元组主语、存储主键同一
{Class}::PK，零映射表
四项核心价值
- 检索即知识——向量命中不是终点，可沿本体关系继续推到靶点、通路、不良反应
- 为领域特征设计——化学指纹、Hamming、Tanimoto 原生支持，不只服务文本 embedding
- 写入后不迁移——向量与业务数据同事务提交，无 ETL 窗口、无双写一致性问题
- 生产级可运维——增量持久化、批量导入路径、监控指标、快照恢复一体化
一句话：别的向量库告诉你"哪些向量像"，OntoDB 告诉你"哪些东西像，以及它们在知识网络里意味着什么"。
12 种数据类型
OntoDB 在单一存储引擎中融合 12 种数据类型：
| 类别 | 数据类型 | 说明 |
|---|---|---|
| 基础 | 键值对 | 高性能读写 |
| 文档 | JSON/BSON，嵌套结构 | |
| 文本 | 倒排索引+中英文分词+BM25排序 | |
| 多媒体 | 元数据注册+SHA256内容哈希+类型/属性检索 | |
| 高级 | 结构化记录 | 关系型数据+事务语义 |
| 图结构 | 实体关系网络+遍历 | |
| 向量索引 | HNSW 语义相似性检索 | |
| 时序数据 | 传感器/监控/日志 | |
| 空间数据 | R-Tree+GeoHash 地理信息 | |
| 语义三元组 | 知识图谱 SPO | |
| 实时 | 流数据 | CDC 变更捕获+连续查询 |
| 事件数据 | 复杂事件处理 |
所有数据通过统一语义锚点（{Class}::{PrimaryKey}）关联，零映射表。
33 项核心技术
存储引擎
| # | 创新 | 一句话 |
|---|---|---|
| 1 | 统一语义锚点 | {Class}::PK 同时作为存储键、图顶点、向量文档键、三元组主体，零映射表关联 |
| 2 | 七步写入联动 | 一次 INSERT 原子完成文档→图→三元组→推理→向量→索引，写入即语义就绪 |
| 3 | 全模态统一存储 | LSM-Tree + 键前缀路由，12 种数据类型在同一引擎中共存 |
| 4 | 二进制行零拷贝过滤 | 在二进制数据上直接执行过滤，无需反序列化，解析时间减少 60% |
| 5 | 三阶段锁提交 | 准备→预提交→提交，避免写锁与索引锁的嵌套死锁 |
| 6 | 四级缓存内核嵌入 | 块缓存+查询缓存+语义缓存+自适应内存管理，零网络开销，缓存与内核共享内存空间 |
推理引擎
| # | 创新 | 一句话 |
|---|---|---|
| 7 | 嵌入式增量推理 | OWL 2 RL 推理内嵌存储引擎，增量不动点算法，性能提升 10-100 倍 |
| 8 | 推理安全机制 | 事实数预算控制防推理爆炸、并行推理线程池、循环继承检测 |
| 9 | 推导链路追溯 | 每条推导结果记录来源规则和输入事实，支持完整推理链查询 |
本体内核：OWL 2 RL 推理引擎
OntoDB 将 OWL 2 RL 推理引擎嵌入存储引擎内核，而非外挂组件。数据写入时自动推理，查询时自动展开子类，推导结果即时持久化。
text
传统方案：数据库 → ETL → 外挂推理引擎 → 推理结果写回数据库（延迟分钟级）
OntoDB： 数据写入 → 内核自动推理 → 推理结果即时持久化（延迟微秒级）
支持的 OWL 2 RL 推理规则：
| 规则 | 含义 | 示例 |
|---|---|---|
| 子类传播 | 子类实例自动属于父类 | 温度传感器 IS_A 传感器 → 查询"设备"自动包含 |
| 等价类 | 等价类实例互相包含 | 职工 = 员工 → 查询任一类自动包含另一类 |
| 传递性 | 传递关系自动推导 | A 包含 B，B 包含 C → A 包含 C |
| 对称性 | 对称关系双向推导 | A 互联 B → B 互联 A |
| 逆属性 | 逆关系自动推导 | A 是 B 的父类 → B 是 A 的子类 |
| 子属性 | 子属性自动继承父属性 | "管理"是"认识"的子属性 → 管理某人必认识某人 |
| 等价属性 | 等价属性互相替代 | “父亲” = “爸爸” → 查询任一自动包含另一类 |
安全机制： 推理预算控制（最大事实数防爆炸）、并行推理线程池、本体循环继承检测、推导链路完整追溯。
查询引擎
| # | 创新 | 一句话 |
|---|---|---|
| 10 | 统一查询语言 OntoQL | 单一语法融合 SQL + 图遍历 + 向量搜索 + 本体推理 + 时序 + 空间 |
| 11 | SPARQL 支持 | 标准 SPARQL 1.1 查询，FILTER/OPTIONAL/UNION/EXISTS 全支持 |
| 12 | 推理子句 | 查询时实时推理，SELECT * FROM Device 自动包含所有子类实例 |
| 13 | 语义缓存 | 语义相似度查询自动命中缓存，不同文本相同语义视为同一查询 |
| 14 | 多模态融合查询优化 | 向量+关系/空间+时序/全文+向量跨模态查询自动选择最优执行计划 |
| 15 | 数据血缘追溯 | 内核级数据来源追踪，追溯到原始写入+每一步推理+规则触发 |
| 16 | 联邦查询 | 外部数据源（PG/MySQL/REST/CSV/JSON）映射为命名空间，统一查询 |
图引擎
OntoDB 内嵌完整的属性图引擎，不是外挂图数据库。图数据与关系数据共享同一存储引擎，写入即图就绪，无需 ETL 同步。
社区版（免费）
| # | 创新 | 一句话 |
|---|---|---|
| — | 属性图存储 | 顶点+边+属性的完整属性图模型，内存 LRU 缓存 + LSM 持久化，按需加载关系类型（<10 万边自动全量加载，>10 万边按需加载） |
| — | 图遍历引擎 | BFS/DFS 双遍历模式，标签索引加速遍历（O(1) 按标签查边），parent map 优化最短路径重建，DFS 改用 push/pop 回溯消除递归分配 |
| — | 图查询融合 | 查询优化器自动路由：1-2 跳翻译为 LSM JOIN 走索引，3+ 跳走图缓存 BFS/DFS，混合查询分阶段执行（关系缩小范围→图遍历→聚合） |
| — | 图分析原语 | PageRank（迭代收敛）、连通分量（BFS）、度分布统计、聚类系数（三角形计数），社区版免费可用 |
| — | 图缓存管理 | 五态状态机（未加载→加载中→已加载→已失效→失败），写入自动标记失效，10 秒防抖冷却，LRU 淘汰保护 2GB 内存上限，分页加载（每次 1 万条） |
| — | 图可视化导出 | DOT（Graphviz）、D3.js JSON、Cytoscape.js JSON、Mermaid 四种格式，支持节点/边颜色和大小配置 |
企业版（商业许可）
| # | 创新 | 一句话 |
|---|---|---|
| — | 分布式图存储 | 一致性哈希分区（虚拟节点），顶点按 ID 分配到分区，跨分区边存储 ghost vertex 引用，全局 BFS 自动跨分区遍历 |
| — | 知识图谱推理 | 前向链推理（数据驱动，自动推导新知识）、后向链推理（目标驱动，反向验证）、三元组模式匹配、规则引擎（IF conditions THEN conclusion）、推理解释（追溯推导链路） |
| — | 图神经网络 | GCN（图卷积网络）推理，node2vec 随机游走生成节点 embedding，余弦相似度查询，NumPy/PyTorch 格式导出 |
| — | 图流式计算 | 增量图算法：流式连通分量（Union-Find）、流式 PageRank（边增删实时更新）、流式度追踪，窗口事件管理 |
| — | 图模式匹配 | 子图同构匹配：给定模式图（顶点标签+边标签），在大图中找到所有匹配子图，回溯搜索 + 标签剪枝 |
| — | 高级图算法 | Dijkstra 加权最短路径（BinaryHeap O(log n)）、介数中心性（Brandes 算法 O(VE)）、子图提取（按标签/边标签） |
| — | 并行 BFS | Rayon 多线程并行邻居扩展，原子位图去重，适合宽图（每节点邻居多） |
| — | CSR 压缩存储 | 压缩稀疏行格式（offsets + neighbors 数组），内存比 HashMap 方案减少约 50%，支持 BFS 和邻居查询 |
OntoQL：统一查询语言
开发者只需学一种语言，就能操作所有数据模态。传统方案需要 SQL + Cypher + 专用向量 API + SPARQL 四种语言。
sql
-- 关系查询
SELECT * FROM users WHERE age > 25;
-- 图遍历
GRAPH TRAVERSE FROM 'Person::1' OUT LABEL 'knows' DEPTH 3;
-- 向量搜索
VECTOR SEARCH ON documents (embedding) QUERY [0.1, 0.2] TOP 10;
-- 本体推理（自动展开子类）
SELECT * FROM Device; -- 自动包含 Sensor, TemperatureSensor 等所有子类
-- 时空查询
SELECT * FROM pois WHERE ST_Distance(location, ST_Point(116.4, 39.9)) < 1000;
-- 上述模态可在同一查询中组合使用
活数据管理
| # | 创新 | 一句话 |
|---|---|---|
| 17 | 活数据生命周期 | 指数/线性/对数三种衰减模型，三级半衰期(7h/70d/2yr)，访问自动激活 |
| 18 | 价值驱动查询 | 查询条件中使用价值得分过滤排序，高频数据自动提升优先级 |
活数据：数据价值自动衰减
传统数据库用 TTL 固定过期，OntoDB 的活数据让数据像生物一样有生命：不用就慢慢"死掉"，用一下就"复活"。
text
传统 TTL：创建时设 30 天过期 → 第 29 天还在用也删掉 → 被动等死
活数据： 频繁访问 → 价值上升 → 自动保留 → 主动续命
长期不访问 → 价值衰减 → 自动降级/清理
| 特性 | 说明 |
|---|---|
| 三级半衰期 | 7 小时（高频热点）→ 70 天（中频温数据）→ 2 年（低频冷数据） |
| 三种衰减模型 | 指数衰减（默认）、线性衰减、对数衰减 |
| 自动激活 | 每次访问自动重置衰减时钟，累加价值得分 |
| 内核级集成 | 价值元数据与数据存储在同一记录中，原子性保证 |
| 向量索引集成 | 高价值数据的向量优先加载到内存，查询更快 |
时序与空间
| # | 创新 | 一句话 |
|---|---|---|
| 19 | TSM 列式存储 | 时间戳 Delta 编码 + 浮点值 Gorilla 编码，存储空间减少 60%+ |
| 20 | 时空联合索引 | 四叉树空间分区 + 时间线排序融合在单一数据结构中 |
| 21 | 嵌入式时空规则引擎 | STTRL 语言，地理围栏/超速/接近/异常位置等 10+ 种规则数据库层执行 |
| 22 | 三级分层存储 | 热层(内存)→温层(SSD)→冷层(HDD)，按数据温度自动迁移，查询透明 |
| 23 | 高级时序分析 | DTW 距离、流式异常检测、滚动/跳跃/会话窗口函数 |
分布式与扩展
| # | 创新 | 一句话 |
|---|---|---|
| 24 | 数据分片 | 类/范围/哈希三种分片策略，运行时动态扩缩容和数据重平衡 |
| 25 | Raft 共识 | 多节点集群一致性，持久化日志，集群白名单，配置同步 |
| 26 | 多协议接入 | PostgreSQL + MySQL + HTTP REST 三协议并存，现有应用无缝迁移 |
| 27 | API 网关内嵌 | 负载均衡、限流、熔断、认证授权，无需独立部署 |
| 28 | 边缘三级部署 | MCU(<100KB) → 嵌入式 Linux → 边缘服务器，统一数据模型和 API |
安全与运维
| # | 创新 | 一句话 |
|---|---|---|
| 29 | CDC 变更捕获 | 内核级集成，WAL 实时提取变更事件，支持 Flink/Spark 消费 |
| 30 | 命名空间作用域隔离 | 裸类名按空间打点前缀、ns.Class 限定名跨空间寻址，查询免 WHERE |
| 31 | 等保2.0三权分立 | 系统管理员/安全管理员/审计管理员互斥，满足中国政务金融合规 |
| 32 | 数据脱敏引擎 | 内核级动态+静态脱敏，身份证号/手机号/银行卡号自动识别脱敏 |
| 33 | CRC自动修复 | SSTable页级CRC校验，检测到损坏自动从Raft副本修复 |
命名空间：作用域隔离
OntoDB 的命名空间在存储键层以类名点前缀承载：USE NAMESPACE Bioet 下写入的裸类名 Drug 落盘为 Bioet.Drug::{pk}，与默认空间的 Drug 分属不同键域——防碰撞、防误读。带点的类名（如共享目录 Bioet.Compound）视为全局限定名，在任何命名空间下保持原样。
text
传统方案：应用层加 tenant_id → 查询时 WHERE tenant_id = ? → 容易遗漏
OntoDB： 裸类名自动限定到会话命名空间 → 键前缀即作用域，无需 WHERE 过滤
| 隔离层级 | 说明 |
|---|---|
| 数据层 | 裸类名按命名空间打点前缀（Bioet.Drug::…），不同空间的同名类物理不同键域 |
| 查询层 | 裸类名自动限定到当前空间；ns.Class 限定名可显式跨空间访问（共享目录用此形式） |
| 自省层 | SHOW CLASSES 在租户内隐藏其他租户的类；default 为管理视图，可见全部 |
| 本体层 | 本体记录可声明所属命名空间 |
| 索引层 | 索引/向量索引按（前缀化后的）类名隔离，各空间独立构建 |
隔离语义：防意外，不防显式——裸名互不可见、互不碰撞；限定名跨空间读取是设计内的显式访问（供共享目录与跨项目引用），共享目录（全局限定名）的写入需要无作用域密钥。default / _default 为默认命名空间，随时可用 USE NAMESPACE default 切回。
一个 OntoDB 实例可服务 N 个租户/项目：命名作用域隔离 + 显式共享，运维成本低。
性能基准
百万级吞吐，微秒级推理，100% 向量召回率。单一系统统一 12 种数据类型，替代 6 个独立数据库。
生产环境实测（生物医药知识图谱）
12 核 / 32GB RAM / NVMe SSD / 2,800 万+ 条知识记录（105 张实体/关系表）/ 32GB / 980 SSTable
| 指标 | 数值 |
|---|---|
| 总记录数 | 2,800 万+（105 张实体/关系表，层级展开计数 2,844 万） |
| 分子结构（SMILES/InChI） | 245 万条（ChEMBL 35） |
| 分子指纹相似检索（Tanimoto） | 21–41ms / 245 万 |
| 607k 行 GROUP BY 聚合 | 123ms（索引下推前 11s，90×） |
| 大表 LIMIT 扫描（16 并发） | 2,546 rps（优化前 10.7 rps，238×） |
| 64 并发 P50 延迟 | 25.8ms（优化前 8.9s） |
| 混合负载长稳 | 180 秒 69,610 查询 / 0 错误 |
| 损坏数据注入测试 | 全部确定性拒绝，无崩溃 |
存储引擎
| 指标 | OntoDB | SQLite | PostgreSQL | Redis |
|---|---|---|---|---|
| 写入 | 1,126,486 ops/s | ~50K | ~30K | ~100K |
| 读取 | 1,306,438 ops/s | ~200K | ~100K | ~100K |
向量搜索
| 数据规模 | 召回率 | 延迟 |
|---|---|---|
| 10K | 100% | 403µs |
| 50K | 100% | 1.03ms |
| 200K | 99.7% | 4.06ms |
| 245 万（分子指纹 Tanimoto） | — | 21–41ms |
OWL 推理（全球首创内嵌引擎）
| 操作 | OntoDB | 外挂引擎 |
|---|---|---|
| is_subclass_of | 390ns | ~10ms |
| 单事实推理 | 50.8µs | ~100ms |
| 批量推理（10K实体） | 22ms | ~5s |
规则引擎
| 规模 | 耗时 |
|---|---|
| 10 条规则 | 34.5µs |
| 1000 条规则 | 1.79ms |
性能对标：OntoDB vs 各领域专用数据库
| 功能 | 专用数据库 | 专用数据库性能 | OntoDB | 说明 |
|---|---|---|---|---|
| 关系存储 | PostgreSQL | ~30K ops/s | 1,126K ops/s | 写入吞吐 |
| 向量搜索 | Milvus | ~1ms / 95-99% | 403µs / 100% | 10K规模 |
| 图查询 | Neo4j | ~10ms | <1ms | BFS/DFS |
| OWL推理 | Apache Jena | ~100ms | 50.8µs | 增量不动点 |
| 时序存储 | InfluxDB | ~200K ops/s | 1,126K ops/s | TSM列式 |
| 规则引擎 | Drools | ~500µs/10条 | 34.5µs/10条 | DSL语法 |
快速开始
从源码编译
bash
# 前置要求：Rust 1.77+
git clone https://gitee.com/ontovalue/ontodb.git
cd ontodb
cargo build --release
# 启动服务器（PostgreSQL 协议 5432 + MySQL 协议 3306 + HTTP 7912）
./target/release/ontodb-server --data-dir ./data --http 0.0.0.0:7912
Docker
bash
docker compose up -d
用 OntoQL 创建第一个表
sql
-- 定义本体
CREATE CLASS Device;
CREATE CLASS Sensor SUBCLASS OF Device;
-- 插入数据（自动完成 7 步联动）
INSERT INTO Sensor (id, location, temperature)
VALUES ('T1', 'Factory_A', 36.5);
-- 查询时自动推理展开（Device 自动包含 Sensor 子类数据）
SELECT * FROM Device;
-- 图遍历
GRAPH TRAVERSE FROM 'Sensor::T1' OUT LABEL 'connects_to' DEPTH 3;
-- 向量搜索
VECTOR SEARCH ON documents (embedding) QUERY [0.1, 0.2] TOP 10;
-- 空间查询
SELECT * FROM devices WHERE ST_Distance(location, ST_Point(116.4, 39.9)) < 1000;
-- 时序查询
SELECT * FROM sensor_data WHERE time > '2024-01-01' LIMIT 100;
适用场景
市场定位：大数据栈的语义服务层。 大数据管道（湖仓/Spark/Flink）管冷数据和批量分析，OntoDB 管语义查询与在线服务——本体推理、多模态统一查询、写入即数据质量门、知识图谱，两边通过 CDC/导入管道衔接。
| 场景 | 为什么用 OntoDB |
|---|---|
| 大模型 / AI 公司 | 向量+知识图谱+推理融合，RAG 检索增强+本体内置，不用外挂向量库+图库+推理引擎 |
| 生物医药 / AI4S | 分子结构+图+向量+本体统一，结构相似→靶点通路→不良反应一条查询闭环（已实证） |
| 互联网公司 | 12 种数据类型统一存储，一个系统替代 MySQL+Redis+Milvus+Elasticsearch+Neo4j |
| SaaS 平台 | 命名空间作用域隔离，一个实例服务 N 个租户，零开销 |
| 知识图谱 | OWL 推理内嵌，写入即推理，推导链路可追溯，不用外挂推理引擎 |
| 智能搜索 | 向量+全文+语义推理融合查询，一个查询同时做语义搜索+知识推理 |
| IoT / 工业互联网 | 时序+空间+图+本体推理统一，STTRL 时空规则引擎内置 |
| 数字孪生 | 12 种数据类型 + 活数据衰减 + 时空规则引擎 + CDC 实时事件 |
| 自动驾驶 | 边缘三级部署 + STTRL 时空规则 + CDC 实时事件 |
| 机器人 | 边缘低功耗 + 实时推理 + 时空感知 + 本体规则引擎 |
| 智慧医疗 | 命名空间多租户作用域隔离+本体推理+时序数据（生命体征）+空间数据（病区定位） |
| 金融风控 | 本体规则引擎自动触发风控规则+实时流数据+CDC+审计链 |
| 电商推荐 | 向量相似性+图关系+活数据衰减（热度自动降级）+实时事件 |
| 智慧城市 | 空间+时序+图+本体推理，地理围栏+轨迹+设备关系统一管理 |
| 多项目数据中台 | 一个 OntoDB 实例跑 N 个项目，命名空间作用域隔离互不干扰 |
| 边缘计算 | MCU < 100KB 内存到完整服务器，统一数据模型和 API |
| 具身智能 | 边缘推理 + 时空规则 + 本体驱动规则引擎 + 多体协同 |
典型行业案例
| 案例 | 痛点 | OntoDB 方案 | 收益 |
|---|---|---|---|
| 生物医药知识图谱（已交付） | 药物-靶点-通路-不良反应分散 5 系统，查"EGFR 抑制剂"漏子类 | 12 模态同库 + subClassOf 推理自动展开 |
607k 行聚合 11s→123ms；大表扫描 238× |
| 临床试验智能匹配 | 入排标准散在文档，人工筛选患者数周 | 入排标准本体化 + 推理匹配队列 | 筛选 周级→分钟级，新试验零代码 |
| 反洗钱关联图谱 | 资金链路分散 3 库，关联挖掘靠人工 | 资金关系图 + 分类本体 + 传递风险推理 | 关联挖掘 ×3，集团风险无遗漏 |
| 设备故障知识图谱 | 故障案例无语义，排障靠老师傅经验 | 故障分类本体 + 因果图 + 时序传感器同库 | 排障时间 -50%，告警准确率 +30% |
| 商品类目智能管理 | 类目树 5-8 层，查"手机"要递归 UNION | subClassOf 自动展开 + 同义扩展 |
1 条 SQL 替代递归，召回率 +35% |
案例一为生产环境实测交付；其余为典型方案设计，收益为行业基准估算。详见 语义元数据深度解析。
场景适配度
分类层级越深、跨表关联越密、数据质量要求越高的场景，语义元数据收益越大：
| 场景 | 分类复杂度 | 跨表关联 | 质量要求 | 适配度 |
|---|---|---|---|---|
| 生物医药 / 化学材料 | ★★★★★ | ★★★★ | ★★★★ | 最高（已实证） |
| 医疗健康 / 金融科技 | ★★★★ | ★★★★★ | ★★★★ | 高 |
| 智能制造 / 电商内容 | ★★★★ | ★★★ | ★★★ | 中高 |
| 智慧城市 / 政务 | ★★★★ | ★★★★ | ★★★★ | 中 |
项目结构
text
ontodb/
├── crates/
│ ├── onto-core/ # 核心类型（EntityId/BinaryRow/R-Tree/GeoHash/DTW）
│ ├── onto-storage/ # LSM-Tree 引擎（WAL/MVCC/HNSW/TSM/分层存储/Bloom）
│ ├── onto-ontology/ # OWL 2 RL 推理引擎（7 条规则/增量不动点/推导追溯）
│ ├── onto-query/ # 查询引擎（OntoQL/SPARQL/优化器/执行器/缓存）
│ ├── onto-graph/ # 图引擎（属性图/BFS/DFS/最短路径/PageRank/缓存管理）
│ ├── onto-server/ # 多协议服务器（PG/MySQL/HTTP/TLS/审计/CDC/限流）
│ ├── onto-cli/ # 命令行 REPL + dump/restore
│ ├── onto-plugin/ # 插件钩子管线（INSERT/UPDATE/DELETE 生命周期）
│ ├── onto-edge/ # 边缘设备 SDK（采集/地理围栏/上报）
│ ├── onto-sharding/ # 数据分片（类/范围/哈希策略）
│ ├── onto-raft/ # Raft 共识（持久化/集群白名单/配置同步）
│ └── ontodb-rules/ # 基本规则 API 服务（DSL 解析/CRUD/热更新）
├── sdk/ # 多语言 SDK（Go/Python/TypeScript）
├── examples/ # 示例应用 + 规则模板（金融/工业/医疗）
├── frontend/ # 规则编辑器 Web UI
└── docs/ # 文档
企业版功能特点
企业版在社区版基础上提供三大核心能力：
本体驱动规则引擎（全球首创）
本体知识自动触发业务规则，领域专家只需定义本体，规则自动生效。 不同于传统规则引擎需要人工编写每一条规则，OntoDB 企业版将 OWL 推理引擎与规则引擎深度融合，实现"知识即规则"。
| 能力 | 说明 |
|---|---|
| 本体→规则自动触发 | OWL 推理结果自动注入规则引擎，无需编码 |
| 企业级规则引擎 | 完整 DSL 语法、分布式推理、冲突检测、版本管理、性能分析 |
安全合规
满足政务、金融、医疗等行业合规要求。
| 能力 | 说明 |
|---|---|
| 身份认证 | RBAC 三权分立、LDAP/SAML 集成 |
| 数据保护 | 国密 SM4 + AES 加密、数据脱敏、密钥管理 |
| 审计合规 | 审计日志、合规保留、完整性校验 |
高可用
企业级可靠性保障。
| 能力 | 说明 |
|---|---|
| 集群高可用 | 自动故障转移、读写分离、滚动升级 |
| 分布式查询 | 跨分片聚合、分布式备份恢复 |
| 可观测性 | 慢查询分析、指标采集、告警 |
联系方式：license@ontovalue.com
许可证
OntoDB 采用双许可模式：
| 版本 | 许可证 | 说明 |
|---|---|---|
| 社区版 | BUSL-1.1 | 免费使用，禁止提供 DBaaS 托管服务，2031-09-15 转 Apache-2.0 |
| 企业版 | 商业许可 | 全功能，需购买许可证 |
社区版（BUSL-1.1）：
- 允许：年营收低于 2000 万人民币的企业免费使用
- 允许：内部使用、本地部署、二次开发、非商业分发
- 允许：企业自用、SaaS 产品中嵌入使用
- 禁止：提供 OntoDB 作为云数据库服务（DBaaS）
- 年营收超过 2000 万人民币的企业须购买商业许可
- 2031-09-15 自动转为 Apache License 2.0
- 详见 LICENSE
企业版（商业许可）：
- 高级推理引擎（完整 DSL + OWL 集成 + 分布式推理 + 性能分析）
- 安全合规（RBAC + LDAP + SM4/AES 加密 + KMS + 审计保留）
- 高可用（集群故障转移 + 跨分片查询 + 备份恢复）
- 详见 LICENSE.COMMERCIAL
- 联系方式：license@ontovalue.com
合规声明： 违反 BUSL-1.1 条款使用 OntoDB（包括但不限于：移除版权声明、提供 DBaaS 托管服务）将承担法律责任。发现违规使用请举报：license@ontovalue.com
贡献
欢迎贡献！请查看 CONTRIBUTING.md。