Three new features in MongoDB 2.8
The other day, I visited a grand gathering of NoSQL fans - World MongoDB Conference .
Eliot Horowitz, Co-Founder and CTO at MongoDB, talked about 3 innovations that will be available in the next release.
Each of the announced innovations aims to achieve the following principles in the MongoDB architecture:
You can watch the presentation video here .
MongoDB has been under development for as long as 7 years. And what have users heard of consistency all these years? Basically, they heard about global locks at the level of the entire database.
It is important to remember that locks in MongoDB are very similar to latches in relational DBMSs - they are very simple and usually take no more than 10 milliseconds. In MongoDB 2.2, the problem of locking at the level of the entire database was solved, and the lock yielding algorithm was improved . This allowed to significantly reduce the number of problems that the community had in connection with locks. However, the MongoDB developers continued to work in this direction.
And now the moment of truth has come: MongoDB 2.8 will have document-level locks! This, of course, is a much greater improvement than the long-awaitedcollection level lock .
Document-level locking has already been posted on github (v.2.7.3), but is not yet ready for use in production . To enable locking mode at the document level, you must start
Let's try to answer one simple question: which data storage engine is best for the future MongoDB? Read speed oriented? Write speed? Security? The guys from MongoDB chose not to bother with the answer. They decided that none of the engines can be considered optimal immediately for all needs. And you really can't argue with that. In general, they developed a replaceable API for an arbitrary storage engine.
There are quite a few requirements for this API, as it should support all existing MongoDB features, support operational scalability, add one or more nodes to the cluster, and much more.
As a result, we will get the ability to connect a replacement storage that will be optimized for specific needs: performance, data compression, etc.
Suggested storage types:
- In-Memory
- RocksDB (from Facebook, sharpened for compression)
- InnoDB (from MySQL)
- TokuKV
- FusionIO (works bypassing the file system, sharpened by low latencies)
In-Memory and RocksDB are already available in the development branch on github. Again, take your time using this on battle servers.
As you know, MongoDB can replicate and shard out of the box. As a result, we get not one database instance, but several at once. In truly large projects, there can be many such nodes. And the problem is not only in the deployment of all these nodes, but also in their further update, backup, monitoring and much more.
All of this routine will now be done for us by the Mongo Management Service (MMS).
MMS is a friendly web interface that allows you to solve a number of tasks in just a couple of mouse clicks:
And for starters: MMS will teach you how to integrate with Amazon EC2 .
I really like the fact that the MongoDB team pays a lot of attention to making their product convenient and useful to developers. And they do this not in a spherical vacuum, but are actively interested in the opinion directly from the community . Therefore, I am confident that MongoDB will continue to maintain an excellent pace of introducing new features, improve security, automate and make the whole routine even more invisible.
Eliot Horowitz, Co-Founder and CTO at MongoDB, talked about 3 innovations that will be available in the next release.
Each of the announced innovations aims to achieve the following principles in the MongoDB architecture:
- Developer Productivity
- Horizontal scalability
- Operational scalability
- Administering a single web server should be simple. The same goes for clusters.
You can watch the presentation video here .
Data consistency
MongoDB has been under development for as long as 7 years. And what have users heard of consistency all these years? Basically, they heard about global locks at the level of the entire database.
It is important to remember that locks in MongoDB are very similar to latches in relational DBMSs - they are very simple and usually take no more than 10 milliseconds. In MongoDB 2.2, the problem of locking at the level of the entire database was solved, and the lock yielding algorithm was improved . This allowed to significantly reduce the number of problems that the community had in connection with locks. However, the MongoDB developers continued to work in this direction.
And now the moment of truth has come: MongoDB 2.8 will have document-level locks! This, of course, is a much greater improvement than the long-awaitedcollection level lock .
Document-level locking has already been posted on github (v.2.7.3), but is not yet ready for use in production . To enable locking mode at the document level, you must start
mongodwith the key useExperimantalDocLocking=true. The growth rate of updates demonstrated at the presentation is staggering: it increased approximately 10 times from 30,000 per / sec to 340,000 per / sec!Custom Data Warehouses
Let's try to answer one simple question: which data storage engine is best for the future MongoDB? Read speed oriented? Write speed? Security? The guys from MongoDB chose not to bother with the answer. They decided that none of the engines can be considered optimal immediately for all needs. And you really can't argue with that. In general, they developed a replaceable API for an arbitrary storage engine.
There are quite a few requirements for this API, as it should support all existing MongoDB features, support operational scalability, add one or more nodes to the cluster, and much more.
As a result, we will get the ability to connect a replacement storage that will be optimized for specific needs: performance, data compression, etc.
Suggested storage types:
- In-Memory
- RocksDB (from Facebook, sharpened for compression)
- InnoDB (from MySQL)
- TokuKV
- FusionIO (works bypassing the file system, sharpened by low latencies)
In-Memory and RocksDB are already available in the development branch on github. Again, take your time using this on battle servers.
Automation
As you know, MongoDB can replicate and shard out of the box. As a result, we get not one database instance, but several at once. In truly large projects, there can be many such nodes. And the problem is not only in the deployment of all these nodes, but also in their further update, backup, monitoring and much more.
All of this routine will now be done for us by the Mongo Management Service (MMS).
MMS is a friendly web interface that allows you to solve a number of tasks in just a couple of mouse clicks:
- One-click deployment (coming soon)
- Instant update of nodes (coming soon)
- Continuous (logging) and incremental backups
- Rollback to any state
- Monitoring 100+ system metrics
- Custom Notifications
And for starters: MMS will teach you how to integrate with Amazon EC2 .
What's next?
I really like the fact that the MongoDB team pays a lot of attention to making their product convenient and useful to developers. And they do this not in a spherical vacuum, but are actively interested in the opinion directly from the community . Therefore, I am confident that MongoDB will continue to maintain an excellent pace of introducing new features, improve security, automate and make the whole routine even more invisible.