This course primarily covers traditional databases, but this article gives an overview of some non-traditional databases and classifies non-SQL databases according to their operational model. Non-SQL databases are schema-less, and not based on a single data model.
NoSQL databases try to offer certain functionality that more traditional relational database management systems do not. Whether it is for holding simple key-value pairs for shorter lengths of time for caching purposes, or keeping unstructured collections (e.g. collections) of data that could not be easily dealt with using relational databases and the structured query language (SQL) – they are here to help.
In this DigitalOcean article, we are going to try to introduce you to various popular NoSQL database management systems and explain their purposes and functionality, so that you can decide which one to use, or if they even suit your application's needs -- at all.
Databases are logically modeled storage spaces for all kinds of different information (data). Each database, other than schema-less ones, have a model which provides structure for the data being dealt with. Database management systems are applications (or libraries) which manage databases of various shapes, sizes, and sorts.
Note: To learn more about Database Management Systems, check out our article: Understanding Databases.
In the past decade or so, relational database management systems have been the choice of many developers and system administrators for a variety of applications, for a variety of reasons. Despite not being exactly flexible, the powerful nature of many RDBMS allowed complex database set-ups to be created, queried and used. This was more than enough for many requirements, since it was not until long ago that different needs started to rise.
The term "NoSQL" was coined over a decade ago, funnily enough as a name to yet-another relational database. However, this database had a different idea behind it: eliminating the use of the standardised SQL. In the next years to come, others picked up and continued to grow this thought, by referring to various other non-relational databases as NoSQL databases.
By design, NoSQL databases and management systems are relation-less (or schema-less). They are not based on a single model (e.g. relational model of RDBMSs) and each database, depending on their target-functionality, adopt a different one.
There are almost a handful of different operational models and functioning systems for NoSQL databases.:
e.g. Redis, MemcacheDB, etc.
e.g. Cassandra, HBase, etc.
e.g. MongoDB, Couchbase, etc
e.g. OrientDB, Neo4J, etc.
In order to better understand the roles and underlying technology of each database management system, let's quickly go over these four operational models.
We will begin our NoSQL modeling journey with key / value based database management simply because they can be considered the most basic and backbone implementation of NoSQL.
These type of databases work by matching keys with values, similar to a dictionary. There is no structure nor relation. After connecting to the database server (e.g. Redis), an application can state a key (e.g.
the_answer_to_life) and provide a matching value (e.g.
42) which can later be retrieved the same way by supplying the key.
Key / value DBMSs are usually used for quickly storing basic information, and sometimes not-so-basic ones after performing, for example, a CPU and memory intensive computation. They are extremely performant, efficient and usually easily scalable.
Note: When it comes to computers, a dictionary usually refers to a special sort of data object. They constitutes of arrays of collections with individual keys matching values.
Column based NoSQL database management systems work by advancing the simple nature of key / value based ones.
Despite their complicated-to-understand image on the internet, these databases work very simply by creating collections of one or more key / value pairs that match a record.
Unlike the traditional defines schemas of relational databases, column-based NoSQL solutions do not require a pre-structured table to work with the data. Each record comes with one or more columns containing the information and each column of each record can be different.
Basically, column-based NoSQL databases are two dimensional arrays whereby each key (i.e. row / record) has one or more key / value pairs attached to it and these management systems allow very large and un-structured data to be kept and used (e.g. a record with tons of information).
These databases are commonly used when simple key / value pairs are not enough, and storing very large numbers of records with very large numbers of information is a must. DBMS implementing column-based, schema-less models can scale extremely well.
Document based NoSQL database management systems can be considered the latest craze that managed to take a lot of people by storm. These DBMS work in a similar fashion to column-based ones; however, they allow much deeper nesting and complex structures to be achieved (e.g. a document, within a document, within a document).
Documents overcome the constraints of one or two level of key / value nesting of columnar databases. Basically, any complex and arbitrary structure can form a document, which can be stored using these management systems.
Despite their powerful nature, and the ability to query records by individual keys, document based management systems have their own issues and downfalls compared to others. For example, retrieving a value of a record means getting the whole lot of it and same goes for updates, all of which affect the performance.
Finally, the very interesting flavour of NoSQL database management systems is the graph based ones.
The graph based DBMS models represent the data in a completely different way than the previous three models. They use tree-like structures (i.e. graphs) with nodes and edges connecting each other through relations.
Similarly to mathematics, certain operations are much simpler to perform using these type of models thanks to their nature of linking and grouping related pieces of information (e.g. connected people).
These databases are commonly used by applications whereby clear boundaries for connections are necessary to establish. For example, when you register to a social network of any sort, your friends' connection to you and their friends' friends' relation to you are much easier to work with using graph-based database management systems.
Key / Value data stores are highly performant, easy to work with and they usually scale well.
Some popular key / value based data stores are:
In-memory K/V store with optional persistence.
Highly distributed, replicated K/V store.
Distributed memory based K/V store.
Some popular use cases for key / value based data stores are:
Quickly storing data for - sometimes frequent - future use.
Some K/V stores (e.g. Redis) supports lists, sets, queues and more.
They can be used to implement Pub/Sub.
Applications which need to keep a state cane use K/V stores easily.
Column based data stores are extremely powerful and they can be reliably used to keep important data of very large sizes. Despite not being "flexible" in terms of what constitutes as data, they are highly functional and performant.
Some popular column based data stores are:
Column based data store based on BigTable and DynamoDB.
Data store for Apache Hadoop based on ideas from BigTable.
Some popular use cases for column based data stores are:
If a large collection of attributes and values needs to be kept for long periods of time, column-based data stores come in extremely handy.
Column based data stores are highly scalable by nature. They can handle an awful amount of information.
Document based data stores are excellent for keeping a lot of unrelated complex information that is highly variable in terms of structure from one another.
Some popular document based data stores are:
JSON-based, Memcached-compatible document-based data store.
A ground-breaking document-based data store.
An extremely popular and highly-functional database.
Some popular use cases for document based data stores are:
Document-based data stores allow you to work with deeply nested, complex data structures.
One of the most critical functionalities of document-based data stores are the way they interface with applications: Using JS friendly JSON.
Graph based data stores offer a very unique functionality that is unmatched with any other DBMSs.
Some popular graph based data stores are:
A very fast graph and document based hybrid NoSQL data store written in Java that comes with different operational modes.
A schema-free, extremely popular and powerful Java graph based data store.
Some popular use cases for graph based data stores are:
As explained in the introduction, graph databases make it extremely efficient and easy to use to deal with complex but relational information, such as the connections between two entities and various degrees of other entities indirectly related to them.
Graph databases excel in any situation where relationships are involved. Modelling data and classifying various information in a relational way can be handled very well using these type of data stores.
In order to draw a clear picture of how NoSQL solutions differ from relational database management systems, let's create a quick comparison list:
If will be working with very large sets of data, consistently scaling is easier to achieve with many of the DBMS from NoSQL family.
NoSQL databases are usually faster - and sometimes extremely speedier - when it comes to writes. Reads can also be very fast depending on the type of NoSQL database and data being queried.
Relational DBMSs require structure from the beginning. NoSQL solutions offer a large amount of flexibility.
NoSQL databases are growing rapidly and they are being actively built today - vendors are trying to tackle common issues and one of them clearly is replication and scaling. Unlike RDBMSs, NoSQL solutions can easily scale and work with(in) clusters.
When it comes to choosing a NoSQL data store, there are a variety of models, as we have discussed, that you can choose from to get the most out of the database management system - depending on your data type.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.