In Chapter 2, Model-View-Whatever, we briefly discussed document-oriented databases, otherwise known as NoSQL databases. This concept is imperative to the MEAN stack, as the M in the MEAN acronym stands for MongoDB, a widely used NoSQL database implementation. NoSQL databases are conceptually divergent from traditional relational, or SQL, databases.
Non-relational databases have existed for decades, but they did not achieve any widespread use until more recently. This rise in popularity led to the term NoSQL first being applied to these types of databases. The reason for the increase in the use of NoSQL databases has primarily been to solve the problem of handling Big Data, or massive and complex datasets, and scaling that data horizontally in modern web applications.
The term NoSQL means non-SQL which implies that it is a non-relational database type. NoSQL databases that are document-oriented, like MongoDB, store their data in documents represented by structured JSON objects. The data types in a NoSQL database like this are defined by the data itself, as is the case with standard JSON:
{
"id": 1
}
For example, if you have a field in a NoSQL database with the key id and the value is 1, a number, you could easily change the value to myID, a string, without needing to change any other reference to that data type:
{
"id": "myID"
}
In this way, the data type for that value is entirely dependent upon what it is defined as. In a relational database, making this change would not be so straightforward.
In contrast to document-oriented databases, traditional SQL databases use tables to structure their data. Each table column is set to a specific data type and the data stored under that column must adhere to the defined type. If you have a large SQL database and wish to change the type for a particular column, it can be potentially problematic and could require the change to be executed on thousands of rows of data. Changing a data type in a JSON document is relatively easy compared to this, as it only involves changing the data itself, and there is no concept of a table column defining the data type across multiple records.
The term relational in regard to relational databases refers to the tabular relation of the data stored. Each table of data is considered a relation because the different data stored within it is related to one another in some manner defined by the applications and programs that will be consuming it. A table in a SQL database can be compared to a JSON object in a NoSQL database. The biggest difference between the two, however, is that a table is composed of rows and columns, and the data is further related by column types and rows containing records of related data. In a NoSQL database, there is no concept of rows and columns, and data can be nested with unlimited scope.
In order to retrieve nested data within a SQL database, relations must also be identified between tables. Since data cannot actually be nested, references from one or more tables to one or more other tables must be used to create related sets of data for use in application Models and Views. SQL is a programming language used to manage and extract the data from relational database tables and format it in such a way that is required for an application.
The majority of NoSQL database systems do not support transactions which conform to the properties of ACID, which stands for Atomicity, Consistency, Isolation, and Durability. This set of properties is required for a database to handle transactions in a reliable fashion. A transaction is any change made to a database. That change can be to a single value for a field in one table, or it can be a change that spans multiple tables and affects multiple rows within those tables. Most widely used relational databases support the ACID properties for transactions, no matter the complexity of the operation that is performed.
The Atomicity property of ACID refers to atomic operations within a database, meaning that the changes required for a transaction must all be ensured to occur, otherwise none will occur. This property provides a guarantee that partial changes are not made, which could lead to corrupt data sets. If an atomic transaction fails at any point within a database, the changes made up to that point are rolled back to their previous state.
The Consistency property of ACID is the requirement that a transaction only causes valid data changes as defined by that database system. This includes ensuring that data is not corrupt, that rollbacks are enforced when necessary, and that all the necessary database triggers related to a transaction are executed.
The Isolation property of ACID requires that a simultaneously executed transaction, or concurrency, does not result in database errors in related data. This can involve different levels of strictness, dependent upon the database system being used. The primary goal of Isolation is that the end result of a set of concurrent transactions is the same as if you were to go back and replay them one after another. Isolation is closely tied to Consistency, and it should always ensure that Consistency is maintained.
The Durability property of ACID requires that a transaction is not lost while being executed. You can imagine any number of things going wrong with a computer that could occur during the execution of a transaction, such as a power outage. When something like this occurs, Durability provides that the database system remembers the transaction that was in the middle of execution by recording it to disk and ensuring that it isn't lost, even after a reboot.
It is true that many NoSQL database systems do not conform to the ACID properties; however, MongoDB does to a certain degree. As mentioned, MongoDB is a document-oriented database system, which is a more terse subset of NoSQL databases. In this fashion, MongoDB has the ability to support ACID transactions at the single-document level. It cannot support multi-document transactions, so in this way it falls short of most relational databases, which can support ACID transactions across multiple tables, but MongoDB still stands out among document-oriented databases at the document level.
Another feature that MongoDB touts above others is Write-Ahead Logging (WAL). This is a set of features allowing a database system to conform to the Atomicity and Durability properties of ACID. To do this, MongoDB writes a record of all operations and their results to an internal log before actually executing the operations. This is a simple and effective way to ensure the Durability of document-level transactions because with all operations logged ahead of execution, evidence of what occurred is not lost in the event of a sudden interruption to an operation. Similarly, this feature ensures Atomicity because it gives MongoDB the ability to undo and redo these operations upon reboot after determining what changes were made and comparing them to the state of the database before the interrupted operation.