DynamoDB vs Amazon Neptune
DynamoDB 和 Amazon Neptune 都是全托管的 AWS 数据库,但它们对数据的建模方式有着根本不同。DynamoDB 是一个你按键查询的键值和文档存储。Neptune 是一个专门构建的图数据库,它存储节点和边(或 RDF 三元组),并用图查询语言直接遍历关系。选择的关键在于:关系是不是你主要要查询的对象。
你该用 DynamoDB 还是 Neptune?
如果你需要在大规模下按键访问结构化记录,且关系有限、可以用键建模,就选 DynamoDB。当连接是查询的核心时就选 Amazon Neptune——多跳遍历、最短路径、推荐、欺诈团伙、知识图谱——在这些场景中,图模型用一条查询就能表达针对键值存储需要多次往返才能完成的事。你的查询有多依赖关系,决定了答案。
DynamoDB vs Amazon Neptune 速览
| 特性 | DynamoDB | Amazon Neptune |
|---|---|---|
| 数据模型 | NoSQL 键值与文档;表中带类型的项目最大 400 KB | 图——属性图(带属性的节点/边)和 RDF(主语-谓语-宾语三元组) |
| 查询语言 / API | 原生 API(GetItem、Query、Scan)外加 PartiQL,一种兼容 SQL 的语言 | 属性图用 Gremlin 和 openCypher;RDF 图用 SPARQL |
| 主要访问 | 基于分区/排序键的键式查找;关系通过键建模 | 关系遍历——在一条查询中跨多跳走边 |
| 关系 | 无原生遍历;用邻接表或单表设计建模 | 边是一等公民;多跳和路径查询原生且高效 |
| 一致性 | 默认最终一致性;可按请求使用强一致性读取 | 集群内读取一致;只读副本提供扩展读取 |
| 扩展模型 | 自动分区;无服务器按需或预置容量 | 带只读副本的预置数据库实例,或 Neptune Serverless(以 NCU 计量的容量)自动扩展 |
| 事务 | 区域内跨多个项目的 ACID 事务 | 针对图变更的 ACID 事务 |
| 定价 / 运维模型 | 按请求付费(按需)或预置容量加存储;无服务器 | 实例时长(预置)或 NCU 时长(Serverless),加存储和 I/O;仅限 AWS |
| 最佳适用工作负载 | 资料、会话、购物车、事件——大规模的键式记录 | 社交图、推荐、欺诈检测、知识图谱、网络/身份图 |
什么时候 DynamoDB 是更好的选择
- 你的访问基于键。 按 id 获取、查询一个分区、在分区内过滤,都能自然映射到 DynamoDB,并在任意规模下保持快速。
- 关系较浅或有限。 一对多和多对多的连接可以用键建模——邻接表或单表设计——无需图引擎。
- 你想要无服务器的简单性和按请求付费。 按需容量没有什么需要预估规格,空闲时可缩放到零。
- 你不做深度遍历。 如果你很少走超过一两跳,图数据库的优势就用不上了。
什么时候 Neptune 是更好的选择
- 关系就是查询本身。 多跳遍历——朋友的朋友、最短路径、「谁和谁相连」——在 Gremlin、openCypher 或 SPARQL 中是原生的,而键值存储则需要多次顺序读取。
- 你需要属性图或 RDF。 Neptune 同时支持这两种模型及其标准查询语言,适合知识图谱和关联数据的用例。
- 你的领域是图形状的。 欺诈检测、推荐引擎、社交网络以及身份/网络图,都能自然地表达为节点和边。
- 遍历模式不断演进。 新的关系问题就是新的图查询,而不是重新设计你的键。
一条有用的经验法则:DynamoDB 可以用邻接表模式表示关系,当你提前知道遍历方式且遍历保持较浅时,这就足够了。当遍历较深、深度可变或即席时,Neptune 的图引擎正是为此而生,能避免在键值存储中走边时的多次往返开销。
使用 DynamoDB
如果你的工作负载基于键,并用邻接表建模关系,那么 DynoTable 是一个面向 DynamoDB 的原生桌面客户端,支持 macOS、Windows 和 Linux。它读取你标准的 AWS 凭证链,因此你的数据留在 DynamoDB 中,无需迁移。它可以浏览并内联编辑项目、可视化地构建键条件和过滤器,并加入了一个 SQL 工作台,能在遵守 DynamoDB 访问模式规则的前提下表达关系型的查询,还提供一个使用你自己 AWS Bedrock 凭证的 AI 助手。
免费的 DynamoDB Expression Builder 能生成邻接表模型所需的键条件、过滤和更新表达式,形式包括 SDK、CLI 和 PartiQL。DynoTable 是一款闭源商业应用;本页描述的是它能做什么,而不是它如何构建。
FAQ
DynamoDB 可以当图数据库用吗?
部分可以。DynamoDB 没有原生的图遍历,但你可以用邻接表模式或单表设计来建模关系,这在遍历已知且较浅时效果不错。对于深度、深度可变或即席的遍历——最短路径、多跳推荐——像 Neptune 这样专门构建的图数据库更合适,因为它原生地走边,而不是发起许多次单独的读取。
Neptune 相比 DynamoDB 支持哪些查询语言?
Neptune 属性图支持 Gremlin 和 openCypher,RDF 图支持 SPARQL。DynamoDB 使用它的原生 API(GetItem、Query、Scan 及相关操作)外加 PartiQL,一种兼容 SQL 的语言。查询语言上没有重叠——它们的模型不同。
我什么时候该选 Neptune 而不是 DynamoDB?
当连接是你查询最多的对象时选 Neptune:多跳遍历、路径查找,或以关系为中心的领域,如欺诈检测、推荐和知识图谱。当访问主要按键进行、关系有限到可以用键建模时选 DynamoDB。有些架构会两者并用——DynamoDB 存放运营记录,Neptune 承载覆盖其上的关联图。
相关内容
- 用邻接表模式、一对多和多对多指南在 DynamoDB 中建模关系。
- 用单表设计把这一切组织起来。
- 用免费的 DynamoDB Expression Builder 构建表达式。
- 下载 DynoTable,浏览、查询和编辑你的 DynamoDB 表。
Last verified 2026-07-12 against the official AWS DynamoDB and Amazon Neptune documentation. Amazon Neptune 和 DynamoDB 是 Amazon Web Services 的服务;此处引用仅用于标识目的。