0% found this document useful (0 votes)
2 views

Distributed and No SQL Databases

This document discusses distributed and NoSQL databases, covering their architecture, storage methods, commit protocols, and types of NoSQL databases. It explains the advantages and disadvantages of replication and fragmentation in distributed databases, as well as the CAP theorem. Additionally, it provides an overview of CRUD operations in MongoDB.

Uploaded by

Sarankumar K
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

Distributed and No SQL Databases

This document discusses distributed and NoSQL databases, covering their architecture, storage methods, commit protocols, and types of NoSQL databases. It explains the advantages and disadvantages of replication and fragmentation in distributed databases, as well as the CAP theorem. Additionally, it provides an overview of CRUD operations in MongoDB.

Uploaded by

Sarankumar K
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 20

Modern database

technology
CHAPTER 4
DISTRIBUTED AND NO SQL DATABASES

SARANKUMAR K - CIT CHENNAI 1


Distributed and no sql
databases
1. Distributed Database Architecture
2. Distributed Database Storage
3. Commit Protocols – 2PC, 3PC
4. Types of No SQL databases
5. CAP Theorem
6. Mongo DB – CRUD Operations

SARANKUMAR K - CIT CHENNAI 2


DISTRIBUTED DATABASE
ARCHITECTURE
 Client – Server Architecture  client connect to central server 
manages distributed database system
 Peer to Peer Architecture  each site in distributed database
system  connected to all other sites
 Both responsible for
 Coordinating Transactions
 Managing Data Storage
 Providing Access Control

SARANKUMAR K - CIT CHENNAI 3


SARANKUMAR K - CIT CHENNAI 4
SARANKUMAR K - CIT CHENNAI 5
DISTRIBUTED DATABASE
storage
 Data can be stored on different sites  by following methods
like Replication and Fragmentation
 Replication  maintain multiple copies of data  stored on
different sites  for faster retrieval  fault tolerance
 Fragmentation  partitioned into several fragments  stored in
distinct sites
 Replication & Fragmentation combined  partitioned into
several fragments  system maintains several identical
replicas of each such fragment

SARANKUMAR K - CIT CHENNAI 6


DISTRIBUTED DATABASE
storage
 Full Replication  every site contains copy of entire database
 Advantages of Replication
 Availability  failure of site containing relation r  does not
result in unavailability of r
 Parallelism  queries on r  may be processed by several
nodes  in parallel
 Reduced data transfer  relation r is available locally at
each site  containing replica of r
 Disadvantages of Replication  Increased cost of updates 
Increased complexity of concurrency control
SARANKUMAR K - CIT CHENNAI 7
DISTRIBUTED DATABASE
storage
 Horizontal Fragmentation  relational table or schema  is
broken down into group of one or more rows  each rows get
one fragment of schema  splitting by rows
 Vertical Fragmentation  relational table or schema  is broken
down into group of one or more columns  each columns get
one fragment of schema  splitting by columns

SARANKUMAR K - CIT CHENNAI 8


DISTRIBUTED DATABASE
storage
 Advantages of Fragmentation
 Horizontal  allows relation to be split  tuples are located 
where they are most frequently accessed
 Allows parallel processing  on fragment of relation
 Vertical  Tuple ID attribute  efficient joining of vertical
fragments

SARANKUMAR K - CIT CHENNAI 9


Commit protocols
 Transaction executed at multiple sites  must either committed
at all sites or aborted at all sites
 Not Accepted to have transaction  committed at one site and
aborted at another
 2PC (2 Phase Commit)  protocol widely used
 3PC (3 Phase Commit)  more complicated and more
expensive

SARANKUMAR K - CIT CHENNAI 10


2 phase commit protocol
 One coordinator  responsible for initiating protocol
 Other entities  called participants
 If coordinator or participants  unable to commit  all parts of
transaction are aborted
 Two Phases
 Phase 1: Coordinator sends “Request to Prepare?”  to all
participants in transaction  Vote Collection Phase
 Phase 2: Implement decision “Commit Initialised” to all
participants  Decision Phase

SARANKUMAR K - CIT CHENNAI 11


SARANKUMAR K - CIT CHENNAI 12
3 phase commit protocol
 One coordinator  responsible for initiating protocol
 Other entities  called participants
 If coordinator or participants  unable to commit  all parts of
transaction are aborted
 Three Phases
 Phase 1: Coordinator sends “Request to Prepare?”  to all
participants in transaction  Vote Collection Phase
 Phase 2: Coordinator sends “Prepare to Commit?”  to all
participants in transaction  Dissemination Phase
 Phase 3: Implement decision “Commit Initialised” to all
participants  Decision Phase
SARANKUMAR K - CIT CHENNAI 13
SARANKUMAR K - CIT CHENNAI 14
Commit protocols
 Transaction executed at multiple sites  must either committed
at all sites or aborted at all sites
 Not Accepted to have transaction  committed at one site and
aborted at another
 2PC (2 Phase Commit)  protocol widely used
 3PC (3 Phase Commit)  more complicated and more
expensive

SARANKUMAR K - CIT CHENNAI 15


Types of nosql Databases
 Key value pair based

 Column based

SARANKUMAR K - CIT CHENNAI 16


Types of nosql Databases
 Document Oriented

 Graph based

SARANKUMAR K - CIT CHENNAI 17


Cap theorem
 Consistency  consistent execution of operation
 Availability  should be always available and responsive
 Partition Tolerance  system should continue to function  even
if communication among servers is not stable
 CA – Consistency & Availability
 CP – Consistency & Partition Tolerance
 AP – Availability & Partition Tolerance

SARANKUMAR K - CIT CHENNAI 18


Cap theorem

SARANKUMAR K - CIT CHENNAI 19


Mongo db - crud operations
 Create  insertOne(), insertMany()
 Read  find(), findOne()
 Replace  updateOne(), updateMany, replaceOne()
 Delete  deleteOne(), deleteMany()

SARANKUMAR K - CIT CHENNAI 20

You might also like