DynamoDB - Parallel Scans, 4x Cheaper Reads, Other Good News(aws.typepad.com)
aws.typepad.com
DynamoDB - Parallel Scans, 4x Cheaper Reads, Other Good News
http://aws.typepad.com/aws/2013/05/amazon-dynamodb-parallel-scans-and-other-good-news.html
2 comments
We've been considering deploying a few things on dynamo within the near future. Anybody with some experience have any recommendations or words of caution?
Make sure you can afford it - DynamoDB can get very expensive fairly quickly as data size grows. Admittedly I last used it over a year ago and for a small company - but eventually we had to pull the plug because of the high costs.
I'd recommend estimating how much you think it will cost you, and then 10X that value. If that value is going to be hard to cover, stick with something else. If you're working for a Fortune 500 however, Dynamo is very nice.
I'd recommend estimating how much you think it will cost you, and then 10X that value. If that value is going to be hard to cover, stick with something else. If you're working for a Fortune 500 however, Dynamo is very nice.
What is expensive about Dynamo exactly? Read, storage? Something else?
Understand your data hotspots -- just because it is in Dynamo and you have moved the slider all the way over to "20,000 IOPS" doesn't mean anything if DDB has partitioned all your data into a single shard behind the scenes -- you'll peak at 3,000 IOPS (for example).
Unfortunately you _still_ need to be aware of how you plan on querying your data to maximize the performance.
This is one of the most common questions/comments I see in the forums.
More info: http://docs.aws.amazon.com/amazondynamodb/latest/developergu...
Also be aware that leveraging the Local Secondary Indexes _does_ enforce a 10GB limit on items with the same hashkey, see the last section here: http://docs.aws.amazon.com/amazondynamodb/latest/developergu...
Unfortunately you _still_ need to be aware of how you plan on querying your data to maximize the performance.
This is one of the most common questions/comments I see in the forums.
More info: http://docs.aws.amazon.com/amazondynamodb/latest/developergu...
Also be aware that leveraging the Local Secondary Indexes _does_ enforce a 10GB limit on items with the same hashkey, see the last section here: http://docs.aws.amazon.com/amazondynamodb/latest/developergu...
I've been using DynamoDB in production to power a large API company which handles thousands of requests per second -- we absolutely love it.
Our stack is on top of EC2, and the DynamoDB read latency is extremely low (1ms -> 10ms per read) -- using it as a data store means you don't even need a caching layer (memcached, etc.) since it's equally as fast, and all data is persistent (and you have no room limits).
I'd highly recommend it to anyone.
Also: if you're using Python, the dynamodb-mapper library is a great (stable) tool for working with DynamoDB.
Our stack is on top of EC2, and the DynamoDB read latency is extremely low (1ms -> 10ms per read) -- using it as a data store means you don't even need a caching layer (memcached, etc.) since it's equally as fast, and all data is persistent (and you have no room limits).
I'd highly recommend it to anyone.
Also: if you're using Python, the dynamodb-mapper library is a great (stable) tool for working with DynamoDB.
My experience with DynamoDB has been the same - very fast access. However I'd recommend checking out ElastiCache - stick that in front of DynamoDB and cache all you can - accessing ElastiCache is much cheaper than accessing DynamoDB.
Isn't this old news already? it happened a week ago and I think Jef Bar posted it to HN at the time.