nucliadb
Rust+Python 双引擎驱动的 AI 搜索数据库，一库融合向量、全文、图关系四层索引
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
Rust+Python 双引擎驱动的 AI 搜索数据库，一库融合向量、全文、图关系四层索引
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
深夜，某医疗科技公司的 AI 工程师小张正面临一个头疼的问题：公司积累了近十年的医学文献、临床报告、药品说明书——这些非结构化数据像一座沉睡的金矿，无法被高效利用。传统的关键词搜索只能找到"糖尿病"返回"糖尿病"，却找不到"胰岛素抵抗相关的代谢综合征治疗方案"这类语义相关的答案。他尝试过 Elasticsearch + Faiss 的组合方案，却发现数据同步、增量更新、多租户隔离等工程问题接踵而至，每次调整都要改两套系统。
这是 RAG（检索增强生成）时代，无数 AI 开发者共同面临的痛点：向量数据库与传统搜索引擎之间的割裂。而 NucliaDB 正是为了解决这个根本矛盾而诞生的——它从设计之初就将向量搜索、全文检索、图关系查询融为一体，成为 AI 搜索的"一站式"数据库。
图1：NucliaDB 架构总览，展示了 Reader、Writer、Searcher 三大组件与底层存储的交互关系
NucliaDB 由西班牙公司 Nuclia 开发并维护。该公司专注于 AI 驱动的搜索和文档处理，曾推出 Nuclia Understanding API——一个可以将非结构化文档自动提取、分类、增强的 SaaS 服务。NucliaDB 正是这一商业产品的开源底层实现。
项目最早于 2021 年公开，采用 AGPLv3 协议开源，这意味着如果企业修改源代码并提供网络服务，必须公开修改后的代码。项目的 GitHub 页面显示已获得 716 颗星、58 个 Fork，活跃的 Issues 和持续的 Commits 说明社区参与度较高。
项目采用 Rust + Python 双语言架构：核心索引引擎用 Rust 编写以保证性能和内存安全，业务逻辑和 SDK 层用 Python 实现以降低开发者使用门槛。这是一个务实的选择——Rust 负责"苦活累活"（向量计算、分布式索引），Python 负责"连接用户"（SDK、API）。
NucliaDB 最核心的差异化在于它的四层索引架构，每一种索引解决不同类型的信息检索问题：
用户可以将文本、图片等非结构化数据通过 embedding 模型转为向量，存入 NucliaDB。查询时，系统计算向量间的余弦相似度或欧氏距离，返回语义最接近的结果。这解决了"找意思相近的内容"问题——用户不需要知道专业术语，系统能理解他的真实意图。
基于经典的 TF-IDF 变体算法，提供传统的关键词精确匹配搜索。这是工程师们最熟悉的能力——输入"糖尿病"，返回包含该词的所有文档。BM25 的优势在于对长文档和罕见词有良好的权重处理。
不仅能搜文档，还能搜文档中的具体段落。系统会自动将长文本切分为语义完整的段落（chunk），对每个段落建立独立索引。这意味着用户可以精确定位到回答问题的具体段落，而不只是返回整篇文档。
NucliaDB 内置了基于图数据库的关系索引能力，支持实体识别和关系推理。例如，系统可以回答"哪些论文研究了 A 药物与 B 蛋白的相互作用"这类需要跨文档关系推理的问题。
这四层索引通过 Unified Search API 统一暴露，调用方可以同时获取向量相似度分数、BM25 排名、段落位置和关系图谱信息，实现了真正的"混合搜索"——同时考虑语义相关性和关键词匹配度。
图2：NucliaDB Node 架构，每个 Node 由 Reader、Writer、Sidecar 三容器组成，实现读写分离
NucliaDB 的分布式设计借鉴了现代数据库的成熟经验，核心是 Node（节点）架构。每个 Node 内部被拆分为三个容器：
每个 Node 可以拥有多个 Shard（分片），每个 Shard 内部包含上述四层索引。通过增加 Node 数量，可以水平扩展系统的写入吞吐和查询并发能力。
多租户隔离通过 Knowledge Box（知识盒子） 机制实现，每个租户的数据完全隔离，查询不会跨租户泄露。这是企业级应用的基本要求，NucliaDB 在架构层面原生支持。
从代码仓库结构来看，NucliaDB 的 Python 部分采用了 asyncio 异步框架，SDK 提供了同步和异步两套接口。从 nucliadb_sdk 的测试文件可以看出，SDK 支持以下核心操作：
Python SDK 的接口设计清晰，测试覆盖完整，说明项目的工程化程度较高。
Rust 部分（nidx/ 子目录）负责底层向量索引和分布式协调，使用 Rust 的高性能特性确保索引速度和数据吞吐。
依赖管理使用 uv（Astral 公司的 Python 包管理器），在 pyproject.toml 中定义了完整的 workspace 结构：
nucliadb/ — 主数据库服务
nucliadb_sdk/ — Python SDK
nucliadb_protos/ — gRPC 协议定义（Protocol Buffers）
nucliadb_models/ — 数据模型定义
nucliadb_utils/ — 公共工具
nucliadb_telemetry/ — 观测（Tracing + Metrics）
nidx/ — Rust 向量索引引擎
必须坦诚地说：NucliaDB 的部署难度相当高。它不是一个可以通过 Docker Compose 一行命令启动的本地工具，而是一个需要专业运维知识的企业级数据库系统。
项目提供了 Helm Chart，支持通过 Kubernetes 部署。但在此之前，你需要准备好：
对于个人开发者或小团队，这不是理想选择。但对于有 Kubernetes 运维能力的企业团队，这套架构提供了生产级别的可用性和可扩展性。
项目提供了 Nuclia Cloud 托管服务，如果不想自建，可以直接使用云服务。
NucliaDB 的出现反映了一个趋势：AI 应用需要专用的数据基础设施。传统的数据库（PostgreSQL、MongoDB）和搜索引擎（Elasticsearch）都不是为向量语义检索设计的。专用向量数据库（Pinecone、Milvus、Weaviate）和 NucliaDB 等产品在 RAG 浪潮中找到了自己的生态位。
NucliaDB 的独特之处在于它的"混合"哲学——不只做向量搜索，而是将向量、全文、图关系统一在同一数据模型下。对于需要同时处理精确匹配和语义理解的应用（如企业知识库、医疗文献搜索、法律合同审查），这是非常有价值的设计。
从增长曲线看，716 颗星对于一个 2021 年的项目来说属于中等水平，不算爆发式增长。但考虑到它的定位是"数据库基础设施"而非"热门应用"，这个数字说明它已经建立了稳定的用户群。项目仍在活跃维护（持续的 commits 和 issues），这对生产级软件非常重要。