A few things you need to know about MongoDB

Henrique Lobo Weissmann is a Brazilian http://www.aliyun.com/zixun/aggregation/6434.html "> software developer who is co-founder of the Itexto Company, This is a consulting firm. Recently, Henrique on the blog about some of the content of MongoDB, some of which are worthy of our attention, especially the developers who are planning to use MongoDB.

So far, MongoDB is the most popular NoSQL database in Brazil (at least based on the number of blogs about MongoDB and the article). MongoDB is a great solution, but what bothers us is that few people know about its limitations. Such things are going on: people see the limits of MongoDB, but they think these are the bugs.

This article lists some of the mongodb limitations that are confusing to the author, and if you intend to use MongoDB, you should at least be aware of these limitations in advance to avoid being caught unprepared.

Consume disk space

This is my first puzzle: MongoDB consumes too much disk space. Of course, this is related to how it is encoded, because MONGODB will avoid disk fragmentation by reallocating large file spaces. It works like this: When you create a database, a file named [DB name].0] is created, and when more than half of that file is used, the system creates a file called db name].1 again, which is twice times the size of the previous file. This continues to occur, so files of 256, 512, 1024, and 2048 are written to disk. Finally, when you create the file again, the size will be 2048Mb. If storage is a limitation of the project, then you have to consider this. The problem has a business solution, called TOKUMX, that will reduce storage consumption by 90%. Moreover, in the long run, the RepairDatabase and compact commands will help you to some extent.

Data replication through replication sets is great, but there are limitations

Replication set policies for data replication in MongoDB are great, easy to configure, and really good to use. But if the cluster has more than 12 nodes, you will have problems. There are 12 nodes in the MongoDB, and here is a description of the problem, and you can track the problem to see if it has been resolved.

Master-slave replication does not ensure high availability

Although it has not been recommended, MongoDB provides another replication strategy, that is, master-slave replication. It solves the 12-node limit problem, but it creates a new problem: if you need to change the primary node of the cluster, then you have to do it by hand, and you're surprised? Take a look at this link.

Do not use the 32-bit version

The 32-bit version of MongoDB is also not recommended, because you can only handle 2GB size data. Remember the first limit? This is a description of MongoDB about the limit.

Consulting fees are very, very expensive (at least for Brazilian developers and companies)

I'm not sure about the situation in other countries, but at least the consultancy fees in MongoDB in Brazil are sky-high. For the "Lightning Consult" program, the price per hour is 450, 00 dollars, and you need to buy at least two hours, in other words, for any company, the price of each consultation is at least 900, 00 dollars. The price is too high compared to Redhat and Oracle.

Poor management tools

This is still a daunting problem for beginners, and MongoDB's management console is too lame. The best tool I know is Robomongo, which is very good for those developers who use it for the first time.

Understand official restrictions

To my surprise, few people would query the limitations of the tools they were going to use. Fortunately, MongoDB's developers released a blog that mongodb all the limitations, and you can learn about it in advance to avoid embarrassment in the process.