NoSQL Databases
By: Gamze Yılan
Tags: Relational Databases, Mongodb, NoSQL, Nosql Database, Sql

If you know absolutely nothing about NoSQL, this article is just for you!

What is NoSQL?

Short for Non-relational SQL is a mechanism for storing and managing data. Unlike relational databases, NoSQL will work with not tables but other methods of modeling. Frequently used for dealing with big data and real time web applications, NoSQL databases are also called Not Only SQL to emphasize that they may work with SQL as well.

Notice: If you are not familiar with relational databases and would like to learn more, check out my beginner-friendly article on relational algebra.

What is Big Data?

Big data is a large, and yet still growing in size, amount of structured and un-structured data. The big data is so large that the traditional methods of storage and processing ends up being inadequate. Within the last decade, due social networks and search engines, there has been a massive increase in data volume to result in the birth of Big Data.

Types of NoSQL Databases

There are multiple types of NoSQL databases. Here are a few of the biggest ones:

Column oriented NoSQL databases: If you are familiar with the relational databases, you will find that they are row oriented.

Let’s say that we have a database consisting of a list of our friends: their names, ages, hobbies, professions. Now a row based database will hold each object, or in this case each friend as a row. All columns and rows will be listed on one single, huge data table. And when searching for friends who are programmers, it will scan each column for each row one by one, going from their ages and hobbies and all for each friend.

For column oriented databases on the other hand; the names, ages, hobbies and professions of our friends will each be another data table, a single column. Then, the friends will be linked to right ages and hobbies through ids. And when searching for friends who are programmers; you can simply go on the professions column, find the programmers row, and follow the matching ids.

Thanks to column oriented databases not only the search is faster, but since we don’t type “programmer” for all of our programmer friends again and again, the data will take less space as well. And if you would like to add new columns, it’s easier to add them on a column based database for that the existing columns won’t be affected by it.

Examples of column based databases are Apache HBase, Facebook’s Cassandra, Hypertable, and Google BigTable.

Key - Value NoSQL databases: These types of databases store everything as a pair of a key and a value. For out friends list name, age, profession, hobbies each will be keys and John, 30, programmer, archery will be values of these keys. You can even encapsulate an entire set of key-value pairs in an object, set a key to it and use it as a value.

Examples of key-value databases are Redis, Voldemort, Riak, and Amazon’s Dynamo.

Document NoSQL databases: With document databases, instead of chopping the objects into pieces for each attribute, you specify a schema and add the object that fits this schema as it is. You can think of this as creating a class while programming, and then adding objects that fit that class’s structure.

For example, if you were to store articles on a relational database, you would have to chop the author name, the date, the headline and the article itself in order to enter these attributes on correct columns. But with document databases, you simply create a schema that shows where the author name, the date, the headline and the article itself is placed. Then, you can upload the documents as they are and the database will know which attribute is which without having to chop it.

Since we can store objects as they are without chopping or combining anything, this database type is often the most useful one. Examples of document databases are MongoDB and CouchDB.

Graph (Network) NoSQL Databases: Graph or network databases are used for storing data that is highly interconnected. This database will take objects and connect them to each other with lines. There can be millions of different types of objects such as people, companies, products… The line will represent the relation between two objects and the line itself, or rather the relation, can have it’s own properties. The line can also be an arrow if there is a direction.

Think about the database of Facebook, for example. You, your friends Tim and George, your mother Sarah and your sister Emily will all be objects and you will have a line connecting you to them. Since your mother is also friends with your sister, there will be another line between them. If you specified that Sarah is your mother, the property of the line that ties you to Sarah will be “mother of” and it will be an arrow pointing you rather than a line. Harvard University, which you and Tim study at, will be a different type of an object. There will be arrows pointing at Harvard University object, connecting you and Tim to it, with the property “student of” on them. Therefore your entire social circle and life will create a web, or rather, a network. In this example every object will be called a node and every line of relation will be called an edge.

Databases of this type can hold great amounts of very complex data and object types, can be connected and disconnected easily. With this type of databases the possibilities will be endless and the entire world will be increasingly interconnected. Since there are no tables, no null values and no boxes to be filled, this type will help you save memory space. With this database type you can add or change many things, easily, with less risk of messing anything up. Therefore while the relational databases happen to still be the dominant type, it seems that things will be soon taken over by this type of databases.

Relational Databases vs NoSQL

While relational databases happen to be used far more widely nowadays, and even though NoSQL databases can be far more efficient, there’s no such case of one replacing the other. There are cases where a Relational Database will be the right one to use, and cases where using NoSQL will make things much more smooth. Both has their own advantages and although one might get more popular over time, neither seems to be dead yet.

NoSQL will be better when handling Big Data for it leaves more room for growth, takes less memory space and queries work far more quickly. For relational databases, you will have to structure the data with a pre-determined schema. You will have to pre-determine columns and rows and fields and even the data type of each field. However, when dealing with dynamic and growing data such as Big Data, that’s not always possible. Here as well, NoSQL comes in handy. NoSQL can handle unstructured data. Here, you won’t have to create tables and columns, and you don’t even have to know your data type.

Perhaps the biggest advantage of NoSQL is scaling. When you are working with a growing website or application, the data you need to store will never get less but only more. There are two types of scaling, scaling up (horizontal scaling) or scaling out (vertical scaling). With relational databases we will use the scaling up method: when your data gets bigger you will have to replace your old, small memory with a larger, bigger one. Scaling out, on the other hand is used with NoSQL Databases: you can simply get 2 more of the exact same memory and spread the growing data on the new ones. Scaling out is far more quick, safe and cheap. When scaling out you can use much cheaper hardware and once you reach the limitations of your node, you can simply use additional nodes.

On the other hand, relational databases are better for handling relational data. You have a schema, certain attributes for each object that is clear and obvious. There is also a good thing called normalization with relational databases, which basically divides a data table that consists of too many columns and rows into multiple databases with smaller amount of columns and rows. And in order to avoid data loss while performing a normalization process over it, we use relations. This saves huge amounts of memory space and makes data easier to work with, giving us better performance. With relational databases you can use SQL (Structured Query Language), an old but very popular, very solid, very easy to learn query language. Also with relational databases, you can determine a bunch of rules on insertion, deletion and updating of data in order to ensure data integrity. You can, for example, forbid the deletion of a name in the gym members list that has “active” written in the membership type column in order to avoid data loss by mistake.