You can start using MongoDB in your web applications right now. The latest versions are stable enough for use in the production. The project is being developed by a team of experts on a permanent basis, many bugs get fixed and new features are released (Project Ideas), plus it is used by a considerable number of Internet project, including SourceForge. There are also drivers written for popular programming languages.
As for Drupal a module has been written, which promises to help implement the above features (mostly in Drupal 7), but it is still under development. Also there is a driver for DBTNG (Database Layer: The Next Generation), which allows us to use MongoDB server just like any other Drupal database (of course excluding the execution of SQL-queries). There's a new feature in Drupal 7 that allows storing fields (CCK Fields replacement) not only in a shared database, but also individually in different storages. This feature is also supposed to be implemented in the above module.
In a nutshell, we can easily use this database server in the new Drupal release to optimize performance and scalability.
Database -> Table -> String -> Field + Value .
Database -> Collection -> Document -> key + value .
In relational databases tables must be strictly structured, while MongoDB allows creating random structure documents.
As you can see we have complete freedom in embedding document keys that relieves us from the need to denormalize like in SQL, i.e. we don't need store related pieces of information in separate documents. Just like SQL, MongoDB has indexes, moreover it fully supports them. We can build an index based on any key of the above document, including the embedded country or an array of tags. You can create composite indexes based on multiple document keys. Rules of optimizing indexes for SQL are mostly suitable for MongoDB and described in documentation.
Suppose we need to sample from a specific collection all the documents, where city value is "Moscow".
Similarly to JOIN, we can also create links to objects in other collections without having to make separate queries to get related documents.
MongoDB handles a large number (millions) of documents, its sampling rate, like in SQL, is optimized by indexes and limits on the number of documents received within a single query, just like in usual relational databases indexes have a negative impact on the rate of sampling. There's a familiar EXPLAIN operation that performs the same function it does in MySQL.
SQL has an INSERT operation for adding and an UPDATE operation for updating entries.
Creating an entry in MongoDB implies the use of three functions: insert, save and update.
Save function is a wrapper for update that simplifies the command syntax.
MongoDB supports several types of atomic operations.
We can use synchronous and asynchronous type of entry, asynchronous one is set by default, and it's faster, because the application doesn't need to wait for server response.
MongoDB is recommended for a large number of simultaneous queries (over a thousand per second), especially when there's a large number of write operations. Judging by the numerous reviews, fast entry is one of this database's main advantages.
Speaking of entries, we should mentionCapped Collections.
The thing is, when writing to a regular collection key _id with a unique document identifier is implicitly added to each document. This key is also a basis for building index. Sizes of the collections are dynamic.
In collections like Capped everything is somewhat different. Key _id is being generated, but to speed up recording of an entry index is not based on it (by default). Also, the space these collections might occupy is preset, which also adds speed. However there are certain restrictions, such as updating documents is permitted only if the document size hasn't changed, deleting documents is not supported, when the collection runs out of space new documents replace the old ones. When using Capped Collections the speed of recording documents will be similar to the speed of recording system logs. You can use this feature, for example, for statistics, caching and logging systems.
Suppose we have a task to sample from a table with comments the total number of votes for each author.
MongoDB offers a more complex but also a more advanced solution called Map/Reduce.
First the necessary documents are selected from the database. Because this is essentially a usual sample query, general rules of optimizing similar operations, such as adding indexes, and limiting the number of selected data apply.
Then reduce function is created in JS, which receives the mapping data, grouped by a particular key defined in the map function and the long-awaited data aggregation starts.
Optionally, you can define the finalize function to run after reduce and perform the data finalization.
Let's try to understand how it happens through an example (taken from here).
This document includes two comments from "kbanker" with two votes.
// Value - the number of votes for a current comment.
As a result we get the grouped data and can use them in our application.
There's a more detailed description in the original article (follow the link above), as well as in documentation.
There is also a group function for aggregation, but we won't dwell on it because it won't work in a scaled architecture and, despite the fact that it runs much faster than map/reduce, it still does not solve the above problem and is still slow at a certain number of entries.
Let's have a look at some aspects of database administration. You can find the complete documentation here.
As a result we get a folder with BSON-format files. Use this folder to restore backup, for example: mongorestore BACKUP_FOLDER.
Read the related documentation section.
The above described interactive console is a great tool for database administration. We can use it to test queries, connection, create indexes, view the status of the current operation and for any other administrative functions.
There are several visual tools for administration in MongoDB, including native clients for OS X and. NET, as well as PHP, Python and Ruby web interfaces. You can find them in the relevant section.
Evaluating MongoDB in terms of its use in Drupal we have to admit it certainly can't be a complete replacement for the usual MySQL or PostgreSQL. It can be used to improve performance of individual elements of the architecture, especially in bottlenecks. For example, it's a good idea to use this database for statistics, caching, storage of user sessions, maintaining a watchdog log, queue management, etc. In addition, modules can actively use this database for storing their data.