AWS DynamoDB的简介与使用

DynamoDB的简介Amazon Dynamodb是一种快速灵活的NoSQL数据库服务，适用于所有需要一致的单位毫秒延迟的应用程序。它是一个完全管理的云数据库，支持文档和关键价值存储模型。其灵活的数据模型、可靠的性能和吞吐量的自动扩展使其非常适合移动、网络、游戏、广告技术、物联网和许多其他应用程序。从今天开始下载dynamodb的本地版本，然后阅读我们的入门指南。表名名称必须符合dy...

steven_zr

4189人浏览 · 2019-04-27 22:30:28

steven_zr · 2019-04-27 22:30:28 发布

DynamoDB的简介

Amazon Dynamodb是一种快速灵活的NoSQL数据库服务，适用于所有需要一致的单位毫秒延迟的应用程序。它是一个完全管理的云数据库，支持文档和关键价值存储模型。其灵活的数据模型、可靠的性能和吞吐量的自动扩展使其非常适合移动、网络、游戏、广告技术、物联网和许多其他应用程序。从今天开始下载dynamodb的本地版本，然后阅读我们的入门指南。

表名

名称必须符合dynamodb命名规则，并且对于当前的AWS帐户和区域必须是唯一的。但是在不同域中的相同名字的表被认为是不同的。

主键

主键可以由一个属性（分区键）或两个属性（分区键和排序键）组成。dynamodb在分区中存储数据。分区是一个表的存储分配，由固态驱动器（SSD）支持，并在一个AWS区域内跨多个可用性区域自动复制。分区管理完全由dynamodb处理，您不必自己管理分区。需要注意的是，分区建的设计是选择一个分区建，该键相对于表中的项数可以具有大量不同的值。分区建的设计原则后面会详细讲到。不能用关系数据库设计主键的思维来设计No SQL 数据库的主键。

按需模式

Amazon DynaModb点播是一种灵活的计费选项，能够在不进行容量规划的情况下每秒处理数千个请求。强烈建议在不确定RCU、WCU的情况下选择此模式。

如果以下任何一项为真，则按需模式是一个不错的选择：

•创建具有未知工作负载的新表。

•您有不可预测的应用程序流量。

•您更喜欢只为您使用的东西付费。

预制模式

如果选择设置模式，则指定应用程序每秒所需的读写次数。您可以使用自动缩放来根据流量变化自动调整表的配置容量。这有助于您管理dynamodb的使用，使其保持在或低于定义的请求速率，以便获得成本可预测性。但是在使用自动缩放的时候会遇到一些问题下面会详细介绍，可以使用控制台默认的费用计算器，计算相应的费用。

开发dynamodb的最佳实践

AWS SDKs

使用任何的dynamoDB API都需要注意AWS的版本，项目中遇到 tagUser function的时候只有 "aws-sdk": "^2.384.0", 以上版本才支持这个API，详细请查阅AWS API的change log,https://github.com/aws/aws-sdk-js/blob/master/CHANGELOG.md

设计分区键以均匀分发工作负载

推荐一篇AWS上的设计分区键的最佳实践的bolg, https://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html

ProvisionedThroughputExceededException

这个错误的信息表明已超过表或一个或更多全局二级索引的最大允许预置吞吐量。要查看预置吞吐量与占用吞吐量的性能指标，请打开 Amazon CloudWatch 控制台。可以使用下面两个方式解决。

错误重试和指数退避

https://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.RetryAndBackoff

代码中实现updateCapacity

产生原因解释如下，总结下来就是auto-scaling也需要时间，所以项目中就显示调用DynamoDB的updatecapacity API。

DynamoDB auto-scaling modifies provisioned throughput settings only when the actual workload stays elevated (or depressed) for a sustained period of several minutes. The Application Auto Scaling target tracking algorithm seeks to keep the target utilization at or near your chosen value over the long term.

When you create a scaling policy, Application Auto Scaling creates a pair of Amazon CloudWatch alarms on your behalf. Each pair represents your upper and lower boundaries for provisioned throughput settings. These CloudWatch alarms are triggered when the table's actual utilization deviates from your target utilization for a sustained period of time.

The CloudWatch alarm then invokes Application Auto Scaling, which in turn notifies DynamoDB to adjust the table's provisioned capacity upward or downward, as appropriate. It might take several minutes before your table's actual read and write traffic is reflected in CloudWatch. If a table has irregular or spiky traffic, DynamoDB autoscaling might not yield the desired results.

And as per CloudWatch metric of the consumed capacity, the load was inconsistent and the overall consume capacity was quickly increasing then decreasing.

Hence throttling can occur for short duration spike in capacity consumption(before the auto scaling occurs), and will get recover if the consumption persists for a sustained period; as autoscaling will trigger.

The AWS SDKs have built-in support for retrying throttled requests so you do not need to write this logic. Each AWS SDK implements retry logic, automatically. You can modify the retry parameters to your needs. With the AWS SDK for Java, you could use the ClientConfiguration class and provide a maxErrorRetry value of 'n' to set the number of retries. In addition to simple retries, each AWS SDK implements exponential backoff algorithm for better flow control. The concept behind exponential backoff is to use progressively longer waits between retries for consecutive error responses.

针对查询和扫描数据的最佳实践

https://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/bp-query-scan.html

我们把项目中的所有查询都改成了query，query支持index查询，效率比scan高很多。

一般来说，在 DynamoDB 中，Scan 操作的效率低于其他操作。Scan 操作始终扫描整个表或二级索引。之后，它筛选出值以提供所需结果，从本质上讲，这增加了从结果集中删除数据这个额外步骤。

如有可能，应避免对大型表或索引使用带有会删除很多结果的筛选条件的 Scan 操作。同时，随着表或索引的增大，Scan 操作的速度会变慢。Scan 操作根据请求的值检查每个项目，可以在单次操作中用尽大型表或索引的预置吞吐量。为了缩短响应时间，请对表和索引进行设计，以便应用程序可以使用 Query 而非 Scan。(对于表，还可以考虑使 GetItem 和 BatchGetItem API。)

或者，如果要在应用程序设计中使用 Scan 操作，应最大程度地降低这一操作对您的请求率的影响。