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 of 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 inserts are written to memory first, then to the database.

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

Answer 1

You can read this answer to understand the use of MongoDB you can de-normalize and flatten 6 tables into just 2 tables/collections and minimizes my queries to potentially just one 1 query

But you can easily query MySQL for 6 tables worth of information related to a single blog post with a single properly crafted SQL statement.

Answer 2

You can use MongoDB on the following points:

1. Schema-less design
2. Scalability in handling huge amount of data
3. Rapid replicates with high availability characteristic
4. Sharding allows linear and scale-out growth with or without running out of budget
5. Support big write load
6. Use of Data locality for query processing