[音乐播放] RICK霍利汉：好吧。 嗨，大家好。 我的名字是里克霍利汉。 我是一名高级主管 解决方案架构师，AWS。 我注重的NoSQL和 DynamoDB技术。 今天我在这里谈 你对那些一点点。 我的背景是 主要是在数据层。 我花了一半的发展 职业生涯编写数据库， 数据访问，溶液 用于各种应用。 我一直在云计算的虚拟化 了约20年。 所以在云计算是云计算， 我们习惯称之为效用计算。 并且想法，它像 PG＆E公司，你付出你用什么。 今天，我们把它叫做云计算。 但这些年来，我一直在 一对夫妇的公司 你可能从来没有听说过。 但我已经编制技术列表 成就，我猜你会说。 我有8项专利中的云系统 虚拟化，微处理器设计， 复杂事件处理， 和其他领域。 因此，这些天，我主要关注的NoSQL 技术和下一代 数据库。 而这一般是什么我要去 今天在这里和你谈论。 所以，你可以期待什么 从本次会议， 我们将通过一个简短的 数据处理的历史。 它总是有帮助的 了解我们来自哪里 为什么我们是我们在哪里。 我们将谈一点 关于NoSQL的技术位 从基本面的角度来看。 我们将进入一些 在DynamoDB内部。 DynamoDB是AWS的没有味道。 这是一个全面的管理和 托管的NoSQL解决方案。 我们将谈论表一点点 结构，应用程序接口，数据类型，索引 和一些的内部的 那DynamoDB技术。 我们将进入一些设计 模式和最佳实践。 我们将谈论如何 使用这种技术对一些 当今的应用程序。 然后我们将讨论一点点 关于进化或出现 在规划一个新范例 所谓的事件驱动应用程序 和DynamoDB在如何发挥为好。 我们将离开你的一点点 一个参考架构的讨论 所以我们可以谈一些 该方法可以使用​​DynamoDB。 所以，首先off--这是个问题 我听到了很多的，什么是数据库。 很多人认为他们 知道数据库是什么。 如果谷歌，你会看到这一点。 这是一个数据的持有结构化集合 在计算机中，特别是那种 是以各种方式进行访问。 我想这是一个很好的 定义一个现代化的数据库。 但我不喜欢它，因为 这意味着两件事情。 这意味着结构。 而这意味着，它是在计算机上。 和数据库没有 总的计算机上存在。 数据库确实存在在许多方面。 一个如此美好的定义 数据库是这样的。 数据库是一个有组织的 机制，用于存储，管理， 和检索信息。 这是从About.com。 所以，我喜欢这个，因为它确实会谈 有关数据库是一个存储库， 一库 信息，不一定 一些坐在一台电脑上。 纵观历史，我们 并不总是有电脑。 现在，如果我问的平均 开发商现在有什么 一个数据库，这是我得到的答案。 某处我可以坚持的东西。 对？ 而且这是真的。 但很不幸。 因为数据库是真的 现代的应用程序的基础。 这是基础 每一个应用程序。 以及如何构建 数据库，如何构建 该数据是要规定如何那 当你扩展的应用程序执行。 所以很多今天我的工作 正在处理什么 发生在开发商 采取这种方法 和善后处理 的应用程序的那个 现在扩展超出了原有的 意图和患糟糕的设计。 所以希望当你 今天走开，你会 有一对夫妇的工具 你的腰带，留住你 作出这些同样的错误。 好吧。 所以，让我们来谈谈一点点 数据库技术的时间轴。 我想，我读了 文章不是很久以前 了，说什么的lines-- 这是一个非常诗意的语句。 它说历史 数据的处理是 满高的水印 数据丰富。 好。 现在，我想这是种真实的。 但事实上，我考虑的是作为 历史上竟涌起 数据压力的高水位。 由于数据速率 食入不降。 它仅上升。 创新发生在 我们看到的数据压力，这 是数据的是量 现在在进入系统。 并且它不能被处理 有效地无论是在时间或成本。 而当我们开始的 看数据的压力。 所以，当我们在看 第一个数据库，这 是的，这就是一个我们的耳朵之间。 我们都出生吧。 这是一个不错的数据库。 它具有高可用性。 它总是上。 你总是可以得到它。 但它的单个用户。 我不能和你分享我的想法。 你不能让我的思绪 当你想要他们。 而他们的abilitiy也不是那么好。 我们忘事。 时不时地，我们的一员叶 并移动到另一个存在 我们失去了一切 这是在该数据库中。 所以，这不是所有的好。 而这种行之有效随着时间的推移 当我们回到了一天 当我们真正需要知道的是， 我们去哪儿去明天 或者我们收集的最佳食品。 但是，当我们开始成长为一个 文明与政府开始 就应运而生，并 企业开始演变， 我们开始意识到我们 需要比多一点什么 我们可以把我们的头。 好吧？ 我们需要记录系统。 我们需要的地方能够存储数据。 因此，我们开始起草文件， 建立图书馆和档案馆。 我们开始开发 系统中的总账会计。 而总账计数该系统 跑了世界上许多世纪以来， 甚至可能数千年的 我们种增长到如此地步 其中，该数据负载超过 这些系统的能力 要能包含它。 而这实际上是发生在19世纪80年代。 对？ 在1880年美国人口普查。 这是真的，其中的转折 指向现代数据处理。 这是在点 数据的所述量 当时正在收集由 美国政府到了点 它历时八年来处理。 现在，八years--作为 你知道，普查 每隔10 years--所以它的 很明显，按时间，我们 拿到了1890年的人口普查， 的数据量即 将要被处理的 政府是 要超过10年，它 将采取推出新的人口普查。 这是一个问题。 所以，一个人叫赫尔曼 霍尔瑞斯来了 他发明了单位记录打卡 卡，打孔卡读卡器，打卡 制表，并整理 该机制这一技术。 而且，他形成于该公司 时间，连同其他几个， 居然成了一个支柱之一 小公司，我们今天所知道所谓的IBM。 因此，IBM最初是在 该数据库业务。 而这也确实是他们做到了。 他们做数据处理。 既然这么冲的扩散 卡，一个巧妙的机制 对能够利用该 技术查询排序结果集。 您可以在这张图片看到 在那里，我们有一个little-- 这是一个有点small--但你可以看到 一个非常巧妙的机械装置 我们有一个打卡甲板。 而别人的回吐 一个小螺丝刀 并通过粘 插槽和提升起来 拿到那场比赛，那 排序的结果集。 这是一个聚集。 我们做这一切的时候 今天在计算机中， 在这里你在数据库中做到这一点。 我们用手工做的，对不对？ 人们把这些东西放在一起。 而正是这泛滥 这些穿孔卡片 到此谓数据鼓 和数据卷轴，纸带。 数据处理产业占 从玩家钢琴一节课。 玩家钢琴回 世纪之交 以前用纸卷用槽 就告诉它播放的按键。 因此，该技术被改编 最终存储数字数据， 因为他们可以把这些数据 到那些纸胶带卷轴。 现在，作为其结果，数据 被actually--如何 您访问这些数据是直接 取决于你如何保存它。 所以，如果我把数据在磁带上， 我有线性访问数据。 我不得不推出全 磁带访问所有的数据。 如果我把数据冲 卡，我可以访问它 中多了几分随意 时尚，也许还不如快。 但也有如何的限制，我们 访问基于如何被存储的数据。 所以这是一个问题 进入上世纪50年代。 同样，我们可以开始看到，作为我们 开发新技术来处理 数据吧，它打开了 门新的解决方案， 对于新方案，新 应用这些数据。 真的，治理 可能是原因 为什么我们开发了一些系统。 但企业迅速成为 进化背后的驱动程序 现代数据库和 现代文件系统。 所以，接下来的事情， 想出了在上世纪50年代 是文件系统和 发展的随机存取存储器。 这是美丽的。 现在，所有的突发性，我们可以把我们的 文件的任何地方对这些硬盘 我们可以随意访问这些数据。 我们可以分析 信息出来的文件。 我们解决了世界上所有的 问题的数据处理。 而这持续了大约20或 30年，直到演变 关系数据库，其中的 是当世决定，我们现在 需要有失败的存储库 数据在文件中的蔓延 我们已经建立的系统。对？ 分布在太多太多的数据 的地方，重复删除的数据， 和储存的成本是巨大的。 在上世纪70年代，最昂贵的资源 该计算机具有被存储。 该处理器是 看作是一个固定的成本。 当我买了盒， 该CPU做一些工作。 这将是纺是否 它的实际工作或没有。 这的确是一个沉没成本。 但是，花了我作为一个 企业是存储。 如果我要购买更多的磁盘旁边 一个月，这是我付出真正的代价。 和该存储是昂贵的。 现在我们快进40年 我们有一个不同的问题。 该计算是现在 最昂贵的资源。 存储很便宜。 我的意思是，我们可以去任何地方的 云，我们可以找到便宜的存储。 但我不能找到便宜的计算。 所以今天的演变 数据库技术的技术， 真是重点围绕 分布式数据库 不患 同类型规模 关系数据库的局限性。 我们将谈论一点点 什么实际意义。 但其原因之一，并 this--我们后面的司机 谈到数据的压力。 数据压力是什么 驱动创新。 而如果你过 过去五年中， 这是一个图表的什么数据 在整个企业一般负载 看起来在过去的五年。 而一般的经验法则 这些days--如果你去Google-- 是90％以上的数据的 我们今天存储，这是 在过去两年内产生。 好。 现在，这是不是一个趋势，这是新的。 这是一个已经有趋势 走出去100年。 自从赫尔曼·霍尔瑞斯 开发了打卡， 我们已经建立数据仓库 并收集数据以惊人的速度。 因此，在过去的100年里， 我们已经看到了这一趋势。 这是不会改变的。 展望未来，我们将看到 此，如果不是加速的趋势。 你可以看到是什么样子。 如果在2010年的业务有一个 在管理数据的TB级， 今天，这意味着他们 管理数据的6.5千兆字节。 这就是6​​500倍的数据。 我知道这一点。 我每天都在与这些企业的合作。 五年前，我 会跟公司 谁也和我谈什么是痛苦 它是管理TB的数据。 他们会聊 给我介绍我们如何看待 这很可能会 是一个PB的两 在几年。 这些公司 今天我带会议， 而且他们跟我谈了 问题是有其管理 几十，20 PB的数据。 这样的爆炸 在行业数据 正推动着巨大 需要更好的解决方案。 和关系数据库是 只是不辜负需求。 所以有一个线性 数据压力之间的相关性 和技术创新。 历史告诉我们 此，随着时间的推移， 每当数据量 需要被处理 超过系统的容量 处理它在合理的时间 或以合理的成本， 那么新技术 被发明，以解决这些问题。 这些新技术， 反过来，开门 到另一组的问题，这 正在收集更多的数据。 现在，我们不是要阻止这一切。 对？ 我们不是要阻止这一切。 为什么？ 因为你不可能什么都知道 有知道的宇宙。 而只要我们还活着， 在整个人类历史上， 我们一直推动知道更多。 因此，它似乎是我们把每一寸 向下科学发现之路， 我们相乘的数据量 我们需要成倍处理 因为我们发现越来越多的多 生活的内部运作， 关于宇宙是如何工作的，约 推动科学发现， 并且本发明那 我们正在做的今天。 的数据量只是 不断增加。 所以能够应对 这个问题是巨大的。 所以的事情之一 我们来看看作为NoSQL的原因？ 怎样的NoSQL解决这个问题？ 好了，关系型数据库， 结构化查询语言， SQL--这是真正的一个结构 关系型数据库 - 这些东西都是 对存储进行优化。 早在上世纪70年代，同样， 磁盘是昂贵的。 存储的提供锻炼 在企业中是永无止境的。 我知道。 我住吧。 我写的存储驱动程序的 enterprised超级服务器公司 早在20世纪90年代。 而底线是费尽另一 存储阵列只是一些 每天都在发生企业。 它从来没有停止过。 高密度的存储需求 对于高密度存储， 和更有效的存储 devices--它从来没有停止过。 和NoSQL是一项伟大的技术 因为它标准化的数据。 它进行重复数据删除的数据。 它把数据的结构 是不可知的每一个访问模式。 多个应用程序可以打的 SQL数据库，运行即席查询， 并获得形状数据，他们 需要处理的工作负载。 这听起来太棒了。 但底线是与任何 系统，如果它是不可知的一切， 它是优化了什么。 好不好？ 这就是我们用得到 的关系数据库。 这对存储进行优化。 这是标准化的。 它的关系。 它支持即席查询。 而且它和它垂直缩放。 如果我需要一个更大的SQL数据库 或更强大的SQL数据库， 我去买一个更大的一块铁。 好不好？ 我曾与很多客户合作 对已通过重大升级 在他们的SQL基础设施只 找到了6个月后， 他们再次碰壁。 而从Oracle或MSSQL答案 或其他人是获得更大的箱子。 那么早晚，你可以不买 大框，这是真正的问题。 我们需要真正改变的东西。 那么，这会起作用？ 它可以很好地用于离线 分析，OLAP类型的工作负载。 这是真正的地方SQL所属。 现在，它今天使用的许多网上 事务处理型 应用程序。 和它的作品只是罚款 利用某种程度的， 但它不能按比例 是的NoSQL的方式做。 我们将谈一点 为什么这是位。 现在，NoSQL的，另一方面， 为计算更加优化。 好不好？ 它不是不可知 访问模式。 就是我们所说的反规范化 结构或分层结构。 在关系数据库中的数据是 从多个表连接在一起 产生你所需要的视图。 在一个的NoSQL数据库中的数据 存储在文档 包含的层次结构。 的所有数据的那些通常是 连接在一起来产生视图 存储在一个单一的文件。 我们将谈论一点点 如何在一对夫妇图表的作品。 但这里的想法是，你存储 你的数据，因为这些实例化的看法。 好不好？ 你进行水平扩展。 对？ 如果我需要增加 我的NoSQL簇的大小， 我并不需要获得一个更大的框。 我得到另一个盒子。 而我那些聚集在一起， 我可以分片数据。 我们要谈点 分片是什么，是 能够扩展该数据库 在多个物理设备 并取出屏障 要求我垂直扩展。 因此，它的真正建立在线 事务处理和规模。 有一个很大的区别 在这里报告的，对不对？ 报告，我不知道 我要去问题要问。 对？ Reporting--如果有人从 我的营销部门 要just--有多少我的客户 有这种特殊的特性谁 买了这个day--我不知道 什么查询他们会问。 所以，我需要无关。 现在，在网上 事务性应用， 我知道是什么问题，我在问。 我构建的应用程序进行 一个非常具体的工作流程。 好不好？ 所以，如果我优化数据 存储以支持该工作流， 这将更快。 这就是为什么NoSQL的可 真正加速交付 这些类型的服务。 好吧。 所以，我们要进入 理论一点点在这里。 而有些人，你的眼睛 可能回退一点点。 但我会尽量保持 为高电平，我可以。 所以，如果你是在项目 管理，有 一个结构称为 三角形的约束。 好。 的约束决定了三角 你不能拥有一切所有的时间。 不能有你的蛋糕和熊掌兼得。 因此，在项目管理，即三角形 约束条件是，你可以拥有它便宜， 你可以把它速度快， 或者你可以拥有不错的。 选择两种。 因为你不能有三个。 对？ 好。 所以你听到这个有很多。 这是一个三重约束， 三重约束的三角形， 或者铁三角是oftentimes-- 当你跟项目经理， 他们会谈论这个。 现在，数据库有 自己的铁三角。 和数据的铁三角 就是我们所说的CAP定理。 好不好？ CAP定理使然 如何数据库操作 下一个非常特定的条件。 我们将谈论 这是什么状况。 但是这三个点的三角形， 可以这么说，是C，一致性。 好不好？ 因此，在CAP，一致性意味着所有 谁可以访问数据库客户端 总会有一个非常 数据一致的看法。 没有人会看到两种不同的东西。 好不好？ 如果我看到的数据库， 我看到了同样的观点 作为我的伙伴谁看到 相同的数据库。 这是一致性。 状况意味着如果 数据库联机，如果能够达到， 所有客户端永远 能够读取和写入。 好不好？ 所以，每一个客户端 可以读取数据库 随时都可以读 数据和写数据。 如果是这样的话， 它是一个可用的系统。 而第三点是什么 我们称之为分区容忍性。 好不好？ 分区容忍性手段 该系统运行良好 尽管物理网络 节点之间的分区。 好不好？ 因此，集群中的节点无法 互相交谈，会发生什么？ 好吧。 因此，关系数据库choose-- 你可以选择其中的两个。 好。 因此，关系数据库选择 要一致，可用。 如果从分区情况 所述的DataNodes在数据存储， 数据库崩溃。 对？ 它只是下降。 好。 这就是为什么他们有 成长与大箱子。 对？ 因为有no--通常，群集 数据库，有没有很多人 该操作的方式。 但是，大多数数据库规模 垂直在一个盒子。 因为他们需要 一致的和可用的。 如果分区是被注入， 那么你就必须做出选择。 你必须做出的选择 是一致的和可用的。 这就是NoSQL数据库做。 好吧。 因此，一个NoSQL数据库，它 有两种形式。 我们have--好，它 有许多种， 但它有两个基本 characteristics--什么 我们所说的CP数据库，或 一致和分区容忍性 系统。 这些人做出选择，当 节点失去彼此接触， 我们不会允许 人写了。 好不好？ 在此之前，分区被删除， 写访问被阻止。 这意味着它们无法使用。 他们是一致的。 当我们看到， 分区自身注入， 我们现在一致， 因为我们不打算 以允许在两个数据改变 分区独立地侧 的对方。 我们必须 重建通信 任何更新之前， 该数据是允许的。 好不好？ 接下来味将是一个AP系统， 或可用，分区 容忍系统。 这些家伙不关心。 对？ 这得到了所有节点 写，我们要了。 所以我复制我的数据 跨多个节点。 这些节点获得一个客户端，客户端进入 在说，我会写一些数据。 节点说，没问题。 节点旁边的他得到 在相同的记录写入， 他会说没问题。 后面的某个地方在后端， 这些数据是怎么回事进行复制。 然后谁家去实现， 呃，哦，他们的系统将实现，嗯，哦， 还有的是一个更新两个方面。 我们做什么？ 而他们做的又是什么 他们做的一些东西， 使他们能够解决数据状态。 我们将谈论 即下图研究。 事情在这里指出。 而且我不会太 多到这一点，因为这 进入深层数据的理论。 但是，有一个交易 框架 运行在一个关系系统， 可以让我放心地进行更新 到数据库中的多个实体。 而会发生这些更新 一次全部或根本没有。 这就是所谓的ACID事务。 好不好？ ACID给了我们原子性，一致性， 隔离性和持久性。 好不好？ 这意味着原子，交易，所有的 我的更新要么发生，或者他们不这样做。 一致性是指 该数据库将始终 被带入一个一致 更新后的状态。 我永远不会离开的数据库 应用更新后的状态不好。 好不好？ 所以这是一个有点不同 比CAP的一致性。 CAP一致性意味着所有的 客户端可以随时查看数据。 酸一致性意味着当 交易的完成，数据的好。 我的关系都不错。 我不打算删除父行 并留下了一堆孤儿的 在一些其他表。 如果我是一致的，不能发生 在酸事务。 隔离是指交易 总会发生一个接一个。 数据的最终结果 将是相同的状态 仿佛这些交易 这是同时发布 被串行执行。 所以这是并发 控制在数据库中。 所以基本上，我不能递增 相同的值两次，两次手术。 但如果我说加1，这个值， 而两笔交易进来 并尝试做到这一点，一个人的 去到那里的第一 而另一个的 会后到那里。 所以，最后，我添加了两个。 你明白我的意思吗？ 好。 耐用性是非常简单的。 当交易 是公认的，这是 去那里连 如果系统崩溃。 当该系统恢复，这 交易的承诺 实际上是要在那里。 所以这是保证 的ACID事务。 这些都是相当不错的保证 有上的数据库， 但他们付出了代价。 对？ 因为这个问题 与此框架 如果在该数据的分区 集，我必须做出决定。 我将不得不让 在一侧或其他更新。 如果出现这种情况， 然后，我不再去 要能保持 这些特点。 他们将不相符。 它们不会被分离。 这是它打破了 对于关系数据库。 这是什么原因关系 数据库垂直缩放。 另一方面，我们有 什么叫做基础技术。 而这些都是你的NoSQL数据库。 好吧。 因此，我们有我们的CP，AP数据库。 而这些都是你所谓的基本 可用软状态，最终 是一致的。 好不好？ 基本上用的，因为 他们是分区宽容。 他们将永远是 还有，即使有 节点之间的网络分区。 如果我可以跟一个节点，我 将能够读取数据。 好不好？ 我可能并不总是能够写 数据，如果我是一个统一的平台。 不过，我就可以读取数据。 软状态指示 当我读到的数据， 它可能不是相同的其他节点。 如果权利是一个节点上发出 别的地方的集群中 现在也没有跨越复制 集群然而，当我读到的数据， 这种状态可能会不一致。 然而，这将是 最终一致性， 这意味着当一个写 建立到系统中， 将各个节点进行复制。 而最终，该状态 将纳入秩序， 并且这将是一致的状态。 现在，CAP定理真 只播放的一个条件。 这条件是当这种情况发生。 因为每当它在工作 正常模式下，没有分区， 一切的一致和可用。 你只担​​心CAP 当我们有这个分区。 因此，这些都是罕见的。 但是，系统如何反应时，这些 发生听写系统的是什么类型的 我们正在处理。 因此，让我们来看看什么 这看起来像AP系统。 好不好？ AP系统有两种形式。 他们进来的味道，是一个 法师，100％，始终可用。 他们进来 其他的味道，它说， 你知道吗，我会担心 这个分区的事情 当实际的分区发生。 否则，将是主要的 节点谁去承担的权利。 好不好？ 因此，如果我们像卡桑德拉。 卡桑德拉将是一个主 主人，让我写给任何节点。 所以会发生什么？ 所以，我在一个对象 数据库上存在两个节点。 让我们把这个对象S. 因此，我们有状态S. 我们有一些操作 S上是持续的。 卡桑德拉让我 写入多个节点。 所以我们可以说我得到一个 写为s到两个节点。 那么，最终发生的是 我们称之为分区事件。 可能没有一个 物理网络分区。 但由于设计的 该系统的，它的 实际上，一旦分割 因为我得到两个节点的写入。 这不是逼着我 通过一个节点写全。 我正在写在两个节点上。 好不好？ 所以，现在我有两个状态。 好不好？ 这是怎么回事发生 是迟早的事情， 还有的将是一个复制的事件。 还有的将是我们 称为分区恢复，这 正是这两个 国一起回来 还有的将是一个算法 在运行数据库内， 决定该怎么做。 好不好？ 默认情况下，最后更新 胜在大多数AP系统。 所以，通常有一种 默认的算法，是什么 他们所谓的回调 功能，这东西 将被调用时，这种情况 检测来执行一些逻辑 解决这一矛盾。 好不好？ 默认的回调和默认 解析器在大多数AP数据库 是，你猜怎么着，时间戳获胜。 这是最后更新。 我打算把该更新在那里。 我可以转储这个纪录，我 倾倒出来，放入恢复日志 这样，用户可以稍后再回来 并说，哎，有一个碰撞。 发生了什么？ 而实际上你可以转储纪录 所有的冲突和回滚 看看会发生什么。 现在，作为一个用户，你也可以 包括逻辑到该回调。 所以，你可以更改 回调操作。 你可以说，嘿，我想 要补救此数据。 我想尝试 合并这两个记录。 但是，这取决于你。 该数据库不知道如何 这样做，默认情况下。大部分时间， 唯一的数据库 知道如何做的是说， 这一次是最后一个记录。 这是一个的要赢， 这就是价值，我打算把。 一旦分区恢复 和复制时， 我们有我们的状态， 现在的黄金，这是 所有这些对象的合并状态。 所以AP系统都没有了。 CP系统不需要 担心这一点。 因为一旦一个分区来 发挥作用，他们只是停止服用 写道。 好不好？ 所以这是很容易 处理是一致的 当你不接受任何更新。 这是与CP系统一样。 好吧。 因此，让我们谈一点 关于访问模式位。 当我们谈论的NoSQL，这是 所有关于访问模式。 现在，SQL是临时性的，查询。 这是关系存储。 我们不必担心 关于访问模式。 我写了一个非常复杂的查询。 它去和获取数据。 这就是这个样子 像，规范化。 因此，在这个特定的结构中， 我们正在寻找一个产品目录。 我有不同类型的产品。 我有书。 我的专辑。 我有录像。 产品之间的关系 和这些书，相册中任一项 和视频表是1：1。 好吧？ 我有一个产品ID， 该ID对应 到一本书，一张专辑，或视频。 好不好？ 这是一个1：1的关系 跨越这些表。 现在，books--他们所 已经是根的属性。 没问题。 那很棒。 一比一的关系，我得到的所有 数据我需要来形容这本书。 Albums--专辑有轨道。 这就是我们所说的一对多。 每一张专辑可以有许多曲目。 因此，对于每个轨道上 这张专辑，我可以有 在此子表再创历史新高。 所以，我创建了一个记录 在我的相册表。 我创建了多个记录 在磁迹的表。 一个一对多的关系。 这种关系是什么 我们称之为多到很多。 好不好？ 你看，演员可能是 在许多电影，许多影片。 所以我们要做的就是，我们把这个映射 这间表，它只是 映射演员ID到视频ID。 现在，我可以创建一个查询联接 通过演员的视频演员的影片， 它给了我一个很好的列表 所有的电影和所有演员 谁在那部电影。 好。 所以在这里我们去。 一对一的是顶层 关系; 1对多， 专辑曲目;多对许多。 这些是三个顶级 在任何数据库之间的关系。 如果你知道如何将这些 关系共同努力， 那么你知道了很多 有关数据库了。 所以NoSQL的工作原理有点不同。 让我们想想一秒钟是什么 看起来像去让我所有的产品。 在关系店里，我 想要得到我的所有产品 对所有我的产品清单。 这是一个很大的查询。 我得到了我所有的书的查询。 我从我的专辑的查询。 而我得到了我所有的影片的查询。 我得把它 一起以列表 全心全意它备份到 应用程序正在请求它。 为了得到我的书，我加盟 产品和书籍。 为了让我的专辑，我得到了加盟 产品，专辑，和跟踪。 而让我的影片，我有 加入产品以视频， 参加过演员影片， 并带来了演员。 所以，这三个查询。 非常复杂的查询到 组装一个结果集。 这是不理想。 这就是为什么当我们谈论 有关的数据结构那 建要不可知的访问 pattern--好这是伟大的。 而且你可以看到这是真的 漂亮的我们如何组织数据。 你知道吗？ 我只有一个记录一个演员。 这很酷。 我重复数据删除所有的演员， 我保持我的协会 在这个映射表。 然而，获取数据 出变得昂贵。 我送了CPU遍布系统 加入这些数据结构一起 能够拉该回数据。 那么，如何解决呢？ 在NoSQL的它是关于 聚集，不归。 因此，我们希望说，我们要 支持访问模式。 当访问模式 该应用程序， 我需要让我的所有产品。 让我们把所有的产品在一个表中。 如果我把所有的产品在一个表中， 我可以选择所有产品 从该表中，我得到这一切。 那么怎么办呢？ 那么在NoSQL的有没有 结构的表。 我们将谈论一点点 这是如何工作的迪纳摩DB。 但你不必相同 属性和相同属性 在每一个单排，在每一个 项目，就像你在一个SQL表做。 而这是什么可以让我 做了很多的事情 并给我一个很大的灵活性。 在这种特殊情况下，我 有我的产品文档。 并在这个特定 例如，一切 在产品表的文档。 而该产品的一本书可能 有一个类型ID，指定一本书。 和应用程序 将交换机上的ID。 在应用层，我要去 要说哦，什么记录类型是什么？ 哦，这是一本记录。 书中记载有这些属性。 让我创建一​​本书的对象。 所以，我要补 本书的对象与此项目。 下一个项目来了， 说，这是什么项目？ 嗯，这项目是一个专辑。 呵呵，我得到了一个完全不同的 对于处理程序， 因为它是一个专辑。 你明白我的意思吗？ 因此，应用程序tier--我 只需选择所有这些记录。 他们都开始进入。 他们可以是各种不同类型。 而且它的应用程序的逻辑 跨越这些类型的交换机 并决定如何处理它们。 再次，所以我们优化 架构的访问模式。 我们正在做它用 折叠这些表。 我们基本上采取 这些标准化结构， 我们正在建设 分层结构。 里面的这些记录每一个 我要去看看数组属性。 本文档的专辑里面， 我看到轨道的数组。 这些曲目现在become--它 基本上这孩子表 存在这里在这种结构。 所以，你可以在DynamoDB做到这一点。 你可以在MongoDB中做到这一点。 您可以在任何NoSQL数据库做到这一点。 创建这些类型的 分层数据结构 允许您检索数据 很快，因为现在的我 不必符合。 当我插入一行到曲目 表或一行到相册表， 我必须符合该模式。 我必须有属性或 这是该表定义的属性。 他们每个人， 当我插入该行。 这不是在NoSQL的情况。 我可以有完全不同的 每一个文件的属性 我插入到集合。 因此，非常强大的机制。 这真是你如何 优化系统。 因为现在该查询，而不是 在加入所有这些表 并执行半打​​查询 给拉了回来，我需要的数据， 我执行一个查询。 而我遍历 横跨设置的结果。 它给你的想法 对NoSQL的权力。 我要去那种横着走这里 并且说一下这个问题。 这是比较厚道的 营销或技术 - 技术的营销 类型的讨论。 但是，要了解是很重要 因为如果我们看一下顶 这里这个图， 我们看什么 就是我们所说的 技术炒作曲线。 而这是什么意思是 新的东西来发挥作用。 人们认为这是伟大的。 我已经解决了我所有的问题。 这可能是端 一切，将所有的一切。 他们开始使用它。 他们说，这东西不能正常工作。 这是不对的。 旧的东西是更好的。 他们回去做 事情他们的方式。 并最终 他们走了，你知道吗？ 这东西并没有那么糟糕。 噢，那是它是如何工作。 一旦他们弄清楚它是如何 作品中，他们开始越来越好。 而关于它的有趣的事情 是，它种行到什么 我们所说的技术采用曲线。 所以会发生什么是我们必须 某种技术的触发。 在数据库的情况下， 它的数据的压力。 我们谈到了高水点 在整个时间数据的压力。 当这些数据的压力达到一定 点，这是一个技术的触发。 它变得太昂贵了。 它需要很长时间才能处理数据。 我们需要更好的东西。 你得到的创新者 在那里跑来跑去， 试图找出解决的办法。 有什么新的想法？ 什么是下一个最好的 办法做这件事情？ 他们拿出的东西。 而人与真正的痛苦， 球员在最前沿， 他们会跳一切都结束吧， 因为他们需要一个答案。 现在什么必然happens--和 它的发生，现在在NoSQL的。 我看到这一切的时候。 什么必然发生的事情是 人们开始使用新的工具 同样的方式，他们所使用的旧工具。 他们发现它 不工作这么好。 我不记得我是谁 谈论今天早些时候。 但是，这就像，当 手持式凿岩机的发明， 人没荡过来 他们的头粉碎的混凝土。 但是，这是什么 与NoSQL的今天发生的事情。 如果你走在大部分商店， 他们正试图成为NoSQL的商店。 他们在做什么是 他们使用的NoSQL， 他们正在加载 完整的关系架构。 因为这是怎么 他们设计的数据库。 他们想知道，为什么 它不是表现非常好？ 男孩，这个东西很臭。 我必须保持我的所有 加入in--这就像，不，不。 保持连接？ 你为什么要加盟的数据？ 你不加入数据的NoSQL。 你可以将它。 所以，如果你想避免这种情况，学习 该工具前，你是如何工作的实际 开始使用它。 不要尝试使用新工具 您使用的旧工具一样。 你将有一个不愉快的经历。 而每一次 那这是怎么回事。 当我们开始来了这里， 这是因为人想通了 如何使用工具。 他们也做了同样的事情时， 关系数据库被发明， 他们被替换的文件系统。 他们试图建立文件系统 关系型数据库 因为这是人的理解。 它没有工作。 因此，了解最佳实践 该技术的你正在使用 是巨大的。 很重要。 所以，我们要进入DynamoDB。 DynamoDB是AWS的 全托管的NoSQL平台。 什么是全管理是什么意思？ 这意味着你不需要 真担心什么。 你进来，你告诉 我们，我需要一个表。 它需要这么多的能力。 你打的按钮，我们提供 台前幕后的所有基础设施。 既然是巨大的。 因为当你说话 关于缩放的数据库， NoSQL的数据群集在 规模，运行PB级， 运行数百万 每秒事务数 这些东西都不是小群。 我们所说的数以千计的实例。 管理实例十万， 即使是虚拟的情况下， 在屁股真正的痛苦。 我的意思是，想想每次 操作系统补丁出来 或数据库的新版本。 这意味着什么 你在操作？ 这意味着你有1200 需要服务器进行更新。 现在，即使有自动化， 这会花费很长的时间。 这可能会导致大量的 运营头痛， 因为我可能会服务了。 当我更新这些数据库，我 可能会做蓝绿部署 我的部署和升级一半的 节点，然后再升级的另一半。 把这些下来。 所以，管理基础设施 规模巨大的痛苦。 而AWS采取痛苦出来。 和NoSQL数据库可以 是非常痛苦的 由于它们的尺寸的方式。 横向扩展。 如果你想获得更大的NoSQL 数据库，你买更多的节点。 你买的每一个节点 另一运营头痛。 因此，让别人为你做的。 AWS可以做到这一点。 我们支持文件键值。 现在，我们没去太多 到另一个图表上。 有很多的不同 NoSQL的口味。 他们都是那种获得的 在这一点上被改写的一起。 你可以看一下DynamoDB和说的话， 我们都是一个文档和密钥值 存储了这一点。 你可以说功能 的一个在另一个之上。 对我来说，有很多这真的是6 二分之一的其他的一打。 这些技术的每一个是一个 FINE技术和罚款的解决方案。 我不会说MongoDB是好还是 不是沙发，然后卡桑德拉糟糕的是， 然后迪纳摩，反之亦然。 我的意思是，这些只是选择。 它速度快，它的 在任何程度上是一致的。 因此，这是一个最大的 奖金你得到AWS。 随着DynamoDB是一种能力 得到一个低个位数 毫秒的延迟在任何程度。 这是该系统的设计目标。 我们有在做客户 每秒数百万的交易。 现在，我会去通过一些那些 在几分钟后在这里使用的情况。 综合接入control-- 我们有我们所说的 身份访问管理，或IAM。 它渗透在每一个系统， 每一个服务，AWS提供。 DynamoDB也不例外。 您可以控制​​访问 到DynamoDB表。 在所有您的AWS账户通过 定义访问角色和权限 在IAM的基础设施。 它是在一个关键和不可或缺的组成部分 我们所说的事件驱动编程。 现在，这是一个新的范例。 听众：怎么你的速度真 阳性与假阴性 您的访问控制系统？ RICK霍利汉：真阳性 与假阴性？ 听众：返回什么 你应该回来？ 相对于曾经在一段时间它 不返回时，应验证？ RICK霍利汉：我不能告诉你。 如果有任何故障 凡上， 我不是问的人 特定的问题。 但是，这是一个很好的问题。 我会很好奇，想知道 我自己，其实。 所以还是那句话，新范式 是事件驱动编程。 这是想法，你可以 部署复杂的应用程序 可以操作一个非常，非常高档次 对此不承担任何基础设施。 没有任何固定 基础设施的任何责任。 我们将讨论一点点 关于这意味着什么，因为我们 坐上去接下来的几个图表。 我们要做的第一件事情 是我们将讨论表。 API数据类型的发电机。 的第一件事情，你会 当你看到这个通知， 如果你熟悉的任何数据库， 数据库有真正两种的API 我会调用它。 两套API的。 其中之一是 管理API。 他们照顾的事情 数据库的功能。 配置存储引擎， 设置和添加表。 创建数据库 目录和实例。 这些things--在DynamoDB，您 有很短，短列表。 因此，在其他的数据库， 您可能会看到几十个 对命令的管理， 命令，用于配置 这些附加选项。 在DynamoDB你不需要这些，因为 您不配置该系统，我们做的。 所以，你需要做的唯一事情是 告诉我，我需要什么尺寸的表。 所以，你得到一个非常 有限的命令集。 你得到一个创建表更新，表， 删除表，并说明表。 这些都是唯一的东西 你需要DynamoDB。 你并不需要一个存储 发动机配置。 我并不需要担心复制。 我不需要担心分片。 我不需要担心 任何有关这东西。 我们做这一切为您服务。 所以这是一个庞大的开销 这只是抬离你的盘子。 然后我们有CRUD操作。 CRUD的东西我们 在数据库的调用 创建，更新，删除操作。 这些都是您共同 数据库操作。 比如像放项目，拿到项目，更新 项目，删除项目，批量查询，扫描。 如果要扫描整个表。 拉一切假表。 一个关于DynamoDB的好东西 是它允许并行扫描。 所以，你其实可以让我知道有多少 要在该扫描运行的线程。 我们可以运行这些线程。 我们可以旋转的扫描最多 在多个线程 这样你就可以扫描整个表 空间非常，非常迅速DynamoDB。 其他的API，我们已经是 我们所说的流API。 我们不会说太多 很多关于这个现在。 我有一些内容以后 在关于此的甲板。 但流确实是一个running-- 把它作为时间排序 和分区更改日志。 一切发生的事情上 该表显示了向上的流中。 每个写表 显示出来的流。 你可以读到流， 你可以做的事情吧。 我们将谈论什么 类型的东西你 做的事情一样复制， 创建二级指标。 各种很酷的 事情你可以与事。 数据类型。 在DynamoDB，我们支持关键 值和文件数据的类型。 在屏幕的左手侧 在这里，我们有我们的基本类型。 关键值类型。 这些都是字符串， 数字和二进制文件。 因此，只要三种基本类型。 然后你就可以拥有集的那些。 的好东西一个关于NoSQL的是 你可以包含数组作为属性。 并与DynamoDB可以包含数组 基本类型为root属性。 然后还有的文档类型。 有多少人熟悉的JSON？ 你们熟悉JSON这么多？ 它基本上是JavaScript的， 对象，符号。 它可以让你基本 限定的分层结构。 您可以存储一个JSON文件 使用DynamoDB通用组件 或者可构建块 在大多数编程语言。 所以，如果你有Java中，你 在地图和列表。 我可以创建对象的区域地图。 的地图作为键值 存储为属性。 以及它可能具有的列表 这些属性中值。 您可以将这种复杂 层次结构 作为一个单独的属性 的DynamoDB项目。 因此，在DynamoDB表中，最喜欢的 NoSQL数据库，表中有一个项目。 在MongoDB中，你会 调用这些文件。 而这将是沙发基地。 另外一个数据库文件。 你叫这些文档。 文档或项目有属性。 属性可以存在或 该项目不存在。 在DynamoDB，有 一个强制属性。 就像在关系数据库中， 你对表的主键。 DynamoDB有我们所谓的哈希键。 哈希键必须是唯一的。 所以，当我定义了一个哈希表， 基本上我在说什么 是每一个项目都会有一个哈希键。 而每一个哈希键必须是唯一的。 每个项目的定义 由唯一的哈希键。 还有只能有一个。 这是正常的，但通常情况下 人们需要什么 是他们要的就是这个哈希 关键的做多一点点 比仅仅是一个唯一标识。 通常情况下，我们希望使用哈希键 作为顶级聚集桶。 而我们做到这一点的方法是 加入我们所说的一系列关键。 所以，如果它只是一个哈希 表，这必须是唯一的。 如果它是一个哈希和范围表中， 散列和范围的组合 必须是唯一的。 所以，想想这样的看法。 如果我有一个论坛。 而形式有主题，有 张贴，它有反应。 所以，我可能有一个哈希 关键，这是主题ID。 我可能有一个范围的关键， 这是响应标识。 这样，如果我想获得的所有 针对特定主题的响应， 我可以查询的哈希值。 我只能说给我所有 具有此散列的项目。 而且我会得到每一个问题 或发布针对特定主题。 这些顶级聚合 是非常重要的。 它们支持的主要接入 应用程序的模式。 一般说来，本 就是我们想要做的。 我们希望有table-- 当你装载表， 我们要构造数据 表以这样的方式内 应用程序可以很 快速检索这些结果。 而通常情况下做到这一点的方法是 维持这些聚合，因为我们 插入的数据。 基本上，我们将数据分散 成亮斗，因为它的用武之地。 范围键允许我 - 哈希 密钥必须平等。 当我查询哈希，我不得不说 给我一个哈希值，等于这一点。 当我查询的范围，我 可以说，给我一个范围 即使用任何种类的 我们支持丰富的运营商。 给我的所有项目的哈希值。 是它等于，大于， 小于，它首先， 它这两个值之间存在吗？ 所以这些类型的范围查询 我们总是感兴趣的 现在有一件事有关数据时， 你看看访问数据时， 您访问的数据，它的 总是关于聚合。 它总是对记录 那些与此有关。 给我这里的一切that's--所有 在这张信用卡的交易 在过去的一个月。 这是一个聚集。 几乎所有的东西，你在做 数据库是某种聚集。 所以能够能够定义 这些桶和给你这些范围 属性能够查询上， 这些丰富的查询支持很多， 很多很多的应用程序的访问模式。 所以其他的事情散列键 做的是它给了我们一个机制 要能够围绕扩展数据。 NoSQL数据库工作最好 当数据是均匀 分布在整个群集。 有多少人熟悉 与散列算法？ 当我说哈希和hashing-- 因为散列算法 是具有能够产生一个方式 一个随机值从任何给定值。 因此，在这种特定的情况下，该 我们运行的hash算法是ND 5为主。 如果我有一个ID，这 是我的散列键，我有1，2，3。 当我运行的散列算法， 它要回来说， 还有1等于7B，2 等于48，3等于CD。 他们都在关键的空间传播。 你们为什么这样做？ 因为这可以确保我能 把跨多个节点的记录。 如果我这样做 递增，1，2，3。 我有一个哈希值范围 运行在这种特殊情况下， 小散的空间， 从00运行到FF， 然后记录将要进来 和他们要去1，2，3，4，5， 6，7，8，9，10，11，12。 怎么了？ 每个刀片将相同的节点。 你明白我的意思吗？ 因为当我分裂了空间， 我对面传播这些记录， 我的分区，我会说 分区1具有密钥空间为0〜54。 分区2为55〜89。 分区3是AA到FF。 所以，如果我使用线性递增 的ID，你可以看到发生了什么。 1，2，3，4，5，6，所有一直到54。 所以当我锤打 记录到系统中， 一切都结束了要去一个节点。 这不好。 这是一个反模式。 在MongoDB中，他们有这样的问题 如果你不使用哈希键。 MongoDB的让您选择 的散列键值。 你应该总是这样做，如果 你使用的是递增的散列 在MongoDB中键，或者你会 钉每写一个节点， 你将被限制 你写吞吐量严重。 听众：那是A9十进制169？ RICK霍利亨：是的，这 周围某处有。 A9，我不知道。 你必须让我的二进制 十进制计算器。 我的大脑不能这样的。 听众：只需一个快速 你蒙戈的意见。 那么，自带的对象ID 与本地蒙戈做到这一点？ RICK霍利汉：是否做到这一点？ 如果指定了它。 随着MongoDB中，您可以选择。 您可以在specify--每个文档 MongoDB中必须有一个下划线标识。 这是独特的价值。 在MongoDB中，你可以指定 是否哈希与否。 他们只是给你的选项。 如果你知道它的 随机的，没有问题。 你不需要这么做。 如果你知道，这不是随机的，那 它递增，然后做的哈希值。 现在的事儿 散列，一旦你哈希 一个value--并且这是 为什么哈希键总是 独特的查询，因为我已经改变了 值，现在我不能做一个范围查询。 我不能说这是 之间的这样或那样的， 因为散列值是不会 为等同于实际值。 当你的哈希因此， 关键的，它只是平等。 这就是为什么在DynamoDB散列键 查询是永远只有平等。 所以，现在在一个范围内key-- 当我再补充一点范围的关键， 这些范围内的密钥记录所有进来 它们会存储在同一个分区。 因此，他们都非常迅速，轻松地 检索因为这是散列， 这是的范围内。 而你看到的一切 具有相同散列 获取存储在同一分区的空间。 您可以使用该范围内的关键，以帮助 找到你的数据接近其父母。 那么，我真的在这里做什么？ 这是一个一对多的关系。 散列关键字之间的关系 和范围的关键是一对多。 我可以有多个哈希键。 我只可以有多个范围 每一个哈希键中键。 散列定义父， 范围界定的孩子。 所以，你可以看到有模拟这里 关系结构之间 与同类型的 构建在NoSQL的。 人们谈论 NoSQL的作为非关系。 这不是非关系。 数据总是有关系。 这些关系只是 建模不同。 让我们来谈谈一点点 有关耐久性位。 当你写DynamoDB，写 总是三通复制。 这意味着我们有三个AZ的。 AZ的是可用性区域。 你可以把可用性 区作为数据中心 数据中心或集合。 这些东西在地理上 相互隔离 在不同的断裂带，跨越 不同的电网和洪泛区。 在一个AZ的故障不 要拿下另一个。 它们也与 加上暗光纤。 它支持一个子1 AZS之间毫秒的延迟。 因此，实时数据复制 能够在多AZS。 而通常情况下多AZ部署 满足高可用性要求 大多数企业组织。 因此，DynamoDB分布 跨越三个AZS默认。 我们只是要知道写 当两个这三个节点回来 并说，是啊，我知道了。 这是为什么？ 因为在读取方面，我们是唯一的 想给你的数据回来时， 我们从两个节点得到它。 如果我复制跨越 三，我从两个阅读， 我总是保证 到具有至少一个 这些读取是 数据的最新副本。 这是什么使得DynamoDB是一致的。 现在，您可以选择打开 那些持续读了。 在这种情况下，我会说， 我只从一个节点读取。 我不能保证它会 为最新的数据。 因此，如果写入进来的， 它没有复制的呢， 你会得到该副本。 这是一个最终一致的读取。 而那是什么是成本的一​​半。 因此，这是值得思考的问题。 当你读出DynamoDB和 你设置你的阅读能力 单位，如果你选择最终 持续读，这是一个很大便宜， 它的大约一半的成本。 因此，这可以节省你的钱。 但是，这是你的选择。 如果你想有一个一致的读或 一个最终一致的读取。 在这个时候，你可以选择。 让我们来谈谈指标。 因此，我们提到， 顶层聚集。 我们有散列键，以及 我们有一系列的键。 这很好。 而这对主表，我 得到了一个散列键，我得到了一个范围的关键。 这意味着什么？ 我有一个属性，我 可以运行针对丰富的查询。 它的范围键。 上item--的其他属性 我可以过滤这些属性。 但我不能做这样的事情，它 开始，或大于。 我怎么做？ 我创建一个索引。 有两种类型的 索引DynamoDB。 索引是真的 表中的另一视图。 而当地的二级指标。 第一个我们要谈论的话题。 因此，当地的次级的共存 在同一个分区中的数据。 正因为如此，它们是上 在相同的物理节点。 他们就是我们所说的是一致的。 含义，它们将确认 随着表的写入。 当写入进来， 我们将通过编写索引。 我们会写上去的表， 然后我们会承认。 所以，这是一致的。 一旦写一直 从表中确认， 它保证了 本地二级索引 将数据的相同的愿景。 但是，它们允许你做的是 定义替代的范围键。 必须使用相同的哈希 键作为主表， 因为它们共同位于 同一分区，他们是一致的。 不过，我可以创建一个索引 不同范围的键。 因此，举例来说，如果我有一个制造商 这有一个毛坯件表进入。 而原零件进来， 它们是由组装聚集。 也许有一个召回。 是由这一点，任何部分 在此日期后生产， 我需要从我行拉。 我可以旋转索引 这将是好看， 聚集上的日期 生产的特定部分。 所以，如果我的最高水平桌子 已经哈希制造商， 也许是被安排在一部分ID，我 可以创建一个索引关闭该表 散列的制造商和 排列在生产日期。 而这种方式，我可以说，任何 在这些日期间生产， 我需要从线上拉。 所以这是一个当地的二级指标。 这些具有的效果 限制你的散列键的空间。 因为它们共存 在相同的存储节点上， 它们限制了混杂键 空间10千兆字节。 DynamoDB，下 表，将分区 你的表每10千兆字节。 当你把10演唱会的数据中，我们 去[PHH]，我们添加另一个节点。 我们不会分开的LSI 在多个分区。 我们将拆表。 但我们不会分开的LSI。 所以这件事情 重要的是了解 就是如果你做的很， 非常，非常大的聚合， 那么你将被限制 到10千兆字节您的LSI。 如果是这样的话，我们可以 使用全局二级。 全球次级是 真正另一个表。 它们的存在完全脱落到 主表的一侧。 他们让我找到了 完全不同的结构。 因此认为它是被插入数据 成两个不同的表，构成 两种不同的方式。 我可以定义一个完全 不同的哈希键。 我可以定义一个完全 不同范围的关键。 我可以运行此 完全独立。 作为事实上，我已经 置备我读能力 写能力为我 全球二级指标 完全独立 我的主表。 如果我定义的索引，我告诉 它有多大的读写 能力它会使用。 并且，它独立 从我的主表。 现在，这两个指标可以让我们 不仅界定哈希和范围键， 但他们让我们 项目附加值。 所以，如果我想读出的指数， 我希望得到一些数据集， 我并不需要返回到主 表，以获得附加的属性。 我可以投射这些附加 属性到表 以支持访问模式。 我知道，我们很可能进入一些 真的，really--渐入杂草 这里的一些这方面的东西。 现在，我得到漂出了这一点。 听众：[听不清] --table关键的意思是一个哈希？ 原来的哈希？ 多缝？ RICK霍利汉：是的。 是。 该表重点基本 指回的项目。 因此，一个索引是一个指针回 原项目在桌子上。 现在你可以选择建立一个 索引，只有具有表键， 并没有其他属性。 为什么会这么做？ 好吧，也许我有非常大的项目。 我真的只需要知道which-- 我的访问模式可能会说， 该项目包含这个属性？ 不需要回报的项目。 我只需要知道 该项目包含它。 所以，你可以建立索引 只有具有表键。 但是，这主要是什么 在数据库中的索引是。 这对于能够快速 确定哪些记录， 哪些行，这 表中的项具有 我正在寻找的属性。 GSIS，所以它们如何工作？ GSIS基本上是异步的。 更新进入表， 表然后异步更新 所有的GSIS的。 这就是为什么GSIS是 最终一致。 重要的是要注意的是 当你建立GSIS， 你明白你创造 的aggregation--另一个层面 现在让我们说一个很好的例子 这里是一个制造商。 我想我可能已经谈 医疗设备制造商。 医疗设备制造商 常常有序号的部分。 要插入的部分 髋关节置换所有 对他们一点序列号。 他们可以有百万， 百万千万件 在所有的，他们出货的设备。 那么，他们需要在汇总 不同的尺寸，所有的份 在装配中，所有的 所做的部分 在某一行，所有 附带的配件 在从某一制造商 在特定日期。 而这些聚合有时 起床到数十亿美元。 所以，我的一些工作 这些人谁是痛苦 因为他们正在创建 这些极大的相聚合 在他们的二级指标。 他们可能有一个毛坯件 表来作为唯一的哈希值。 每个部分都有一个唯一的序列号。 我用的序列号作为散列。 这很漂亮。 我的原始数据表被扩展 所有在整个密钥空间。 我的[？写 ？] [？摄入？]是真棒。 我采取了很多的数据。 然后，他们所做的事情是他们创造一个GSI。 我说，你知道吗，我需要看 所有的所有零件的制造商。 好了，突然我 采取十亿行， 而他们的东西到 一个节点，因为当 我合计为 制造商ID为乱码， 和零件号为的范围内， 那么所有的突然我 把一个十亿分率​​成什么样 这家制造商已交付了我。 这可能会导致很多 对在GSI压力， 再次，因为我骂一个节点。 我把所有这些 插入到一个节点。 这是一个真正的问题用例。 现在，我得到了一个很好的设计 图案你如何避免这种情况。 这就是问题之一 我一直工作着。 但会发生什么，是GSI可能 没有足够的写容量 为能推动所有这些 行到一个节点。 而会发生什么，然后是 伯，客户表， 主表将被节流 因为GSI跟不上。 所以，我的插入率 落在主表 我的GSI试图跟上。 好吧，那么GSI的，LSI的， 我应该使用哪一个？ LSI公司是一致的。 GSI的是最终一致性。 如果没关系，我建议使用 GSI，他们更灵活。 LSI的可以模拟为一个GSI。 并且如果在每个散列密钥的数据大小 您的收藏超过10千兆字节， 那么你会希望使用 GSI，因为它只是一个硬性限制。 好吧，那么缩放。 吞吐量迪纳摩DB，你 可以提供[听不清] 吞吐量到表中。 我们已经有客户 供应60 billion-- 在做60个十亿的要求，定期 超过一万个请求运行 每秒在餐桌上。 确实没有 理论极限多少 以及如何快速表 可以迪纳摩DB运行。 还有一些软 在您的帐户限额 我们摆在那里让 你不发疯。 如果你想比 即，不是一个问题。 你来告诉我们。 我们将调高转盘。 每个帐户被限制在一定程度 在每一个服务，就在蝙蝠 所以人们不发疯 让自己陷入麻烦。 没有限制的大小。 你可以把任何数量 桌子上的物品。 一个项目的大小是 限于每400千字节， 这将是项目没有属性。 所以所有属性的总和 被限制为400千字节。 再然后，我们有 那个小LSI问题 每个哈希的10 GB的限制。 听众：小数目，我失踪 你告诉我，那is-- 听众：哦，400千字节 每件的最大尺寸。 因此，一个项目具有所有属性。 所以400 k是总大小 该项目，400千字节。 因此，所有的属性 结合时，所有的数据 这是在所有的这些属性， 卷成总大小， 目前今天的项目限制为400ķ。 所以再次扩展，实现了 通过分区。 吞吐量是供应 在表级别。 还有的实际上是两个旋钮。 我们阅读能力 和写的能力。 因此，这些被调整 彼此独立。 RCU的措施，严格一致的读取。 好了，如果你说我要1000 RCU的那些都是严格一致， 这些都是一致的读取。 如果你说我想 最终一致性读取， 你可以提供1000 RCU的，你要去 得到2000最终 持续读。 而一半的价格对于那些 最终由在读。 再次，调整 彼此独立。 他们有throughput-- 如果你消耗你的RCU的100％， 你不会冲击 可用性你的权利。 因此，他们是完全 相互独立的。 好了，所以的事情之一 我简要地提到了节流。 节流是坏的。 节流表示不好没有SQL。 有些事情我们可以做些什么来帮助 你减轻限制你 正在经历。 但最好的解决方案 这就是让我们 一看你在做什么，因为 有一个反模式在这里打球。 这些东西，这样的事情不统一 工作负载，热键，热分区。 我打一个特定的密钥空间 很难对一些特殊的原因。 我为什么这样做呢？ 让我们明白这一点。 我在我的混合热数据冷数据。 我让我的表得到 巨大的，但有真 数据只有某个子集 这真的对我有意思。 因此，对于日志数据，例如，很多 客户，他们得到每天记录数据。 他们获得了大量的日志数据。 如果你只是倾倒所有的日志 数据整合到一个大表，随着时间的推移 该表会得到巨大的。 但我真的只关心 过去24小时，过去七天， 在过去30天。 时间无论窗口 我很感兴趣，期待 对于困扰我，或者事件 该事件也同样吸引了我， 这是唯一的窗口时间，我需要。 那么，为什么我把10年 值得在表日志数据？ 是什么引起的 表中的片段。 它得到巨大的。 它开始铺开 在成千上万的节点。 而且，由于你的能力 这么低，你 实际上率每个限制 其中的一个单独的节点。 因此，让我们开始考虑如何 这样做，我们在推出该表。 如何管理这些数据一点点 更好地避免这些问题。 又是什么样子？ 这是什么样子。 这是不好的NoSQL的样子。 我这里有一个快捷键。 如果你看看在这里边， 这些都是我的分区。 我有16个分区在这里 在这个特定的数据库。 我们做这一切的时候。 我运行这个客户所有的时间。 这就是所谓的热图。 热图告诉我，你怎么是 访问您的密钥空间。 而这是什么告诉我是 这有一个特定的哈希 这家伙喜欢的 非常多的，因为他是 打它真的，真的很难。 因此，蓝色是不错的。 我们喜欢蓝色。 我们不喜欢红色。 红的，其中的压力 得到高达100％。 100％，现在你将要节流。 所以每当你看到任何红色线条状 this--，它不只​​是迪纳摩DB-- 每一个NoSQL数据库有这个问题。 有反模式，可以 驱动这些类型的条件。 我做的是我与客户合作 为缓解这些条件。 又是什么样子？ 这是获得最多 出迪纳摩DB吞吐量， 但它真的越来越 最出的NoSQL的。 这不限于发电机。 这是definitely--我 曾经工作在蒙戈。 我熟悉很多NoSQL的平台。 每个人心中都有这些类型的 热键问题。 为了充分利用任何对NoSQL 数据库，特别是迪纳摩DB， 要创建表 其中，哈希键元素 大量不同的值， 高度的基数。 因为这意味着我在写 以许多不同的桶。 越桶我 写入，就越有可能 我传播的写入负载或 读取加载到多个节点， 更可能的，我有一个 在桌子上的高吞吐量。 然后我想的值是 要求相当均匀地随着时间的推移 并均匀地随机越好。 嗯，这是一种有趣的， 因为我真的不能 当用户来控制。 所以，我只想说，如果我们传播 东西横跨密钥空间， 我们很可能会在更好的形状。 有一定的 准时交货量 那你不会 要能够控制。 但是，这些都是真的 两个维度，我们有， 空间，获得均匀 传播，时间，请求 抵达的均匀间隔的时间。 如果这两个 条件得到了满足， 那么这就是它的 将会是什么样的。 这是更漂亮。 我们真的很高兴在这里。 我们有一个非常均匀的访问模式。 是的，也许你得到一个 小的压力飘飞， 但没有什么太广泛。 所以，这是惊人的多少倍， 当我与客户合作， 即先用大红色的曲线图 酒吧和所有的丑陋的黄色是 所有的地方，我们 获得与行使完成 经过几个月 重新架构， 他们正在运行完全相同的 工作量在完全相同的负载。 而这也正是它看起来像现在。 所以你得到的NoSQL什么是 数据模式是绝对 绑在访问模式。 你可以优化数据模式 支持这种访问模式。 如果不这样做，那么你会 看到这些类型的问题 这些热键。 听众：嗯，难免有些地方 将要比其他热。 RICK霍利汉：始终。 总是。 是的，我的意思是总有 A--并再次，有 一些设计模式，我们会获得通过 这将谈谈你是如何处理 与这些超级大聚合。 我的意思是，我有他们， 我们该如​​何处理？ 我有一个很好的用例 我们将讨论有关这一点。 好吧，让我们的谈话 一些客户现在。 这些家伙是AdRoll。 我不知道，如果你 熟悉AdRoll。 你可能看到他们 很多在浏览器上。 他们的广告重新定位，他们 最大的广告重新定位业务 在那里。 他们通常定期碾过 每日起60十亿的交易。 他们正在做的过万 每秒事务。 他们有一个非常简单的表 结构，最繁忙的表。 它基本上只是一个 哈希关键是饼干， 的范围是人口统计 类别，然后 第三属性是得分。 因此，我们每个人都有饼干 我们的浏览器，从这些家伙。 而当你去 参与商户， 他们基本上横跨得分您 不同的人口统计类别。 当你去一个网站， 你说我想看看这个ad-- 或者基本上你不说that-- 但是当你去网站 他们说你要看到这个广告。 他们去得到AdRoll该广告。 AdRoll看你在他们的桌子。 他们发现你的cookie。 广告商告诉 他们，我希望有人 谁是人到中年， 40岁的男子，进入运动。 而且他们得分，你在那些人口 和他们决定是否 这是一个很好的广告给你。 现在，他们有一个SLA 他们的广告商 提供分10毫秒 在响应每一个请求。 因此，他们使用的是DB迪纳摩此。 他们打了我们​​一个 每秒百万的请求。 他们能够做到所有的 查找，分流所有的数据， 并获得附加的链接回到那个 广告主在10毫秒。 这真的很惊人 实现他们有。 这些家伙actually-- 难道这些家伙。 我不知道这是否是这些家伙。 可能是这些家伙。 主要讲述us--没有，我 不要认为这是他们。 我认为这是别人。 我正与一个 客户的告诉我 现在，他们已经 去迪纳摩DB，他们 零食的花费更多的钱 他们的开发团队每个月都会 比他们在自己的数据库中度过。 因此，它会给你一个 节约成本的想法 您可以在迪纳摩DB获得巨大。 好吧，dropcam是另一家公司。 这些家伙是一种of--如果你认为 对物联网，dropcam 基本上是互联网安全的视频。 你把你的相机在那里。 相机有一个运动检测器。 有人走来， 触发提示点。 相机开始记录了一段时间，直到 它没有检测到任何运动了。 提出该视频在互联网上。 Dropcam是一个公司，是 基本切换到发电机DB 因为他们遇到 巨大的成长的烦恼。 而他们告诉我们， 突然PB的数据。 他们不知道他们的服务 会如此成功。 比YouTube上更多的入站视频 正是这些家伙让。 他们使用DynamoDB跟踪所有的 元数据对所有的视频​​关键点。 因此，他们有他们推S3桶 所有二进制神器之中。 然后，他们有 迪纳摩DB记载， 指人们对这些S3三个对象。 当他们需要看视频， 他们期待在迪纳摩DB中的记录。 他们点击链接。 他们拉下从S3的视频。 所以这是什么样的这个样子。 这是直接从他们的队伍。 迪纳摩DB降低其 交货期为视频事件 从5到10秒。 在他们的老关系存储， 他们曾经有去执行 多重复杂的查询图 哪些视频拉下， 到小于50毫秒。 所以，这是惊人的，令人惊叹 多少性能 您可以在优化得到和 你调的基础数据库 以支持访问模式。 Halfbrick，这些家伙，它是什么， 水果忍者我想是他们的事。 这对迪纳摩DB所有运行。 而这些人，他们是一支伟大 开发团队，大发展 店。 没有一个良好的老年退休金计划的团队。 他们没有很多 经营资源。 他们都在努力试图保持 他们的应用基础架构起来 并运行。 他们来找我们。 他们看着那个迪纳摩DB。 他们说，这是对我们来说。 他们建立了自己的全 应用程序框架就可以了。 这里一些非常好的意见 从球队在自己的能力 目前重点建设 游戏和不 具有保持 基础设施，这 正在成为一个巨大的量 开销为自己的球队。 所以，这是后话that--的 受益您从迪纳摩DB得到。 好了，进入 这里的数据建模。 我们谈了一些有关 这一对一，一对多， 和许多许多类型的关系。 你如何保持那些迪纳摩。 在迪纳摩数据库，我们使用 索引，一般来说， 旋转从数据 一种口味到其他。 哈希键，范围键和索引。 在这个特定的 例如，大多数州 有一个许可要求的 只有一个司机的每人执照。 你不能去拿到两司机 许可在波士顿的状态。 我不能在得克萨斯州做。 这是一种事情是这样的。 所以在DMV，我们查找，我们 要查找驾照 由社会安全号码。 我想查找用户的详细信息 通过驾照号码。 所以，我们可能有一个用户的表 对序列号的散列密钥， 或社会安全号码，和 各种属性的项目定义。 现在，该表上的我 可以定义一个GSI的 翻转周围，说我想 上牌照，然后哈希键 所有其他项目。 现在，如果我想查询，并找到 对于任何给定的社会许可证号 安全号码，我可以 查询主表。 如果我要查询，我想 得到社保 数或由其他属性 许可证号，我可以查询GSI。 这种模式是一个 以一对一的关系。 只是一个很简单的GSI， 围绕翻转那些东西。 现在，说说一对多。 一对多基本上是 您的哈希范围的关键。 当我们获得了很多与此 用例是监控数据。 监测数据来自定期 间隔，如物联网。 我们总是得到所有这些 记录进来所有的时间。 我想找到所有的读数 之间的特定时间段。 这是一个非常常见的查询 监测基础设施。 大老远跑到大约是找到一个 简单的表结构，一个表。 我有一个设备测量表 上的装置ID的散列密钥。 而我对一系列关键 时间戳，或在此情况下，紫装。 并允许我执行复杂 针对该范围键查询 并返回这些记录中 是相对于结果 设置我正在寻找。 它建立一个 一对多的关系 到使用的主表 散列键，范围键结构。 所以这是一种建 到表中迪纳摩DB。 当我定义一个哈希 和范围T台，我 定义一个一对多的关系。 这是一个父子关系。 让我们来谈谈多 许多关系。 并为这个特定实例中， 再次，我们将使用GSI的。 而让我们来谈谈游戏 场景：我有一个特定的用户。 我想找出所有的游戏 他的注册或播放。 并对于给定的游戏，我 想找到的所有用户。 那么，如何做到这一点？ 我的用户的游戏桌，我要去 以具有用户ID的散列键 而游戏的范围键。 所以一个用户可以有多个游戏。 这是一个一个的一对多关系 用户与他扮演的游戏。 然后在GSI， 我会翻转周围。 我将哈希的游戏 我将范围的用户。 所以，如果我想获得的所有 游戏用户的演奏中， 我会查询主表。 如果我想要得到所有用户 这是在玩特定的游戏， 我查询了GSI。 所以你看我们是如何做到这一点？ 您构建这些GSI的支持 使用的情况下，该应用程序中，访问 图案，该应用程序。 如果我需要查询有关 这个维度，让 我创建该维度的索引。 如果我不这样做，我不关心。 并根据使用的情况下，我 可能需要索引或我可能不是。 如果它是一个简单的一对多， 主表是好的。 如果我需要做这么多，以 很多的，还是我需要做一个的， 那么也许我确实需要 到第二索引。 因此，一切都取决于 我想要做的 我试图让成就什么。 也许我不会花太多 很多时间谈论的文件。 这得到了一点点，也许， 更深的比我们需要进入。 让我们来谈谈一点点 关于丰富的查询表达式。 因此，在迪纳摩DB，我们有 创造能力 我们所说的投影表达式。 投影表达式是简单 采摘田野或值 要显示。 好了，我做一个选择。 我做对迪纳摩数据库的查询。 我说，你知道吗，秀 我唯一​​的五星级评价 此特定产品。 所以，这就是我所希望看到的。 我不希望看到所有的 该行的其他属性， 我只是想看看这个。 这就像在SQL中，当您 说选择星或表， 你得到的一切。 当我说从选择名称 桌子，我只得到一个属性。 它在同样的事情 迪纳摩DB或其他NoSQL数据库。 过滤器表达式让我 基本上切断结果定了下来。 所以，我做一个查询。 查询可能会回来与500个项目。 但我只想要项 有一个属性，说这一点。 好了，让我们过滤掉这些项目 那些特定的查询不匹配。 因此，我们有过滤器表达式。 过滤器表达式可以 在任何属性上运行。 他们不喜欢的范围查询。 提高查询是更有选择性。 过滤器的查询要求我去 得到的整个结果来设定，然后 能开出，我不想要的数据。 这是为什么重要？ 因为我读了这一切。 在查询中，我会阅读和 这将是一个关于数据的巨人。 然后我要去 能开出什么，我需要。 如果我只是雕刻出 几排的，那么这就是确定。 它不是那么低效。 但是，如果我读一大堆的 数据，只是开拓出一个项目， 然后我会更好 关闭使用范围查询， 因为它更具有选择性。 这将节省我很多 钱，因为我付出相应的代价读。 如果这一回来的结果 跨越这线可能会更小， 但我付出的读取。 因此，了解 你得到的数据。 这是在迪纳摩DB非常重要的。 条件表达式，这就是 你可以称之为乐观锁。 更新如果不存在，或者这个值 相当于什么我指定。 如果我有一个时间戳 记录，我可能会读取数据。 我可能会改变这些数据。 我可能会写的 数据回数据库。 如果有人改变了纪录， 时间戳可能已经改变。 而这样我的条件 更新可以说更新 如果时间戳等于此。 否则更新会失败，因为有人 更新的同时记录。 这就是我们所说的乐观锁定。 这意味着，有人 可以进来并改变它， 我要去检测到它 当我回去写。 然后，我其实可以读到 数据和说，哦，他改变了这一点。 我需要考虑到这一点。 我可以在更改数据我 记录和应用其他更新。 所以，你可以捕捉那些增量 的时间之间发生的更新 你读出的数据和 时间你可能会写入数据。 听众：和过滤器 表达其实就是不 在数量或不是 - [插入VOICES] RICK霍利汉：我不会 得到太多到这一点。 这是一个保留关​​键字。 英镑观点是保留 关键字迪纳摩DB。 每个数据库都有自己的保留 名称的集合不能使用。 迪纳摩DB，如果您指定 一斤在这方面， 你可以定义那些名字了上面。 这是一个参考价值。 这可能不是最好的语法 最多有此讨论， 因为它进入一些real-- 我会一直谈论更多 关于在更深的层次。 但我只想说，这可能 要查询扫描他们views-- 也不英镑的观点是大于10。 这是一个数值，是的。 如果你想要，我们可以谈 该讨论之后。 好吧，让我们进入 在最佳实践某些情况下 我们要讨论在哪里 这里的一些应用程序。 什么是用例迪纳摩DB。 什么是设计 模式在迪纳摩DB。 而第一个我们要 谈的是物联网。 因此，我们得到了很多of--我猜， 什么是它 - 50％以上的 在互联网上，这些天的交通 实际上是由机器生成的， 自动化过程，而不是由人类。 我的意思是这件事这件事， 你携带在你的口袋里， 多少数据，这一件事是 实际发送身边没有你 知道这绝对是惊人的。 您的位置信息 有关如何快，你要去的地方。 您如何看待谷歌地图工程 当他们告诉你的业务是什么。 这是因为有百万， 数以百万计的人驾车去 与手机，发送 数据遍布的地方所有的时间。 所以的事情之一 关于这种类型的数据 进来，监测数据，日志 数据，时间序列数据，是它 通常只有有趣 为一点点时间。 该时间后，它的 没那么有趣。 所以我们讲了，别让 这些表成长过程中没有界限。 这里的想法是，也许我已经得到了24 时间的价值在我的热表的事件。 而这热表将是 置备以非常高的速度， 因为它采取了大量的数据。 它采取了大量的数据 在和我读了很多。 我有很多的操作 针对该数据运行查询。 24小时后哎，你 知道吗，我不在乎。 所以，也许每一个半夜，我滚 我的表到一个新表 我取消置备此表。 我会采取RCU年代和 WCU的下降，因为24小时后 我没有运行尽可能多 查询针对该数据。 所以，我要省钱。 也许30天我不知道 甚至需要关心这一切。 我可以采取WCU的 下一个所有的方式， 因为你知道，这是 永远不会得到写入。 该数据是30天。 它永远不会改变。 这几乎永远不会得到阅读， 所以我们就采取RCU下降到10。 而且我节省了此一吨的钱 数据，并且只支付我的热数据。 所以这是看最重要的事情 在当你看一个时间序列 数据传来的体积。 这些策略。 现在，我可能就让它 都去同一个表 只是让该表增长。 最后，我要 看性能问题。 我将不得不开始存档 某些数据从表中的， 什么不是。 让我们更好 设计应用程序 这样就可以正确运行这种方式。 所以它只是自动 在应用程序代码。 在午夜每晚 它推出的表。 也许我需要的是一个滑动 的24小时的数据窗口。 然后定期我 主叫关表数据。 我有一个修整它 cron作业，我把它 到这些其他表， 无论你需要什么。 因此，如果一个过渡工作，这是伟大的。 如果不是，修剪。 但是，让我们保持这种热点数据 远离你的感冒数据。 它会为您节省大量的金钱和 让你的表的更多的表演。 因此，接下来的事情再说吧 的是产品目录。 产品目录是 很常见的情况。 这其实是一个很常见的模式 我们会看到各种各样的东西。 你知道，Twitter的 例如，热鸣叫。 每个人都来了， 抓住了鸣叫。 产品目录，我得到了销售。 我得到了热销。 我每70000请求 第二次来的产品 说明我的产品目录。 我们认为，这对零售业 操作颇有几分。 那么，我们如何同解决？ 有没有办法来面对这一切。 我所有的用户希望看到的 相同的数据块。 他们的到来，同时。 而且他们都发出请求 对于相同的数据。 这给了我，热键，那大红色的 条纹我的图表，我们不喜欢。 这就是那个样子。 所以，在我的密钥空间我越来越 敲定在售项目。 我越来越没有任何其他地方。 我该如何解决这个问题？ 好了，我们有缓存缓解这一点。 缓存，你把基本的内存 分区中的数据库的前面。 我们已成功 [听不清]缓存，你怎么 可以设置自己的缓存，[听不清] 缓存[？任何你想要的研发，？]。 端起在数据库的前面。 而这种方式，你可以存储数据 从这些热键在高速缓存 空间，并通过高速缓存中读取。 然后大部分的阅读 开始看这个样子。 我把所有这些缓存命中在这里 我没有什么事情到这里 因为数据库是坐在后面的 高速缓存和读取永远不会通过。 如果我更改数据 数据库，我必须更新缓存。 我们可以使用的东西 像蒸做到这一点。 我会解释如何工作的。 好吧，短信。 电子邮件，大家都用电子邮件。 这是一个非常好的例子。 我们已经有了某种信息表。 而我们得到的收件箱和发件箱。 这就是在SQL将 看样订做的收件箱。 我们那种使用同一种 策略使用GSI公司，GSI公司的 我的收件箱和发件箱我。 所以我就生的消息来了 到我的信息表。 而第一种方式这 也许，说好，没问题。 我有原始消息。 消息来了[听不清] 消息ID，这是伟大的。 这是我唯一的哈希。 我要创建两个GSI的一 我的收件箱，一个是我的发件箱。 而第一件事我会做 是，我会说我的哈希键 将成为收件人和 我会安排的日期。 这是梦幻般的。 我得到了我很好的观点在这里。 但是有一个小问题在这里。 你碰到这 关系型数据库以及。 他们所谓的垂直分区。 你要保持你的大数据 远离你的小数据。 而原因是因为我得 去阅读的项目来获得属性。 如果我的身体都在这里， 然后读就几件 如果我的身体长度 平均每256千字节， 数学变得相当难看。 所以说，我想读大卫的收件箱。 大卫的收件箱中有50个项目。 的平均值和大小为256千字节。 这是我的转化率 对于RCU的为四字节。 好吧，让我们一起去 最终一致性读取。 我还在吃1600 RCU的 只是看大卫的收件箱。 哎哟。 好了，现在让我们想想 有关如何应用程序的工作原理。 如果我在一个电子邮件应用程序， 我看着我的收件箱， 我期待在每封邮件的正文， 没有，我在看的摘要。 我看只有头。 因此，让我们建立一个表结构 看起来更像。 因此，这里的信息 我的工作流程需求。 这是在我的收件箱GSI。 它的日期，发送者， 这个问题，然后 消息ID，它指向 回邮件表 在那里我能得到身体。 那么，这些将是记录ID。 他们将指向回 项ID在迪纳摩数据库表。 各项指标始终creates-- 总是具有项 ID为部分of--的 自带的索引。 好吧。 听众：它告诉它在那里的存储？ RICK霍利亨：是的，它告诉 exactly--这也正是它的作用。 它说，这是我重新备案。 它会指出这回我重新备案。 究竟。 好了，现在我的收件箱 实际上要小得多。 而这实际上支持 的电子邮件应用程序中的工作流程。 所以我的收件箱，我点击。 我走，我点击了邮件， 这时候我需要去获得身体， 因为我要去 去一个不同的看法。 所以，如果你想MVC类型 框架，模型视图控制器。 该模型包含 数据的视图需要 和控制器相互作用。 当我改变帧，当 予改变的角度来看， 它是确定返回到 服务器和重新填充模型， 因为这是用户期望的结果。 当他们改变看法，这是当 我们可以回到数据库。 所以电子邮件，请单击。 我在找尸体。 往返。 去拿身体。 我读少了很多数据。 我只是读体的 当他需要他们大卫需求。 我也不会在1600年烧毁 RCU的只是为了显示他的收件箱。 所以，现在that--这是方法 该LSI或GSI--我很抱歉， GSI，将制定。 我们有我们的哈希收件人。 我们已经得到的日期范围键。 而且我们已经得到了预期的属性 我们只需要支持这样的观点。 我们旋转，对于发件箱。 散列发件人。 和在本质上，我们有 非常漂亮，干净的看法。 而且这basically--我们 有这个漂亮的消息 表正在被很好地传播，因为 它的哈希只，散列消息ID。 而且我们有两个指标是 被旋转关闭该表。 好了，所以这里的想法是不 保持大数据和这个小数据 一起。 垂直分区， 这些分区表。 不要读数据，你就不必。 好吧，游戏。 我们都喜欢的游戏。 至少我很喜欢游戏的话。 因此，一些事 我们处理的时候 我们正在考虑的游戏，对不对？ 游戏这些天，特别是移动 游戏，是所有关于思维。 而且我要在这里一个旋转 点点远离DynamoDB。 我要引进 一些讨论 周围的一些的 其他AWS技术。 但是对游戏的想法是想 关于原料药方面，API的是， 一般来说，HTTP和JSON。 这是怎么手机游戏样的 与后端进行交互。 他们这样做的JSON张贴。 他们得到的数据，它的一切， 一般来说，在漂亮的JSON API的。 事情是得到朋友，得到 领先榜，交换数据， 用户生成的内容， 推送至系统， 这些类型的东西 我们要做的。 二进制资产数据，该数据 可能不坐在数据库中。 这可能在坐 对象存储，对不对？ 但数据库将会 最终告知系统， 告诉应用程序 哪里去得到它。 不可避免地，多人 服务器，后端基础设施， 而专为高 可用性和可扩展性。 因此，这些都是事情，我们都希望 在当今游戏的基础设施。 因此，让我们一起来看看 是什么样子。 有一个核心的后端， 非常简单。 我们这里有一个系统 多个可用区。 我们谈到AZS作为being--认为 它们作为独立的数据中心。 一个以上的数据中心 按AZ，不过没关系， 只是把它们作为单独的数据 中心在地理上 和故障隔离。 我们将有一个 夫妇EC2实例。 我们将有 一些后端服务器。 也许，如果你是一个传统的 架构，我们 使用我们所说的RDS， 关系数据库的服务。 可能是MSSQL，MySQL的， 或类似的东西。 这是这样一个大量的应用 设计的今天。 嗯，我们可能要一起去 这是当我们向外扩展。 我们将继续前进，把 在S3存储在那里。 这S3存储桶，而不是服务 从我们的servers--这些对象 我们能做到这一点。 你把你所有的二进制 在服务器上的对象 您可以使用这些服务器 实例来服务这些数据了。 但是，这是相当昂贵的。 更好的办法是继续前进， 把这些对象在S3存储桶。 S3是一个对象存储库。 它内置专 提供了这些类型的东西。 而让这些客户端请求 直接从这些对象桶， 卸载的服务器。 所以我们开始在这里进行扩展。 现在我们得到的用户遍布世界各地。 我得到了用户。 我需要在本地有内容 靠近这些用户，对不对？ 我创建了一个S3桶 作为我的源代码库。 我会前，与 在CloudFront的分布。 CloudFront的是CD和 内容分发网络。 基本上，它需要你指定的数据， 并将其缓存所有在互联网上 让用户随处都可以有 一个非常快速的响应时， 他们要求这些对象。 所以，你得到一个想法。 有种你充分利用所有的 AWS的方面这里完成这件事。 而最终，我们抛出 在自动伸缩群。 因此，我们的AC2实例 我们的游戏服务器， 当他们开始变得繁忙 和越来越忙， 他们只会旋转另一 例如，旋转另一个实例， 旋另一个实例。 因此，该技术具有自动气象站，它 允许您指定的参数 围绕您的服务器将增长。 所以，你可以拥有服务器的n个 在那里，在任何给定的时间。 如果你的负载消失了，他们会 收缩，这一数字将缩小。 并且如果负载回来， 它会重新生长出来，弹性。 因此，这看起来不错。 我们有很多的EC2实例。 我们可以把缓存 数据库的前面， 尝试并加速数据库。 下一个压力点 一般人看到 是他们使用的是扩展游戏 关系数据库系统。 老天，数据库 性能是可怕的。 我们怎么改进呢？ 让我们尝试把 缓存在这一方面。 那么，高速缓存不起作用 如此之大的游戏，对不对？ 对于游戏，写作是痛苦的。 游戏非常写沉重。 当你缓存不起作用 因为你一直写重 得更新缓存。 您更新缓存，它的 不相关被缓存。 它实际上只是额外的工作。 所以，我们去哪里吗？ 你已经有了一个很大的瓶颈 那里在数据库中。 而且去的地方 明明是分区。 分区是不是 易当你做 处理关系数据库。 关系数据库，你 负责管理，有效的， 密钥空间。 你说A和M之间的用户 去这里，与N和Z去那里。 而你切换 整个应用程序。 所以，你正在处理 这个分区的数据源。 你有交易限制 不跨越分区。 你有各种各样的 混乱，你是 对付那里努力 处理向外扩展 ，建设大型基础设施。 这只是没有乐趣。 听众：所以你是说 越来越多的源点加快 这个过程？ RICK霍利汉：增加？ 听众：源点。 RICK霍利汉：源点？ 听众：从信息， 其中的信息是从哪里来的？ RICK霍利汉：没有。 我想说的是增加 分区中的数据存储数 提高吞吐量。 因此，这里发生了什么是用户 进入EC2实例在这里， 好吧，如果我需要一个用户 这是A至M，我会去这里。 从氮磷，我会去这里。 从P到Z，我会去这里。 听众：好，那所以这些都是 所有存储在不同的节点？ RICK霍利汉：是的。 想到这些作为 不同的孤岛的数据。 所以你必须做到这一点。 如果你正在试图做的 这一点，如果你想 在大规模的关系平台， 这是你在​​做什么。 你服用的数据和 你砍倒它。 而你分区它跨越 该数据库的多个实例。 而你管理所有的 在应用程序层。 这是没有乐趣。 那我们要到哪里去？ 我们想去DynamoDB，全面管理， 的NoSQL数据存储，提供的吞吐量。 我们使用二级指标。 它基本上是HTTP API和 包括文档支持。 所以你不必担心 有关的任何分区。 我们做这一切为您服务。 所以，现在，而是你 只写表。 如果该表需要被分割， 这种情况发生在幕后。 你完全绝缘 从作为一个开发者。 因此，让我们来谈谈 一些用例 我们碰到的游戏，共同 游戏场景，领先榜。 所以，你有用户进来， 说他们是BoardNames 对，分数为这个用户。 我们可能会被散列的用户名， 然后，我们有一系列的游戏。 因此，每一个用户希望看到 所有他玩游戏 和所有他的最高得分 在所有的游戏。 所以这是他个人的排行榜。 现在，我要进去，我想get-- 所以我得到这些个人排行榜。 我想要做的就是去得到 最高分在所有用户。 那么，如何做到这一点？ 当我的纪录被散列上 用户ID，排列在游戏中， 嗯，我要继续前进 和重组，建立一个GSI， 而我要重组这些数据。 现在，我要哈希的 BoardName，这是游戏。 而我要去范围的最高分。 而现在我已经创造了不同的桶。 我使用的是同一个表， 相同的项目的数据。 但我创建一个水桶，让 我最高分通过游戏的集合。 我还可以查询该表 要获得这些信息。 所以，我给自己定了查询模式最多 通过辅助索引的支持。 现在，他们可以通过BoardName进行排序 和分类TopScore，视。 所以你可以看到，这些类型 的使用，你在游戏中获得的情况。 另一个很好的使用情况下，我们在游戏中获得 为奖励和谁是获奖。 这是一个伟大的使用情况 在这里我们称之为稀疏的索引。 稀疏索引是 能够产生 这不一定索引 包含在表中的每一个项目。 为什么不呢？ 因为这是作为属性 索引并没有对每一个项目存在。 所以在这个特定 使用的情况下，我是说， 你知道吗，我要去 创建一个名为奖的属性。 我想给每个用户 具有该属性的奖励。 用户没有奖项 不会有属性。 所以，当我创建了 索引，用户只能 所要显示 在索引是 那些实际上已经赢得了奖项。 所以这是一个伟大的方式，能够 创建过滤索引的 是非常，非常有选择性的不 必须索引整个表。 因此，我们越来越低的时间在这里。 我要继续前进，跳跃 出来，跳过此方案。 说一下about-- 听众：我能问一个简单的问题？ 一个是写重？ RICK霍利汉：是什么？ 听众：写沉重。 RICK霍利汉：写沉重。 让我看看。 听众：或者是不 东西，你可以只 声音在几秒钟的事？ RICK霍利汉：我们去 通过投票的情景。 这并不是说不好。 难道你们有几分钟？ 好。 因此，我们将讨论表决。 因此，实时投票，我们有 要求进行投票。 要求是我们让 每个人只能投票一次。 我们希望任何人能够 改变他们的投票。 我们希望实时聚合 并分析了人口统计学 我们正在将是 显示在网站上的用户。 想想这个场景。 我们的工作很多现实 电视节目，其中他们 做这些事确切​​类型。 所以，你能想到的情景， 我们有亿万 十几岁的女孩有 与他们的移动电话 和投票，以及投票和 对于无论他们是谁投票 发现是最流行的。 因此，这些都是一些 要求我们冒了出来。 这样一来，先来 在解决这一问题的 将建立一个 非常简单的应用程序。 所以，我有这个程序。 我有一些选民在那里。 他们来了，他们打的表决程序。 我有一些原始的投票表 我就抛售这些选票成。 我有一些汇总 投票表 会尽我的分析和人口统计数据， 我们会把这一切都在那里。 这是伟大的。 生活很好。 生活的好，直到我们发现， 总有一两个 人是流行的选举。 只有一个或两件事情 人们真正关心的。 如果你在投票 规模，突然我 将被锤击这个鬼 两个候选人，一个或两个候选人。 项目的数量非常有限 人们发现很受欢迎。 这不是一个很好的设计模式。 这实际上是一个 非常糟糕的设计模式 因为它创造正是我们 谈到这是热键。 热键是一些我们不喜欢的。 那么，我们如何解决这个问题？ 真的，来解决这个问题的方法是 通过采取这些候选​​桶 并为我们每一位候选人， 我们要添加一个随机值， 东西我们知道，随机 1和100之间的值， 介于100和1000， 或者一个与1000之间， 然而，要随机值 追加到该候选人的结束。 而且还我真的做了什么呢？ 如果我使用的候选者ID为 斗到总票数， 如果我添加了一个随机的 号的该端， 我创建了现在的10桶，一 百桶，千桶 我正在聚集跨越票。 所以，我有几百万，数以百万计， 数以百万计的记录进来 对于这些候选人，我现在蔓延 这些票对候选A_1 通过候选A_100，因为 每次投进来， 我生成一个随机的 1和100之间的值。 我这套结上的结束 候选人的人的投票支持。 我为之倾倒成桶。 现在，在背，我知道 我得到了一百桶。 所以，当我要先走 和聚合票， 我从所有这些水桶阅读。 所以，我继续和补充。 然后我做了分散收集 我走到哪里出来说，嘿， 你知道吗，这个应聘者的关键 空间是百余桶。 我要收集所有 投票从这些百桶。 我要汇总 他们，我会说， 候选人A目前拥有 x的总投票数。 现在，无论是写 查询和读查询 是很好的分布 因为我正在写跨越 而我在读在数百键。 我不写， 跨越一个关键看现在。 所以这是一个伟大的格局。 这实际上可能是1 的最重要的设计 图案中的NoSQL规模。 你会看到这种类型的 设计模式在每一种滋味。 MongoDB中，DynamoDB，它不 事，我们都必须做到这一点。 因为当你处理 这些巨大的聚合， 你必须想出一个办法来 它们分布横跨桶。 因此，这是你做的方式。 好吧，那又怎样 你现在正在做的 是你的交易已读 成本写的可扩展性。 我读的成本 有点复杂 我必须去从读 百水桶而不是一个。 但我能写。 而我的吞吐量，我写 吞吐量是不可思议的。 因此，它通常是一个有价值的 技术缩放DynamoDB， 或与此有关的任何的NoSQL数据库。 所以我们想出如何去衡量它。 而我们盘算如何 消除我们的热键。 这是梦幻般的。 而我们得到了这个漂亮的系统。 而且它给了我们非常正确的投票 因为我们有记录的投票重复数据删除。 它的建成DynamoDB。 我们谈到条件的权利。 当选民进来，看跌期权 插入在桌子上， 他们与他们的选民身份插入， 如果他们试图插入另一张选票， 我做了有条件的写操作。 只说写这个 如果这不存在。 所以，当我看到， 该票的打表， 没有人会是 能够把他们的选票研究。 这是梦幻般的。 我们正在递增 我们的候选人计数器。 我们正在做我们的 人口和一切。 但是，如果发生了我 应用倒下？ 现在突然票 都进来，我 不知道，如果他们要处理 在我的分析和人口统计学 了。 而当该应用程序 回来了，怎么 地狱做我知道什么票都有 被处理，我从哪里开始？ 因此，这是一个真正的问题，当你 先来了解一下这种类型的场景。 我们如何解决呢？ 我们解决它与我们 致电DynamoDB流。 流是一个时间排序和 每个分区的访问权限更改日志 表中，每一个写 对表的访问。 这是写的任何数据 表显示上的流。 它基本上是24小时的队列。 项目打流， 他们生活24小时。 它们可被读取多次。 保证被传送 只有一次到流， 可以读取n次。 然而，如此众多的进程要 消费数据，你可以使用它。 它会出现每次更新。 每写只会 一旦出现流上。 所以你不必担心 约两倍的处理它 从同样的过程。 它的每个项目严格有序。 当我们说时间 有序和分区， 每个分区你会看到在流。 您将看到订单项，更新。 我们不保证 对，你是流 要得到每一笔交易 在整个项目的顺序。 所以流是幂等。 难道我们都知道幂等意思？ 幂等的意味着你可以做到这一点 过来，过来，一遍又一遍。 结果将是相同的。 流是幂等， 但他们必须是 从起点开始发挥， 无论你选择，到最后， 否则将不会导致 在相同的值。 同样的事情用MongoDB的。 MongoDB中有一个结构 他们所谓的OPLOG。 它是完全相同的结构。 很多NoSQL数据库 有这样的结构。 他们用它做的事情 像复制，这 正是我们做流。 听众：也许 异端的问题，但你 谈谈应用程序做下来的等等。 现流保证 永远不可能往下走？ RICK霍利亨：是啊，小溪 都保证不会跌的。 我们管理基础架构 背后。自动流 部署在他们的自动缩放组。 我们将通过一个小 会发生什么位。 我不应该说他们不 保证再也不去了。 元素都保证 出现在流中。 并且流将是可访问的。 那么，下山或回来 了，这种情况下。 这covers--没关系。 好吧，让您得到不同 视图类型关闭屏幕。 这是很重要的一个视图类型 程序员通常是，是什么？ 我得到的旧观点。 当更新打表，它会 推旧视图到流 这样的数据可以存档，或改变 控制，改变识别，变更 管理。 新的图像，它现在以后有什么 更新，这是另一种类型的视图 你可以得到。 你可以得到旧的和新的图像。 也许我想他们两个。 我想看看是什么东西。 我想看看它改成。 我有一个符合型 过程中运行。 它需要验证 当这些情况发生变化， 他们是在一定限度内 或某些参数内。 然后，也许我只 需要知道发生了什么变化。 我不在乎什么项目改变。 我并不需要需要知道 什么属性改变。 我只需要知道， 该项目被感动。 因此，这些都是意见类型 你下车流 并可以与之交互。 该应用程序 消耗流， 这是一种这样的工作方式。 DynamoDB客户要求 推数据的表。 流部署在我们所说的碎片。 碎片缩放 独立的表。 他们不用排队完全 你的表的分区。 而之所以说是 因为他们排队 向的能力，当前的 表中的容量。 他们部署在其 自己的自动伸缩群， 他们开始分拆视 有多少写操作都进来， 有多少reads--说实在的，写的。 有没有reads--但如何 很多写操作进入。 然后在回 为此，我们有我们 调用KCL，或室壁运动客户端库。 室壁运动是一个数据流 加工技术从亚马逊。 而流是建立在。 所以你用KCL启用 程序读取数据流。 实际上室壁运动客户端库 管理人员为您服务。 而且它也做了一些 有趣的东西。 它会创建一些表了 在您的DynamoDB表 跟踪哪些项 已经被处理。 于是就这样，如果它落在后面，如果 它属于过去，来，并得到 站在后面时，它可确定 是它在处理流。 这是非常重要的，当 你在谈论复制。 我需要知道什么 数据被处理 和哪些数据尚未处理。 所以KCL库流将 给你很多的功能。 它负责所有的家务。 它代表了一个工人，每碎片。 它创建一个管理表 每一个碎片，对每一个工人。 而那些工人火， 他们认为这些表 所以你知道这个纪录 被读取并处理。 然后，如果处理这样 死了，回来上网， 它可以恢复正确的地方起飞。 因此，我们使用它进行 跨区域复制。 很多客户有需要 移动数据的数据表或部分 各地不同的区域。 有九个区域 世界各地。 所以有可能是一个need--我 可能有用户在亚洲，用户 在美国的东海岸。 它们具有不同的数据 需要在本地分布。 也许用户哪些航班从 亚洲转移到美国， 我想复制 他的数据与他。 所以，当他下飞机，他有 用他的手机应用程序，一个很好的经验。 您可以使用跨区域 复制库做到这一点。 基本上，我们有 提供两种技术。 一个人的控制台应用程序，你可以 站起来对自己的EC2实例。 它运行纯粹的复制。 然后我们给你的库。 该库，你可以用它来打造 你自己的应用程序，如果你 想要做疯狂的事情与数据 - 过滤器，复制的只是其中的一部分， 旋转数据，将其移动到 不同的表，等等，等等。 所以这是一种什么样子。 DynamoDB流可 通过我们所说的LAMBDA处理。 我们提到的事件一点点 驱动的应用程序架构。 LAMBDA是一个关键组成部分。 LAMBDA是触发按需代码 响应于特定的事件。 一这些事件可能是一个 记录出现在流。 如果记录出现在流， 我们会打电话给这个Java功能。 那么，这是JavaScript的，和Lambda 支持Node.js的，使用Java，Python， 并即将支持 其他语言。 而我只想说，这是纯粹的代码。 写在Java中，你定义一个类。 你推JAR成LAMBDA。 然后你指定的类 响应于该事件来调用。 然后拉姆达基础设施 后面将要运行的代码。 该代码可以处理 关闭流记录。 它可以做任何它想做的。 在这个特殊的例子中，所有我们 真正做的是记录的属性。 但是，这只是代码。 代码可以做任何事情，对不对？ 所以，你可以旋转的数据。 您可以创建一个衍生观点。 如果它是一个文档结构， 你可以扁平化的结构。 您可以创建备选索引。 各种东西，你可以 做的DynamoDB流。 真的，这是什么样子。 所以，你得到这些更新进入。 他们来了断弦。 他们的lambda函数读取。 他们正在旋转的数据和 推它在衍生表， 通知变更外部系统， 并且将数据推入ElastiCache。 我们谈到了如何把缓存 在数据库中的正面为销售 场景。 那么会发生什么，如果我 更新项目的描述？ 好吧，如果我有一个LAMBDA 在该表上运行的功能， 如果我更新项目的描述，它会 拿起记录过流， 它会更新ElastiCache 实例与新的数据。 所以这是一个很大的 我们做什么用LAMBDA。 这是胶水代码，连接器。 它实际上给 发射能力 并运行非常复杂的应用程序 无需专用服务器 基础设施，这是真的很酷。 因此，让我们回到我们 实时投票架构。 这是新的和改进我们的 流和KCL功能的应用程序。 和以前一样，我们可以 处理任何规模的选举。 我们喜欢这一点。 我们做了分散云集 在多个水桶。 我们有乐观锁怎么回事。 我们可以保持我们的选民 从改变他们的投票。 他们只能投票一次。 这是梦幻般的。 实时容错能力， 现在可伸缩的聚合。 如果事情翻倒， 知道在哪里可以自己重新启动 当它回来了，因为 我们使用了KCL应用程序。 然后我们还可以使用 KCL应用程序将数据推出 到红移其他 应用程序的分析，或使用 该弹性MapReduce运行 实时流聚合断 的该数据。 因此，这些事情我们 还没有谈到太多。 但他们更多 技术，来 如果你正在寻找熊 在这些类型的方案。 好了，所以这是有关 分析与DynamoDB流。 你可以收集重复数据删除 数据，做各种 好看的东西，在汇总数据 内存，创建这些派生表。 这是一个巨大的用例 那很多客户 正在参与，以嵌套 这些JSON文件属性 和创建附加的索引。 我们在最后。 感谢您的轴承和我在一起。 因此，让我们来谈谈 参考架构。 DynamoDB坐在这么中间 大部分的AWS基础设施。 基本上，你可以把它挂 高达任何你想要的。 使用内置的应用迪纳摩包括 LAMBDA，ElastiCache，CloudSearch， 该数据推伸到弹性 MapReduce的，从DynamoDB进出口 进入S3，各种工作流程。 但可能是最好的 事情谈， 这是真的 有趣的是，当我们 谈论事件驱动的应用程序。 这是一个例子 内部项目 我们已经在这里我们实际上 发布收集的调查结果。 因此，在一封电子邮件中链接 我们送出去，以后还有 是一个小环节说点击 这里以应对调查。 而当一个人点击 这个链接，会发生什么情况 是他们拉下安全 从S3 HTML调查表。 有没有服务器。 这仅仅是一个S3对象。 这种形式的出现， 在浏览器中加载了。 它有骨干。 它有复杂的JavaScript 它的运行。 所以这是非常丰富的应用程序 在客户端的浏览器中运行。 他们不知道，他们不是 与后端服务器进行交互。 在这一点上，它的所有的浏览器。 他们公布的结果是什么 我们所说的亚马逊API网关。 API网关是一个简单的网络API 你可以定义和挂钩 到任何你想要的。 在这种特殊情况下，我们 迷上了一个lambda函数。 所以我的POST操作 发生的事情没有服务器。 基本上，该API网关坐在那里。 它花费了我什么，直到人 开始张贴到它，对吗？ lambda函数只是坐在那里。 它花了我什么，直到 人们开始打它。 所以你可以看到，作为卷 增加，这时候的费用来。 我没有运行的服务器7/24。 所以，我拉的形式 淘汰下来的水桶， 我通过API发布 网关到lambda函数。 然后拉姆达 功能说，你知道 什么，我有一些PIIS，一些 个人身份信息 在这些反应。 我的意见，从用户的到来。 我有电子邮件地址。 我已经得到了用户名。 让我分裂这一关。 我要产生一些 元数据关闭此记录。 而我要去推 元数据到DynamoDB。 而且我可以加密所有数据 并将其推入DynamoDB，如果我想要的。 但它更容易对我来说，在这 使用的情况下，继续前进的发言权， 我要推的原始数据 进入加密的S3桶。 所以我用建在S3服务器端 加密和亚马逊的密钥管理 服务让我有一个键 可以在一个固定的间隔转动， 我可以保护PII数据 因为这整个工作流程的一部分。 所以我做了什么？ 我刚刚部署一个整体 应用程序，我没有任何服务器。 那么，什么样的事件驱动应用程序 建筑为你做。 现在，如果你仔细想想 该用例this-- 我们还有其他的客户我说 到这个确切的架构谁 运行惊人的大战役，谁 在看这个去，噢，我的。 因为现在，他们可以 基本上推在那里， 让这样的活动只是坐在 在那里，直到它启动，而不是 不用担心无花果约 什么样的基础设施 将是那里支持它。 然后尽快 该活动完成后， 它就像基础设施 只是马上消失 因为实在 没有基础设施。 就这么坐在LAMBDA只是代码。 这是坐落在DynamoDB仅仅是数据。 这是一个了不起的方式 来构建应用程序。 听众：那么，这更 短暂的比起来， 如果它被存储实际的服务器上？ RICK霍利汉：当然。 由于该服务器实例 将必须是一个7/24。 它必须是可用于 有人回应。 那么你猜怎么着？ S3提供7/24。 S3总是响应。 而S3是非常，非常好 在煮好的对象。 这些对象可以是HTML文件，或 你想要的JavaScript文件，或什么的。 您可以运行非常丰富的网络应用 从S3桶，而人呢。 所以这就是这里的想法 是摆脱的方式 我们曾经考虑一下。 我们都曾经以为在 术语服务器和主机。 这不是这个问题了。 这是关于基础设施的代码。 部署代码到云 让云中运行它。 而这正是AWS正在努力做的事情。 听众：所以你的金盒中间 的API网关不是服务器状， 反而是just-- RICK霍利汉：你能想到的 它作为服务器的门面。 所有这是它会采取一个HTTP 请求，并将其映射到另一个进程。 这就是它。 在这种情况下，我们正在映射 它以一个lambda函数。 好了，所以这是我的一切。 非常感谢。 我很感激​​。 我知道我们想随着时间的推移一点点。 并希望你们了 信息一点点 你今天可以带走。 我很抱歉，如果我去 一下自己的头， 但有一个好很多 基本的基础知识 我想对你非常有价值的。 所以，谢谢你邀请我。 [掌声] 听众：[听不清] 是当你在说什么 你必须要经历的事情 从开始到结束 以获得正确的价值观 或相同的值， 如何将这些值 改变，如果[听不清]。 RICK霍利亨：哦，等幂？ 如何将这些值的变化？ 好了，因为如果我没有跑 这一切的方式来结束， 那么我不知道什么样的变化 在最后一英里发了言。 它不会是 相同的数据，我所看到的。 听众：哦，所以你只要 还没有得到整个输入。 RICK霍利汉：对。 你必须从一开始走 向端，然后它的 将是一个一致的状态。 凉。 听众：所以你给我们DynamoDB 可以做文档或键值。 我们花了很多时间对 有井和方式键值 翻转它周围。 当你看着那些表，是 留下的文件的方法吗？ RICK霍利汉：我不会 说离开它后面。 听众：他们从the--分离 RICK霍利汉：随着文档 方法，在DynamoDB文档类型 只是所认为的另一个属性。 它是一个包含一个属性 分层数据结构。 然后在查询 您可以使用属性 使用对象标记这些对象。 所以，我可以过滤嵌套 在JSON文件的属性。 听众：所以，任何时候我 做一个文档的方法， 我有点可以到达tabular-- 听众：当然。 听众：--indexes和 你刚才讲的事情。 RICK霍利亨：是的， 索引和所有这一切， 你想索引的时候 JSON的性能， 我们不得不这样做的方式是，如果 你插入一个JSON对象或文档 进入迪纳摩，您可以使用流。 流会读取输入。 你会得到的JSON 对象，你会说OK， 什么是我想要索引的属性？ 您创建一个衍生表。 现在，这是它的工作原理，现在的方式。 我们不会让你指数 直接这些属性。 听众：Tabularizing您的文件。 RICK霍利亨：没错，压扁 它，tabularizing它，没错。 这就是你用它做。 听众：谢谢。 RICK霍利亨：是的， 绝对的，谢谢你。 听众：所以它是一种 蒙戈满足Redis的分类器。 RICK霍利亨：是啊， 这是一个很多这样的。 这是一个很好的说明了它。 凉。