NoSQL databases | How do NoSQL databases work

 

How_do_NoSQL_databases_work

NoSql databases became very talked-about big companies depend on them,

store many petabytes of information and run several queries per second.

 

What is a NoSql database?

 

How does it work? &

 

Why does it scale such a lot better than traditional relational databases?

 

Let's start by quickly explaining the matter with relational databases like Mysql, Mariadb sql server and alike.

 

You can have a table for patrons orders and products linking them together logically customers place orders and orders contain products.

 

This tight organization is great for managing your data, 

but it comes at a price relational databases have a tough time scaling they need, 

take care of these relationships and that is an intensive process requiring lots of memory and compute power.

 

So for ages you'll keep upgrading your database server, but at some point it won't be ready to handle the load in technical terms.

 

We say that relational databases can scale vertically but not horizontally, 

whereas nosql databases can scale both vertically and horizontally, 

you'll be able to compare this to a building vertical scaling means adding more floors to an existing building why horizontal scaling means adding more buildings, 

you intuitively understand that vertical scaling is barely possible to a particular extent while horizontal scaling is way more powerful.

 

Why do Nosql databases scale?

 

First of all, 

they are doing away with these costly relationships in nosql, 

every item within the database stands on its own this easy modification means they're essentially key value stores,

each item within the database only has two fields a singular key and a price.

 

When you want to store product information, 

you'll use the product's barcode because the key and also the product name because the value this seems restrictive, 

but the worth are often something sort of a json document containing more data just like the price and outline.

 

This simpler design is why NOSQL databases scale better.

 

If one database server isn't enough to store all of your data or handle all the queries.

 

You can split the workload across two or more servers each server will then be answerable for only part of your database to administer. 

an example apple runs a nosql database that consists out of 75 000 servers in NOSQL, 

terms these parts of your database are called partitions, 

it brings up an issue if your database is split across potentially thousands of partitions.

 

How does one know where an item is stored?

 

That's where the first key comes in.

 

Remember NOSQL databases are key value stores and therefore the key determines, 

what partition an item are stored behind the scenes NOSQL databases, 

use a hash function to convert each item's primary key into variety, 

that falls into a hard and fast range say between zero and 100, 

this hash value and therefore the range is then accustomed determine where to store an item.

 

If your database is tiny enough or doesn't get many requests.

 

You can put everything on one server.

 

This one will then be accountable for the whole range,

if that server becomes overloaded,

you'll add a secondary server,

which implies that the range are split in half server 1 are going to be accountable for all items with a hash between 0 and 50, 

while server 2 will store everything between 50 and 100.

 

And within the number of queries, you'll be able to execute this range is additionally called a key space.

 

It's a simple system that solves two problems where to store new items and where to seek out existing ones.

 

All you have got to try to to is calculate the hash of an item's key and keep track of which server is liable for which a part of the key space.

 

Now during this example, 

the range of 0 to 100 may be a bit small it'd only allow you to separate up your database into 100 pieces at the most so real NOSQL databases, 

have much bigger key spaces allowing them to scale almost with none restrictions besides great scalability nosql is schema-less, 

which implies that items within the database don't have to have the identical structure.

 

Each one are often completely different in an exceedingly on-line database.

 

You have to define your table structure then each item must conform to that, 

changing the structure isn't straightforward and will even cause data loss not having a schema is an enormous advantage, 

if your application and system is consistently evolving now at this time, 

it's clear that NOSQL databases have certain advantages over relational ones, 

but that's to not say that relational databases are obsolete off from it.


NOSQL is more limited within the way.

 

You can retrieve your data only allowing you to retrieve items by their primary key finding orders by id isn't any problem, 

but finding all orders above a particular amount would be very inefficient relational databases on the opposite hand haven't any trouble with this now there are workarounds for this issue.

 

But as long as you recognize how you are going to access your data which won't always be the case.

 

Another downside is that NOSQL databases are eventually consistent after you write a brand new item to the database and take a look at to read it back right away.

 

It might not be returned as,

I've explained NOSQL splits your database into partitions, 

but each partition is mirrored across multiple servers that way a server can go down without much impact, 

after you write a replacement item to the database one in all these mirrors will store the new item and so copy it to the others within the background.

 

This process might take a touch little bit of time.

 

So after you read that item back the NOSQL database might try and read it from a mirror that does not have it yet

 

 

This is not a big issue in practice because data is replicated in just a few milliseconds.

 

And if you want consistency most NOSQL databases do have that option.

 

So in summary both nosql and relational databases will be around for the foreseeable future each with their own strengths and weaknesses.

 

So now you know how NOSQL works.

 

Let's look at a many exemplifications cloud providers heavily promote nosql, 

because they can gauge it more fluently aws has dynamodb google cloud has bigtable and azure has macrocosm db and to give you another illustration of their scalability during amazon high day amazon's nosql database peaked at 45 million requests per second.

 

That's mind-boggling but you can also run NOSQL databases yourself with software like Cassandra, cilla, couchdb, mongodb.

 

Let's quickly talk about the name NOSQL.

 

It's a bit confusing as it can have two meanings first up NOSQL,

can mean not only SQL pointing to the fact that some NOSQL databases partially understand the SQL query language on top of their own query capabilities and secondly, 

it's often called NOSQL in the sense of non-relational because it can't easily store relational data.