Dynamodb 读写单元 [英] Dynamodb reading and writing units

查看:10
本文介绍了Dynamodb 读写单元的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读有关 Amazon DynamoDB 的各种文章,但对于如何使用这些读/写单元,我仍然有些困惑.例如,使用免费版本,我每秒有 5 个写入单元和 10 个读取单元可用,每个单元代表 1kb 的数据.但这究竟意味着什么?

I've been reading various articles on the Amazon DynamoDB but I'm still a little confused on the reading/writing units on how these are used. For example, using the free version, I have 5 writing units and 10 reading units available per second, each unit representing 1kb of data. But what does this really mean?

这是否意味着每秒最多可以执行 10 个读取请求或每秒最多可以请求 10kb 的数据(无论是 10 还是 100 请求)?因为这方面对我来说不是很清楚.因此,如果我有 20 个用户同时访问我网站上的一个页面(这导致执行 20 个查询来检索数据),会发生什么?他们中的 10 个会立即看到数据,而另外 10 个会在 1 秒后看到数据吗?或者如果请求的数据(乘以 20)小于 10kb,他们会立即看到数据吗?

Does this mean max 10 read requests can be performed per seconds or max 10kb of data can be requested per seconds(regardless of whether there are 10 or 100 requests)? Because this aspect is not clear for me. So if I have 20 users who concurrently access a page on my website(which result in 20 queries being performed to retrieve data), what will happen? Will 10 of them see the the data immediately while the other 10 will see it after 1 second? Or will they all see the data immediately if the data requested (multiplied by 20) is less then 10kb?

另外,如果读取单元不够,100个用户同时请求每个1kb的数据,是不是所有的请求都需要10秒才能完成??

Also, if the reading units are not enough, and 100 users request concurrently 1kb of data each, does this mean all the requests will require 10 seconds to complete??

另外,定价有点令人困惑,因为我不明白这些价格是为保留或消耗的单位支付的?例如,他们说价格是写入吞吐量:每 10 个写入容量单位每小时 0.00735 美元".这是否意味着即使在一天中没有提出任何写作请求,人们也会支付 ($0.00735*24=$0.176)?

Also, the pricing is a little confusing as I don't understand if the prices are paid for units reserved or consumed? So for example they say the price is "Write Throughput: $0.00735 per hour for every 10 units of Write Capacity". Does this mean one will pay ($0.00735*24=$0.176) even if no writing requests are made during a day?

推荐答案

你是正确的,因为容量与正在读/写的对象的大小紧密相关.

You are correct in that the capacity is tightly bound to the size of the objects being read/written.

AWS 更新了他们计算吞吐量的方式,并将其计算的对象从 1 KB 增加到 4 KB.下面的讨论仍然有效,但某些计算现在不同了.

AWS has updated how they calculate throughput, and the they've increased from 1 KB objects to 4 KB for their calculations. The discussion below is still valid, but certain calculations are different now.

请始终查阅最新的 DynamoDB 文档,以获取有关如何计算吞吐量的最新信息和示例.

Always consult the latest DynamoDB documentation for the latest information and examples on how to calculate throughput.

来自 AWS DynamoDB 文档(截至 2014 年 1 月 8 日):

From the AWS DynamoDB documentation (as of 1/8/14):

写入所需的容量单位 = 每次写入的项目数第二个 x 项目大小(四舍五入到最接近的 KB)

Units of Capacity required for writes = Number of item writes per second x item size (rounded up to the nearest KB)

读取所需的容量单位* = 每次读取的项目数第二个 x 项目大小(四舍五入到最接近的 KB)

Units of Capacity required for reads* = Number of item reads per second x item size (rounded up to the nearest KB)

  • 如果您使用最终一致性读取,就每秒读取而言,您将获得两倍的吞吐量.

根据您的示例问题,如果您想每秒读取 10KB 的数据,则需要配置 10 个读取单元.无论是对 1 KB 数据发出 10 次请求,还是对 10 KB 数据发出单个请求,都没有关系.您被限制为 10KB/秒.

Per your example question, if you want to read 10KB of data per second you'll need 10 Read Units provisioned. It doesn't matter if you make 10 requests for 1 KB of data or if you make a single request for 10 KB of data. You're limited to 10KB/second.

请注意,所需的读取容量单位数已确定通过每秒读取的项目数,而不是 API 的数量来电.例如,如果您需要每秒从您的表,如果你的项目是 1KB 或更少,那么你需要 500 个单位读取容量.500个单独的GetItem没关系调用或 50 个 BatchGetItem 调用,每个调用返回 10 个项目.

Note that the required number of units of Read Capacity is determined by the number of items being read per second, not the number of API calls. For example, if you need to read 500 items per second from your table, and if your items are 1KB or less, then you need 500 units of Read Capacity. It doesn’t matter if you do 500 individual GetItem calls or 50 BatchGetItem calls that each return 10 items.

对于您的 20 个用户示例,请注意数据会四舍五入到最接近的 KB.因此,即使您的 20 个用户请求 0.5 KB 的数据,您也需要 20 个读取单元来同时为所有用户提供服务.如果您只有 10 个读取单元,那么其他 10 个请求将被限制.如果您使用 Amazon DynamoDB 库,它们具有自动重试逻辑以再次尝试请求,因此它们最终应该得到服务.

For your 20 user example, keep in mind that data is rounded up to the nearest KB. So even if your 20 users request 0.5 KB of data, you'll need 20 Read Units to service all of them at once. If you only have 10 read units, then the other 10 requests will be throttled. If you use the Amazon DynamoDB libraries, they have auto-retry logic baked in to try the request again so they should eventually get serviced.

对于您关于 100 个用户的问题,其中一些请求可能只是被限制并且重试逻辑最终可能会失败(代码只会在停止尝试之前重试请求多次) - 所以您需要准备好处理来自 DynamoDB 的 400 个响应代码并做出相应反应.在使用 DynamoDB 时监控您的应用程序并确保您不会在应用程序关键事务上受到限制,这一点非常重要.

For your question about 100 users, some of those requests may simply be throttled and the retry logic may eventually fail (the code will only retry the request so many times before it stops trying) - so you need to be ready to handle those 400 response codes from DynamoDB and react accordingly. It's very important to monitor your application when you use DynamoDB and ensure you aren't going to be throttled on app critical transactions.

关于定价的最后一个问题 - 您按小时支付预订费用.如果您保留了 1000 个读取单元,而您的网站完全没有流量,那太糟糕了,您仍然需要为这 1000 个读取单元按小时付费.

Your last question about pricing - you pay hourly for what you reserve. If you reserve 1000 Read Units and your site has absolutely no traffic, then too bad, you'll still pay hourly for those 1000 Read Units.

为了完整性 - 请记住,吞吐量是按表提供的.因此,如果您有 3 个 DynamoDB 表:用户、照片、朋友,那么您必须为每个表预置容量,并且您需要确定适合每个表的容量.在这个简单的示例中,也许照片在您的应用程序中的访问频率较低,因此与您的用户表相比,您可以提供更低的吞吐量.

For completeness - keep in mind that throughput is provision PER TABLE. So if you have 3 DynamoDB tables: Users, Photos, Friends then you have to provision capacity for each table, and you need to determine what is appropriate for each table. In this trivial example, perhaps Photos is accessed less frequently in your app so you can provision lower throughput compared to your Users table.

最终一致的读取非常适合节省成本,但您的应用必须设计为能够处理它.最终一致读取意味着如果您更新数据并立即尝试读取新值,您可能无法取回新值,它可能仍会返回之前的值.最终,如果有足够的时间,您将获得新的价值.由于不能保证读取最新数据,因此您支付的费用更少 - 但如果您设计得当,那是可以的.

Eventually consistent reads are great for cost saving but your app has to be designed to handle it. An eventually consistent read means that if you update data and immediately try to read the new value, you may not get the new value back, it may still return the previous value. Eventually, with enough time, you'll get the new value. You pay less since you aren't guaranteed to read the latest data - but that can be OK if you design appropriately.

这篇关于Dynamodb 读写单元的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆