NOSQL

Who are we?

Tarek Yasser Radwa Ahmed Abdelrahman Jamal Iten Emad
 TABLE OF CONTENTS

01 02
Definition & History Types of NoSQL
What is it? How did it Document based, column
change over time? based, etc..

03 04
CAP, Pros and Cons SQL VS NoSQL
Perfectly balanced, as
Decisions, decisions..
everything should be.
 01
Definition & History
 Let’s go back..

• The name was first introduced in 1998 by Carlo

Strozzi
• Wasn’t the NoSQL we all know and love!
Back to the future! Well, 2009..

• Reintroduced and popularized by

this handsome fella!
• Johan Oskarsson, then working at
Last.fm
Misnomer

• Doesn’t literally mean “No SQL”

• Storzzi suggested “NoREL” as an alternative.
Non relational databases
• Existed since the 1960s.
• Simple operation, store the object as is into persistent
storage.
• Gained popularity in the mid 1990s as a relational database
contender.
Common Characteristics

Non-relational

Open-Source

Cluster Friendly

Schema Free

Fitting for The Modern Web

On The Other Side..
Relational databases

• Relational databases existed since the mid 1980s

• Offered easy integration, reporting, and concurrency
control. Which made them robust and safe.
• Used SQL as the standard language of communication.
Can’t have your cake and eat it too..

• Suffered many problems.

• An example: Impedance
mismatch
Impedance Mismatch

• The fragmentation of data for storage, then recollection

for use.
• Required mapping systems to map data back into one
coherent object.
Crossing Paths?
Not yet…
• Even at the start of the 2000s, relational databases still
reigned supreme.
• Why? Relational databases have become the backbone of
many essential applications.
• Would require a significant amount of work to replace.
Now!

• As the internet grew, single servers couldn’t keep up.

• Vertical scaling wasn’t adequate, rapidly growing websites
had to find an alternative.
• Time for a change of perspective!
NoSQL + Distributed Systems
• Relational databases had a hard time dealing with
distributed systems/data, scaling down.
• Non relational to the rescue!
• Horizontal scaling, allowed for smaller and cheaper
systems to be used.
• Easy to scale, no downtime or availability concerns.
Relational Strikes Back
Evolution & Mimicry

• Relational databases borrowed clustering, master-slave

servers, and sharding. This allowed scaling up only.
• Predefined queries, gave up flexibility for performance.
• Highly inelastic, cannot “undistribute” the data.
• Maintenance and power costs.
 THREE COLUMNS MAY BE USEFUL

OBJECTIVES KEY RESULTS INITIATIVES

Mercury is the closest Venus has a beautiful Despite being red, Mars is
planet to the Sun name, but it’s hot actually cold
 02
Types of NO SQL
 Not all but Some
Key value pair based  
Store data in pair of keys and values (key )

The most basics type of NO SQL, to handle a huge of data base, based on Amazon ‘ Dymano paper

When you retrieve some thing , you only use the key

Allow developer to store scheme less(you don’t need to have scheme, each row follows key with
value which can search quickly like hash table)

Store data as hash table which key is unique and value may be any thing (string ,JSON file,BLOB’basic
large object’)

Every key is primary key

Key can be strings, hashes, sets , sorted sets (not just number)or attribute with value) 

Examples :  Aerospike ,Apache Cassandra ,Berkeley DB,Couchbase Server,Redis,Riak,

Dymano DB
Key value pair based  

• Key-Value Store Vs Cache

Caches and key-value store do have differences. Where key-value stores can be used as
a database to persist data, caches are used in conjunction with a database when there
is a need to increase read performance. Caches are not used to enhance write or
update performance yet key-value stores are very effective. Where key-value stores
can be resilient to server failure, caches are stored in RAM and cannot provide you
with transactional guarantees if the server crashes.
 Column-Oriented Databases 

• Store data in  set of Columns without consuming memory

in unwanted data.
• Fast , Specially  in  aggregate functions.
• Examples : MariaDB, CrateDB, ClickHouse, Greenplum
Database, Apache Hbase, Apache Kudu
 Column (NO SQL ) vs Row (SQL) 
Name City Age

Matt Los Angeles 27

Dave San Francisco 30

Tim Oakland 33

Jim New York 29

Carrey Boston 32

You need to access the all disks in Row to get the sum of
ages but in Col , you need only to access disk1
Document Oriented Database

• Store data in a document

• Store data in object which mapping to value
• Each document associates  with Unique key
• It can be nested documents 
 Document Oriented Database
• No expensive & Complex Joins like SQL , You need only object
to get data
• Resilient and Scalable which means you can distribute data in
more than one services  
• No need For ORM layer 
Examples:
MongoDB, OrienteDB ,CouchDB which encoded in XML,JSON ,
BSON
ORM Layer​

ORM stands for object relational mapping

ORM used to covert data between system using OOP
 Graph Databases

• Based on Graph theory

• It consist of edges and nodes
• Nodes represents entities , Edges represents relationships
• Graphs may be directed and undirected
• It can be used in social networks
• How it stored ????
Graph Databases
key-value store or document-oriented database for storage, making
them inherently NoSQL structures. A node would be represented
as any other document store, but edges that link two different
nodes hold special attributes inside its document
Examples :Neo4j ,DGraph, ..etc
Graph Databases
Graph Databases

• RDF Triple store : The RDF triple store is a type of graph database that
stores data as a network of objects and uses inference to uncover new
information out of existing relations.
• RDF: standard resource description framework
 03
Consistency, CAP and
Pros & Cons
How does NoSQL fare?
Consistency
Definition

• Any database transaction must not lead to a change in data

that violates any of the database’s constraints.
• Consistency does not guarantee the transaction
correctness, only it being in line with the rules.
Database Consistency Models

• ACID
• BASE
• Many others between them with different degrees of
consistency guarantees
 ACID

• Atomic

• Consistent

• Isolated

• Durable
Atomic
• Any database transaction consists of many statements that
are executed together.
• If any statement was executed incorrectly, the database
would be changed incorrectly.
• This is called a database inconsistency.
Atomic

• Atomicity is treating the whole transaction as a single unit.

• If a statement was executed incorrectly, the transaction is
aborted, and any changes are reversed.
Consistent

• Any database transaction must not break any database’s

rules or constraints.
Isolated

• Retrieving data from the database often requires more than

one transaction.
• Those transactions are executed concurrently (at the same
time) instead of consecutively.
• This could lead to all sorts of problems.
Isolated

• Isolation ensures that the results of executing concurrent

transactions will be the same as executing consecutive
transactions.
Durable

• The result of a transaction will remain stored in the

database in the event of a system failure (losing power,
crashing, etc..).
• Transaction results are stored in non-volatile memory.
 ACID

• ACID is one of the strongest models in terms of consistency

guarantees.

• ACID guarantees the consistency of the database after every

transaction and has many safety checks.

• All major relational databases use ACID.

 BASE

• Basically Available

• Soft state

• Eventually Consistent
 BASE

• This consistency model is used with distributed system

(Database is stored across many nodes).

• BASE doesn’t guarantee database consistency after every

transaction.
Basically Available

• Being available as much as possible.

• The same data is stored on multiple nodes in case of
failure.
Eventually Consistent

• After any database update, if a long enough time passes

with no further updates, the database will become
consistent.
Soft state

• After any transaction, we can only guess the state of the

database.

• This is because we have no consistency guarantees across

transactions.
 BASE

• Most major NoSQL databases (except graph databases) use

the BASE consistency model.

• Graph databases use the ACID consistency model.

Which consistency model is better?
It depends…
• A banking system where each deposit/withdrawal should
notify the client right away?
 Use ACID.
• A social media platform where it’s fine if some of your
friends see your posts a few minutes late?
 Use BASE.
CAP theorem
 CAP

• Consistency

• Availability

• Partition Tolerance
Consistency

• Every node in the distributed network must return the

same most up to date result.

• This is different to the definition of consistency in ACID.

Availability

• All functioning nodes that are connected to the system

network should respond to any read or write requests
within a reasonable amount of time.
• The result is not necessarily the most up to date one.
Partition Tolerance

• The system should continue functioning even if some

partitions were to fail or stop working.
 CAP

• Normally, the system can provide all three properties in CAP.

• In the event of a network failure (network partition), the

system can only provide two of the three properties.
However, that definition is slightly inaccurate
 CAP
• In the event of a network partition, the system must be able
to continue functioning.

• In the event of a network partition, the system can either

provide availability or consistency.

• The choice is not binary however, it’s a fine gradient between

both.
Let’s look at an example
Who makes the choice?
Business people!
Pros & Cons
 Pros

• Easily Scalable.

• Easy to use and develop.

• Needs less administration.

• Flexible.

• Support for multiple data structures.

Easily scalable
• When using distributed systems, data is stored on many
nodes.
• If one were to use a relational database, the data of a single
entity, which would be split into many tables, would be
stored in multiple nodes.
• This would make it hard to keep track of the many tables
in case we want to update the information of an entity.
Easily scalable

• The problem would be even worse if we kept multiple

copies of the same data for more reliability.
• On the other hand, NoSQL databases store entities as a
single unit.
• Keeping track of data, updating entities and their copies
becomes much simpler.
Easy to use and develop

• In many cases, it’s easier and more natural to store data as

a single unit instead of splitting it between tables.
Less need for adminstration

• NoSQL databases need much less administration

compared to relational ones.
Flexible

• NoSQL databases are better at handling change as they

have no fixed schema.
Support for multiple datastructures

• NoSQL databases allow many different approaches

depending on your needs (key-value, document-based,
column-based and more).
 Cons

• Less Mature

• Few experienced developers

• Less Support

• No standardization
Less Mature

• NoSQL databases are relatively new, they are not as

mature as relational databases and lack their stability and
rich functionality.
Few experienced developers

• As NoSQL is still relatively new, it lacks the millions of

experienced developers that SQL has.
Less Support

• In relational databases, if an important function were to

fail, enterprises have access to support from highly
experienced remote database administration services that
can fix the problem in a timely manner.
• Most NoSQL databases don’t have access to anywhere
near this level of support.
No standardization

• NoSQL lacks standardized platforms like SQL, which is

hindering it from expanding further. And causes migration
concerns.
 04
NoSQL vs. SQL
Which is better?
 The big question:
Which is better?
NoSQL or
SQL
Comparison Points
• Definition
• Examples
• Data Model
• Schema
• Scalability
• Language
• Security
• Best Usage
• Real Scenarios
 NoSQL vs. SQL
Definition
• Means Not Only SQL • Means Structured Query
• Implements non-tabular Language

NoSQ or non-relational data • Implements RDBMSs

SQL
bases as documents, (Relational Data Base
graphs, etc… Management Systems)
L Examples
• MongoDB, RavenDB • MySQL
• BigTable, HBase • Oracle
• Redis, Cassandra • PostgreSQL
• Neo4j, CouchDB • Microsoft SQL Server
 NoSQL vs. SQL
Data Model
Follows the principles of the
Follows the BASE model

NoSQ
ACID model (Atomicity
(Basic Availability Soft State
Consistency Isolation

SQL
Eventually Consistent)
Durability)

L Schema
• Structured, semi-structured
or even unstructured data
can all be stored together
• Very loose schema or no
schema at all
• The data in must be
structured and constraints
must be planned
• Requires a strict schema
 NoSQL vs. SQL
Scalability
Uses horizontal scaling and
can divide the data in the
NoSQ same table into blocks or
chunks and distributed across
multiple servers
L Language
• No standard language to use
• Each NOSQL framework designer
has made their own language
• No aggregate functions or complex
inquiries
Utilizes vertical scaling that can
be thought of as increasing the
number of rows in a table while
SQL
the number of columns remains
constant
• Utilizes a standard question
language known as SQL.
• Can deal with complex inquiries
through specialized interface
• Can use aggregate functions
 NoSQL vs. SQL
Security
NoSQL
• Not designed with security as a
priority so has weak security
• A security layer must be added
to NoSQL applications.
• Hopefully will get better as the
NoSQL market matures in the
future
SQL
• Remarkably secure systems
that guarantee the protection of
services, data & users
• Can encrypt data, limit access
and authorization, protect data
from theft, destruction of data
and malicious behaviour
 NoSQL vs. SQL
Best
• When the access pattern is defined Usage
• When the access patterns aren’t defined or
random
• When the primary key is known • When you want to perform relational
queries
• When the data model fits best (for example
• When you want to perform flexible and
graphs in social media) complex queries
• When you want to use a more documented
• When there’s a need for a very high
access language
performance and low latency • When you want to enforce field constraints 

NoSQL SQL
 • Small Project + Low Scale +
Unknown Access Patterns
• Large Project + High Scale +
Relational Queries
NoSQL
Real Scenarios
• Medium/Large Project + High
Scale + High Performance
SQL
• Cloud Based Computing and
Storage
• Projects with Big Data
NO ONE WINS!!!!
 The Future
of NoSQL
• Won’t be the only data base in the market
• More Security Measures
• Better decisions to choose the best database for every
application
• High probability of Polyglot Persistence
 THANKS
DO YOU HAVE ANY
QUESTIONS?

CREDITS: This presentation template was created by Slidesgo, including icons

by Flaticon, infographics & images by Freepik
 References
• How NoSQL Databases Work? - By SimplyExplained
• An introduction to NoSQL Databases - By TravestyMedia
• GOTO 2012 • Introduction to NoSQL - By Martin Fowler
• https://en.wikipedia.org/wiki/NoSQL
• 11 OPEN NoSQL Document-Oriented Databases.
• https://www.profium.com/en/blog/graph-database-use-cases/
• https://aws.amazon.com/nosql/document/
• A suitable solution to this,the Top Column Oriented Databases.
• https://www.mongodb.com/scale/types-of-nosql-databases
• Relational Databases Are Not Designed For Scale - MarkLogic
• SQL vs NoSQL | Difference Between SQL and NoSQL | Intellipaat
• https://www.lifewire.com/abandoning-acid-in-favor-of-base-1019674
• Elmasri & Navanthe (2016) Fundamentals of Database Systems, 7 edn.,Pearson