Tag: Amazon DynamoDB


全新推出 – Auto Scaling for Amazon DynamoDB

Amazon DynamoDB 拥有十万多的客户,客户身处各种行业,使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势,客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配:使用 DynamoDB,您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表,然后开始添加数据,其他的交给 DynamoDB 处理。

DynamoDB 提供预置容量模式,可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器,在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改,但客户已经在询问我们,有没有方法让管理 DynamoDB 容量变得更加轻松。

现在,我们推出了 Auto Scaling for DynamoDB,可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率,并提供读取和写入容量的上限和下限。之后,DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况,并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用,您还可以对现有表和索引配置此功能。即使您不在左右,DynamoDB Auto Scaling 也将监控您的表和索引,并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据,帮助您最大程度地提高应用程序的可用性,并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的……

使用 Auto Scaling

现在当您创建新表时,DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们,也可以取消选中“Use default settings”,然后输入您自己的参数:

以下是您输入自己的参数的方式:

目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间,使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算,了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。

Auto Scaling 的实际操作

为了了解这项重要的新功能的实际操作,我按照入门指南中的指示进行了操作。我启动了一个全新的 EC2 实例,安装了 (sudo pip install boto3) 并配置了 (aws configure) 适用于 Python 的 AWS 开发工具包。然后我使用 Python 和 DynamoDB 一节中的代码创建了一个表,为其填充了一些数据,并手动为该表分别配置了 5 个读取和写入容量单位。我稍作休息,以便 CloudWatch 指标形成简洁的直线,这样我就可以展示 Auto Scaling 的效果了。这是我开始应用负载之前指标的样子:

步骤3中,我修改了代码,以便继续在 1920 年至 2007 年之间随机选择年份执行查询,运行一份代码,并在一两分钟后查看了读取指标:

占用的容量高于预置的容量,导致出现了大量的受限制读取。现在就是 Auto Scaling 发挥作用的时间了!我返回控制台,单击了我的表中的 Capacity 选项卡。然后我单击 Read capacity,接受默认值,并单击 Save

DynamoDB 创建了一个新的 IAM 角色 (DynamoDBAutoscaleRole) 和一对 CloudWatch 警报来管理读取容量的 Auto Scaling:

DynamoDB Auto Scaling 将会管理警报的阈值,在扩展过程中上下移动这些阈值。第一个警报被触发,表状态更改为 Updating,同时预置了额外的读取容量:

几分钟内,读取指标中就会显示这一更改:

我启动了我修改后的查询脚本的其他几个副本,并观察额外容量的预置情况,如红线所示:

我删除了所有的脚本,然后去做其他的事情,同时等待缩减警报触发。以下是我返回时所看到的:

第二天,我检查了我的 Scaling activities,看到警报在一夜间已经触发了多次:

这在指标中也有显示:

到现在为止,对于这种情况,您需要根据预期使用情况合理设置您的读取容量,还要准备着为超额容量 (蓝线和红线之间的空间) 付款。否则,您可能将它设置得太低,忘了进行监控,而在流量攀升时容量耗尽。使用 Auto Scaling,您就可以做到两全其美:当需求增加,表明需要更多容量时自动响应,当容量不再需要时,再一次自动响应。

须知事项

DynamoDB Auto Scaling 可用于处理以大致可预测、通常为周期性的方式变化的请求速率。如果您需要处理不可预测的读取活动突增,则应将 Auto Scaling 与 DAX 结合使用 (请参阅 Amazon DynamoDB Accelerator (DAX) – 读取操作密集型工作负载的内存缓存以了解更多信息)。另外,AWS SDK 会检测受限制的读取和写入请求,并在适当的延迟之后重新尝试这些请求。

我之前提到了 DynamoDBAutoscaleRole。该角色为 Auto Scaling 提供它要扩展和收缩表和索引所需的权限。要了解更多有关这一角色及其使用权限的信息,请参阅Using the AWS Management Console With DynamoDB Auto Scaling

Auto Scaling 拥有完整的 CLI 和 API 支持,包括启用和禁用 Auto Scaling 策略的能力。如果您的流量存在一些可预测的时限性峰值,则您可以通过编程的方式禁用 Auto Scaling 策略,在设定的时间段内预置更高的吞吐量,并在之后重新启用 Auto Scaling。

DynamoDB 中的限制页面中所述,您可以按您所需的频率,根据您的需求增加预置容量 (受限于可以申请增加的每帐户限制)。对于每个表或全局二级索引,您每天最多可将容量减少九次。您将按照正常的 DynamoDB 定价为您预置的容量付费。您还可以通过购买 DynamoDB 预留容量进一步节省费用。

现已推出 此功能现已在所有区域推出,您可以立即开始使用。

-Jeff

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍

相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC(Infrastructure as Code)自动化运维的一项重要服务,可以帮助用户对 AWS资源进行建模和设置,以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项:Mappings段和Parameters段,可以帮助用户组织模板里的参数和映射,让用户更好地自定义堆栈,以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID,或者管理企业内部的不同部门。

但是当用户所在的组织越来越多地采用IAC自动化时,mappings和parameters的数量也会急剧增长,给CloudFormation模板的编写和维护带来复杂度。

解决方案

本文里我们介绍一种方法:用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。

本文中主要用到了以下几种 AWS服务:

1、DynamoDB表:Amazon DynamoDB是一个NoSQL数据库,这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放,而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中,整个企业采用这样一张表:partition key包括组名(比如说team1、team2等)和环境(比如说development、test、production等),sort key保存应用的名字。这个表里的数据类似这样:

当我们把这些数据都insert到DynamoDB中后,可以在AWS console里看到表中的内容是这样的:

2、Lambda方法:AWS Lambda又称为Serverless的计算,通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联,它从CloudFormation模板接收primary key和sort key作为输入,查找DynamoDB表,并且返回所有的key-value数据。

3、Custom lookup resource:这是CloudFormation里的一个自定义资源,与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源,还支持几种自定义资源,包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时,CloudFormation自动地向Lambda API发起请求,引发方法并将请求的数据传给Lambda方法,本例中所请求的数据是primary key,返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource,所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource:

让我们将这几种服务组合起来,并且定义好它们之间的交互顺序,整个解决方案就是下图展示的这样:

那么整个的交互顺序如下:

1、用户创建DynamoDB表,插入所需的mappings和parameters数据。

2、CloudFormation模板中的custom resource调用Lambda方法,用组名和环境名称(“teamname-environment”)作为partition key,用应用名称(”appname”)作为sort key。

3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。

4、DyanamoDB将结果返回给Lambda方法。

5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。

6、custom resource拿到数据后,堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。

结论

通过这种方式,可以将我们创建堆栈所需的固定部分保存在模板中,而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中,用Lambda实现两者之间的关联。对于大型组织来说,这样可以提高运维效率,也是使用CloudFormation的一种最佳实践。

参考

可以在我们的网站上下载到相关的sample code:https://github.com/awslabs/custom-lookup-lambda

关于AWS Lambda的更多内容请参考网站:https://aws.amazon.com/lambda/

关于CloudFormation自定义资源的更多内容请参考网站:http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

作者介绍

张芸

AWS云架构咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,为企业客户和合作伙伴提供迈向云端的专业服务。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移、应用优化、架构设计等咨询设计和实施服务。在加入AWS之前有近10年的云计算和大数据开源技术研究和开发经验,拥有多项美国和中国专利及专利申请,涉及云计算及服务,分布式系统,软件定义数据中心和自动化运维等领域,合作编著图书《大数据–战略·技术·实践》。

 

数据库迁移服务DMS——手把手教你玩转MongoDB到DynamoDB之间数据库迁移

1. 前言

AWS最近刚刚宣布了一项关于数据库迁移的新feature,支持Mongodb数据库作为源端,迁移到目标端Dynamodb中,这样可以使MongoDB的用户充分利用DynamoDB数据库提供的技术优势,譬如完全托管服务,高性能低延迟(毫秒级),精细化粒度控制等等。由于最近项目中涉及很多数据库迁移的事情,同时也对NOSQL数据库异构平台迁移非常感兴趣,写了这篇文档供大家参考。

2. DMS服务介绍

DMS作为数据迁移服务支持下面三种迁移类型:

  • 迁移源库中存在的数据到目标库
  • 迁移源库中存在的数据并且复制新增加的数据到目标库
  • 只复制新增加的数据库

数据迁移时源端和目标端设置

  • MongoDB作为源端

AWS DMS支持Mongodb作为源端的版本为2.6.x和3.0.x,MongoDB 作为一个基于文档存储的数据库,数据模式非常灵活,支持JSON和BJSON格式进行存储。当前AWS DMS 支持MongoDB作为源端以两种模式进行迁移,它们分别是文档模式和表模式。在文档模式中,需要设置参数extractDocID=true和nestingLevel=none,在复制时不支持collection的重命名。在表模式中需要启用表模式需要设置nestingLevel=one,另外在选择CDC时它不支持添加新的collection和重名collection。

  • DynamoDB作为目标端

使用Dynamodb作为目标端时需要配置partion key和Object mapping。

具体注意事项请参考官方文档链接:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html

3. 配置步骤

3.1 安装Mongodb

安装Mongodb的方式有多种方法,可以选择Marketplace或者AWS提供的cloudformation以及手动下载Mongodb软件进行安装,我选择手动安装Mongodb2.6.12版本。

A、登录EC2,获取如下软件:

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-mongos_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-tools_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-server_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-shell_2.6.12_amd64.deb

B、安装软件包:

ubuntu@ip-172-31-60-214:~$ sudo dpkg -i mongodb-org*

C、创建数据目录和日志目录:

ubuntu@ip-172-31-60-214:~$ sudo mkdir /data /log

D、启动mongodb数据库服务:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –logpath /log/mongodb.log –smallfiles –oplogSize 50 –fork

打开mongodb的shell, 验证服务启动成功。

ubuntu@ip-172-31-60-214:~$ mongo

MongoDB shell version: 2.6.12

connecting to: test

如下图所示:

3.2 通过脚本生成数据

for (var i = 1; i <= 793308; i++) {

               db.testData.insert( { x : i , name: "MACLEAN" , name1:"MACLEAN", name2:"MACLEAN", name3:"MACLEAN"} )

db.contacts.insert( { name: "Amanda", status:

"Updated" } )

db.contacts.insert( { name: "tom", status: "Updated" } )

db.contacts.insert( { name: "jack", status: "Updated" } )

db.contacts.insert( { name: "jack1", status:    "Updated" } )

db.contacts.insert( { name: "steph", status:    "Updated" } )

3.3 验证数据生成

运行如下命令:

3.4配置mongodb的副本集

A、启动mongodb数据库

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork

如下图:

B、登录到mongodb中,进行副本的初始化,如下图所示:

ubuntu@ip-172-31-60-214:~$ mongo localhost

MongoDB shell version: 2.6.12

connecting to: localhost

>

rs.initiate()

C、验证部署配置

> rs.conf()

D、创建管理员角色

rs0:PRIMARY> use admin

switched to db admin

rs0:PRIMARY> db.createUser(

…   {

…     user: “root”,

…     pwd: “rootpass”,

…     roles: [ { role: “root”, db: “admin” } ]

…   }

… )

如下图所示:

E、停止mongodb,然后重启mongodb:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork –auth

如下图所示:

至此,Mongodb的数据库准备工作完成。

3.5 使用global账号登录到DMS服务,如下图所示:

A、创建复制实例:

指定Name,Instance class,Allocated storage,VPC选择创建,如下图所示:

创建mongodb源端的Endpoint,输入Endpoint identifier,Source engine指定为mongodb,Servername为Mongodb数据库主机IP,Port,Authentication mode,username等信息,如下所示:

注意在高级设置中指定extraDocID=true;nestingLevel=none

点击test connection验证连接成功。

点击创建完成。

B、创建目标端DynamoDB的endpoint

在endpoint console中选择create endpoint,并输入信息:Endpoint identifier,Endpoint type为Target,Target engine为dynamodb,指定Service Aceess Role ARN,并在advanced中设置:extractDOcID=true;nestingLevel=none

如下图所示:

点击test connection,验证成功,选择create 完成创建。

此处主要角色的设置需要指定:dms-vpc-role,同时attached 3个policy,如下图所示:

endpoint创建完成,如下所示:

C、创建task

点击create task,输入如下信息:task name,source endpoint,target endpoint,migrate type,Enable loging,同时根据实际需求进行相应的任务设置。

创建table mappings,点击json tab,进行手动输入设置:

注意,json文件内容需要根据各自创建的表进行手动创建。

点击创建任务,任务创建完成。

D、验证数据导入成功

返回任务列表,选择table statistics,查看表的导入是否成功,如下图所示:

MongoDb记录成功导入到dynamodb中,选择log可以通过cloudwatch查看DMS导入过程的记录。

登录到DynamoDb中,发现表成功创建,并且导入成功,如下图:

至此整个利用DMS进行Mongodb到Dynamodb的数据库迁移完成。

关于如何设置Table mapping 请参阅官方文档:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.DynamoDB.html

附录

测试中我使用的Table Mapping json内容如下:

{

            "rules": [

                        {

                                    "rule-type": "selection",

                                    "rule-id": "1",

                                    "rule-name": "1",

                                    "object-locator": {

                                                "schema-name": "test",

                                                "table-name": "%"

                                    },

                                    "rule-action": "include"

                        },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "contacts"

        },

        "target-table-name": "contacts",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "3",

          "rule-name": "TransformToinventory",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "inventory"

        },

        "target-table-name": "inventory",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToEC2test",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "ec2Test"

        },

        "target-table-name": "ec2Test",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "testData"

        },

        "target-table-name": "testData",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            }

  ]

}

 

作者介绍

王友升

AWS解决方案架构师,拥有超过13年的IT从业经验,负责基于AWS的云计算方案架构咨询和设计,推广AWS云平台技术和各种解决方案。在加入AWS之前,曾在中地数码,浪潮,惠普等公司担任软件开发工程师,DBA和解决方案架构师。在服务器,存储,数据库优化方面拥有多年的经验,同时对大数据,Openstack及AI方面也进行一定的研究和积累。

DAX – DynamoDB集成全托管的内存缓存,轻松搞定读取负载!

相信大家已经都知道,Amazon DynamoDB 是一项全托管的NoSQL 数据库服务,适合所有需要一致性且延迟低于 10 毫秒的任意规模的应用程序,支持文档和键值存储模型。使用DynamoDB,可创建数据库表来存储和检索任意量级的数据,并提供任意级别的请求流量。现在,DynamoDB还提供了Auto-Scaling的功能,即可以通过你预先设置的阈值自动扩展和缩减表的吞吐量,做到完全弹性自动伸缩的目的,真正达到让你的数据库按实际吞吐量进行付费。

这么高的并发量却依然可以保持服务器的平均延迟在个位数毫秒,这让DynamoDB受到了非常多用户的青睐。然而随着大数据时代的数据暴增,很多客户的场景比较特殊,他们对数据库的响应时间越来越苛刻,甚至需要达到微秒的级别!这无疑给DynamoDB数据库又带来了一个难题。甚至也有客户会提到,能不能在DynamoDB前面放一层类似Redis的Cache服务呢?如果这样做的话,需要自己搭建缓存数据库,并且解决DynamoDB和Redis之间的数据同步问题;同时还要重写代码实现业务逻辑,比如如果数据在缓存中,则立即返回,如果数据没有在缓存中,则必须从数据库里面读取,将数据写入到缓存中,然后再返回。

当用户还带着这样的担心时,现在,Amazon DynamoDB已经整合了这一特性,推出了一个新的功能,即Amazon DynamoDB Accelerator,简称DAX。这是一种完全托管并且高度可靠的内存缓存,即使每秒种的请求量达到数百万,却依然可以将Amazon DynamoDB的响应时间从数毫秒缩短到数微秒!其实在很多场景都可以用到DAX,比如实时竞拍、秒杀、电商、社交游戏等场景,DAX可以提供快速的内存读取性能;再比如在产品促销日,读取访问量会明显上升,但是销售日结束访问量就会回归正常,诸如此类读取密集型的工作负载但同时又对成本敏感的应用都可以使用DAX服务。像类似于Expedia、Twilio、Genesys、eyeview等客户都已经率先用上了DAX服务

目前,DAX还是处于预览版,您可以点击链接进行申请。接下来,让我们创建一个DAX集群,赶紧体验一下微秒级别的响应测试吧!

1. DAX集群的原理

上图中可以看到,DAX起了一组缓存的节点(目前最多可以是10个节点),并将这些节点置放在VPC内部,应用程序部署在EC2上,这样EC2和DAX Cluster通过内网直接访问。关于DAX的内存缓存,主要是DynamoDB的读和写操作:

(1)最终一致性的读取操作,支持GetItem、BatchGetItem、Query、Scan接口,如果读取在DAX缓存中命中,将直接从DAX集群里读取;如果是第一次读取没有命中,那就从DyanmoDB里面读取。

(2)写入操作支持BatchWriteItem、UpdateItem、DeleteItem、PutItem接口,写入的时候数据先写入到DynamoDB表,确认写入成功之后,然后再写到DAX集群(item cache),这个操作只有在DynamoDB表和DAX集群都写入了数据的时候才算成功。如果由于一些原因这个操作失败了,那么这个item将不会缓存到DAX里面,并且会抛出一个exception。这种方式可以让缓存和数据库的数据保持一致性和完整性,不会出现过期数据在缓存里面。

(3)如果DAX有多个节点时,会选取一个主节点(primary node),多个从节点(read replica node),数据最终会分布到所有节点上,但对于客户端来说,只需要关心唯一的DAX连接地址,已经内置了负载均衡和路由策略,并且自动执行故障检测、故障恢复、软件修补等管理任务。

接下去,我们将模拟这一过程,进行实际测试。

2. 启动DAX集群

首先启动一个DAX集群,指定集群的节点数(目前节点最多为10个),我们建议您在生产环节中启用两个以上的节点,并将这些节点置放在不同的可用区中,从而提高高可用。设置好相应的IAM Role和Policy。Policy可以配置“只读”权限,或者“读和写”权限。更多关于权限配置可以参考:

http://s3.amazonaws.com/dynamodb-preview-dax/DAX.access-control.html

接下去设置DAX集群的子网组,DAX集群的节点会部署在这些子网里面。选定VPC和相对应的子网,并设置安全组。安全组入站需要打开DAX所用到的8111端口。

接下去配置DAX的参数组,指定Cache的Query TTL和Item TTL值。TTL的时间小到可以是“秒”,大到可以到“天”。

也可以自定义选定维护窗口,如果需要的话可以再加一个SNS通知,这样只要集群有维护就会立刻以短信,或者邮件等形式通知到您。

到这里,DAX集群就创建成功了。DAX集群会有一个唯一的endpoint地址,例如,这里是

dax-cluster-demo.bnsilv.clustercfg.dax.usw2.cache.amazonaws.com:8111

另外可以看到在这个例子中DAX集群启动了3个节点。

DAX集群具体的3个节点

3. 启动EC2 ,作为应用程序的server,同时作为DAX的client

如果仅作为测试,可以启动一台t2.micro的小型机器(Amazon Linux)。

EC2通过监控检查,启动成功。

4. 安装Java应用程序

(1)首先通过客户端连接到这台Amazon Linux EC2

(2)安装Java SDK

sudo yum install -y java-devel

(3)下载最新版的AWS Java SDK

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/aws-java-sdk-1.11.125.zip

unzip aws-java-sdk.zip

(4)下载最新版的DAX Jave客户端

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/DaxJavaClient-latest.jar

(5)设置CLASSPATH环境变量

export SDKVERSION=1.11.125

export CLASSPATH=.:./DaxJavaClient-latest.jar:aws-

java-sdk-$SDKVERSION/lib/aws-java-sdk-$SDKVERSION.jar:aws-

java-sdk-$SDKVERSION/third-party/lib/*

(6)下载Java应用程序代码

wget https://s3-us-west-2.amazonaws.com/danrongdemo/DynamoDB-Accelerator-Test-Demo/TryDax.zip

unzip TryDax.zip

(7)编译代码:javac TryDax*.java

(8)执行代码:java TryDax

以下是完整的应用程序拓扑图

5. 直接读取DynamoDB表的响应测试

从图中可以看到,直接从DynamoDB表里进行读取数据,分布执行了GetItem、Query、Scan操作,服务器的平均延时在个位数毫秒级别(小于10ms)。

此时查看DAX的监控还没有任何cache指标产生:

6. 加上DAX后进行测试

调整DAX的endpoint,通过代码判断当daxClient不为空时,就会采用DAX方式去查询。

将DAX的endpoint以参数形式传入执行,代码会判断DynamoDB的读取操作启用DAX内存缓存。

再次执行查询操作,发现:

上图中可以发现,第一次通过GetItem读取的时候由于DAX集群中没有数据,所以直接读取DynamoDB表,延迟在4.7ms左右,与此同时,会把数据写入到DAX集群中。当再次进行GetItem读取的时候,会直接从DAX内存缓存中读取,响应时间大概在0.8ms左右。同理,对于Query操作也可以发现,第一次查询DynamoDB表的响应时间是17.2ms,但是第二次读取时直接从DAX进行查询,响应时间缩短到了0.5ms左右。因此,不管是GetItem,Query还是Scan操作,读取操作的响应时间都已经大大提升了!另外,对于读取和写入操作,DAX已经自动集成了CloudWatch进行监控,很容易可以监控例如CPU使用率,Item Cache命中数,Query Cache命中数,总共的请求数等19个指标。

7. 如何将DAX整合到现有的DyanmoDB开发中?

您有可能会关心,我现在的业务代码已经基于DynamoDB开发好了,如何要把DAX整合进去,代码的开动量会不会很大呢?这一问题AWS已经替您考虑到了,例如有一张名为Music的表,主键(partition key)是Artist,排序建(sort key)是SongTitle。直接上代码:

8. 如何增加DAX的集群节点数?

增加DAX的节点数,可以通过API或者命令行操作,点击“Add node”:

然后选择新增加节点的个数,可以自定义DAX节点所在的可用区。如下:

9. 小结

如果您已经在使用Amazon DynamoDB了,集成DAX只需要稍微改动一下DAX client的实现,核心的业务逻辑代码基本上不用做任何改动。

DynamoDB的服务器平均延时在个位数毫秒级别,但是新出的DAX功能和DyanmoDB配合起来使用,则可以性能进一步推到一个新的层级,在处理每秒接收数以百万计请求的读取密集型工作负载时,响应时间缩短到以微秒级别,大概在0.几个ms左右。效果还是蛮惊人的!

更多DAX的介绍: https://aws.amazon.com/cn/dynamodb/dax/

关于DAX的价格: https://aws.amazon.com/cn/dynamodb/pricing/

作者介绍

毛郸榕

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,毕业于北京航空航天大学云计算专业,硕士,毕业后直接加入亚马逊AWS中国。在大规模后台架构、企业混合IT和自动化运维等方面有着丰富的实践经验。目前在集中精力学习新一代无服务器架构的开发与设计。

Amazon DynamoDB 让海量数据管理变为可能

随着大数据技术的发展,其数据集可以增长的非常庞大,以至于基于传统的关系型数据库管理系统及其工具集很难处理这些庞大的数据集。处理这些问题需要新的工具、框架、软件和服务。与此同时,越来越多的企业需要连续不断地访问数据,从而提高效率,改善用户体验。好的大数据工具集将以较低的成本,接近实时的速度提供可伸缩、高性能的数据管理和分析功能。企业借助于这些工具可以获得更强大的智能及竞争优势。

NoSQL(Not only SQL)非关系型数据库是近年来发展最为迅猛的大数据处理技术之一。在这一领域有非常多的产品和解决方案,包括众多的开源工程。如何选择一款合适的产品往往是困扰企业的难题。此外,企业应用场景各式各样,如何将NoSQL与企业IT融合也是一个重要的课题。如今的企业中,并非所有用例都直观地倾向于使用关系型数据库,或者都需要严格的ACID属性(特别是一致性和隔离性)。以Web为中心的企业中信息管理的新兴模式,使得“非关系型数据库”成为处理这些数据的最佳选择(较之关系型数据库来说)。NoSQL提供了对非结构化数据的支持,拥有支持分区的水平伸缩性,支持高可用性等。常见的NoSQL应用场景包括:日志挖掘、分析社交计算、外部数据聚合、前端订单处理系统、企业内容管理等。

Amazon DynamoDB是一种完全托管的NoSQL数据库服务,提供快速且可预测的性能,能够实现无缝扩展。Amazon DynamoDB可自动将表的数据和流量分布到足够多的服务器中,以处理客户指定的请求容量和数据存储量,同时保持一致的性能和高效的访问。所有数据项目均存储在固态硬盘(SSD)中,并在区域的多个可用区间自动复制,以提供内置的高可用性和数据持久性。例如,您可以使用Amazon DynamoDB创建数据库表,并可在表中存储和检索任意数量的数据和处理任何级别的请求流量。也可以通过AWS管理控制台创建新的Amazon DynamoDB数据库表、扩展或缩小表的请求容量而不导致停机或性能降低,还能查看资源使用率与性能指标。使用Amazon DynamoDB,你可以将操作和扩展分布式数据库的管理工作负担交给AWS服务,无须担心硬件预配置、设置和配置、复制、软件修补或集群扩展等问题。

使用Amazon DynamoDB能带来哪些好处

1    可扩展:Amazon DynamoDB旨在实现吞吐量和存储容量的高效无缝扩展

  • 预配置吞吐量:创建表时,只须指定所需的吞吐容量即可。Amazon DynamoDB会为您的表分配专用资源以满足性能要求,并自动将数据分区到足够多的服务器以满足请求容量。如果您的应用程序需求发生变化,只须使用AWS管理控制台或Amazon DynamoDB API调用更新表的吞吐容量即可。在扩展过程中,仍然能够保证之前的吞吐量水平没有下降。
  • 自动存储扩展:Amazon DynamoDB表中可存储的数据量没有限制,而且随着您使用Amazon DynamoDB写入API所存储数据量的增加,该服务会自动分配更多存储。
  • 完全分布式的无共享架构:Amazon DynamoDB可水平扩展并在数百台服务器中无缝扩展单个表。

2     快速、可预测的性能:Amazon DynamoDB的服务端平均延迟不超过10毫秒。该服务在固态硬盘中运行,其构建方式旨在任何规模均能保证服务性能持续优良,降低延迟。

3     轻松管理:Amazon DynamoDB是完全托管的服务,您只须创建数据库表,其余事情都交由该服务代劳。您无须担心硬件或软件预配置、设置和配置、软件修补、操作可靠的分布式数据库集群,也不必担心随着扩展的需要在多个实例间对数据进行分区等问题。

4     内置容错能力:Amazon DynamoDB内置容错能力,可在某个地区多个可用区域之间自动同步备份数据,以实现高效的可访问性,即使单台机器甚至设施出现死机,防护措施可保证数据万无一失。

5     灵活:Amazon DynamoDB没有固定模式。相反,每个数据项目可以有不同数量的属性。多种数据类型(字符串、数字、二进制数据和集)使数据模型更加丰富。

6     高效的索引:Amazon DynamoDB表中的每个项目均由一个主键标识,让您能够快速高效地访问数据项目。还可以就非键值属性定义二级索引,并使用替代键查询您的数据。

7     强一致性、原子计数器:与许多非关系数据库不同,Amazon DynamoDB允许您对读取操作使用强一致性检验以确保始终读取最新的值,从而使开发更加便捷。Amazon DynamoDB支持多种本地数据类型(数字、字符串、二进制数据和多值属性)。该服务还支持本地原子计数器,允许您通过调用单个API调用自动递增或递减数字属性。

8     安全:Amazon DynamoDB非常安全,采用经过验证的加密方法验证用户身份,以防未授权数据访问。此外,它还与AWS Identity and Access Management集成,为组织内的用户实现精细的访问控制。

9     集成监控:Amazon DynamoDB在AWS管理控制台中为您的表显示关键操作指标。该服务还与CloudWatch集成,以便您查看每个Amazon DynamoDB表的请求吞吐量和延迟,并轻松跟踪您的资源使用情况。

10  Amazon Elastic MapReduce集成:Amazon DynamoDB还与Amazon Elastic MapReduce(Amazon EMR)集成。Amazon EMR允许企业使用AWS服务中托管的即用即付计费Hadoop框架对大型数据集执行复杂分析。依赖Amazon DynamoDB的强大服务能力,客户可轻松使用Amazon EMR分析Amazon DynamoDB中存储的数据集,并在Amazon S3中存档结果,同时在Amazon DynamoDB中保存完整原始数据集。

AdRoll使用Amazon DynamoDB的案例

广告重定向旨在将网站访问者转变为客户。重定向是带动全球在线企业营收的主要因素之一,而AdRoll是该行业的领导者之一,为了有效地服务于广告,AdRoll需要能够灵活快速地增加容量,在极快的响应时间内实时中标,并通过自动化确保系统迅速响应竞价。

通过推出自己的实时竞价基础设施,AdRoll需要为四个大区中的每个用户都同步数据,这大约涉及数亿用户及每秒数万次写入。该公司不仅要应对实时写入海量数据这一艰巨任务,而且,竞价系统对于每个竞价请求有着100毫秒的严格上限,因此,AdRoll需要强力确保读取方面的性能。在评估了多种替代方案后,该公司决定使用Amazon DynamoDB来实现低延迟,确保吞吐量及快速扩展能力。

Amazon DynamoDB表由主键(分区键,或分区键和排序键)和属性组成,如表1所示。无模式设计意味着每个数据项目都可能具有数量不同的属性。多种数据类型(字符串、数字、二进制数据和集合)使数据模型更加丰富。AdRoll表设计为将Cookie用作分区键,将配置文件ID用作排序键,而将时间戳用作属性。AdRoll对所有表都使用了分区键和排序键。

         表1  Amazon DynamoDB表

分区键 排序键 属性
Cookie(用户ID) 配置文件 时间戳
“1234” “Segment1” “1378237387”
“1234” “Segment2” “1378237417”

通过将Amazon DynamoDB与Apache Storm配合使用,AdRoll只需不到50毫秒,即可在保持低成本的同时,复制其遍布世界各地的数据集,同时对竞价和对客户发布广告提供快速的响应时间。AWS服务提供的可扩展性同样使AdRoll获益匪浅。AWS服务使AdRoll能够处理来自Facebook、Google、Yahoo和其他高访问量网站的流量,借此,支持的每日展示次数超过了500亿。