dynamodb入门(dynamodb的使用方法)

很多新手对于如何解决DynamoDB的问题不是很清楚。为了帮助大家解决这个问题，下面小编就详细讲解一下。需要的人可以从中学习，希望你能有所收获。

DynamoDB是亚马逊基于《Dynamo: Amazonrsquo;s Highly Available Key-value Store》实现的NoSQL数据库服务。可以满足数据库的无缝扩展，保证数据的持久性和高可用性。开发人员不必费心去关注DynamoDB的维护、扩展和性能等一系列问题。它完全由亚马逊托管，因此开发人员可以将更多精力投入到架构和业务层面。

下面主要介绍作者团队在具体业务中遇到的挑战，基于这些挑战最终选择亚马逊DynamoDB的原因，在实践中遇到了哪些问题，如何解决。本文不会详细讨论Amazon dynamidb的技术细节，也不会涵盖Amazon dynamidb的所有特性。

背景与挑战

TalkingData移动广告效果监测产品(TalkingData Ad Tracking)作为介于广告主和媒体之间的广告监测平台，每天需要接收大量的促销样本信息和实际效果信息，最终将实际效果归结于促销样本。

比如我们通过手机的某个新闻APP浏览信息时，会看到信息流中穿插的广告。广告可以是文字、图片或者视频的形式，不管是什么样的广告，都可以和用户互动。

如果广告推送准确，并且只是用户感兴趣的内容，用户可以点击广告了解更多信息。一旦广告被点击，监控平台就会收到用户这次触发的点击事件。我们称这个点击事件样本信息所携带的所有信息，可能包括被点击广告的来源、点击广告的时间等等。通常点击广告会引导用户进行相关操作，比如下载广告推荐的APP。当用户下载并打开APP时，移动广告监控平台会收到APP发送的效果信息。到目前为止，即使是广告的成功转型。

DynamoDB实践：当数据量巨大且不可预测时，如何确保高可用性和实时性？

移动广告监控平台需要接收到源源不断的样本信息和效果信息，并实时反复不断地进行转化。就监控平台而言，责任重大，多多少少不能记录。如果转换数据记录的多，广告主需要向媒体支付更多的广告费，如果媒体记录的少，就会有损失。这给平台带来了一些挑战：

数据量大：部分媒体可能会利用非正常手段制作假样本，实现利润最大化，造成“虚假流量”。因此，除了真实的用户样本，广告监测平台还会收到大量的虚假样本，影响正常的监测和归属。在最“疯狂”的时候，我们的平台一天就能收到40亿次点击样本事件请求。我们要知道，这些点击样本事件是要留给后续的效果归属的，样本的有效期变化很大，最短的12小时，最长的90天不等。

数据量不可预测：广告主推送、app store竞价排名等一系列促销活动，会导致大量样本数据突然流入。面对这些不可预测的交通状况，我们还是要保证系统的正确性、稳定性和实时性。

实时处理：广告主依靠广告监控平台的实时处理结果来调整广告推广策略。因此，广告监测平台需要支持实时数据处理，以便为广告主更快优化推广策略提供有力支持。同时，广告监测平台的处理结果也要实时传回媒体和广告主。可见，准确性和实时性是系统必须满足的基本条件。

样本存储：归属是我们业务的核心功能。我们需要明确哪个推广样本带来了用户下载打开APP mdash的转化效果；mdash即上图第7步，用户安装APP后，监控平台要找出第1步样本的推广活动，这是一个查询匹配的过程。对于庞大的归因样本数据，有效期是不同的。我们应该如何存储样本，使系统属性快速，而不影响实时结果，这也是一个很大的挑战。

最初形态

2017年6月之前，我们的业务处理服务部署在机房，使用Redis版存储所有样本数据。Redis使用多节点分区，每个分区以主从模式部署。一开始，我们在Redis中部署了多个节点，这些节点被划分为多个分区，每个分区有一个主节点和一个从节点。起初这种方法没有问题，但随着用户设置样本有效期的延长和监测样本的增加，当时的节点数量逐渐不足以支撑业务存储水平。如果用户监控和推广量突然增加，我们的系统存储将面临崩溃，业务将陷入瘫痪。所以我们进行了第一次扩张。

因为之前的部署方式，我们只能将Redis的多个节点的容量翻倍，所有的都需要手动操作，在这期间我们尽力了。

办法来保护用户的样本数据。

DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性?

这种部署方式随着监测量的增长以及用户设定有效期变长会越来越不堪重负，当出现不可预知的突发量时就会产生严重的后果。而且，手动扩容的方式容易出错，及时性低，成本也是翻倍的增长。在当时由于机器资源有限，不仅  Redis 需要扩容，广告监测平台的一系列服务和集群也需要进行扩容。

化解挑战

经过讨论和评估，我们决定将样本处理等服务迁移到云端处理，同时对存储方式重新选型为 Amazon  DynamoDB，它能够满足我们的绝大部分业务需求。经过结构调整后系统大概是下图的样子：

DynamoDB实践：当数据量巨大而不可预知，如何保证高可用与实时性?

• 应对数据量大且不可预知：我们的平台需要接受推广监测连接请求，并进行持久化用于后续的数据归因处理。理论上来说系统进来多少广告监测数据请求，DynamoDB  就能存多少数据，只需要一张表就可以存储任意数量级的数据。不用关心 DynamoDB 扩容问题，在系统运行时我们感知不到存储正在扩容。这也是 Amazon  官方宣称的完全托管、无缝扩展。

• 高可用：Amazon DynamoDB 作为存储服务提供了极高的可用性，对于写入 DynamoDB 的全部数据都会存储到固态硬盘中，并且自动同步到 AWS  多个可用区，以达到数据的高可用。这些工作同样完全由 Amazon DynamoDB 服务托管，使用者可以将精力放到业务架构及编码上。

• 实时处理：Amazon DynamoDB 提供了极高的吞吐性能，并且支持按秒维度配置任意级别的吞吐量。对于写多读少的应用可以将每秒写入数据的数量调整成  1000 甚至更高，将每秒读取的数量降低到 10 甚至更少。吞吐量支持使用者任意设定，在设定吞吐量时除了可以随时在 Web 管理后台调整外，还可以通过  DynamoDB 提供的客户端动态调整。比如系统在运行时写入能力不足了，我们可以选择到 Web 管理后台手动上调或在代码中通过调用客户端 API  的方式实现自动上调。使用客户端动态调整的方式会让系统具备较高的收缩能力，同时还可以保证数据的实时处理，系统数据流量变高了就动态调整上去，数据流量变低了再动态调整下来。相比手动调整来看，动态调整的方式更为灵活。基于以上几点，我们认为  Amazon DynamoDB 可以很轻松的支撑系统的核心业务能力。对于业务侧需要做的就是，整理好业务逻辑把数据写到 DynamoDB 就可以了，剩下的就交给  DynamoDB 去做。

此外还有：

• TTL：我们利用了 Amazon DynamoDB 提供的 TTL 特性管理那些有生命周期的数据。TTL  是对表中要过期的数据设置特定时间戳的一种机制，一旦时间戳过期 DynamoDB 在后台会删除过期的数据，类似于 Redis 中的 TTL 概念。借助 TTL  的能力，我们减少了很多业务上不必要的逻辑判定，同时还降低了因存储量带来的成本。

• 流：在我们的业务中没有启用流来捕获表的动作，但我们认为 DynamoDB 流是一个非常好的特性，当存储在 DynamoDB  表中的数据发生变更(新增、修改、删除)时，通知到相关的服务 / 程序。比如我们修改了一条记录的某个字段，DynamoDB  可以捕获到这个字段的变更，并将变更前后的结果编写成一条流记录。

实践出真知

我们在使用一些开源框架或服务时总会遇到一些“坑”，这些“坑”其实也可以理解为没有很好的理解和应对它们的一些使用规则。DynamoDB  和所有服务一样，也有着它自己的使用规则。在这里主要分享我们在实际使用过程中遇到的问题以及解决办法。

数据偏移

在 DynamoDB  中创建表时需要指定表的主键，这主要为了数据的唯一性、能够快速索引、增加并行度。主键有两种类型，「单独使用分区键」作为主键和「使用分区键 +  排序键」作为主键，后者可以理解为组合主键(索引)，它由两个字段唯一确定 / 检索一条数据。DynamoDB  底层根据主键的值对数据进行分区存储，这样可以负载均衡，减轻单独分区压力，同时 DynamoDB 也会对主键值尝试做“合理的”分区。

在开始我们没有对主键值做任何处理，因为 DynamoDB  会将分区键值作为内部散列函数的输入，其输出会决定数据存储到具体的分区。但随着运行，我们发现数据开始出现写入偏移了，而且非常严重，带来的后果就是导致  DynamoDB 表的读写性能下降，具体原因在后面会做详细讨论。发现这类问题之后，我们考虑了两种解决办法：

所以我们选择了第二种方法，调整业务代码，在写入时将主键值做哈希，查询时将主键条件做哈希进行查询。

自动扩容潜规则

在解决了数据偏移之后读 / 写性能恢复了，但是运行了一段时间之后读写性能却再次下降。查询了数据写入并不偏移，当时我们将写入性能提升到了 6 万 +/  秒，但没起到任何作用，实际写入速度也就在 2 万 +/ 秒。最后发现是我们的分区数量太多了，DynamoDB 在后台自动维护的分区数量已经达到了 200+  个，严重影响了 DynamoDB 表的读写性能。

DynamoDB 自动扩容、支持用户任意设定的吞吐量，这些都是基于它的两个自动扩容规则：单分区大小限制和读写性能限制。

单分区大小限制

DynamoDB 会自动维护数据存储分区，但每个分区大小上限为 10GB，一旦超过该限制会导致 DynamoDB  拆分区。这也正是数据偏移带来的影响，当数据严重偏移时，DynamoDB 会默默为你的偏移分区拆分区。我们可以根据下面的公式计算分区数量：

数据总大小 / 10GB 再向上取整 = 分区总数

比如表里数据总量为 15GB，15 / 10 = 1.5，向上取整 = 2，分区数为 2，如果数据不偏移均匀分配的话两个分区每个存储 7.5GB  数据。

读写性能限制

DynamoDB 为什么要拆分区呢?因为它要保证用户预设的读 / 写性能。怎么保证呢?依靠将每个分区数据控制在 10G  以内。另一个条件就是当分区不能满足预设吞吐量时，DynamoDB 也会将分区进行扩充。DynamoDB 对于每个分区读写容量定义如下：

写入容量单位：写入容量单位(WCU：write capacity units)，以每条数据最大 1KB 计算，最大每秒写入 1000 条。

读取容量单位：读取容量单位(RCU：read capacity units)，以每条数据最大 4KB 计算，最大每秒读取 3000 条。

也就是说，一个分区的最大写入容量单位和读取容量单位是固定的，超过了分区最大容量单位就会拆分区。因此我们可以根据下面的公式计算分区数量：

(预设读容量 /3000)+(预设写容量 /1000)再向上取整 = 分区总数

比如预设的读取容量为 500，写入容量为 5000，(500 / 3000) + (5000 / 1000) = 5.1，再向上取整 = 6，分区数为  6。

需要注意的是，对于单分区超过 10G 拆分后的新分区是共享原分区读写容量的，并不是每个表单独的读写容量。

因为预设的读写容量决定了分区数量，但由于单分区数据量达到上限而拆出两个新的分区。

所以当数据偏移严重时，读写性能会急剧下降。

冷热数据

产生上面的问题是由于我们一开始是单表操作。这样就算数据不偏移，但随着时间推移数据量越来越多，自然拆出的分区也越来越多。

因此，我们根据业务做了合理的拆表、设定了冷热数据表。这样做有两大好处：

提升性能：这一点根据上面的规则显而易见，热表中数据量不会持续无限增长，因此分区也稳定在一定数量级内，保证了读写性能。

降低成本：无谓的为单表增加读写性能不仅效果不明显，而且费用也会急剧增高，使用成本的增加对于谁都是无法接受的。DynamoDB  存储也是需要成本的，所以可以将冷表数据存储到 S3 或其他持久化服务中，将 DynamoDB 的表删除，也是降低成本的一种方式。

表限制

表对于数据的大小以及数量并没有限制，可以无限制的往一张表里写入数据。但对于 AWS 的一个账户，每个 DynamoDB 使用区域的限制为 256  张表。对于一个公司来说，如果共用同一个账号的话可能会存在创建表受限的风险。所以如果启用了冷热表策略，除了删冷表降低成本外，也是对 256  张表限制的一种解决办法。

属性名长度

上面提到了写入单位每条数据最大 1KB、读取单位每条最大 4KB  的限制。单条数据的大小除了字段值占用字节外，属性名也会占用字节，因此在保证可读性的前提下应尽量缩减表中的属性名。

DynamoDB 的使用也是存在成本的，主要体现在写入和读取的费用。我们自己研发了一套按照实际流量实时调整读、写上限的策略。随着发展 DynamoDB  也推出了 Auto Scaling 功能，它实现了自定义策略动态调整写入与读取上限的能力，对于开发者来说又可以省去了不少研发精力。目前我们也有部分业务使用了  Auto Scaling 功能，但由于该功能的限制，实际使用上动态调整的实时性略显欠缺。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。