4 ms·

Why would there be throttling? A WCU is 1KB per second.

by vp8989 8y ago

forrestbrazeal 8y ago
Prior to the release of on-demand scaling, you had to provision your capacity units in DDB, and even once they introduced autoscaling there was always the risk that a burst of activity over your set threshold would lead to some throttled calls. My point isn't about the specific numbers so much as that it's nice to see that scaling finally being managed smoothly - one less thing to worry about.
- vp8989 8y ago
  https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/ https://aws.amazon.com/blogs/database/how-amazon-dynamodb-ad... They initially implemented capacity units to be spread evenly at the partition level and now they have finally implemented it to work at the table level (which is how they sell it and how they talk about it). Big whoop, you still have to ask daddy if you want to write at more than 80MB/s per account.
- tracker1 8y ago
  I was first playing with dynamo when the autoscaling feature was released... it wasn't great at the time (neither was manually scaling). It's nice to see the feature is working better now.
  - shortj 8y ago
    To be clear, the auto-scaling with provisioned capacity still lags behind demand quite a bit. The new on-demand pricing makes this a non-issue but you pay for it at much higher cost at any sort of sustained load. https://serverless.com/blog/dynamodb-on-demand-serverless/ https://serverless.com/blog/dynamodb-on-demand-serverless/ has a good breakdown of when to use on-demand vs provisioned capacity.
    - vp8989 8y ago
      Paying in terms of write units adds so much complexity to what would otherwise be dead simple code. Normally, you just write to a data store until it's done. The faster the disks the less time it takes. Now, writes can "fail" so you need to wait/retry or put it back on a queue to reprocess when you have write units available (both of those and the associated logging will cost you $ on AWS).

Why would there be throttling? A WCU is 1KB per second.

by vp8989 8y ago

Why would there be throttling? A WCU is 1KB per second.

Prior to the release of on-demand scaling, you had to provision your capacity units in DDB, and even once they introduced autoscaling there was always the risk that a burst of activity over your set threshold would lead to some throttled calls. My point isn't about the specific numbers so much as that it's nice to see that scaling finally being managed smoothly - one less thing to worry about.

vp8989 8y ago
https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/ https://aws.amazon.com/blogs/database/how-amazon-dynamodb-ad... They initially implemented capacity units to be spread evenly at the partition level and now they have finally implemented it to work at the table level (which is how they sell it and how they talk about it). Big whoop, you still have to ask daddy if you want to write at more than 80MB/s per account.
tracker1 8y ago
I was first playing with dynamo when the autoscaling feature was released... it wasn't great at the time (neither was manually scaling). It's nice to see the feature is working better now.
- shortj 8y ago
  To be clear, the auto-scaling with provisioned capacity still lags behind demand quite a bit. The new on-demand pricing makes this a non-issue but you pay for it at much higher cost at any sort of sustained load. https://serverless.com/blog/dynamodb-on-demand-serverless/ https://serverless.com/blog/dynamodb-on-demand-serverless/ has a good breakdown of when to use on-demand vs provisioned capacity.
  - vp8989 8y ago
    Paying in terms of write units adds so much complexity to what would otherwise be dead simple code. Normally, you just write to a data store until it's done. The faster the disks the less time it takes. Now, writes can "fail" so you need to wait/retry or put it back on a queue to reprocess when you have write units available (both of those and the associated logging will cost you $ on AWS).