Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Choosing a database service - mongohq vs dynamodb

Currently I am gathering information what database servce we should use. I am still very new to web development but we think we want to have a noSQL database.

We are using Java with Play! 2.

We only need a database for user registration.

Now I am already familiar with GAE ndb which is a key value store such as dynamoDB. MongoDB is a document db. I am not sure what advantages each solution has.

I also know that dynamoDB runs on SSD's and mongoDB is inmemory.

An advantage of mongoDB would be that Java Play! already "supports" mongodb.

Now we don't expect too much database usage, but we would need to scale pretty fast if our app grows.

What alternatives do I have? What pros/cons do they have? Considering:

  • Pricing
  • Scaling
  • Ease of use
  • Play! support?
like image 471
Maik Klein Avatar asked Jul 31 '12 14:07

Maik Klein


People also ask

Why would you choose an Amazon DynamoDB over other database solutions?

Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale. DynamoDB offers built-in security, continuous backups, automated multi-Region replication, in-memory caching, and data import and export tools.

When should you not use DynamoDB?

Even though the solution has many benefits, one of the major drawbacks is that the solution lacks an on-premise deployment model and is only available on the AWS cloud. This limitation does not allow users to use DynamoDB for applications that require an on-premise database.

How do I choose between RDS and DynamoDB?

The significant difference between these two services is that Amazon RDS is relational, whereas DynamoDB is a NoSQL database engine. In terms of storage size, DynamoDB stands out with its ability to support tables of any size. But with RDS, the storage size changes based on the database engine we use.

What is better than DynamoDB?

MongoDB stores query data in RAM which means query performance is significantly better than what you would find with Dynamo. So if speed is a concern for your app, MongoDB may be the best choice.


2 Answers

(Disclosure: I'm a founder of MongoHQ, and would obviously prefer you choose us)

The biggest difference from a developer perspective is the querying capability. On DynamoDB, you need the exact key for a given document, or you need to build your keys in such a way that you can use them for range based queries. In Mongo, you can query on the structure of the document, add secondary indexes, do aggregations, etc.

The advantage of doing it with k/v only is that it forces you to build your application in a way that DynamoDB can scale. The advantage of Mongo flexible queries against your docs is that you can do much faster development, even if you discount what the Play framework includes. It's always going to be quicker to do new development with something like Mongo because you don't have to make your scaling decisions from the get go.

Implementation wise, both Mongo and DynamoDB can grow basically unbounded. Dynamo abstracts most of the decisions on storage, RAM and processor power. Mongo requires that you (or someone like us) make decisions on how much RAM to have, what kind of disks to use, how to managed bottlenecks, etc. The operations hurdles are different, but the end result is very similar. We run multiple Mongo DBs on top of very fast SSDs and it works phenomenally well.

Pricing is incredibly difficult to compare, unfortunately. DynamoDB pricing is based on a nominal per GB fee, but you pay for data access. You need to be sure you understand how your costs are going to grow as your database gets more active. I'm not sure I can predict DynamoDB pricing effectively, but I know we've had customers who've been surprised (to say the least) at how expensive Dynamo ended up being for the stuff they wanted to do.

Running Mongo is much more predictable cost-wise. You likely need 1GB of RAM for every 10GB of data, running a redundant setup doubles your price, etc. It's a much easier equation to wrap your head around and you're not in for quite as nasty of a shock if you have a huge amount of traffic one day.

By far the biggest advantage of Mongo (and MongoHQ) is this: you can leave your provider at any time. If you get irked at your Mongo provider, it's only a little painful to migrate away. If you get irked at Amazon, you're going to have to rewrite your app to work with an entirely different engine. This has huge implications on the support you should expect to receive, hosting Mongo is competitive enough that you get very good support from just about any Mongo specific company you choose (or we'd die).

I addressed scaling a little bit above, but the simplest answer is this: if you define your data model well, either option will scale out just about as far as you can imagine you'd need to go. You are likely to not do this right with Mongo at first, though, since you'll probably be developing quickly. This means that once you can't scale vertically any more (by adding RAM, disk speed, etc to a single server) you will have to be careful about how you choose to shard. The biggest difference between Mongo and Dynamo scaling is when you choose to make your "how do I scale my data?" decisions, not overall scaling ability.

So I'd choose Mongo (duh!). I think you can build a fantastic app on top of DynamoDB, though.

like image 193
MrKurt Avatar answered Sep 27 '22 02:09

MrKurt


As you said, mongoDB is one step ahead among other options, because you can use morphia plugin to simplify DB interactions(you have JPA support as well). Play framework provides CRUD module (admin console) and secure module as well (for your overall login system), so I strongly suggest you to have a look at' em.

like image 23
Alpay Avatar answered Sep 27 '22 02:09

Alpay