How NoSQL Databases Work

Have you ever wondered how Google stores all of its data? After all, Google is one of the fastest search engines. It's able to store and categorize unrelated data for millions of websites. If that isn't impressive enough, Google can figure out what you want from your search query, filter through all of that data, and respond with information in less than 1 second. So, how does Google do this?

One of the tools Google uses is something called NoSQL. NoSQL is a way to store large amounts of unrelated data quickly. So, let's take a look at what NoSQL is and how it can be used.

How NoSQL Databases Work [VIDEO]

In this video, CBT Nuggets trainer Ben Finkel discusses the difference between relational and NoSQL databases, when you’d use each type of database, and why NoSQL values speed and flexibility over consistency and efficiency.

What is a NoSQL Database?

NoSQL either stands for non-SQL or not only SQL depending on who you ask. By its nature, NoSQL is non-relational. What does that mean?

To fully understand NoSQL we need to learn about a couple of other things.

First, computer systems need some sort of storage mechanism. There are a lot of options for ways to store data in applications, but non-standard storage mechanisms can create a lot of issues quickly.

Application developers could create their own storage mechanisms, and some developers do. For example, games use non-standard configuration files to store video game settings. What happens when you need to store a lot of data, though, or you need to share data with another application?

It should be no surprise that we have settled on a few standard ways of storing data over the last few decades. Application developers, businesses, and the like have decided that databases are excellent tools for storing large amounts of data. Databases are great for retrieving data quickly, too.

So, that is the first thing we need to understand. Computer systems need a common way to store large amounts of data and retrieve it quickly.

During the '70s using a relational database became the standard for data storage. Relational databases store related data together. Data is separated into different tables with each table storing data in rows and columns like a spreadsheet. Because data is relational, one table might have customer information such as names, addresses, and phone numbers while another table stores customer login information.

Though relational databases are extremely efficient and fast, they are difficult to both design and maintain. You need to fully understand all the data that is going to be stored in that database before that database or the application using that database is built.

Relational databases can be updated later, but those updates require a lot of work. Both the database itself as well as the application using it need to be adjusted and tested before those changes can be sent to a production environment. Deployment for those changes requires a lot of careful planning, too.

That is the second thing we need to understand. Though relational databases are amazingly fast and efficient, they take a lot of work to build and maintain.

Eventually, the complications with relational databases were solved with NoSQL databases. Unlike relational databases, where you need to heavily plan for the type of data being stored in it, NoSQL databases do not require any planning. They can simply store data.

This makes NoSQL databases great for certain applications like IoT devices, search engines, and sales data.These types of data points may change and evolve constantly.

Likewise, NoSQL databases are very simple to start working with because of how little planning they require. That means developers can develop, prototype, and deploy applications much faster. Because of how well NoSQL databases can adjust to change and how fast they can be built, they also fit the more popular form of agile software development, too.

Are you interested in trying a NoSQL database? Here's a couple of examples of some NoSQL databases:

• MondoDB

• Cassanda

• Redis

• DynamoDB

• CosmosDB

NoSQL Databases vs SQL Databases

As the name implies, NoSQL databases don't use SQL. SQL is just a type of relational database, though. More specifically, it is the querying language for a type of relational database. Since NoSQL databases do not use SQL, it is safe to assume that NoSQL databases are not relational.

This means that NoSQL databases don't need to be designed before they are implemented. Since data doesn't need to be relational, databases don't need to be structured or organized first. Of course, this carries some consequences, too. NoSQL databases are not the holy grail of databases. Much like relational databases, NoSQL databases have their pros and cons, too.

First, because NoSQL databases don't need to be normalized, and because they are capable of storing a lot of different data types, NoSQL databases can be much larger than relational databases. Database size used to be a hefty concern. Physical computer data storage was very expensive, and computers had a very finite amount of computing power. Physical data storage is cheap today and even a low-end computer has all the processing power most databases need. Nonetheless, the difference in database size will play a role as your applications and services grow and databases need to be expanded.

We just touched on the topic of required computing power, too. NoSQL databases require more computing power than a relational database. Again, modern computers have more than enough horsepower for most databases. Still, there is a big difference in the amount of computing power required for a NoSQL database versus a SQL database.

For instance, a small SQL database can easily run on a Raspberry Pi along with a web server and PHP. A Raspberry Pi could host a NoSQL database, but it's going to have a much harder time handling the load of a web server along with that database. This difference in required compute power can change the processing infrastructure of a NoSQL-based application as it grows.

Finally, because NoSQL databases do not store relational data, they are much more capable of storing a lot of different data types. For instance, NoSQL databases can comfortably store different types of images along with different pieces of metadata. Though this could be accomplished with a relational database, it is considerably harder and each datapoint for those images needs to align in some way.

Of course, there are more differences between NoSQL and SQL databases. The points highlighted above are the primary differences, though. Those differences will impact the planning and execution stages of applications the most.

What are the NoSQL Data Storage Models?

NoSQL databases can store data in a few different ways:

• Key:Value Pairs

• Documents

• Graphs

• Columns

• Objects

Key:Value pairs are as simple as the label implies. Each data point in the NoSQL database stores data with a key followed by its value (EG. Name: "Jon").

Documents are more like JSON objects. They use key:value pairs as well, but those pairs are organized in the same fashion as a JSON object. For instance, we might have a document describing a person:

{ Name: Person 1
{
Height: 6 feet,
Hair Color: Brown,
Weight: 220 pounds,
}
}

Graphs are quite different from key:value pairs or documents. Graphs consist of two pieces:

• Nodes

• Edges

Nodes store information about an object (person, place, thing, idea, etc…). Edges explain the relation between different nodes.

Finally, we have column, or wide-column, data models. Wide-column data models are like the rows and columns that we would see in a relational database, but each record might not have the same type of information in each column. Each row may have more or fewer columns associated with it.

When to Use NoSQL Databases

NoSQL databases can be a very useful tool, but when should you use a NoSQL database instead of a relational database? Let's highlight a few cases where NoSQL databases should be used instead of a relational database below:

• You don't know what kind of data will be stored in an application.

• Data may change frequently in an application.

• You need to develop an application with as little overhead or planning as possible.

• You need to develop an application as fast as possible.

• You can't relationally store data affordably.

• You need to be able to scale your database in size quickly.

• You anticipate your application evolving rapidly.