A Tale of Two Databases, Revisited: DynamoDB and MongoDB 73
Questioning his belief in relational database dogma, new submitter Travis Brown happened to evaluate Amazon's Dynamo DB and
MonogDB. His situation was the opposite of Jeff Cogswell's: he started
off wanting to prefer Dynamo DB, but came to the conclusion that the
benefits of Amazon managing the database for him didn't outweigh the
features Mongo offers. From the article:
"DynamoDB technically isn't a database, it's a database service.
Amazon is responsible for the availability, durability, performance,
configuration, optimization and all other manner of minutia that I
didn't want occupying my mind. I've never been a big fan of managing
the day-to-day operations of a database, so I liked the idea of taking
that task off my plate. ... DynamoDB only allows you to query against the primary key, or the primary key and range. There are ways to periodically index your
data using a separate service like CloudSearch, but we are quickly
losing the initial simplicity of it being a database
service. ... However, it turns out MongoDB isn't quite as difficult as
the nerds had me believe, at least not at our scale. MongoDB works as
advertised and auto-shards and provides a very simple way to get up
and running with replica sets."
His weblog entry has a few code snippets illustrating how he came to his
conclusions.
MongoDB is broken by design. (Score:5, Interesting)
Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design [hackingdistributed.com].
Amazon Pricing problems (Score:5, Interesting)
If my sites really grew I would even contemplate going a step further and running my own physical servers. The joy of being able to reach out and jam USB sticks into them would be pretty good.
Re:MongoDB is broken by design. (Score:3, Interesting)
Mongo fanboys. They're a menace to society. I worked at a trading firm that was infested with them, and they tried making Mongo a dependency in all parts of our codebase. It's nasty stuff, polluting your code with macros if you aren't extremely careful about #include order, running the server wreaks havoc with I/O on a box, and it really didn't perform that well when trying to extract the kinds of data sets needed for useful analysis.
apples and oranges (Score:5, Interesting)
Comparing DynamoDB with MongoDB is like comparing apples and oranges. The only thing the two share in common really is the fact that neither supports SQL (and for that reason are called NoSQL databases). Their intended purpose is completely different which is why I found it strange that the author of the original Slashdot story would pit them against each other the way he did.
If DynamoDB is to be compared against another datastore, the most similar alternative would probably be Google App Engine's Datastore/big table.
Similarities between DynamoDB and GAE Datastore
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
Re:Amazon Pricing problems (Score:4, Interesting)
I have worked with amazon aws and with dedicated server providers. Amazon has been much faster and reliable.
Furthermore, the way to protect your life savings from a potential business failure is not through inefficient procurement practices. Just incorporate, otherwise you will be open to all kind of risks (must of it unknown to you, and uninsured)
Re:MongoDB is broken by design. (Score:4, Interesting)
Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design [hackingdistributed.com].
Speaking of which, the same back to you.
Did you know the author of the article you pointed to is a competitor and recommends his NoSQL Database called HyperDex as a reasonable alternative (although, he doesn't state he's the developer for HyperDex, nor does he state the fact that HyperDex is still in alpha and doesn't work properly)?
Nicely played Anonymous Coward!