{"id":18977,"date":"2017-10-17T12:15:22","date_gmt":"2017-10-17T09:15:22","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=18977"},"modified":"2017-10-17T10:47:45","modified_gmt":"2017-10-17T07:47:45","slug":"guide-nosql-software-developers","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/nosql\/guide-nosql-software-developers\/","title":{"rendered":"Guide to NoSQL for Software Developers"},"content":{"rendered":"

If you are following backend development<\/a> or Big Data fields, you\u2019ve probably noticed that for the last couple of years, there has been a lot of hype about NoSQL databases. While some people seem to be very passionate about them, others may think that they are a gimmick: They have different, unusual data models, unfamiliar application programming interfaces, and sometimes unclear applications.<\/p>\n

In this article, I will describe why NoSQL databases were created in the first place, what problems they solve, and why suddenly we need to have so many different databases.<\/p>\n

If you are new to NoSQL, you may be especially interested in the last part of the article where I list what NoSQL databases you should learn first to get a 360-degree view of this area.<\/p>\n

Why do we suddenly need a new database?<\/h2>\n

https:\/\/youtu.be\/kZxFq7VBhXI<\/a><\/p>\n

You may wonder what is wrong with\u00a0relational databases<\/a> in the first place. They worked fine for many years, but now we have a new obstacle that they can\u2019t handle anymore.<\/p>\n

According to some predictions<\/a>, in 2018 humanity as a whole will generate 50,000 GB of data per second. This is a tremendous amount of data, and storing and processing it is a serious engineering challenge. What is even scarier is this number is constantly growing.<\/p>\n

Relational databases are ill-equipped to work with these amounts of data. They are designed to run a single machine and if you need to handle more requests, you have only one option: Buy a bigger computer with more memory and a better CPU. Unfortunately, there is a limit to how many requests a single machine can handle, and we need a different database technology that can run on multiple machines.<\/p>\n

Now, some of you may scoff, and say that there are two widespread techniques of how you can use multiple machines if you use a relational database: replication and sharding. But they are not sufficient methods to handle challenges that we are facing.<\/p>\n

Read replication is a technique in which every update to your database is propagated to other hosts that can handle only read requests. In this case, all changes are applied by a single host, called the leader, while all other hosts, called read replicas, maintain a copy of the data. A user can read from any machine, but can change data only through the leader host. This is a useful and very popular technique, but it allows only handling of more read requests and doesn\u2019t solve the problem of handling the required amount of incoming data.<\/p>\n

<\/p>\n

\"\"<\/a><\/p>\n

Sharding is another popular technique where you have many relational database instances, and every instance accepts reads and writes for a part of your data. If you store information about a customer in your database, with sharding, one machine may process all requests for customers whose names start with A, another will store all the data for customers whose names start with B, and so on.<\/p>\n

\"\"<\/a><\/p>\n

While sharding allows you to write more data, managing a sharded database can be a nightmare. You have to balance data across machines and scale your cluster up and down when necessary. While it may look simple in theory, implementing it correctly is a major challenge<\/a>.<\/p>\n

Can we have a better relational database?<\/h2>\n

I hope that by now, you see that relational databases can\u2019t handle the amount of data that we generate, but you may still be left wondering why someone can\u2019t build a better relational database that can run on multiple machines. You might think that the technology is simply not there yet and we will soon enjoy a distributed relational database.<\/p>\n

Unfortunately, though, this will never happen because it is mathematically impossible, and we can do nothing about it.<\/p>\n

To understand why this is the case, it\u2019s important to talk about the so-called CAP theorem. The CAP theorem, which was proven in 1999, states that any distributed database running on multiple machines can have these three properties:<\/p>\n