MongoDB — the flexible and scalable NoSQL database

Relational databases were the uncontested go-to solution for managing electronic data for decades. And it’s not without reason: MySQL, which first appeared in 1995, still provides the basis for countless web projects. The growing volume and diversity of data that characterizes modern web applications has made databases with non-relational approaches serious contenders to traditional solutions. These distributed data storage systems, such as MongoDB, which first appeared in 2009, operate in a document-oriented fashion and are referred to as NoSQL databases due to the fact that they don’t make use of SQL (structured query language), the traditional query language for relational databases. And while this demands more from the application layers, it allows databases and work processes to be distributed among multiple servers, which enables this modern database to be scaled up almost without limit.

Unlike MySQL, MongoDB functions in a document-oriented manner and implements a completely different approach when it comes to saving data:

• Data is not saved in tables, but in collections.
  
  
• Documents in BSON formats replace table rows in these documents there are defined fields that replace the SQL table’s columns.
  
  
• Here, a field is always a pair from a key, which also simultaneously depicts the name of a field, and a value. This value can stand for a number, word, or a text, but also for entire lists of words, numbers, or complete files.
  
  
• A MongoDB document is a collection of key-value pairs as well as MySQL table lines.

The key difference here is that the document isn’t subject to any particular scheme, while all rows in a MySQL table follow the same structure; the latter have the same number of values, each with the same data types. Individual MongoDB documents, on the other hand, have their own unique structure. This allows new fields containingany value to be created at any given time, a feature that would require complete restructuring for relational databases, like MySQL. And while keys need to be unique within a given document, it’s permitted for this same key to be used again in other documents. This latter aspect isn’t possible with MySQL databases; instead joins are used to direct between the two tables. These joins can be created in the form of embedded documents or references.

A further fundamental difference when comparing MongoDB vs MySQL is seen in how both models approach the topic of calling up data. As a NoSQL database, MongoDB obviously doesn’t make any use of SQL as its query language and supports data processing with its own language. This set-up enables communication between MongoDB and the corresponding client to take place. In order for this process to function, the database, with the help of libraries and drivers, uses the object-specific methods of the client application’s corresponding programming language. These libraries and drivers can be downloaded separately from the official homepage.

Moreover, complex queries can be performed with the MapReduce model, which is typically implemented for document-based databases.

MongoDB always proves an excellent choice for those interested in realizing web projects that are based on large, unstructured quantities of data. Working within a document-based format, without being bound to a particular scheme is especially well-suited for different data types that need to be both quickly saved and processed. And given that it can be distributed onto multiple servers, the database system also makes horizontal, virtually unlimited scaling possible without limiting operability. In order to guarantee long-term data security and availability, MongoDB also allows copies of databases to be created and made available on multiple servers. The document-oriented database also shows its strengths when compiling amounts of data from one or multiple sources.

Using MongoDB is recommended for all web projects that match the following descriptions:

• Scalability: if your web project is growing, so too is the number of queries it has to deal with, which puts pressure on your databases.
  
  
• Availability: if your web application depends on being constantly available, even in the event of a server outage.
  
  
• Flexibility: your project should be able to be dynamically adjusted at any time.

Distributing data onto multiple servers highlights a key difference between MongoDB and relational databases: upon saving data in a MongoDB database, there’s a short window of time in which subsequent reading accesses only receive the old data. Referred to as eventual consistency, this model is used in the MySQL fork, MariaDB, and many other database systems. The advantage here is that database servers that are separated from larger database clusters through network partitions can still accept write accesses from applications.

Are you not sure which database model is best for your web project? You don’t have to decide: a combination of different types is also possible.