Thanks for the summary George, interesting. Cheers Simon
On Thursday, 19 January 2012 at 18:58, George Burt wrote: > I was excited by it until I tried to see a use for it. The index is almost > only a key store index. But you can have a very simple second index key. > You can only find the second ken if you know the first. If your first key > is the a customer and the second key is a date, then you can find all the > documents for a customer. And you can find all the docs for a customer for > a particular date. But you cannot find out who all posted on a particular > date. Think ["cust1234","10-10-2012_001"] where the composite has to be > unique (primary key). > > But it is very fast. Think Redis if you have an EC2 machine in the same > area as the DynamoDB (LAN speed). But, they throttle it to only allow the > maximum requests you have paid for. But it is hard to pay for a cloud > instance of Redis that has 50 gigs of storage, where it only costs $50 per > month with DynamoDB. So the throughput is slower than Redis but the > datasize can be much bigger. > > A penny per hour buys you a max of 50 docs per second. > > You can raise the max per second any time you like, but it has to stay at > that rate for 24 hours. > > This throttling is not too bad because you can raise it to any level at > anytime, which is very, very powerful. In an instant, you could raise it > to 100k units, which would give you 5 million reads per second and 1 > million writes. And it would actually deliver these speeds! Of course, it > would cost you a minimum of $24,000 (and that is only if you dialed it back > down, otherwise it is $24,000 per day.) > > Still, for $72 per month, you could get a max of 500 reads per and 100 > writes. But, the problem is that you payload is limited to 1k. Well, > actually, if you had a document that was 500k, it would consume the entire > second's worth of capacity. This works out to 1.8 gigs of theoretical > output per hour. In reality, the actual out put would be far lower. > Clearly you can't move much data economically with this. > > Storage is also a lot more expensive than S3 (roughly 8 or 9 times as much). > > Also, it is a no-brainer in the sense that you don't have to worry about > anything except setting the dial at what you need. It is very safe, > redundant and is supposed to always have consistent performance at any > scale. > > I think on any economical sized installation, couch on an ec2 instance will > out perform DynamoDB (because of the throttling) and you can store > information for a fraction of the cost. And with DynamoDB, you don't > really need replication. > > So, I would say DynamoDB falls in between Redis and CouchDB. > > George > > > On Thu, Jan 19, 2012 at 9:51 AM, Arek Stryjski <[email protected] > (mailto:[email protected])>wrote: > > > On Thu, Jan 19, 2012 at 01:19, Mark Hahn <[email protected] > > (mailto:[email protected])> wrote: > > > > > > http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html > > > > Wow it is this Dynamo! > > > > Thanks for link, > > Arek > > > > > > > -- > George Burt > President > TrueShot Enterprises, LLC. > (386) 208-1309 > Fax (213) 477-2195 > www.TrueShot.com (http://www.TrueShot.com) > 12756 92nd Ter > Live Oak, FL 32060 > >
