When to use MongoDB

Question

I'm writing an application that doesn't necessarily need scaling abilities as it won't be collecting large amounts data at the beginning. (However, if I'm lucky, I could down the road potentially.)

I will be running my web server and database on the same box (for now).

That being said, I am looking for performance and efficiency.

The main part of my application will be loading blog articles. Using an RDBMS (MySQL) I will make 6 queries (2 of the queries being joins), just to load a single blog article page.

select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)

However, with MongoDB I can de-normalize and flatten 6 tables into just 2 tables/collections and minimizes my queries to potentially just one 1 query,

users
blogs
    ->blog_album
    ->blog_tags        
    ->blog_notes
    ->blog_comments
    ->blog_author_participants

Now, going with the MongoDB schema, there will be some data redundancy. However, hard drive space is cheaper than CPU/servers.

1.) Would this be a good scenario to use MongoDB?

2.) Do you only benefit in performance using MongoDB when scaling beyond a single server?

3.) Are there any durability risks using MongoDB? I hear that there is potential for loss of data while performing inserts - as insert are written to memory first, then to the database.

4.) Should this stop me from using MongoDB in production?

Answer 1

You would use MongoDB when you have a use case that matches its strengths.

Do you need a schema-less document store? Nope, you have a stable schema.

Do you need automatic sharding? Nope, you don't have extraordinary data needs or budget for horizontally scaling hardware.

Do you need map/reduce data processing? Not for something like a blog.

So why are you even considering it?