最近使用DynamoDB才发现里面一堆坑。踩进去全是钱。
DynamoDB 是依据读取容量 写入容量和数据存储大小（表和索引）收费。这个读取容量写入容量就很恐怖了。还有autoScaling自动扩容也全是钱
所以这里非常有必要了解下读取容量和写入容量。天天读AWS的文档人都不好了。
官方文档：https://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/ProvisionedThroughput.html
1 读取/写入容量基本概念
1.1 读取容量单位
读取容量单位 表示对大小最多为 4 KB 的项目每秒执行一次强一致性读取(最新数据读取)，或每秒执行两次最终一致性读取(可能不是最新数据)。
假设您创建一个带 10 个预置读取容量单位的表。这将允许您对大小最多为 4 KB 的项目每秒执行 10 次强一致性读取，或每秒执行 20 次最终一致性读取。
简单来说就是：1个读取容量单位1秒可以读一次，一次数据量不能超过4KB，超过需要多加容量。
1.2 写入容量单位
写入容量单位 表示对大小最多为 1 KB 的项目每秒执行一次写入。
例如，假设您创建一个带 10 个写入容量单位的表。这将允许您对大小为 1 KB 的项目每秒执行 10 次写入。
简单来说就是：1个写入容量单位1秒可以写一次，一次数据量不能超过1KB，超过需要多加容量。
1.3 超容量了怎么办
如果您的应用程序执行读取或写入操作的速率高于表能够支持的速率，则 DynamoDB 将开始限制 这些请求。
当 DynamoDB 限制读取或写入时，它会将 ProvisionedThroughputExceededException 返回给调用方。随后，应用程序可以采取相应的措施，例如，在重试请求之前等待一段较短的间隔。DynamoDB 控制台显示表的 Amazon CloudWatch 指标，以便您能够监视受限制的读取请求和写入请求。
1.4 初始吞吐量设置
我们创建表和全局二级索引时都需要设置初始容量。表和全局二级索引均会占用读取和写入容量，，AWS免费额度为25个写入，25个读取。所以需要预估每秒请求数量。不过也可以使用AutoScaling方式，动态调整每张表和索引容量
2 索引对读取和写入容量的影响
2.1 索引实现原理
每个二级索引都由 DynamoDB 自动维护。在基表中添加、修改或删除项目时，表上的所有索引也会更新，以反映这些更改。即添加删除肯定会占用读取和写入容量
全局二级索引的投影是从表复制到二级索引中的属性集。表的分区键和排序键始终投影到索引中；您可以投影其他属性以支持应用程序的查询要求。当您查询索引时，Amazon DynamoDB 可以访问投影中的任何属性，就像这些属性是在它们自己的表中一样。
DynamoDB 自动将每个全局二级索引与其基表同步。当应用程序对某个表写入或删除项目时，该表的所有全局二级索引都会使用最终一致性模型异步更新。应用程序绝不会直接向索引中写入内容。
预置吞吐量使用
全局二级索引：每个全局二级索引都有自己的用于读取和写入活动的预置吞吐量设置。对全局二级索引执行的查询或扫描会占用索引 (而非基表) 的容量单位。全局二级索引更新也是如此，因为会进行表写入。对于全局二级索引查询或扫描，您只能请求投影到索引中的属性。DynamoDB 不从表提取任何属性。
本地二级索引：对local secondary index执行的查询或扫描会占用基表的读取容量单位。向表写入时，其local secondary index也会更新；这些更新会占用基表的写入容量单位。
2.2 索引读取和写入容量
创建全局二级索引时，必须根据该索引的预期工作负载指定读取和写入容量单位。全局二级索引的预置吞吐量设置独立于其基表的相应设置。对全局二级索引执行的 Query 操作会占用索引 (而非基表) 的读取容量单位。在表中放置、更新或删除项目时，表的全局二级索引也会更新；这些索引更新会占用索引 (而非基表) 的写入容量单位。
例如，如果您对全局二级索引执行 Query 操作并超过其预置读取容量，则您的请求会受到阻止。如果您对表执行大量写入活动，但是该表的全局二级索引没有足够写入容量，则对该表进行的写入活动会受到限制。
索引的读取容量：
对于 全局二级索引 查询，DynamoDB 的预置读取活动的计算方式与其表查询的方式相同。唯一不同的是，本次计算基于索引条目的大小，而不是基表中项目的大小。读取容量单位的数量就是返回的所有项目的所有投影属性大小之和，该结果会向上取整到 4 KB 的下一个倍数。
索引的写入容量：
在添加、更新或删除表中的项目，并且全局二级索引受此影响时，全局二级索引将占用为此操作预置的写入容量单位。一次写入操作的预置吞吐量总成本是对基表执行的写入操作以及更新全局二级索引所占用的写入容量单位之和。请注意，如果对表执行的写入操作不需要全局二级索引更新，则不会占用索引的写入容量。
索引对读取写入容量的影响：
- 如果您向定义了索引属性的表中写入新项目，或更新现有的项目来定义之前未定义的索引属性，只需一个写入操作即可将项目放置到索引中。
- 如果对表执行的更新操作更改了索引键属性的值（从 A 更改为B），就需要执行两次写入操作，一次用于删除索引中之前的项目，另一次用于将新项目放置到索引中。
- 如果索引中已有某一项目，而对表执行的写入操作删除了索引属性，就需要执行一次写入操作删除索引中旧的项目投影。
- 如果更新项目前后索引中没有此项目，此索引就不会额外产生写入成本。
- 如果对表的更新仅更改了索引键架构中投影属性的值，但不更改任何索引键属性的值，则需要执行一次写入以将投影属性的值更新到索引中。
2.3 如何正确使用索引
2.3.1 最大程度地减少索引的数量
全局二级索引都需要配置预制读取写入容量， 不管用没有都得给钱，表的写入删除都会去更新该索引。
2.3.2 对于写入活动工作量很大的表，避免使用索引
如果一个表经常进行大规模写入删除，只要上面建立索引，索引也会进行大规模写入删除操作，这些都会占用大量的读取写入容量。
2.3.3 慎重选择投影
由于二级索引会占用存储空间和预配置吞吐量，因此您应尽可能地减少索引的大小。此外，相较于查询整个表，索引越小，性能优势越明显。
实际使用中，如果你投影很多，每次更新到投影中的属性也就会同步更新索引，占用写入容量。
如果你建立了5个索引，5个索引均投影了某个一个属性，当改变项目中该值时，5个索引均会更新。
3 AutoScaling 模式
DynamoDB Auto Scaling 使用 AWS Application Auto Scaling 服务代表您动态调整预置的吞吐容量，以响应实际的流量模式。这将允许表或全局二级索引增大其预置的读取和写入容量以处理突增流量，而不进行限制。当工作负载减小时，Application Auto Scaling 将减少吞吐量，这样您将无需为未使用的预置容量付费。
DynamoDB 将不会允许您过快地增加预置容量
您将为 TestTable 创建扩展策略(使用Formation部署时)。该策略定义 Application Auto Scaling 可以调整表的预置吞吐量的详细情况，以及它在执行此操作时需要采取的措施。您将此策略与您在上一步中定义的可扩展目标 (TestTable 表的写入容量单位) 相关联。
该策略包含以下元素：
- PredefinedMetricSpecification – Application Auto Scaling 允许调整的指标。对于DynamoDB，以下值是 PredefinedMetricType 的有效值： DynamoDBReadCapacityUtilization DynamoDBWriteCapacityUtilization
- ScaleOutCooldown – 增加预置吞吐量的每个 Application Auto Scaling 事件之间的最短时间(以秒为单位)。该参数允许 Application Auto Scaling 持续但不是激进地增加吞吐量以应对实际工作负载。ScaleOutCooldown 的默认设置是 0
- ScaleInCooldown –减少预置吞吐量的每个 Application Auto Scaling 事件之间的最短时间 (以秒为单位)。此参数允许Application Auto Scaling 以渐进和可预测的方式减少吞吐量。ScaleInCooldown 的默认设置是 0。
- TargetValue – Application Auto Scaling 确保消耗的容量与预置的容量的比例保持在该值或接近该值。应将TargetValue 定义为百分比。
4 踩到的坑
1 表预制容量用不完也是按预置容量收费。
2 全局二级索引也是需要读取和写入容量的。
3 AutoScaling并不是实时扩容和收缩，其中有一段启动和冷却时间，可以自己设置
4 索引不可写，但索引投影的属性在表中改变，即会同样更新索引内容即会占用索引写入容量。如果你用了五个索引都投影了某个属性，而该属性内容改变了，5个索引都会更新，这里就用掉了5个容量。
5 慎用scan 读取表中的所有项目。DynamoDB 所考量的是评估所得的项目大小，而不是扫描返回的项目大小。
6 自动扩容会使用cloudwatch，而自动扩容条件下，一个表（或全局二级索引）就会占用5个警报容量，一个警报容量就是0.1刀一个月。5个带全局二级索引的表就是50个容量，cloudwatch前10个容量免费，意思开启autoScaling固定一个月就是4刀的cloudwatch支出。