A Comparison of NoSQL Database Management Systems and Models(Part 1)

akila liyanage
6 min readApr 2, 2021
o

The standard relational database model, which includes tables made up of rows and columns, is what most people think of when they think about databases. Alternative data structures have become more popular in recent years as developers have found workarounds to the relational model’s limitations. These non-relational database models have been dubbed NoSQL databases, and each has its own set of benefits, drawbacks, and use cases.This article will take you through a couple of the most common NoSQL database models. It will compare and contrast some of their benefits and drawbacks, as well as include some examples of database management systems and their future implementations.

The Drawbacks of Relational Databases

Databases are functionally modeled knowledge or data clusters. Meanwhile, a database management system (DBMS) is an application that deals with a database. A database management system (DBMS) helps you to handle database access, write records, execute queries, and perform other database management activities. Although database management systems and databases are commonly used interchangeably, the two terms are not synonymous. A database is any set of records, not just one stored on a disk, and a database management system (DBMS) is the program that helps you to communicate with one.

There is a fundamental model that structures how data is processed and retrieved in all information management systems. A relational database management system (RDBMS) is a database management system that uses the relational data model as its foundation. In this model, data is arranged into tables, which are more formally referred to as relations in RDBMSs.Structured Query Language (SQL) is widely used in relational database management systems to handle and view data contained in the database.
The relational model has long been the most common method of data processing, and all of today’s most popular database management systems use it.The relational model, on the other hand, has a variety of pitfalls that can be troublesome in certain circumstances.It can be difficult to scale a relational database horizontally, for example. Horizontal scaling, also known as scaling out, is the method of adding more devices to an existing stack to spread out the load and allow more traffic and faster loading. Vertical scaling, on the other hand, entails improving the hardware of an installed server, typically by installing additional RAM or CPU. The idea that the relational model is structured to ensure continuity means that clients querying the same database will only see the most recent data makes scaling a relational database horizontally impossible. It’s difficult to maintain continuity when scaling a relational database horizontally through several devices so clients can write data to one node and read data from another.

Since the relational model is built to guarantee accuracy, clients querying the same database can only see the most recent results, rendering horizontal scaling of a relational database difficult. When extending a relational database horizontally across several platforms so that clients can write data to one node and read data from another, it’s difficult to preserve consistency.The relational model was developed to handle structured data, or data that aligns with a predefined data form or is at least arranged in a predetermined manner, allowing it conveniently sortable and searchable, which is another drawback of RDBMSs. However, with the advent of personal computers and the internet in the early 1990s, unstructured data — such as email addresses, images, and videos — became more prevalent. As these limits became more restrictive, developers started searching for solutions to the standard relational data model, resulting in the proliferation of NoSQL databases.

About NoSQL

The word “NoSQL” itself has a hazy meaning. Carlo Strozzi invented the term “NoSQL” in 1998 to describe his then-new NoSQL Database, which was chosen simply because it did not use SQL to manage results. After Johan Oskarsson arranged a developer meetup in 2009 to address the spread of “open source, distributed, and non relational databases” including Cassandra and Voldemort, the word took on a new meaning. The meetup was dubbed “NOSQL” by Oskarsson, and the phrase has since become a catch-all for any database that does not use the relational model. Strozzi’s NoSQL database, interestingly, uses the relational paradigm, implying that the original NoSQL database does not meet the modern concept of NoSQL. There are many organizational data structures aligned with the NoSQL definition and “NoSQL” applies to any DBMS that does not use the relational paradigm. The table below lists a number of these data models, but it’s important to remember that this isn’t an exhaustive list:

Despite their various underlying data structures, most NoSQL databases have a few characteristics in common. For instance, NoSQL databases are often configured to emphasize compatibility over accuracy. In this case, consistency ensures that every read operation will return the most recently written data to the database. All data written to one node in a distributed database configured for high continuity will be automatically accessible on all other nodes; otherwise, an error will occur. In comparison, NoSQL databases often aspire for long-term stability. This means that newly written data is gradually (usually in a matter of milliseconds) made available on other database nodes, but not always immediately. This has the advantage of increasing data availability: even though you don’t see the most recent data written, you will always see an older version of it instead of having a mistake.

Relational databases are made to work with data that has been normalized and falls within a predefined schema. A schema is an overview of how the data in the database is configured, while normalized data is data that has been arranged in a way to minimize redundancies — ensuring that the database takes up as less physical space as possible — in the form of a DBMS. Although NoSQL databases can manage normalized data and order data according to a predefined schema, their data structures typically provide much more consistency than relational databases’ static layout. As a result, NoSQL databases are considered to be a great option for semi-structured and unstructured data storage. However, since NoSQL databases lack a predefined schema, it’s up to the database administrator to decide how the data can be structured and accessible in whichever way makes the most sense with their use. Let’s take a closer look at some of the most commonly used NoSQL database models now that you have a better understanding of what NoSQL databases are and how they vary from relational databases.Key-value Databases

Key-value Databases

Associative arrays are stored and managed in key-value databases, commonly known as key-value stores. An associative array, also known as a dictionary or hash table, is made up of key-value pairs, each of which acts as a unique identifier for retrieving a value. Simple objects, such as integers or strings, can be used as values, as can more abstract objects, such as JSON structures.

Unlike relational databases, which describe a data structure consisting of tables with rows and columns and predefined data types, key-value databases store data as a single array with no structure or reference.An application may specify a key (for example, the meaning of life) and a corresponding value (for example, 42) after connecting to the database server, which can then be obtained in the same manner by providing the key. Any data contained in a key-value database is viewed as an opaque glob, and it’s up to the application to work out how it’s organized.

Key-value databases are commonly referred to as high-performing, reliable, and scalable databases. Caching, message queuing, and session management are all popular applications for key-value databases.

Some popular open-source key-value data stores are:

In the next chapter, will continue on on the Columnar Databases. 😇

--

--

akila liyanage

Undergraduate at SLIIT | programmer/developer | DevOps Trainee at CAKE Technologies SL