Also known as "Non Relational" databases.
Relational, schema based, databases are harder to scale.
Some Web 2.0 companies with huge environments, growing data and big infrastructure needs, like Google, Amazon, or Facebook. They presented their own solutions to the problem – technologies like BigTable, DynamoDB, and Cassandra.
The first solutions of NoSQL database types were developed by big companies to meet their specific needs, like Google’s BigTable, maybe the first NoSQL system, and Amazon’s DynamoDB.
The success of these proprietary systems generated a big interest and there appeared a number of similar open-source and proprietary database systems, some of the most popular ones being Hypertable, Cassandra, MongoDB, DynamoDB, HBase, and Redis.
One important difference between NoSQL databases and common relational databases is the fact that NoSQL is a form of unstructured storage.
This means that NoSQL databases do not have a fixed table structure like the ones found in relational databases.
NoSQL databases have many advantages compared to SQL relational databases.
One important, underlying difference is that NoSQL databases have a simple and flexible structure, without a schema.
NoSQL databases are based on key-value pairs.
NoSQL databases may include column store, document store, key value store, graph store, object store, XML store, and other data store modes.
Each value in the database will have a key usually. Some NoSQL database models also allow developers to store serialized objects into the database, not only simple string values.
Open-source NoSQL databases don’t require expensive licensing fees and can run on low-resources hardware, rendering their deployment cost-effective.
Also, when working with NoSQL databases, either open-source or proprietary, scalation is easier and cheaper than when working with relational databases. This is because it’s done by horizontally scaling and distributing the load on all nodes, rather than the usual vertical done with relational database systems, which is replacing the main host with a more powerful one.
First, most NoSQL databases do not support reliability features that are natively supported by relational databases. These reliability features can be atomicity, consistency, isolation, and durability (ACID).
This also means that NoSQL databases, which don’t support those features, trade consistency for performance and scalability.
In order to support reliability and consistency features, developers must implement their own personal code, which makes the system more complex.
Other problem found in most NoSQL databases is incompatibility with SQL queries.
It should be noted that the table shows a comparison on the database level, not the various database management systems that implement both models.
Various implementations often provide their own proprietary techniques to overcoming some of the problems and shortcomings in both systems.
In the Key Value store type, it is used a hash table in which a unique key points to an specific item.
Keys can be organized into logical groups, only requiring keys to be unique on their own group. This allows the existence of identical keys in different logical groups.
Key is the only need to deal with the items on the table. Data is stored in a form of a string, JSON, or BLOB (Binary Large OBject).
One of the biggest issues in this form of database is the lack of consistency at the database level.
Popular implementations:
Document stores are similar to key value stores in that they are schema-less and based on a key-value model. Also both share many of the same advantages and disadvantages. They lack consistency on the database level, which makes way for applications to provide more reliability and consistency features.
There are however, some important differences between the two.
In Document Stores, the values (documents) provide encoding for the data stored. Those encodings can be XML, JSON, or BSON (Binary encoded JSON).
Also, querying based on data is possible.
Popular implementations:
Atomicity. This property states that a transaction must be treated as an atomic unit, that is, either all of its operations are executed or none. There must be no state in a database where a transaction is left partially completed. States should be defined either before the execution of the transaction or after the execution/abortion/failure of the transaction.
Consistency. The database must remain in a consistent state after any transaction. No transaction should have any adverse effect on the data residing in the database. If the database was in a consistent state before the execution of a transaction, it must remain consistent after the execution of the transaction as well.
Durability. The database should be durable enough to hold all its latest updates even if the system fails or restarts. If a transaction updates a chunk of data in a database and commits, then the database will hold the modified data. If a transaction commits but the system fails before the data could be written on to the disk, then that data will be updated once the system springs back into action.
Isolation. In a database system where more than one transaction are being executed simultaneously and in parallel, the property of isolation states that all the transactions will be carried out and executed as if it is the only transaction in the system. No transaction will affect the existence of any other transaction.
Proudly self-hosted on a cheap Raspberry Pi