Introduction To NoSQL Database

CE – TE – ADBMS
Mrs. Ujwala Ravale and Amita Suke
Assistant Professor,
Dept. of Computer Engg.,
SIES Graduate School of Technology

1
Ms. Ujwala Ravale
4.1 Introduction to NoSQL Databases

• A database Management System provides the mechanism to store

and retrieve the data.

• There are different kinds of database Management Systems:

1. RDBMS (Relational Database Management Systems)

2. OLAP (Online Analytical Processing)

3. NoSQL (Not only SQL)

2
Ms. Ujwala Ravale
Agenda
• Introduction to NoSQL

• Limitations of Relational Database

• What is NoSQL

• Business Drivers of NoSQL

• NoSQL Data Architecture Patterns

• NoSQL solution for big data

• Choosing distribution models

3
Ms. Ujwala Ravale
Different SQL Databases

4
Ms. Ujwala Ravale
What is NoSQL?

NoSQL is a set of concepts that allows the rapid and

efficient processing of data sets with a focus on
performance, reliability, and agility.

5
Ms. Ujwala Ravale
Limitations of Relational databases
• Need to define structure and schema of data first and
then only we can process the data.

• Provides consistency and integrity of data by

enforcing ACID properties.

• Most of the applications store their data in JSON format.

• RDBMS don’t provide you a better way of performing

operations such as create, insert, update, delete etc on
this data.

6
Ms. Ujwala Ravale
Advantages of NoSQL

• High scalability

• High Availability

7
Ms. Ujwala Ravale
RDBMS Vs NoSQL
• RDBMS: It is a structured data that provides more functionality but
gives less performance.

• NoSQL: Structured or semi structured data, less functionality and high

performance.

8
Ms. Ujwala Ravale
NOSQL DATABASES

9
Ms. Ujwala Ravale
What is NoSQL?
• More than rows in tables

• Free of joins

• Schema-free

• Works on many processors

• Uses shared-nothing commodity computers

• Supports linear scalability

• Innovative

10
Ms. Ujwala Ravale
Comparison between SQL and NoSQL Databases

11
Ms. Ujwala Ravale
4.3 Types of NoSQL Database :

• Document Database

• Key value stores

• Graph store

• Wide column stores

12
Ms. Ujwala Ravale
NoSQL Data Architecture Patterns

13
Ms. Ujwala Ravale
NoSQL Database Categories

• Document Database

• Key value stores

• Graph store

• Wide column stores

14
Ms. Ujwala Ravale
NoSQL Data Architecture Patterns

15
Ms. Ujwala Ravale
Data Models
NoSQL databases are classified in four major data
models :

16
Ms. Ujwala Ravale
Key-value
 Simplest NOSQL databases

 The main idea is the use of a hash table

 Access data (values) by strings called keys

 Data has no required format

 Data model: (key, value) pairs

 Key maps to a BLOB(Binary Large Object)

 Example of Key-value store DataBase : Redis,

Dynamodb, Riak, Memcache etc.
17
Ms. Ujwala Ravale
Operations using KEY VALUE STORE

• Get(key)

• Put (key, value)

• Multi-get(Key1, Key2,….Keyn)

• Delete(key)

18
Ms. Ujwala Ravale
KEY VALUE STORE PROS

 Any data type in value field

 Consistent

 Returned values on queries can be used to convert into lists,

data frames etc.

 Scalable

 Reliable

 Key can be synthetic or auto generated

19
Ms. Ujwala Ravale
KEY VALUE STORE CONS

 No indexes are made on values.

 Do not provide traditional DBMS capabilities ,such as ACID

properties when multiple transactions are executed
simultaneously.

 No queries on values.

 Maintaining unique keys is a problem if volume is large.

20
Ms. Ujwala Ravale
Key Value Stores

21
Ms. Ujwala Ravale
Key Value Stores

22
Ms. Ujwala Ravale
Document-Based Store NoSQL

• In this type of database, the record and its associated data are
stored in a single document.

• So this model is not completely unstructured but it is a kind of

Semi-structured data.

• The difference between a document and Key value pair is that in

document type storage is that in this type some kind of encoding is
provided while storing the data in documents.

• It can be XML encoding or JSON encoding.

• The below example shows a document that can be stored in a

document database but with a different encoding.

23
Ms. Ujwala Ravale
DOCUMENT STORES
 The central concept of a document-oriented database is the notion
of a document.

 Documents in a document store are roughly equivalent to the

programming concept of an object.

 They are not required to adhere to a standard schema, nor will

they have all the same sections, slots, parts or keys.

 Generally, programs using objects have many different types of

objects, and those objects often have many optional fields.

 Every object, even those of the same class, can look very
different.

 Document stores are similar in that they allow different types of

documents in a single store, allow the fields within them to be
optional, and often allow them to be encoded using different
encoding systems.
24
Ms. Ujwala Ravale
DOCUMENT STORES

25
Ms. Ujwala Ravale
DOCUMENT STORES

26
Ms. Ujwala Ravale
Document-Based Store NoSQL
• The document type is mostly used for CMS systems, blogging
platforms, real-time analytics & e-commerce applications. It should
not use for complex transactions which require multiple operations
or queries against varying aggregate structures.

• Amazon SimpleDB, CouchDB, MongoDB, Riak, Lotus Notes,

MongoDB, are popular Document originated DBMS systems.

27
Ms. Ujwala Ravale
Example:

</employeename>

• The difference between conventional databases and document-

based databases is that data here is not stored in tables like
conventional databases but are stored in documents.

• The examples of databases using the above data model are

MongoDB and Couchbase.

• These types of databases are used extensively especially in big

data analysis.
28
Ms. Ujwala Ravale
COLUMN ORIENTED DATABASES
 Column-oriented databases primarily work on columns and every column is treated

individually.

 Values of a single column are stored contiguously.

 Column stores data in column specific files.

 In Column stores, query processors work on columns too.

 All data within each column data file have the same type which makes it ideal for

compression.

 Column stores can improve the performance of queries as it can access specific

column data.

 High performance on aggregation queries (e.g. COUNT, SUM, AVG, MIN, MAX).

 Works on data warehouses and business intelligence, customer relationship

management (CRM), Library card catalogs etc.

29
 Example of Column-oriented databases : BigTable,
Ms. Ujwala RavaleCassandra, SimpleDB etc
COLUMN-ORIENTED DATABASE

30
Ms. Ujwala Ravale
GRAPH DATABASES
 A graph database stores data in a graph.

 It is capable of elegantly representing any kind of data in a highly

accessible way.
 A graph database is a collection of nodes and edges.

 Each node represents an entity (such as a student or business)

and each edge represents a connection or relationship between
two nodes.

 Every node and edge is defined by a unique identifier.

 Each node knows its adjacent nodes.

 As the number of nodes increases, the cost of a local step (or

hop) remains the same.
 Index for lookups.
 Example of Graph databases: OrientDB, Neo4J, [Link].
31
Ms. Ujwala Ravale
GRAPH STORES

32
Ms. Ujwala Ravale
GRAPH STORES

33
Ms. Ujwala Ravale
Analyzing big data with a shared-nothing architecture

34
Ms. Ujwala Ravale
Analyzing big data with a shared-nothing architecture

35
Ms. Ujwala Ravale
Analyzing big data with a shared-nothing architecture

• A shared nothing architecture (SN) is a distributed computing

architecture in which each node is independent and self-sufficient,
and there is no single point of contention across the system.

• More specifically, none of the nodes share memory or disk storage.

• People typically contrast SN with systems that keep a large amount

of centrally-stored state information, whether in a database, an
application server, or any other similar single point of contention.

36
Ms. Ujwala Ravale
 Comparison of NoSQL Databases w.r.t CAP & ACID

Database Type Example CAP Preference ACID Properties

AP (Available + Partition Limited ACID. Usually eventual

tolerant) – sacrifices strong consistency; transactions not
Key-Value Stores Redis, Riak, DynamoDB
consistency for speed & supported (except simple
availability atomic operations).

MongoDB supports atomic

MongoDB → CP (Consistency
operations at document level
+ Partition tolerance)CouchDB
Document Stores MongoDB, CouchDB (not multi-doc by default).
→ AP (Availability + Partition
CouchDB uses eventual
tolerance)
consistency.

Cassandra → AP (Highly Cassandra: Tunable

available, eventual consistency (can trade C vs A
Columnar/ Wide-Column
Cassandra, HBase consistency)HBase → CP per query). HBase: Strong
Stores
(Strong consistency, less consistency but weaker
availability) availability.

Support ACID transactions

Typically CP (Consistency + (Neo4j fully ACID). Focus more
Graph Databases Neo4j, JanusGraph
Partition tolerance) on consistency for graph
traversals.
37
Ms. Ujwala Ravale
4.2 What is the CAP Theorem?

CAP theorem is also called brewer's theorem. It states that

is impossible for a distributed data store to offer more than
two out of three guarantees:

1. Consistency
2. Availability
3. Partition Tolerance

38
Ms. Ujwala Ravale
BASE Properties

39
Ms. Ujwala Ravale
BASE Properties

‌ oSQL relies upon a softer model known as the BASE model(instead of

N
ACID properties)

 Basically Available: Guarantees the availability of the data . There

will be a response to any request (can be failure too).

 Soft state: The state of the system could change over time.

 Eventual consistency: The system will eventually become

consistent once it stops receiving input.

40
Ms. Ujwala Ravale
 Notion of ACID Vs BASE
ACID Properties (Traditional Databases)
Used in: Relational Databases (RDBMS like MySQL, PostgreSQL, Oracle).
Goal: Ensure reliability & correctness of transactions.
[Link]
•A transaction is all-or-nothing.
•Example: Money transfer → debit from account A & credit to account B must both
succeed or both fail.
[Link]
•A transaction takes the database from one valid state to another.
•Example: Account balance cannot become negative if rules don’t allow it.
[Link]
•Transactions are executed as if they are the only one running.
•Prevents dirty reads, phantom reads, race conditions.
[Link]
•Once committed, data is permanently stored, even after crashes.
Focus: Correctness, integrity, reliability.
Limitation: Hard to scale in distributed systems (because strong guarantees slow things
down).
41
Ms. Ujwala Ravale
🔹 BASE Properties (NoSQL & Distributed Databases)
Used in: NoSQL (Cassandra, DynamoDB, MongoDB, CouchDB).
Goal: Ensure availability & scalability with relaxed consistency.
[Link] Available
•System guarantees availability of data, even if some nodes fail.
[Link] State
•State of the system may change over time, even without input, due to
replication/async updates.
[Link] Consistent
•Over time, all replicas will converge to the same value, assuming no new
updates.
✅ Focus: Scalability, availability, performance.
❌ Limitation: Temporary inconsistencies allowed.

42
Ms. Ujwala Ravale
ACID vs BASE: Comparison
Feature ACID (RDBMS) BASE (NoSQL)

Consistency Strong consistency Eventual consistency

Availability May sacrifice availability High availability

Social media, IoT, large-scale

Use Case Banking, transactions, ERP
web

Flexible, tolerant of
Approach Strict, rule-based
inconsistencies

Performance Slower (due to strict rules) Faster, scalable

Tolerance Low fault tolerance High fault tolerance

43
Ms. Ujwala Ravale
4.2 Replication: (Distribution models) Master-slave versus peer-to-peer

44
Ms. Ujwala Ravale
Master-slave versus peer-to-peer

• In master-slave configuration where all incoming database

requests (reads or writes) are sent to a single master node and
redistributed from there.

• The master node is called the NameNode in Hadoop.

• This node keeps a database of all the other nodes in the cluster
and the rules for distributing requests to each node.

• In the peer-to-peer model stores all the information about the

cluster on each node in the cluster.

• If any node crashes, the other nodes can take over and processing
can continue.

45
Ms. Ujwala Ravale
Choosing distribution models: master-slave versus peer-to-
peer
• Peer-to-peer systems distribute the responsibility of the master to
each node in the cluster.
• In this situation, testing is much easier since you can remove any
node in the cluster and the other nodes will continue to function.
• The disadvantage of peer-to-peer networks is that there’s an
increased complexity and communication overhead that must occur
for all nodes to be kept up to date with the cluster status.

46
Ms. Ujwala Ravale
Master Slave Distribution Model

• With a master-slave distribution model, the role of managing the

cluster is done on a single master node.
• This node can run on specialized hardware such as RAID drives to
lower the probability that it crashes.
• The cluster can also be configured with a standby master that’s
continually updated from the master node.
• The challenge with this option is that it’s difficult to test the standby
master without jeopardizing the health of the cluster.
• Failure of the standby master to take over from the master node is
a real concern for high-availability operations.

47
Ms. Ujwala Ravale
 Sharding
Sharding means splitting (partitioning) the data into smaller chunks and storing them on
different servers.
Purpose:
•Handle large datasets that don’t fit on a single machine.
•Improve write scalability by spreading load.
•Reduce query load per node.

How Sharding Works:

•Shard key: A field (like user_id or region) decides how data is split.
•Each shard contains a subset of the data.
•A router/cluster manager directs queries to the right shard.

Example:
•Users 1–10000 → stored in Shard 1
•Users 10001–20000 → stored in Shard 2

48
Ms. Ujwala Ravale
Key Differences

Feature Replication Sharding

Copying same data across Splitting data across multiple

Definition
multiple nodes nodes

Goal Availability & reliability Scalability & performance

Each node has partial
Data Stored Each node has full dataset
dataset

Reads scale well, writes

Reads/Writes usually to master (unless Both reads & writes scale
multi-master)

Only data in failed shard

Failure Handling Other replicas take over
unavailable

Disaster recovery, fault

Use Case Handling very large datasets
tolerance

49
Ms. Ujwala Ravale
Handling Transactions, consistency and eventual consistency

1. Handling Transactions
In databases, a transaction is a sequence of operations (read,
write, update) that should behave like a single unit.
In traditional (ACID) systems:
Transactions follow Atomicity, Consistency, Isolation,
Durability.
Example: Bank transfer → debit + credit = one transaction.
In distributed systems:
Transactions may span multiple nodes.
Protocols like Two-Phase Commit (2PC) or Three-Phase
Commit (3PC) ensure atomicity.
Trade-off: can cause blocking and reduced availability.
50
Ms. Ujwala Ravale
2. Strong Consistency
Guarantees that all clients see the same data at the same time
(after a write).
Every read reflects the most recent write.
How it is handled:
Synchronous replication: Write must be confirmed by all
replicas before it is committed.
Consensus protocols: Paxos, Raft ensure nodes agree on the
latest state.
Pros: Correctness, reliability.
Cons: Higher latency, less availability if network partitions
occur.

51
Ms. Ujwala Ravale
3. Eventual Consistency
A weaker model often used in BASE systems (NoSQL, distributed DBs).
Guarantees that if no new updates happen, eventually all replicas will
converge to the same value.
How it is handled:
Asynchronous replication: Writes are accepted locally, then propagated to
replicas in the background.
Conflict resolution:
Last Write Wins (LWW)
Vector clocks (track version history)
Application-specific reconciliation
Pros: High availability, fault tolerance, fast responses.
Cons: Temporary inconsistencies possible (e.g., two users see different
balances).

52
Ms. Ujwala Ravale
Strong Consistency vs Eventual Consistency
Feature Strong Consistency Eventual Consistency

Reads Always latest value May see stale (old) values

Slower, waits for replicas to Faster, writes accepted

Writes
sync immediately

Higher (works even if some

Availability Lower (may block on failures)
nodes down)

Banking, payments, inventory Social feeds, messaging, IoT,

Use Cases
systems caching

53
Ms. Ujwala Ravale
Thank You!
(ujwalar@[Link])

54
Ms. Ujwala Ravale