A few things you need to know about MongoDB

Henrique Lobo Weissmann, a software developer from Brazil, is a co-founder of Itexto, 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 will happen continuously, so files of 256, 512, 1024, and 2048 will be 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 situation. 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.

The data replication achieved through the replica set is great, but there are also limits to the replication set policy for data replication in MongoDB It's 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 be surprised. Take a look at this link.

Do not use the 32-bit version of the MongoDB 32-bit version is also not recommended, because you can only handle 2GB size of 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 don't know about 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 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 dollars. The price is too high compared to Redhat and Oracle.

Bad management tools This is still a headache 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.

To understand the official restrictions I am surprised that few people will be able to inquire about the limitations of the tools they will use. Fortunately, MongoDB's developers released a blog that mongodb all the limitations, and you can learn about the information ahead of time and avoid embarrassment during the use process.

Readers, there are also more and more companies using MongoDB, and you may share some of the experience and lessons you have learned when using this NoSQL database.

Article reproduced from: Open source China community [Http://www.oschina.net]