Live data from Hacker News

Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

allthingsdistributed.com

61–70 of 135 posts

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#61
post #32

Earlier quoted context omitted.

No. They offer the equivalent of Amazon S3, SimpleDB and SQS, but nothing comparable to this

Can you elaborate how this is different and not comparable? Azure's table service offers the same automatic partition management, unlimited per-table scalability, composite keys, range queries, and availability guarantees. The linked paper goes into more details.

Besides the points I already complained about before... How about 200ms response times even when performing a query using the Row & Partition Keys. I'm not sure if by composite keys you were referring to something other than the RK & PK because those are the only indexes you get.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#62
post #49

Trying to read thru all the hype, this looks like Riak hosted on machines with SSDs, with less features, and a nice billing system in front of it. Of course for people who want a hosted solution, the fact that it is hosted, is what gives it a lot of value. There haven't been a lot of hosted NoSQL databases, at least on this scale and availability, out there. But technologically, what's new here? Is there anything her…

As you and others have pointed out, hosting + SSDs + synchronous replication across availability zones counts for a lot. If DynamoDB lives up to the hype, it could be a huge step forward in the world of "don't have to think about it" data storage.

DynamoDB does have at least one significant feature not provided by Riak -- range scans. This makes many common access patterns much easier to implement efficiently. Still, as you suggest, there don't appear to be any fundamental technical advances here. The advances are in the service model and operation.

And there are, of course, many limitations. (Just to name a few: items -- i.e. rows -- can't exceed 64K; queries don't use consistent reads; seemingly no atomic update of multiple items.) It's miles ahead of SimpleDB, but still not nearly as flexible as many of the existing NoSQL databases. If Amazon lives up to past performance, they'll make steady improvements, but slowly.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#63

Pricing: $0.01 per hour for every 10 units of Write Capacity and $0.01 per hour for every 50 units of Read Capacity.

It is amusing that was positioned to try to address SimpleDB's problem of "pricing complexity". These aren't those complicated "Machine Hours", they're "Capacity Units"! As someone who has grappled in the past and is grappling again with the issues of pricing a database-as-a-service though, this is very much a non-trivial issue. If you have nice scaling characteristics and you want to charge the minimal price, your p…

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.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#64
post #63

Earlier quoted context omitted.

It is amusing that was positioned to try to address SimpleDB's problem of "pricing complexity". These aren't those complicated "Machine Hours", they're "Capacity Units"! As someone who has grappled in the past and is grappling again with the issues of pricing a database-as-a-service though, this is very much a non-trivial issue. If you have nice scaling characteristics and you want to charge the minimal price, your p…

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 backwards (pay for capacity rather than for usage), but I'm learning that psychology is perhaps just as important here.

It seems like what you really want is a throttle with per-query charging, to cap your bill. Probably you'd much prefer not to be forced to pay your cap every month, but I don't think that's being offered.

(Edit: Downvotes? Am I wrong here? If so, please contribute to the discussion and tell me why!)

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#65
post #53
post #49

Trying to read thru all the hype, this looks like Riak hosted on machines with SSDs, with less features, and a nice billing system in front of it. Of course for people who want a hosted solution, the fact that it is hosted, is what gives it a lot of value. There haven't been a lot of hosted NoSQL databases, at least on this scale and availability, out there. But technologically, what's new here? Is there anything her…

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?

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#66

Very interesting that there's no mention of the CAP theorem here, despite Amazon's heavy reliance on it in the past when marketing their non-relational stuff.

I'm very curious about this too. I posted in another thread:

"Doesn't that just sweep the latency tradeoff under the rug, or is flash making up the difference? What about the availability tradeoff? (I like the formulation here, consistency vs availability and consistency vs latency, as opposed to CAP which never made sense as a 3-way tradeoff: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-an...)

http://news.ycombinator.com/item?id=3480805

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#67
post #63

Earlier 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…

Presumably if your traffic is predictable you could reduce the cap during quieter periods.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#68

Earlier quoted context omitted.

It's a database, so you can always get your data out again.

It's a non-standard (NoSQL) database. Even SQL databases, despite years of standardization and efforts at poaching each other's customers, still have rough edges that make moving between different SQL database products non-trivial. Just because you can get your data out doesn't mean you're not locked in to all of SimpleDB/DynamoDB's quirks, of which there will be a lot more because it's not following a standard appro…

DynamoDB and SimpleDB are also a lot simpler than SQL databases. As far as I can tell, DynamoDB is a key/value DB with support for ranges and MapReduce, and not dissimilar to other NoSQL databases like Riak.

There may be instances where large datasets are hard to migrate from DynamoDB, but overall it doesn't look to me like lock-in would be that much of a problem, assuming you have a decent abstraction layer.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#69

Earlier 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…

Presumably if your traffic is predictable you could reduce the cap during quieter periods.

True, but I then see this as a step backwards vs SimpleDB's pricing model.

Re: Amazon DynamoDB – a Fast and Scalable NoSQL Database Service from AWS

#70
post #9

Fast, Consistent, Secure & Replicated. Game changed.

Not really if you pay attention to the set of NoSQL DB's available already. They are just hosting their own now.

Would be interested in details about any with Strong Consistency, decent replication across fault areas, which get the same level of performance (single digit ms) at a cost equivalent to dynamodb.

Quite a lot can be done with smart use of hugely scalable simple key-value maps.

Post reply on HN