I posted a comparison to Cassandra here: http://news.ycombinator.com/item?id=3480480
Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
71–80 of 135 posts
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#72Earlier quoted context omitted.
Capacity Units strike me as a big improvement (for the user) over Machine Hours, because it's very clear how a given usage pattern will translate into Capacity Units. I can predict how many Capacity Units I'll need. I've gotten badly burned over seemingly simple queries using unexpectedly high Machine Hours in SimpleDB.
My understanding is that DynamoDB's Capacity Units are just a query throttle, and you get charged based on the throttle you set, whether or not you use that capacity. It also looks like you can still have one query that consume many, many Capacity Units (e.g. table scans). SimpleDB's Machine hours are basically the same units, but without the throttle. So, from a technical and value viewpoint, it's a huge step backwa…
True, it's pay-for-capacity and that's worse for the user. On the flip side, the constant factor seems to be about 20x cheaper (caveat: this is based on my personal experience with SimpleDB; since Amazon doesn't seem to explain how "box usage" is computed, I don't know how broadly applicable my experience is).
The big plus for Capacity Units is that Amazon actually provides a deterministic model for figuring out what you'll be charged for a given query.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#73This still seems a bit expensive to me for an application that would require thousands of writes per second? ie. 5k writes per second is ~$120/day. Using this for performance based analytics for example would seem out of the realm of reason for the moment.
Can you explain your use case a bit more? I'm having a hard time imagining something that does ~430M DB writes/day but can't easily afford to pay $120 for those writes.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#74Earlier quoted context omitted.
My understanding is that DynamoDB's Capacity Units are just a query throttle, and you get charged based on the throttle you set, whether or not you use that capacity. It also looks like you can still have one query that consume many, many Capacity Units (e.g. table scans). SimpleDB's Machine hours are basically the same units, but without the throttle. So, from a technical and value viewpoint, it's a huge step backwa…
True, it's pay-for-capacity and that's worse for the user. On the flip side, the constant factor seems to be about 20x cheaper (caveat: this is based on my personal experience with SimpleDB; since Amazon doesn't seem to explain how "box usage" is computed, I don't know how broadly applicable my experience is). The big plus for Capacity Units is that Amazon actually provides a deterministic model for figuring out what…
Ah - that is a fair point, transparency of the "unit". The "box usage" formula was reverse-engineered and shown to be fairly simple:
http://www.daemonology.net/blog/2008-06-25-dissecting-simple...
This is a big step forward in transparency, although I would suggest that SimpleDB's pricing shouldn't have been obscured in the first place.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#75"Amazon DynamoDB stores data on Solid State Drives (SSDs)" This is big.
When Amazon notes "SSD," from a client's perspective, it is only marketing. The storage media matter when you are managing your own hardware. The storage media do not matter in SaaS. For example, the storage media could be floppys and you would get satisfactory performance if there was a memory cache. Similarly you could get poor performance with SSD media if the networking layer(s) were slow. Similarly if the storage media were fault-likely CD's that wouldn't matter either, to us, because of the data replication performed in "the service." What matters in this case is the reported and actual latency.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#76I hope this means an SSD option for RDS is coming soon.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#77Earlier quoted context omitted.
For one, it responds quicker than Riak: Riak has (cold) response times of about 300ms, while this service claims single-digit ms response times. Also setting up Riak is not exactly trivial, and using this service outsources that hassle.
Could you clarify what you mean by "cold response time of 300ms"? Cold as in requesting data that hasn't yet been cached in RAM? How good does it get once the cache is warm?
Yes, that's what I meant with 'cold'. For recently requested data, that is cached in RAM, the response can be as quick as 3 ms.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#78Earlier quoted context omitted.
Could you clarify what you mean by "cold response time of 300ms"? Cold as in requesting data that hasn't yet been cached in RAM? How good does it get once the cache is warm?
Yes, that's what I meant with 'cold'. For recently requested data, that is cached in RAM, the response can be as quick as 3 ms.
Thanks, that's useful to know.
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#79I would love the option to add N index (at cost). My guess is they will add options for additional indexes in the future...everyone needs start somewhere. Even at Amazon's size and scale.
> Even at Amazon's size and scale. At Amazon's size and scale, it's all the more important that you start with something simple with well-understood performance characteristics from day one. AWS doesn't really get a grace period during which they get to fix scalability problems.
Exactly, compare this to SimpleDB. SimpleDB started out with an advanced query language that let query and filter your results in all sorts of ways. And guess what? SimpleDB is still limited to 10 GB per domain (aka, database). Want to horizontally scale? The official suggestion is to shard your data across domains. This is a really messy solution because you have to preshard based on estimated database size and resharding is nearly impossible (you'd have to rewrite your entire DB).
AppEngine went the other route and provided a very simple database API at first and all queries had to be range scans over an index. Any query you wanted to perform had to be precalculated by defining a composite index and some things (like inequalities on multiple fields) weren't supported. Over time they've built upon their basic database and added features such as a zigzag merge join algorithm which lets you perform queries that were otherwise impossible with a given set of indexes.[1]
I bet DynamoDB will be going the AppEngine route by starting with a simple, scalable base which can be used to build more advanced query engines and features.
1. http://code.google.com/appengine/articles/indexselection.htm...
Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS
#80Earlier quoted context omitted.
It seems as if this site is a user-edited wiki, and there are a lot of things that need to be filled in (in case anybody is up to speed on DynamoDB and wants to help). For instance, the Map/Reduce entry was still '?' when I wrote this.
And Big Table (or at least GAE) does support transactions.
[deleted]