DynamoDB 键值数据库

01 它是干嘛的

DynamoDB 是超大规模场景下的键值数据库：它不追求复杂查询，而是把「给定一个键，极快地取回一条数据」做到极致。它的秘诀是把数据按分区键水平切分到很多台机器上，每台机器各管一摊、互不干扰，因此流量再大也能通过加机器来扛，这也是它在电商大促等极端场景下依然稳定的原因。

02 为什么会有它

一个能扛住大促的数据库，传统数据库为什么做不到

传统关系型数据库通常跑在一台很强的服务器上，所有数据都挤在一起。它很全能，能灵活地做各种复杂查询，但天花板也很明显：一旦请求量超过这台机器的能力，整个系统就会变慢甚至卡死。想突破只能分库分表，而这是一项极易出错、维护成本极高的工程。

电商的麻烦在于流量根本无法预测。平时流量平稳，大促那天可能瞬间暴涨几十倍，谁也不敢保证自己的数据库一定扛得住。传统数据库在大促中一旦成为瓶颈，前面所有的服务器扩容都白费。

DynamoDB 的诞生源于亚马逊内部一篇著名的论文：他们发现，如果要做到「几乎无限扩展、永远在线」，就必须放弃把所有数据放在一处。于是他们设计了「无共享架构」——把数据按一个编号切分到许多独立的分片上，每个分片只管自己那部分，机器之间不共享任何状态。要扩容，就多分几个分片；某个分片出问题，其他分片照常工作。这一设计后来成为全球分布式数据库的通用范本。

03 它怎么工作

DynamoDB 的关键只有两个词：分区键和水平切分。分区键决定一条数据落在哪台机器上，水平切分则让数据可以不断一分为二、分摊到更多机器，从而突破单机上限。

重点看数据被切成一格格分片、每格各占一台机器那部分：这就是「水平切分」的画面，也是它能不断加机器扛流量的根本原因。

数据是怎么被切分到很多机器上的：分区键与水平扩展

1
① 写入时按分区键定位
每条数据都要带一个分区键（例如用户编号）。系统对键做一次计算，决定它该落在哪个分片上。
2
② 各分片独立工作
每个分片只负责自己那部分数据，彼此不共享资源，一个分片繁忙不会拖慢其他分片，这就是无共享架构。
3
③ 选择读一致性
读取时可选「最终一致」或「强一致」：最终一致更快更便宜，但可能读到稍旧的版本；强一致保证一定读到最新写入，代价是稍慢稍贵。
4
④ 自动分裂与合并分片
某个分片数据变多、压力变大时，系统自动把它一分为二；空闲时再合并，容量随负载自动伸缩。
5
⑤ 按容量模式计费
可以选「按需模式」完全不管容量，也可以选「预置模式」提前声明读写能力以获得更低单价。

04 谁在用它

电商购物车与订单

用户量大、读写频繁、要求毫秒响应，按用户编号切分后天然适合水平扩展。

会话与登录态存储

把用户的登录信息集中存起来，多台服务器共享，用户换一台机器访问也不会掉线。

物联网设备数据

海量设备持续上报状态，按设备编号分区写入，流量再大也能稳定承接。

游戏排行榜与玩家资料

需要极快读写、且能承受开服瞬间的流量洪峰，键值模型正好匹配。

高并发的事件记录

把点击、埋点等海量小记录快速写入，后续再批量取出分析。

05 怎么用

上手极快，但「表结构怎么设计」几乎决定了成败，务必按查询方式来设计表。

01先想清楚系统会用哪些查询，再据此确定分区键：设计目标是让每次查询都只需一个键、不扫全表。
02在控制台创建表，指定分区键，并按预期流量选择按需或预置容量模式。
03写入几条测试数据，确认能用分区键毫秒级取回整条记录。
04如有「再加一个条件筛选」的需求，可以再设一个排序键，让同一分区内按顺序读取。
05为频繁出现的第二类查询建立索引，避免让程序去扫描整张表。
06上线后观察读写用量与限流指标，必要时调整容量模式或分区键设计。

用 AWS SDK 写入并按键取回一条记录ts

import { DynamoDBClient, PutItemCommand, GetItemCommand } from '@aws-sdk/client-dynamodb'

const db = new DynamoDBClient({ region: 'us-east-1' })

// 写入：以 userId 为分区键存一条记录
await db.send(new PutItemCommand({
  TableName: 'Users',
  Item: { userId: { S: 'u-1001' }, name: { S: '小明' } }
}))

// 读取：给定分区键，毫秒级取回整条记录（不扫描全表）
const { Item } = await db.send(new GetItemCommand({
  TableName: 'Users',
  Key: { userId: { S: 'u-1001' } }
}))
console.log(Item)

避坑提示

!分区键要尽量分散：如果大量请求都集中在同一个键上（例如用「当天日期」当键），会造成热点，拖慢整个系统。
!强一致读更贵也更慢，只有确实不能容忍读到旧数据时才开，例如查看刚提交的订单状态。
!DynamoDB 不支持随意按任意字段查询，设计前先列清所有查询需求，必要时用索引，别指望临时拼条件。

06 关键概念

分区键: 决定一条数据落在哪台机器上的那个字段，类似按姓氏把人群分到不同窗口。
无共享架构: 每台机器各管一摊、互不依赖，因此一台出问题不会连累其他机器。
水平切分: 把数据分成许多份放在不同机器上，靠加机器来提升整体能力。
最终一致与强一致读: 前者更快但可能读到稍旧的版本，后者保证读到最新数据但代价更高。
索引: 为另一类常用查询额外建的一张「目录」，让那种查询不用扫描整张表。

07 容易混淆的对比

自建分库分表的 MySQL功能更全、支持复杂查询，但分片、扩容与一致性都要自己实现，维护难度高。

Cassandra / MongoDB同属分布式数据库，也能水平扩展，擅长场景与一致性模型各有侧重。