dynamodb
Amazon DynamoDB是AWS云中的托管NoSQL数据库 ，可为从移动应用程序后端到广告技术的用例提供关键基础架构。 DynamoDB针对需要读取和写入单个密钥但不需要联接或其他RDBMS功能的事务性应用程序进行了优化。 对于这部分需求，DynamoDB提供了一种方法，使其具有几乎无限可扩展的数据存储区，而只需很少的维护。
尽管DynamoDB非常流行，但我们经常从开发人员那里听到的一个常见抱怨是DynamoDB非常昂贵。 特别是，随着使用量的惊人增长，成本可能会急剧增加。 在这篇文章中，我们将研究为什么DynamoDB会被视为昂贵的三个原因，并概述可以采取的使DynamoDB的成本更合理的步骤。
DynamoDB分区键
鉴于使用DynamoDB的简便性，开发人员可以在短时间内取得长足的进步。 但是存在一些潜在的陷阱，这是由于在开始使用数据之前没有仔细考虑数据分布。 为了有效地在DynamoDB中管理数据，重要的是要了解DynamoDB的一些内部结构（即如何在后台存储数据）。
如前所述，DynamoDB是NoSQL数据存储，这意味着它有效支持的操作是GET（通过主键或索引）和PUT。 您存储在DynamoDB中的每个记录都称为一个项目，这些项目存储在分区中。 这些分区都是自动管理的，不会暴露给用户。 每个项目都有一个分区键，用作内部哈希函数的输入，以确定该项目将驻留在哪个分区中。 分区本身存储在SSD上，并跨区域中的多个可用区复制。
每个单独的分区都有一些限制：
- 一个分区最多可以存储10 GB的数据。
- 一个分区最多可支持3000个读取容量单位（RCU）或1000个写入容量单位（WCU）。
考虑到这些限制，我们知道可以基于两个条件将数据放置在更多分区上。 如果单个分区的大小超过10 GB，则需要创建一个新分区来存储更多数据。 同样，如果用户请求的读取或写入容量超过单个分区所支持的容量，则会在后台创建新的分区。
除了分区之外，另一个值得理解的方面是DynamoDB中的读写定价方式。 读取和写入消耗称为RCU（读取计算单元）和WCU（写入计算单元）的抽象单元。 DynamoDB中的每个读取或写入都会消耗这些单位，因此，随着读取和写入工作负载的增加，您将分别消耗更多的RCU和WCU。
我们选择的分区键决定了数据在分区之间的平均分配方式。 选择不是非常随机的分区键是一种反模式，可能会导致这些分区内的数据分布不均。 直到最近，分区之间的RCU和WCU分配都是无弹性的，并且是静态完成的。 但是，在由于数据分配不均而导致“热键”的情况下，某些分区将需要比其他分区更多的RCU和WCU分配，这导致为确保过载的分区有足够的空间而过度配置RCU和WCU的问题。 RCU和WCU。
在2018年，Amazon引入了Amazon DynamoDB自适应功能 ，通过允许RCU和WCU的分配在分区之间更加动态来缓解此问题。 今天，DynamoDB甚至“立即”执行此重新分配。 结果，即使存在热键问题，也可能不会立即需要超出所需RCU和WCU的超额配置。
但是，如果您回忆起单个分区上的WCU和RCU的限制以及整体大小限制，那么如果您希望分配超出这些限制的资源（某些高流量应用程序就是这种情况），则可能会产生高昂的成本。 耐克在DynamoDB cost上的工程博客将其作为设置成本的驱动因素之一。 有趣的是，他们没有重新设计分区键，而是选择将一些表移到关系数据存储中。
简而言之，以次优方式对数据进行分区是使用DynamoDB增加成本的原因之一。 尽管自适应容量在某种程度上减轻了这一原因，但仍然最好设计具有足够随机分区键的DynamoDB表，以避免出现热分区和热键问题。
DynamoDB读/写容量模式
在为表配置RCU和WCU时，DynamoDB有几种不同的模式可供选择。 选择正确的模式可能会对您的应用程序性能以及产生的成本产生重大影响。
在顶层，有两种模式： 预 配置容量和按需容量 。 在预配置的容量内，您可以获得类似于AWS的其他地方的预留实例工作方式的预留定价，其中您可以通过在一段时间内向产品投入一定的费用来获得折扣定价。 然后是DynamoDB Autoscaling，可与预配置容量模式结合使用。
您应使用的模式取决于您要在DynamoDB之上构建的应用程序类型。 预置容量模式是指您为一定数量的RCU和WCU付费时，它们始终可用于您的表。 在以下情况下，这是推荐的操作模式：
- 如果您的工作负载稳定，并且在RCU和WCU中表现出相似的要求，并且变化很小。
- 与DynamoDB Autoscaling一起使用时，如果您的工作负荷表现出可预测的可变性（例如，根据一天中的时间）。
- 如果您为服务进行读/写限制的成本很高。
如果您突然遇到高峰或工作负载突然增加，则可能会很昂贵，因为您提供的容量必须超出高峰，以避免节流。 当应用程序的容量消耗逐渐增加或减少时，自动缩放可以提供帮助，但通常无法有效应对峰值和突发事件。
如果选择使用自动缩放，则随着容量的调整，某些请求可能会受到限制，而在操作可能会影响您收入的面向客户的应用程序（例如电子商务网站）时，这可能是不可接受的。 如果我们选择提供比任何突发次数/峰值都更多的固定容量，这将确保您的用户获得最佳体验。 但这也可能意味着很多时间会浪费很多容量。
当您开始使用新工作负载并且尚未对其进行容量估计时，或者当使用量可能无法预测时，切换到按需模式可能是一种节省成本的好方法。 在按需模式下，DynamoDB可以管理所有容量并完全自行扩展和缩小。 一些用户报告说，通过从预配模式转变为按需模式，可以节省大量成本 。
对于每个RCU / WCU，按需模式的价格可能比预配置容量高6到7倍，但在处理最大和最小负载之间的较大差异时，它的性能更好。 按需模式对于表的开发实例也很有用，在这种情况下，表的使用率经常降为零，并且出现不可预测的峰值。
按需模式对您的特定表是否具有成本效益？ 这取决于您的访问模式，数据规模和业务目标。 因此，选择正确的模式并为您的特定表设置正确的自动缩放比例非常重要。 表的最佳模式可能会根据用例，工作负载模式和错误容忍度而有所不同。
DynamoDB扫描和GSI
DynamoDB支持两种不同类型的读取操作，即查询和扫描。 查询是基于主键或索引键的查找。 顾名思义，扫描是对整个表进行扫描以查找特定结果的读取调用。 当DynamoDB对表中的单个项目或几个项目进行操作时，其优化操作是查询操作。 DynamoDB还支持二级索引，该二级索引允许基于除主键以外的其他键进行查找。 二级索引在读取和写入期间还会消耗RCU和WCU。
有时，对DynamoDB数据运行更复杂的查询很重要。 这可能是在某个时间段内找到电子商务零售商购买量最高的10个项目，或某个广告平台的广告转化率。 对于这些类型的查询，扫描通常非常慢，因此第一步通常是创建GSI（全局二级索引）。
正如耐克发现的那样 ，过度使用全局二级索引可能会非常昂贵。 耐克采用的解决方案是将这些工作负载转移到关系数据库中。 但是，这并非总是一种选择，因为在DynamoDB上，有一些事务查询在规模上比在关系数据库中更好地工作，而关系数据库可能需要更多调整。 对于复杂查询，尤其是分析查询，您可以通过将DynamoDB表与更适合高效运行复杂查询的其他工具或服务进行同步来节省大量成本。
Rockset就是这样一种用于运维分析的引擎，它是云原生的，不需要管理服务器或基础架构。 一旦提供了对DynamoDB表的读取访问权限，Rockset集合就可以通过使用DynamoDB流中的更改日志来复制DynamoDB中发生的更改。 这为您提供了Rockset中DynamoDB表的最新索引版本（几秒钟之内）。 您可以在此索引集合上使用SQL的全部功能来运行复杂的OLAP查询，并通过使用Rockset API和SDK构建实时仪表板或自定义应用程序来提供这些查询。
这种方法比直接在DynamoDB上运行这些查询要便宜得多，因为Rockset是一个搜索和分析引擎，专门针对半结构化数据进行了索引和运行复杂查询。 利用聚合索引 ，Rockset将SQL查询转换为在RocksDB-Cloud上进行快速键查找的方法。 每个查询都能够利用分布式执行和基础索引的机会，以确保查询结果以毫秒为单位返回。
对于希望在其事务性数据存储之上构建可操作的分析仪表盘以监视系统当前状态的开发人员，Rockset尤其有用。 Rockset用户通过使用Rockset上的实时同步和查询来构建实时仪表板以及高级搜索应用程序 。
综上所述，选择不正确的分区键，错误的容量模式，过度使用扫描和全局二级索引都是导致DynamoDB成本随着应用程序规模飞涨的原因。 与DynamoDB相关的大部分成本往往是由于缺乏对其内部的了解，或者是由于试图针对从未设计为有效服务的用例进行改造而引起的。 明智地选择分区键，选择适合您的工作负载的操作模式，并使用专用的操作分析引擎可以提高DynamoDB表的可伸缩性和性能，同时保持对DynamoDB帐单的控制。
Anirudh Ramanathan是一位软件工程师，专注于分布式系统和机器学习。 他对初创企业和企业家精神充满热情。 目前，他在数据库的未来在Rockset并作为顾问Doc.ai 。
-
新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们选择的技术，我们认为这些技术对InfoWorld读者来说是重要的，也是他们最感兴趣的。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到newtechforum@infoworld.com 。
翻译自: https://www.infoworld.com/article/3409075/3-cost-cutting-tips-for-amazon-dynamodb.html
dynamodb
985
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
