A Tale of Two Databases, Revisited: DynamoDB and MongoDB

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.

Comments

MongoDB is broken by design.

[Anonymous Coward]

Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design.

Re:MongoDB is broken by design.

[_merlin]

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.

Re:MongoDB is broken by design.

[stephanruby]

Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design.

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!

Amazon Pricing problems

[EmperorOfCanada]

I am sufficiently freaked out by Amazon pricing that I just can't use it. I have two simple fears. One is that I screw up with my code and do a bazillion transactions per second that result in either a ridiculous bill or exhausting my budget resulting in my service having to shut down. Secondly I am scared that some kind of DDOS would blow through my life savings. I much prefer the control of having my own dedicated servers with extremely fixed costs. It might not be the most efficient scheme but with the service I use they can throw extra servers on pretty quickly and I can set them up in a flash. So yes I am potentially hosed if Opera or Slashdot feature my work but I sleep like a baby knowing that amazon won't be billing me a house tomorrow. I even tried out their free service and while loving it was deathly afraid of getting billed.

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:Amazon Pricing problems

[MariusBoo]

Actually there is no reason to be freaked out by their pricing. Just buy the number of instances that you need (one for example) and don't set up any auto-scaling. This way if you get slashdoted your instance will just fail as a normal server would and you will incur no charges. Also no service...

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)

apples and oranges

[bennini]

We are heavy users of MySQL (Percona) and MongoDB at my work. Recently I have been researching DynamoDB because of a specific use-case. A side project I run uses Google App Engine with Datastore (aka bigtable) for persistence.

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

• both use "schema-less" table structures for storing items (i.e. two items in a single table can have different columns)
• both support relatively simple primary keys (GAE only allows a single column PK, Dynamo allows a pseudo-two-column PK)
• both encourage only efficient queries (GAE forces it, Dynamo allows full table scans but they are highly discouraged)
• both support list properties (a column with multiple string values for example)
• both are hosted "in the cloud" and scale horizontally almost infinitely
• both are billed based on reads/writes + total stored data (Dynamo has an extra dimension to cost which is throughput)
• both have very limited support for referential integrity between items (GAE supports "embedded" entities and recently added basic relationships but nothing like many to many)
• GAE supports transactions across entities within the same group (i.e. on the same server) and recently added support for XA transactions (tx's across entities in different groups/on different servers). Dynamo does not have transactions but it supports some atomic operations on an individual item like compare and get.

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