Amazon DynamoDB Limits

先放几个链接：
开发人员指南 Developer Guide
API Reference
Service, Account, and Table Quotas in Amazon DynamoDB
How Amazon DynamoDB adaptive capacity accommodates uneven data access patterns (or, why what you know about DynamoDB might be outdated)

这三个都是官方链接，可放心食用
最好中英文对照着阅读，因为很多地方翻译不准确，读的时候会感到迷糊

Map/List

最大支持 32 级嵌套

item size

最大 400 KB

item collection

基表和 LSI 中具有相同分区键的 item 的集合

最大 10 GB，存在 LSI 时才会有此限制

Indexes

只能 Query 或 Scan

LSI 每个表最多 5 个

用了 LSI 会有 item collection 最大 10 GB 的限制
只能在 create table 时开启，删除表时被自动删除，不可更改

GSI 每个表默认配额 20 个

不支持强一致性读

Query / Scan

最多返回 1 MB 的数据
可以指定 limit 限制最多读几个 item
如果还有数据，会返回一个 LastEvaluatedKey

BatchGetItem

最多一次传入 100 个 item 的 key
最多返回 16 MB 的数据
如果有部分 item 还没取到，会返回 UnprocessedKeys

BatchWriteItem

最多同时 PutItem/DeleteItem 25 个，且数据总和不超过 16 MB，且每个 item 不超过 400 KB
不可指定 condition，不会返回被删掉的 item
如果有 PutItem 失败，会返回在 UnprocessedItems 里 (put 失败很可能因为超过了分配的吞吐量)

TransactGetItems / TransactWriteItems

最多 25 个 item，合计大小不超过 4 MB

Throughput Limits

单个分区吞吐量上限: 3000 RCU，1000 WCU

预置容量模式下单个表默认吞吐量上限: 40000 RCU, 40000 WCU (包括基表和 GSI) 参考链接

单个账号默认吞吐量上限: 80000 RCU, 80000 WCU

如需改大要联系 https://aws.amazon.com/support

[cloudshell-user@ip-10-0-17-8 ~]$ aws dynamodb describe-limits
{
    "AccountMaxReadCapacityUnits": 80000,
    "AccountMaxWriteCapacityUnits": 80000,
    "TableMaxReadCapacityUnits": 40000,
    "TableMaxWriteCapacityUnits": 40000
}

adaptive capacity

当突然有很多流量持续涌入某个分区时，如果该分区被分配的平均吞吐量不够用，则首先会消耗 burst capacity(过去 5 分钟没有用完的容量)，burst capacity 用完了还不够的话就会被限流。通常再过 5-30 分钟之后，会恢复正常。

DynamoDB adjusted the table to better handle the imbalance. It typically takes 5–30 minutes from the time a table encounters request failures to when adaptive capacity restores normal performance.

Initial Allocation of Partitions

一个分区最大承载 3000 RCU 和 1000 WCU，所以建表时，初始分区个数可以表示为：
( readCapacityUnits / 3,000 ) + ( writeCapacityUnits / 1,000 ) = initialPartitions (rounded up)
比如，建一个表，配置 1,000 RCUs，500 WCUs，那么初始分区数为：
( 1,000 / 3,000 ) + ( 500 / 1,000 ) = 0.8333 --> 1

stackoverflow 上有人给出了这个公式的链接，但是原始链接已不存在。最新的官方文档中是没有这么个公式的。但是公司同事确信有公式(他几年前看到过)。
终于我在官方文档的 github 仓库中找到了线索(官方文档每页下面都有一个 Edit this page on GitHub, 我是循着它找到 github 的)
Initial Allocation of Partitions
这个 GuidelinesForTables.md 文件在 2018.4.24 被删除

数据的存储

AWS re:Invent 2018: Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321)

DynamoDB 存储的每一份数据都是存储在 3 个 Available Zone 的节点上的

当 PutItem 时，client --> Request Router(这是一个无状态节点，有很多很多个) --> leader(三个节点中的 leader) --> followers(另外两个节点)
当 leader 收到其中一个 follower 的 ack 后，给 client 返回写成功状态，同时可能更新 LSI，异步更新 GSI、DynamoDB Stream、Global Table

Put/Update Item 的更新如果改变了二级索引(LSI 或 GSI)的 KeyAttribute，则在二级索引中会产生两个操作：删除原 item + 插入新 item
因此消耗的 WCU 为：基表 WCUs + 二级索引 DeleteItem 消耗的 WCUs + 二级索引 PutItem 消耗的 WCUs
注意：更新失败也会消耗 WCU 参考
同理，读失败也消耗 RCU

当 GetItem 时，默认情况下是「最终一致性」读，Request Router 会随机从 3 个节点中的一个读取数据，返回给 client
如果指定 ConsistentRead，则从 leader 节点读取数据并返回