The problem with autoscaling DynamoDB is that every time you scale up they shard your table into more partitions but they never merge them back when you scale down. You end up with less throughput per partition once you've scaled back down. The only way to correct this is to completely recreate your table. Does Neptune take this into consideration?
@chadboyda: Good point, per-partition throughput reduces as the #partitions increases but if your load is uniform, it wouldn't impact your overall throughput. Neptune does take this into consideration, although we can't change the inherent DynamoDB behavior. We talk about how to address this problem proactively in our best practices. Our recommendation: create table with 12-month peak throughput and then immediately bring it down to what you want right now. If the table is already created, bump up the throughput to the 12-month peak just once and then bring it down to what you want right now. In either case, this will ensure DynamoDB doesn't change partitions internally when you scale up and scale down within in 12-month peak range. But if you range goes beyond the peak, you'd still run into the problem that you'd described. We've seen in many case, people can predict the highest peak with reasonably high confidence. (think database world where they'd always known this in the past for many years).
Very reliable and already bringing down our DynamoDB cost. We have a highly varying traffic, previously we had to manually up/down-scale to prevent rate limit exceeded. For most part of the day we had very low traffic and we do not want to pay high DDB cost. Autoscaling is already saving us money and also freeing us of the manual responsibility.
We've been using Neptune to autoscale our DynamoDB throughput for a while now. It's been super reliable and has kept our costs low without us having to think about anything.
10 comments
[ 4.5 ms ] story [ 37.8 ms ] threadRefer to our first best practice point for more details: http://blog.neptune.io/dos-and-donts-of-dynamodb-autoscaling...