Reasons for and against moving from SQL server to MongoDB

Question

I know this is a big question and it's not a yes or no answer but we develop web apps and are looking into using MongoDB for our persistence solution. Combining MongoDB with NoRM for object storage.

What I want to ask is what pitfalls have you experienced with switching from SQL to mongo? When is mongo simply not the right solution and is mongodb's advantages enough to move development from SQL?

Solution 1

In my opinion the format of your data should be the primary concern when choosing a storage backend. Do you have data that is relational in nature? If so, can it and is it a good idea to model the data in documents? Data modeling is as important in a document database as in an relational database, it just done differently. How many types of objects do you have and how are they related? Can DBrefs in Mongodb do the trick or will you miss foreign keys so much it will be painful? What are your access patterns for the data? Are you just fetching data of one type filtered by a field value, or do you have intricate fetching modes?

Do you need ACID transactional integrity? Does the domain enforce a lot of constraints on the data? Do you need the scalability factor of a document database or is that just a "cool" thing to have?

What are your consistency and data integrity requirements? Some NoSQL solutions and MongoDB in particular are quite loose on the write consistency in order to get performance. NoSQL is no uniform landscape and other products, e.g. CouchDB has other characteristics in this department. Some are tunable too.

These are all questions that should go into the choice of storage.

Some Experiences

• Doing extensive reporting on the stored data can be harder when using MongoDB or any document database and some use cases have been combining RDBMS and document-db for that purpose.
• (Very) Different query model. MongoDB differs from other document-dbs too.
• Flexible to change data format/schema during development
• Unknown territory
• varying degree of maturity in drivers and frameworks
• Fast
• Simpler (in many ways) product and management tools (compared to many RDBMS products)
• No more impedance mismatch. The storage fits the data, not the other way around.
• Less friction and more direct access to data.
• Domain more tied to persistence (depending on the ORM "level" of NoRM, on how much it abstract away the backend. I haven't used NoRM so I can't answer that.)

Solution 2

cons

1. (the lack of / different vision on) durability (read http://www.mikealrogers.com/2010/07/mongodb-performance-durability)
2. No transactions
3. No constraints
4. Aggregation with MapReduce is slow and you need to write code for something like group-by
5. Reporting is harder, the developer defines the relations but business analysts can't build their own queries, they can't for example do a 'minus' ('except' in sql server lingo)

pros

1. you can easily add new 'columns' and 'tables'
2. speed
3. sharding (still beta)
4. document matches more closely to an object than a set of relational tables so mapping becomes easier
5. It broadens the mind

Solution 3

Your mileage may vary, but this is a quick graph I put together to compare the speed of updating multiple "table rows" (non-hierarchical flat document in MongoDB) with and without an index to give us an idea of how it would scale for our application.

Solution 4

I've been poking around with it a few days now. This is what I can say about it:

FOR:

• No more SQL statements
• Your database resembles your classes not the other way around
• Your "schema" is more flexible
• Scales well
• Very easy to get started with
• < opinion>It's cool< / opinion>

AGAINST:

• I'm currently trying to implement a custom Membership Provider And Role Provider for my mongo app but somehow my MemberShip user class has NULL fields when I try to retrieve it from mongo.
• Somewhere I've read about the C# driver that it's relatively young but stabilizing so expect some changes. (Although this wouldn't hold me back)

One thing i noticed that's missing from the tutorials: Initialise your lists inside your object otherwise it will throw an error while trying to .save(yourobj). The safest thing to do is write a constructor in your class that makes sure you don't have any NULL objects inside your object. This way you won't get an error if you forget something.

Solution 5

You might find a couple of pros and cons of using a NoSQL database (MongoDB included) in this Getting started with NoSQL. A quick summary would be: a different data model (think if a mapping from the object model to "this new model" is needed, will it work well), a different query model (MongoDB queries are pretty capable though when compared with others), no transactions (you have some atomic operations though).

Anyways, from my perspective the most important change is the data model and the way you are designing your app with this new approach.

View more solutions

Comments

[TTT]

You can do stored procs with MongoDb and people do use this feature: mattinsler.com/why-and-how-i-replaced-amazon-sqs-with-mongod‌​b

[You]

@TTT. You're right. Edited out now.

[Mickel]

+1. I've been struggling with lists in my POCOs for a while now, thanks for letting me know how it is supposed to work. Wasn't expecting to find the answer here :)

[Shawn Miller]

I've written a bunch of ASP.NET providers for MongoDB that you might be able to use: github.com/freshlogic/MongoDB.Web

[BanksySan]

Where did this graph come from?

[GroovyCakes]

My personal experimentation on my development machine... granted, some time ago, now.