实践出真知，看我们怎样化解DynamoDB的挑衅

DynamoDB 是 Amazon 基于《 Dynamo: Amazon’s Highly Available Key-value Store 》实现的 NoSQL 数据库处事。它可以满意数据库无缝的扩展，可以担保数据的耐久性以及高可用性。开拓职员不必操心存眷 DynamoDB 的维护、扩展、机能等一系列题目，它由 Amazon 完全托管，开拓职员可以将更多的精神放到架构和营业层面上。

本文首要先容作者地址团队在详细营业中所碰着的挑衅，基于这些挑衅为何最终选型行使 Amazon DynamoDB，在实践中碰着了哪些题目以及又是怎样办理的。文中不会具体接头 Amazon DynamoDB 的技能细节，也不会涵盖 Amazon DynamoDB 的所有特征。

配景与挑衅

TalkingData 移动告白结果监测产物(TalkingData Ad Tracking)作为告白主与媒体之间的一个告白投放监测平台，天天必要吸取大量的推广样本信息和现实结果信息，并最终将现实的结果归因到推广样本上。

举个例子，我们通过手机某消息类 APP 赏识信息，会在信息流中看到穿插的告白，告白也许是笔墨情势、图片情势、视频情势的，而不管是哪种情势的告白它们都是可以和用户交互的。

假如告白推送较量精准，恰恰是用户感乐趣的内容，用户也许会去点击这个告白来相识更多的信息。一旦点击了告白，监测平台会收到这一次用户触发的点击变乱，我们将这个点击变乱携带的全部信息称为样本信息，个中也许包括点击的告白来历、点击告白的时刻等等。凡是，点击了告白后会引导用户举办相干操纵，好比下载告白保举的 APP，当用户下载并打开 APP 后，移动告白监测平台会收到这个 APP 发来的结果信息。到此为止，对付告白投放来说就算做一次乐成转化。

DynamoDB实践：当数据量庞大而不行预知，怎样担保高可用与及时性?

移动告白监测平台必要吸取绵绵不断的样本信息和结果信息，并重复、不断的及时处理赏罚一次又一次转化。对付监测平台来讲，它的责任重大，不能多记录，也不能少记录，假如转化数据记多了告白主必要多付告白费给媒体，记少了媒领会有吃亏。这样就为平台带来了几大挑衅：

• 数据量大：有的媒体为了好处最大化也许会采纳非正常本领制造假的样本，发生“卖弄流量”，以是告白监测平台除了会收到真适用户样本外，也会收到大量造假的样本，影响正常的监测和归因。在最“猖獗”的时辰，我们的平台会在一天内收到 40 亿 + 的点击样才干件哀求。要知道，这些点击样才干件是要保存下来作为后续结果归因用的，并且样本有用期大不沟通，从最短 12 小时到最长 90 天不等。
• 数据量不行预知：对付告白主的大推、应用市肆竞价排名等一系列的推广，会导致突发大量样本数据流入。面临这些流量不行预知的环境，我们仍要担保体系的正确、不变、及时。
• 及时处理赏罚：告白主依靠告白监测平台及时处理赏罚的功效来调解告白推广计策。因此告白监测平台必要支持数据及时处理赏罚，才气为告白主更快的优化推广计策提供有力支撑。与此同时，告白监测平台的处理赏罚功效也要及时回传给媒体方以及告白主。可以看到，精确性和及时性是体系必必要满意的根基前提。
• 样本存储：我们的营业最焦点的成果就是归因，我们要明晰譬喻用户下载打开 APP 的这个转化结果是由哪一个推广勾当样本带来的——也就是上图中的第 7 步，当用户安装 APP 后，监测平台要对应找到第 1 步中样内地址推广勾当，这个是一个查询匹配的进程。对付复杂的归因样本数据，有用期又各不沟通，我们应该奈何存储样本才气让体系快速归因，不影响及时功效，这也是一个很大的挑衅。

最初形态

在 2017 年 6 月前我们的营业处理赏罚处事陈设在机房，行使 Redis Version 2.8 存储全部样本数据。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 去做。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!