Reasons and against switching from SQL server to MongoDB

Question

I know this is a big question and it is not a yes or no answer, but we are developing web applications and exploring the use of MongoDB for our persistence solution. Combining MongoDB with NoRM to store objects.

What I want to ask is what did you experience when switching from SQL to mongo? When is mongo simply not the right solution and is mongodb an advantage sufficient to move development from SQL?

Answer 1

In my opinion, the format of your data should be the main problem when choosing a repository. Do you have data that is relational in nature? If so, can it and is it good to model data in documents? Data modeling is just as important in a document database as it is in a relational database, it's just done differently. How many types of objects do you have and how are they related? Could DBrefs in Mongodb do the trick or will you miss foreign keys so it will hurt? What are your data access patterns? Are you just retrieving data of the same type, filtered by field value, or do you have confusing sampling modes?

Do you need ACID transaction integrity? Does the domain provide a large number of data restrictions? Do you need a scalability factor for a document database or is it just a cool thing?

What are your requirements for data integrity and integrity? Some NoSQL and MongoDB solutions, in particular, are completely sequence-free in order to get performance. NoSQL is not a homogeneous terrain and other products, for example. CouchDB has other features in this department. Some are also customizable.

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

Some impressions

• Extensive reporting of stored data can be more difficult when using MongoDB or any document database, and some use cases combine RDBMS and document-db for this purpose.
• (Very) Different query patterns. MongoDB is also different from other dbs documents.
• Ability to change data / schema format during development
• Unknown territory
• varying degrees of maturity in drivers and frameworks
• Fast
• Simplification (in many ways) of products and management tools (compared to many RDBMS products).
• More impedance mismatch. Storage is suitable for data, not the other way around.
• Less friction and more direct data access.
• The domain is more tied to preservation (depending on the ORM level of “NoRM”, how much it abstracts the backend. I have not used NoRM, so I cannot answer this question.)

Answer 2

against

• (absence / vision) longevity (read http://www.mikealrogers.com/2010/07/mongodb-performance-durability )
• No transaction
• Without Borders
• MapReduce aggregation is slow, and you need to write code for something like group-by
• Reporting is more complicated, the developer determines the relationship, but business analysts cannot create their own queries, they cannot, for example, do the “minus” (“exclude” in sql server lingo)

pros

• you can easily add new "columns" and "tables"
• speed
• sharding (still beta)
• A document is more accurately mapped to an object than to a set of relational tables, so matching becomes easier.
• He expands the mind

Answer 3

I’ve climbed out with him for several days. Here is what I can say about this:

FOR:

• More SQL statements
• Your database is like your classes, not the other way around.
• Your “layout” is more flexible.
• Scales well
• It’s very easy to start with
• <opinion> This is cool, / opinion>

AGAINST:

• I'm currently trying to implement a custom provider provider and role provider for my mongo application, but somehow my MemberShip user class has NULL fields when I try to extract it from mongo.
• Somewhere I read about the C # driver that it is relatively young, but stable, so we expect some changes. (Although it won't hold me back)

One thing that I noticed that is missing from the tutorials: Initialize your lists inside your object, otherwise it will throw an error when trying .save (yourobj). The safest thing to do is to write a constructor in your class that ensures that you do not have NULL objects inside your object. Thus, you will not get an error if you forget something.

Answer 4

Your mileage may vary, but this is a quick graph that I put together to compare the update speed of several "table rows" (non-hierarchical flat document in MongoDB) with and without an index, to give us an idea of ​​how this will be scaled for our applications.

Answer 5

You can find several pros and cons of using a NoSQL database (included by MongoDB) in this Getting Started with NoSQL . A brief summary would be: a different data model (think whether you need to map the object model to "this new model", whether it will work well), a different query model (MongoDB queries are quite efficient, although compared to others), no transactions (for you have some atomic operations though).

In any case, from my point of view, the most important change is the data model and the way you develop your application using this new approach.