What kind of application can I use Mongodb in?

Question

• Use Mongodb in every kind of application is bad?
• There are application types where it is most recommended and types where it is not recommended to use a Nosql?

Answer 1

Of course it’s bad, and that goes for any technology. Can you use it in any application? Probably yes, the question is how good the result will be and how much effort you will have to make.

Do you need transactions? Forget any Nosql. To supply this, people are recreating transaction control in the application, probably much worse. Or they’re "let it go," after all, in most cases it works. It has applications that can work in most cases, it has applications that need to work in all cases.

Do you need relationships? You’ll suffer with any Nosql. And let me tell you something: most applications need relationships, and in order not to use them, applications are creating redundant data and working on application consistency. This can be good or bad. Performance will probably suffer.

Mongodb has transactions only inside the document, and if I am not outdated, with limitations (already improved, but not yet solved in fact). Is your application document oriented? Most are not.

I’m not going to talk about Nosql as cache because it’s not the case with Mongodb, but cache invalidation is a very difficult problem and one usually accepts a more or less solution.

That’s why I always say that a relational database should be the first choice until it’s no longer appropriate. Even today relational characteristics provide non-relational characteristics that integrate well and have the best of both worlds.

It is not possible to say in a generic way what is best, it depends on the use pattern.

Myths

• Nosql is best for large data volumes

  It can be... in some situations. But if you need the resources mentioned above, what good is it to be better at something and not provide the necessary?

• Nosql has better performance

  Each type has some advantage if it does a certain operation a lot, but it is not good for everything.

  There are cases that Mongodb will be too fast for writing and reading (it is true that probably would not need it with this pattern).

  Writing is slow and miraculous. It is possible to minimize some effects, especially amplification, but it will not change absurdly without compromising durability.

  Most applications do much more reading than writing. But if the readings are isolated Mongodb is doing well, the problem is when he starts making document relations.

• Nosql scale well

  It’s true. If you don’t need relationships and transactions. Scaling up these mechanisms is very complicated in any adopted model. If you abandon them the SQL-based model scale easy (at least the good products).

The relational model adopts the ACID, Nosql (in fact the correct one would be Norel) adopts the GROUNDWORK. You need to know which is more important. If you need ACID, forget Nosql.

There is already a hybrid model based on Nosql. I can’t tell if the results are good, but I’m sure it has disadvantages.

There are several accounts of past dramas because they adopted Mongodb by fad and not by necessity. Everyone thinks it’s Facebook when they are at most an industry with complex processes that cannot fail and low volumes of data and operations. Facebook has needs and advantages you don’t have.

Mongodb can be useful in secondary or core applications when the core activity is fully focused on unstructured documents.

I suggest reading about the CAP.

They say new versions of Mongodb have transactions beyond the document. It may be, but let’s remember that they said it before when it wasn’t true and they even said they had put it in a recent version and it didn’t actually happen. Even if I do now, if I use it, it loses some trait that people enjoy. I’ve seen people say that Mongodb was breaking up with CAP Heorem, I laughed a lot.

See more:

• What are the most common types of databases for web applications?
• How to choose between Nosql and SQL?
• Nosql is as problematic as it seems?
• What is a Nosql Bank? How it works?
• What makes a JOIN bad in a database?
• What it means document-oriented?

Answer 2

My answer is based on practical experiences.

Mongo stores JSON. If your application is dealing with many JS objects and you want to persist with them, use Mongodb. This will make your DAL and MVC layers very thin, because they are not packaging all the properties of the JS object and trying to force them into a structure (schema) in which they do not fit naturally.

Writing speed?!?!
Guy is not using Mongodb that you will have this advantage, if you really need to solve a problem of writing speed of your data use another bank like Voldemort.

Staggering?!?!
Who needs it in practice?! Facebook?! Unless you’re creating something to compete with Facebook, why would you need to scale it up?!? :)

If you want to use Mongodb blz, but don’t expect him to do magic for you.

Answer 3

I quite like the mongodb, I’m more used to it. It’s very fast, it’s also the database nosql most used in the world, with a very large community.

At Mongo you work with collections and documents, as it is not sql you use his language bson which is based on the json.

It is important to point out that a Nosql bank is very good but does not eliminate relational Dbs in SGDB, after all one should not exclude decades of proven experience. In some cases it will be better one than the other, but there are cases, as mine where I use hybridly the two types of database.

The blog this guy is very cool to understand some very important things about mongoDB and helps you understand some care about Mongodb in a very balanced way. More things can be seen here

As Mongodb allows you to insert fields at any point in your document, that is, it has schema-free, so there should be plenty of care to create your data architecture due to this flexibility.

A legal case to use Mongo is in dynamic form where the user can create random fields depending on the need for it when we do not know which fields will be created so it can be created in the document according to the need.

Answer 4

Nosql is best suited for those systems that have higher storage and performance needs. There are several types of Nosql databases, the Mongodb is a document-oriented Nosql bank. This type of bank has an incredible performance for writing and not so good for reading.

In this project, posted on github, we can have a performance comparison against Mysql https://github.com/webcaetano/mongo-mysql

In other words, Mongodb is recommended for projects that require a lot of writing.

Another great advantage is the ease of scaling the bank to several servers, maybe this is the reason why several companies adopt this type of bank nowadays.