NodeDB

什么是 NodeDB？

NodeDB 是一个单一数据库引擎，旨在通过将不同数据类型——关系型、向量（AI）、图、文档、列式和科学数组——整合到一个基于 Rust 的架构中，来取代多个数据系统。其明确目标是减少独立数据库之间的碎片化，并消除处理混合数据时对“管道”和“Python 胶水”的需求。

一个关键定位是，现有的 PostgreSQL 客户端可以“直接”用于连接，而 NodeDB 支持 GraphRAG 风格的查询，将向量搜索和图扩展融合为一条查询。页面展示的示例说明了语义检索加上图上下文，作为数据库层工作流的一部分。

主要特性

• 统一引擎支持多种数据模型（关系型、向量、图、文档、列式、科学数组），无需在独立系统间切换即可存储和查询不同数据类型。
• 基于 Rust 的架构，被描述为“超高效”引擎，以单个 Rust 二进制文件实现。
• PostgreSQL 客户端兼容：页面声明现有的 Postgres 客户端“直接可用”，旨在降低采用新后端的摩擦。
• GraphRAG 查询支持，在一条语句中结合向量搜索与图扩展，被定位为“数据库层的 GraphRAG”。
• 一条查询的 GraphRAG 融合工作流，支持 top-k 检索、扩展深度、边标签和方向以及结果融合设置的控制（如示例语句所示）。

如何使用 NodeDB

1. 通过加入早期访问流程或使用网站上的“获取早期访问”选项来开始使用。
2. 使用现有的 PostgreSQL 客户端连接，因为页面明确声明了 Postgres 客户端兼容性。
3. 提交一条 GraphRAG 风格的查询，根据查询参数从向量执行语义检索并通过图边扩展。
4. 使用该查询的融合结果作为 LLM 上下文基础，因为页面将其框定为数据库层提供的语义检索加上图上下文。

使用场景

• 无需外部管道构建 GraphRAG 检索：运行一条数据库查询，执行基于向量的语义检索，通过图边扩展相关实体，并融合结果供下游 LLM 使用。
• 使用图上下文回答实体中心问题：检索 top 向量匹配，然后通过关系（使用边标签和方向）扩展，以在同一查询中收集附近图信息。
• 实现排名和结构均重要的混合检索：使用所示的融合检索参数（例如 top-k、扩展深度和融合设置）平衡直接向量匹配与图扩展结果。
• 减少应用侧编排：通过将向量和图操作的融合移入数据库查询本身，避免“管道”和“Python 胶水”。
• 跨多种模型类型整合数据存储：当应用当前依赖独立系统处理关系数据、向量和图关系时，使用 NodeDB 作为覆盖这些类别的单一引擎。

常见问题

• NodeDB 是否需要单独管道或 Python 胶水来结合向量和图检索？ 页面声明该方法使用“一条查询”，强调“无管道”和“无 Python 胶水”，描述为数据库层的融合。

• “您的现有 Postgres 客户端直接可用”是什么意思？ 网站明确声称 PostgreSQL 客户端兼容，暗示可以使用常见的 Postgres 客户端模式进行连接。

• 在此上下文中，GraphRAG 是什么？ 页面将 GraphRAG 框定为“向量搜索 + 图扩展”，融合为一条查询，产生语义检索结果连同供 LLM 使用的图上下文。

• NodeDB 支持哪些数据模型？ 页面列出了关系型、向量、图、文档、列式和科学数组数据。

替代方案

• 独立的向量数据库 + 独立的图数据库：这会将向量搜索和图遍历保持在不同系统中，通常需要在应用层协调检索和融合（页面定位 NodeDB 可避免管道和胶水代码）。
• 带有外部重排序/融合的混合搜索服务：某些解决方案提供语义搜索加重排序，但工作流可能仍需协调检索与图/上下文扩展步骤。
• 传统 SQL 数据库 + 向量/图扩展：您可能使用插件近似混合模型查询，但页面的卖点聚焦于统一引擎和跨数据类型的一查询融合。
• 应用层实现的 GraphRAG：不是在数据库内部执行向量搜索和图扩展，应用可运行多个检索步骤，然后为 LLM 组装上下文。