Things do not tell you about MongoDB: MongoDB -leaf MongoDB: fast (very) easy to use (I think), stable and suitable for a variety of situations they have to deal. I am a fan conditional and as such this post expose some of the limitations of this product which, I admit, scared me when I found out (mea culpa). Maybe I telling you before his adoption of MongoDB experience will be much quieter than mine, is not it?
Hungry for bytes
Something interesting in MongoDB is how quickly this consumes your hard disk space if you do not take care. To avoid problems with file fragmentation (and thus more performance) MongoDB pre-allocates your data files. The first file will be named [name of your database] .0 and will have 64 Mb in size. As you use the allocated space, when using half of this file, a new call [name of your bd] .1 will be created with 128 Mb. And this will continue to file with 256, 512, 1024 and finally 2048 Mb. From then every new file will have 2 GB in size.
If disk space is a constraint for you may MongoDB is not a good option. Because space is pre-allocated, it is important that from time to time give you the necessary maintenance on your database. The Repair Database and compact commands can save you some space, but this will depend on your configuration.
For this problem, there is a very interesting commercial solution called TokuMX which is a storage engine that reduces by 90% the consumption of MongoDB disk space. In this link, there are more details about the product.
Data replication with replica-set is fantastic but there are limits
Set up a cluster with MongoDB is very easy. The replica-set strategy for data replication is fantastic and works extremely well. However, if replication is one of your requirements here is one important restriction: you can only work with a maximum of 12 knots. More than that does not work and you will have to come up with some more complicated strategy.
The staff is already thinking to overcome this limitation. There is even one issue for this. If you want, you can put pressure on the development team this voting.
Replication with the slave master strategy is ridiculous and desrecomen data
If you need more than 12 us to replicate your data, there is a strategy considered obsolete and desrecomen data by the staff of MongoDB which is the master-slave. With it you can have how many nodes you dream. It works like this: the master node is done writing, and slaves copying the data (are for reference). So, in theory, you would have high availability, right? Okay, since your master node does not fall.
If the master falls, to elect a new master you will have to stop all instances of your MongoDB cluster (yes, you read that right) and manually reset them to choose a new primary server. Doubt? Read the documentation about. “Very high” availability.
32-bit version of Escape
The 32-bit version of MongoDB only works with a maximum of 2 GB of information (including rates ), thus avoiding the most of this version in production environment especially the first fact I mentioned in this post. The staff of MongoDB even already told us this .. Use the maximum to learn how to use Mongo or development.
Beware of overly complex documents
This is a very common misstep by those in love with the documentary paradigm ultra store complex objects. Keep in mind some limitations of MongoDB:
Your document may have up to 16 Mb in size.
The maximum depth of a document is 100.
Face it: write a document of this magnitude is not a good idea anywhere, but I have heard some cases where occurred. So keep this in mind.
CARA advise but with some free training
If you need a direct MongoDB consulting ” factory “, prepare the pocket. At least for the Brazilian market value is quite salty. Are you sitting? $ 450.00 per hour on the light background (minimum two hours). Doubt? Here the link.
But there are also free courses that can reduce the likelihood of you need to hand in his pocket. This link for more information on this.
Tools for administration are still bad
Unfortunately, the tools to MongoDB administration are still pretty bad. There are alternatives paid, but not yet tested. Until this moment the only one that satisfied me and even then with reservations was RoboMongo. There are some who try to imitate tables (the name escapes me now ) that only make your life more complicated than it should. Avoid them. By the way, hint: the first contact with MongoDB try to focus on documents and forget the tables.
Know the limitations of MongoDB
MongoDB is a fantastic solution, however, is very common fall in love with technology and with this, we forget that this ever possesses limitations. And then in the future just emerging phrases like: ” MongoDB does not pay “, ” this should be called MongoDB Buy “, etc.
Incidentally, this is advice I give in adopting ANY database management system . Where the supplier discloses the limitations of your product. In the case of MongoDB, I suggest you read the documentation about these limits. In this post, I explained a few that surprised me. A much more complete list can be found in this official link.