Comment Will these guys get 41 months in jail too? (Score 3, Insightful) 79
If the justice department or any company affected by this wants to, they could claim Computer Fraud and Abuse.
Yet somehow I doubt the "researches" will get any jail time.
Differences between DynamoDB and GAE Datastore
One major difference between GAE Datastore and DynamoDB is that GAE supports single and multi property indexes while Dynamo does not support indexes at all aside from a table's primary key. GAE datastore supports efficient queries that use the indexes (if you try to run a query that does not use an index it will fail) along with some basic predicates like equality, inequality, greater than and less than expressions, etc. In DynamoDB, if you want an index, you have to build it yourself in a supplementary table.
GAE Datastore Self-Merge Joins
GAE datastore also supports what they call "self-merge joins" which are super powerful. I don't know if any other schema-less datastore has this.
DynamoDB Purpose
The main reason one would use DynamoDB is when they need scalable throughput; in other words, when your needs for write and/or read speeds fluctuate drastically and when you know you will occasionally spike to extremely high throughput requirements. For times when you expect to have huge throughput for writing, you can pay to scale for that small period of time and then you can reduce your costs by throttling down to a more sane limit. You can run MapReduce jobs over DynamoDB tables using Amazon Elastic Map Reduce. And you can also copy a DynamoDB table into an Amazon Redshift "warehouse"; once the data is copied into Redshift you can run efficient SQL queries over it and Redshift can efficiently do that over petabytes worth of data.
MongoDB
MongoDB, on the other hand, is a "schema-less," document oriented database that is good for organizing clumps of information as a single "item" in the datastore. So for example, you can have a single book document which contains nested information about its authors, keywords, reader reviews, and statistics about word usage in the book....all in a single mondodb "record." This is essentially impossible in DynamoDB (unless you do what the previous article's author did by storing an object graph as JSON within a single column but this is kind of misuse). Mongo also provides indexes on properties in those documents (even nested properties) similar to traditional RDMS indexes on table columns. It has very good support for clustering and it's very easy to setup. MongoDB is very fast therefore it is good for applications that intend to be very write-intensive. I believe this is one of the main reasons that people compare it to Dynamo. However, it is easier to scale Dynamo since you don't need to standup any additional servers yourself. MongoDB does not support transactions; operations on a single document are atomic but the database does not provide any native mechanisms for performing an atomic modification to two or more documents (you would basically have to implement 2 phase commit yourself). MongoDB has a powerful query language based on javascript/json but personally, I find it extremely painful to use compared to SQL.
For the TLDR-crowd:
I am not familiar with CouchDB but I think it would belong in the MongoDB family.
it's not any different than a restaurant declining to take a reservation because they're full. Respectable businesses do this all the time. It's perfectly reasonable.
If AT&T is either unwilling or unable to provide network support to keep up with consumer demand for the iPhone, then their exclusivity deal should be nullified. I'm surprised the contract they signed with Apple does not include some provisions for dealing with this sort of situation.
This is exactly why exclusivity deals are bad. People in NY are now stuck with either buying an iPhone and having shitty service or not buying an iPhone.
Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker