亚马逊AWS官方博客

Category: 数据库

Amazon Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接 今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。 在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。 借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。 创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。 接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。 接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。 大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS […]

Read More

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊 应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。 在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。 下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。 Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service。 Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis Agent和 GitHub 相关项目。 Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose。 有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。 AWS CloudFormation template帮你快速完成如下工作: 准备Amazon […]

Read More

通过机器学习自动优化 DBMS

本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击:原文链接 数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”,控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素,因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动,但对许多组织来说专家的费用过于高昂。 卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune,它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS,即使是毫无数据库管理专业知识的人。 与其他 DBMS 配置工具不同,OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此,OtterTune 维护了一个存储库,用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型,以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验,进而推荐可改善最终目标 (例如,减少延迟或提高吞吐量) 的设置。 在本文中,我们将讨论 OtterTune ML 管道中的每一个组件,并演示这些组件如何彼此交互以优化 DBMS 配置。然后,我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能,评估 OtterTune 对 MySQL 和 Postgres […]

Read More

挖掘EB级别数据的价值 – Redshift Spectrum介绍及最佳实践

随着数据存储技术的快速发展,众多企业客户可以以低成本存储PB级别甚者EB级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源,又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力,但很多数据并不能被有效的分析甚至根本未作任何分析,形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。 作为一个托管的数据仓库服务,Amazon Redshift从它发布至今已经帮助全球成千上万的客户解决了PB级别数据的分析能力,实现了复杂SQL的快速查询。但随着数据的飞速增长,我们看到越来越多的客户数据开始逼近EB级别。对于这样体量的大数据,虽然Redshift也可以支持快速的复杂SQL查询,但毕竟我们需要启动更多的Redshift集群,消耗更多的CPU和存储成本,同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在S3上,通过EMR集群也可以实现快速低成本的数据清理,但针对复杂的(诸如Join类)的查询速度会很慢,不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。 为了真正摆脱数据分析的瓶颈、消灭暗数据,我们的客户需要既能高效执行复杂的查询,又能享受高度可扩展的数据并行处理,也能利用近乎无限的低成本的S3存储资源,还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务Redshift Spectrum的使命。 Redshift Spectrum 介绍 Redshift Spectrum可以帮助客户通过Redshift直接查询S3中的数据。如同Amazon EMR,通过Redshift Spectrum客户可以方便的使用多种开放数据格式并享有低廉的存储成本,同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum采用了无服务器架构,所以客户不需要额外配置或管理任何资源,而只需为Redshift Spectrum的用量付费。使用方面,Redshift Spectrum享有和Amazon Redshift一样的复杂查询的优化机制、本地数据的快速读取以及对标准SQL的支持。结合上述功能特点,Redshift Spectrum可以在几分钟内完成对EB级别的数据的复杂查询,这使它在众多大数据分析服务中脱颖而出。我们做了一个实验,在对一个EB的数据做涉及四个表的join,filter和group的查询时,1000个节点的Hive集群预估需要耗时5年,而Redshift Spectrum只用了173秒。 另外Redshift Spectrum 是Amazon Redshift的一个内置功能,所以使用Redshift Spectrum 对Redshift客户现有的查询服务和BI工具不会有任何影响。在Redshift Spectrum的底层,我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配,前端的客户无需做任何资源部署和配置。Redshift Spectrum也很好的支持了高并发 – 客户可以通过任何多个Amazon Redshift集群同时访问S3上的数据。 Redshift Spectrum 上一个查询任务的生命周期 一切从Redshift Spectrum的查询任务提交给Amazon Redshift集群的领导节点开始。首先,领导节点负责优化、编译、并推送查询任务给Amazon Redshift集群的计算节点。然后,计算节点从外部表获得数据目录,并基于查询任务里的join和filter动态移除不相关的数据分区。这些计算节点同时也会检测在Redshift本地是否已有部分查询数据,从而只从S3上扫描本地没有的数据以提升效率。 接下来,Amazon Redshift的计算节点会基于需要处理的数据对象生成多个查询需求,并行提交给Redshift Spectrum,Redshift Spectrum再据此启动上千个工作线程。 这些工作线程进一步从S3上扫描、筛选并聚合数据,将处理好的结果数据传回Amazon Redshift集群。最后,传回的结果数据在Redshift 集群本地作join和merge操作,然后将最终结果返回给客户。 Redshift Spectrum 的优势 Redshift Spectrum的架构设计有很多优势。第一,剥离计算与S3上的存储,使计算资源可以独立弹性扩展。第二,大幅提升了并发效率,因为客户可以用多个Redshift集群访问同一组S3上的数据。第三,Redshift Spectrum沿用了Amazon Redshift的查询优化机制,可以生成高效的查询规划,即便面对诸如多表join或者带统计函数(window function)的复杂查询也能胜任。第四,可以对多种格式的数据源直接查询 – Parquet, RCFile, […]

Read More

使用 Amazon Redshift 中的查询监控规则管理查询工作负载

本文主要介绍了如何利用Amazon Redshift的WLM(工作负载管理)功能,监控数据仓库的查询性能,从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景,给出了简单的配置过程。 众所周知,数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。 为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能,Amazon Redshift工作负载管理(WLM)使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM,短时间,快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此,某些查询有时可能会陷入不相称的资源分配,并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。 虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法,但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则,监视查询的资源使用情况,然后在查询违反规则时执行操作。 工作负载管理并发和查询监控规则 在Amazon Redshift环境中,单个集群最多可以同时连接500个连接。 吞吐量(Throughput)通常表示为每小时的查询量以最大化性能,但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中,工作负载管理(WLM)可以最大限度地提高吞吐量,而不太考虑并发性。 WLM有两个主要部分:队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。 例如,假设您有一个并发度为10的队列(100%内存分配)。这意味着每个查询最多可以获得10%的内存。 如果大部分查询需要20%的内存,那么这些查询将交换到磁盘,导致较低的吞吐量。 但是,如果将并发度降低到5,则每个查询分配20%的内存,并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候,常见的错误认知是认为更高的并发性将产生更好的性能。 现在你了解了并发性,这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则,如果查询违反了该规则,则会执行相应的操作。 可以使用十二种不同的资源使用指标,例如查询使用CPU,查询执行时间,扫描行数,返回行数,嵌套循环连接等。 每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。 这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列,从而提高吞吐量和响应速度。 例如,对于专用于短时运行查询的队列,您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询,您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。 使用场景 使用查询监控规则来执行查询级别的操作,从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中: 日志记录(log):记录信息并继续监视查询。 跳出(hog):终止查询,并重新启动下一个匹配队列。 如果没有其他匹配队列,查询将被取消。 中止(abort):中止违反规则的查询。 以下三个示例场景显示如何使用查询监视规则。 场景1:如何管理您临时查询队列中的未优化查询? 连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示: IF return_row_count > 1B rows then ABORT. 在以下截图中,任何返回BI_USER组中超过十亿行的查询都将中止。 场景2:如何管理和控制未调优的CPU密集型查询? 偶尔引起CPU飙升的查询不一定有问题。 然而,持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如,在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。 […]

Read More

使用Apache Kylin和Amazon EMR进行云上大数据OLAP分析

作者:史少锋 Kyligence资深架构师,Apache Kylin committer & PMC   公司简介 上海跬智信息技术有限公司 (Kyligence) 是由Apache Kylin (首个来自中国的 Apache 软件基金会顶级开源项目) 核心团队组建,专注于大数据分析领域创新的数据科技公司。Apache Kylin是近两年迅速崛起的开源分布式大数据分析引擎,它充分利用Hadoop MapReduce,HBase,Spark等成熟技术,对超大数据集进行预计算(构建Cube),从而当在线查询请求到来时,通过检索Cube以亚秒级低延迟返回结果,实现真正的大数据上的交互式分析。对于用户来说,Kylin屏蔽了底层平台的技术细节,用户只需要掌握多维模型、数据仓库、SQL等知识,就可以通过Kylin的Web界面进行建模,Kylin将自动生成任务对数据进行计算。计算完成后用户即可通过各类可视化工具连入Kylin进行分析,易用性非常高。今天,Apache Kylin已经在众多企业得到广泛应用,如今日头条等。 解决方案 Kyligence为各行各业的客户提供基于AWS公有云平台的Hadoop数据仓库解决方案。Elastic MapReduce (Amazon EMR) 是AWS推出的云上Hadoop方案,这一方案使得Hadoop的部署、监控、扩容变的非常灵活方便。Amazon EMR将计算和存储分离,可以使用S3做数据存储,用户可随需启停Hadoop而不用担心数据丢失,用户只需为运行时使用的资源付费,从而大大减少运维成本。以最近发布的Apache Kylin v2.0和Amazon EMR 5.5(海外版)为例,在AWS云上使用Kylin是非常简单快速的。 1. 启动EMR集群 如果您已经有在运行的,包含了HBase 1.x服务的EMR集群,那么这一步可以跳过,您可以使用现有集群进行此实验。 EMR的启动非常简单,登录AWS控制台,选择Amazon EMR服务,点击“Create Cluster”,选择最新的5.5版本,类型为HBase: 这里您可以选择合适的硬件配置;默认是m3.xlarge 3个节点,其中1个节点为master,另外两个为core节点。选择合适的EC2 key pair,随后点击“Create cluster”,AWS便会开始自动安装和配置Hadoop/HBase集群。 大约20分钟后,集群状态显示为“Waiting Cluster ready”,这意味着集群准备就绪可以使用了。   2. 安装Apache Kylin 2.0 Apache Kylin以Hadoop client的方式运行,使用标准协议/API与集群交互。您可以将它安装在集群的任意节点上,通常建议安装在一个单独的client节点上。在这里我们为了简单,就把Kylin安装在master节点上。 在AWS控制台上,您可以获取SSH到Amazon EMR的方法;点击“Master public DNS”旁边的SSH链接,即可获得,如下图所示: SSH登录到master节点后,创建一个Kylin安装目录,下载并解压Apache Kylin […]

Read More

新增 – 适用于 Amazon Simple Queue Service (SQS) 的服务器端加密

作为 AWS 服务家族最老牌的成员, Amazon Simple Queue Service (SQS) 是许多应用程序的重要组成部分。Amazon SQS,实现更好的架构和利用 Amazon SQS 和 Amazon DynamoDB 进行大规模消息处理等演示文稿说明了如何使用 SQS 构建恢复能力强且高度可扩展的应用程序。如今,我们为 SQS 增加了服务器端加密支持,使它变得更加有用。现在,您可以选择使用  AWS Key Management Service (KMS) 提供的加密密钥,将 SQS 加密消息存储于标准队列和 FIFO 队列中。您可以在创建队列时选择此选项,还可以为现有队列设置此选项。SSE 会加密消息正文,但不会影响队列元数据、消息元数据或队列指标。在现有队列中添加加密不会加密任何积压消息。同样,删除加密时也会将积压消息保持加密。 创建加密队列 最新版本的 AWS管理控制台 允许您使用方便的图形选择标准队列或 FIFO 队列: 您可以针对队列和可选的死信队列设置属性: 现在,您可以选中使用 SSE 并选择所需的密钥: 您可以使用由 AWS 托管的客户主密钥 (CMK),每个客户在每个区域只拥有唯一的客户主密钥;您还可以创建并管理您自己的密钥。如果您选择使用自己的密钥,不要忘了更新您的 KMS 密钥策略,允许对消息进行加密和解密。您还可以配置数据重用周期。此间隔控制 SQS 刷新来自 KMS 的加密信息的频率,范围在 1 分钟到 24 小时之间。使用较短的间隔可以改善安全性,但会提高 […]

Read More

使用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 […]

Read More

数据库迁移服务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 […]

Read More

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 […]

Read More