SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Rise of NoSQL
February 15, 2016
Abdul Manaf
Agenda
• DBMS
• Constraints & Problems with RDBMS
– They are not constraints they are features of RDBMS
• The Rise of NoSQL – History
• NoSQL – A Alternative DBMS / Features
• NoSQL – Categories
• NoSQL – Benefits
• NoSQL – Use Cases
DBMS
Storage and retrieval of data
• Flat file systems
• RDBMS – Structured data
• OLAP – Cubes
• NoSQL – Collections
RDBMS
Relational Dominance
• Store data persistently
• Concurrency control
• Transactions
• Mostly standard interfaces and
mechanisms to integrate application data
• Reporting
The RDBMS Bottleneck
The RDBMS Bottleneck
Here comes the Problems , Performance Bottleneck
• My application is crawling
• Queries are pretty slow
• A single query takes hours to complete
• Need to add a column to 1 TB of table
Scale your Database
• Vertical
– Buy bigger boxes
• Horizontal
– Distributed systems
General Problems
• Not easy to scale after certain extent
• The Natural Act – Pretty complex to manage
• Cost of scaling is too high for Enterprise boxes
– CPU Cycles
– Memory
– Disk
– I/O
Relational databases were not designed to run efficiently on clusters.
NoSQL Movement
• 3 V’s : Volume , Variety and Velocity
• Movement away from using databases as integration points in favor of
encapsulating databases with applications and integrating using services.
NoSQL – Common Characteristics
• Faster development Cycles
NoSQL Objective
Categories of NoSQL
Key Value
Document
Column
Graph
The CAP Theorem
The CAP Theorem : It works for Distributed
Systems
• RDBMS v/s NoSQL
• ACID v/s BASE
CAP Theorem 1/2
● It is impossible for a distributed computer
system to simultaneously provide all three of
the following guarantees:
○ Consistency (all nodes see the same data at the
same time)
○ Availability (a guarantee that every request receives
a response about whether it was successful or
failed)
○ Partition tolerance (the system continues to operate
despite arbitrary message loss or failure of part of
the system)
• A distributed system can satisfy any two of these guarantees
• at the same time, but not all three.
CAP Theorem 2/2
● In other words, CAP can be expressed as "If
the network is broken, your database won’t
work"
○ "won't work" = down OR inconsistent
● In RDBMS we do not have P (network
partitions)
○ Consistency and Availability are achieved
● In NoSQL we want to have P
○ Need to select either C or A
○ Drop A -> Accept waiting until data is consistent
○ Drop C -> Accept getting inconsistent data
sometimes
NoSQL Systems and CAP
ACID vs BASE
Scalability and better performance of NoSQL is
achieved by sacrificing ACID compatibility.
Atomic, Consistent, Isolated, Durable
NoSQL is having BASE compatibility instead.
Basically Available, Soft state,
Eventual consistency
ACID -- Requirement for SQL DBs
• Atomicity. All of the operations in the transaction will
complete, or none will.
• Consistency. Transactions never observe or
result in inconsistent data.
• Isolation. The transaction will behave as if it is the only
operation being performed upon the database (i.e.
uncommitted transactions are isolated)
• Durability. Upon completion of the transaction, the
operation will not be reversed (i.e. committed transactions
are permanent)
BASE -- Basically Available
● Use replication and sharding to reduce the
likelihood of data unavailability and use
sharding, or partitioning the data among
many different storage servers, to make any
remaining failures partial.
● The result is a system that is always
available, even if subsets of the data
become unavailable for short periods of
time.
BASE and Availability
● The availability of BASE is achieved through
supporting partial failures without total
system failure.
● Example. If users are partitioned across five database
servers, BASE design encourages crafting operations in
such a way that a user database failure impacts only the
20 percent of the users on that particular host.
○ This leads to higher perceived availability of the
system. Even though a single node is failing, the
interface is still operational.
BASE -- Eventually Consistent
● Although applications must deal with instantaneous
consistency, NoSQL systems ensure that at some
future point in time the data assumes a consistent
state.
● In contrast to ACID systems that enforce consistency
at transaction commit, NoSQL guarantees
consistency only at some undefined future time.
○ Where ACID is pessimistic and forces consistency at the end of every
operation, BASE is optimistic and accepts that the database
consistency will be in a state of flux.
BASE and Consistency
● As DB nodes are added while scaling up, need for
synchronization arises
● If absolute consistency is required, nodes need to
communicate when read/write operations are
performed on a node
○ Consistency over availability -> bottleneck
● As a trade-off, "eventual consistency" is used
● Consistency is maintained later
○ Numerous approaches for keeping up "distributed consistency"
are available
■ Amazon Dynamo - consistent hashing
■ CouchDB - asynchronous master-master replication
■ MongoDB - auto-sharding+replication cluster with a master server
BASE -- Soft State
● While ACID systems assume that data consistency
is a hard requirement, NoSQL systems allow data to
be inconsistent and relegate designing around such
inconsistencies to application developers.
● In other words, soft state indicates that the state of
the system may change over time, even without
input.
○ This is because of the eventual consistency model (the acronym is
a bit contrived).
NoSQL
• What is Missing • What is there
When to Use
When Not to Use
Example
Example
Conclusion
• All the choice provided by the rise of NoSQL
databases does not mean the demise of RDBMS
databases.
• We are entering an era of polyglot persistence, a
technique that uses different data storage
technologies to handle varying data storage
needs.
• Polyglot persistence can apply across an
enterprise or within a single application.
Thank You !
Thank You !

Weitere ähnliche Inhalte

Was ist angesagt?

Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...
Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...
Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...Rajesh Kannan S
 
Scalability Considerations
Scalability ConsiderationsScalability Considerations
Scalability ConsiderationsNavid Malek
 
Replication in Distributed Database
Replication in Distributed DatabaseReplication in Distributed Database
Replication in Distributed DatabaseAbhilasha Lahigude
 
Server load balancer ppt
Server load balancer pptServer load balancer ppt
Server load balancer pptShilpi Tandon
 
Base paper ppt-. A load balancing model based on cloud partitioning for the ...
Base paper ppt-. A  load balancing model based on cloud partitioning for the ...Base paper ppt-. A  load balancing model based on cloud partitioning for the ...
Base paper ppt-. A load balancing model based on cloud partitioning for the ...Lavanya Vigrahala
 
HbaseHivePigbyRohitDubey
HbaseHivePigbyRohitDubeyHbaseHivePigbyRohitDubey
HbaseHivePigbyRohitDubeyRohit Dubey
 
#lspe Building a Monitoring Framework using DTrace and MongoDB
#lspe Building a Monitoring Framework using DTrace and MongoDB#lspe Building a Monitoring Framework using DTrace and MongoDB
#lspe Building a Monitoring Framework using DTrace and MongoDBdan-p-kimmel
 
Database , 5 Semantic
Database , 5 SemanticDatabase , 5 Semantic
Database , 5 SemanticAli Usman
 
Dynamic Load balancing Linux private Cloud (DRS)
Dynamic Load balancing Linux private Cloud (DRS)Dynamic Load balancing Linux private Cloud (DRS)
Dynamic Load balancing Linux private Cloud (DRS)kamrankausar
 
Database , 17 Web
Database , 17 WebDatabase , 17 Web
Database , 17 WebAli Usman
 
DataCluster
DataClusterDataCluster
DataClustergystell
 
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009CloudAngels
 
A load balancing model based on cloud partitioning
A load balancing model based on cloud partitioningA load balancing model based on cloud partitioning
A load balancing model based on cloud partitioningLavanya Vigrahala
 
Replication in Distributed Real Time Database
Replication in Distributed Real Time DatabaseReplication in Distributed Real Time Database
Replication in Distributed Real Time DatabaseGhanshyam Yadav
 
Load Balancing from the Cloud - Layer 7 Aware Solution
Load Balancing from the Cloud - Layer 7 Aware SolutionLoad Balancing from the Cloud - Layer 7 Aware Solution
Load Balancing from the Cloud - Layer 7 Aware SolutionImperva Incapsula
 
The Power of Determinism in Database Systems
The Power of Determinism in Database SystemsThe Power of Determinism in Database Systems
The Power of Determinism in Database SystemsDaniel Abadi
 

Was ist angesagt? (19)

Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...
Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...
Slashn Talk OLTP in Supply Chain - Handling Super-scale and Change Propagatio...
 
Scalability Considerations
Scalability ConsiderationsScalability Considerations
Scalability Considerations
 
Replication in Distributed Database
Replication in Distributed DatabaseReplication in Distributed Database
Replication in Distributed Database
 
Running MySQL in AWS
Running MySQL in AWSRunning MySQL in AWS
Running MySQL in AWS
 
Server load balancer ppt
Server load balancer pptServer load balancer ppt
Server load balancer ppt
 
Base paper ppt-. A load balancing model based on cloud partitioning for the ...
Base paper ppt-. A  load balancing model based on cloud partitioning for the ...Base paper ppt-. A  load balancing model based on cloud partitioning for the ...
Base paper ppt-. A load balancing model based on cloud partitioning for the ...
 
HbaseHivePigbyRohitDubey
HbaseHivePigbyRohitDubeyHbaseHivePigbyRohitDubey
HbaseHivePigbyRohitDubey
 
#lspe Building a Monitoring Framework using DTrace and MongoDB
#lspe Building a Monitoring Framework using DTrace and MongoDB#lspe Building a Monitoring Framework using DTrace and MongoDB
#lspe Building a Monitoring Framework using DTrace and MongoDB
 
Database , 5 Semantic
Database , 5 SemanticDatabase , 5 Semantic
Database , 5 Semantic
 
Dynamic Load balancing Linux private Cloud (DRS)
Dynamic Load balancing Linux private Cloud (DRS)Dynamic Load balancing Linux private Cloud (DRS)
Dynamic Load balancing Linux private Cloud (DRS)
 
Database , 17 Web
Database , 17 WebDatabase , 17 Web
Database , 17 Web
 
DataCluster
DataClusterDataCluster
DataCluster
 
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009
Nick Bond - Zeus - Load Balancing in the Cloud - CloudCamp Berlin 30.04.2009
 
A load balancing model based on cloud partitioning
A load balancing model based on cloud partitioningA load balancing model based on cloud partitioning
A load balancing model based on cloud partitioning
 
Cluster computing
Cluster computingCluster computing
Cluster computing
 
Cluster Computing
Cluster ComputingCluster Computing
Cluster Computing
 
Replication in Distributed Real Time Database
Replication in Distributed Real Time DatabaseReplication in Distributed Real Time Database
Replication in Distributed Real Time Database
 
Load Balancing from the Cloud - Layer 7 Aware Solution
Load Balancing from the Cloud - Layer 7 Aware SolutionLoad Balancing from the Cloud - Layer 7 Aware Solution
Load Balancing from the Cloud - Layer 7 Aware Solution
 
The Power of Determinism in Database Systems
The Power of Determinism in Database SystemsThe Power of Determinism in Database Systems
The Power of Determinism in Database Systems
 

Andere mochten auch

交點台北Vol.9 - Allen - 如何操作夢
交點台北Vol.9 - Allen - 如何操作夢交點台北Vol.9 - Allen - 如何操作夢
交點台北Vol.9 - Allen - 如何操作夢交點
 
交點桃園 Vol.02 兩分鐘自我介紹
交點桃園 Vol.02 兩分鐘自我介紹交點桃園 Vol.02 兩分鐘自我介紹
交點桃園 Vol.02 兩分鐘自我介紹交點
 
ASSASSINO %22Rendezvous%22
ASSASSINO %22Rendezvous%22ASSASSINO %22Rendezvous%22
ASSASSINO %22Rendezvous%22Daniel Lim
 
希望之國簡介
希望之國簡介希望之國簡介
希望之國簡介交點
 
Algoritmos programacion psm
Algoritmos   programacion psm Algoritmos   programacion psm
Algoritmos programacion psm geraldinsalasj
 
交點桃園 Vol.01 兩分鐘自我介紹
交點桃園 Vol.01 兩分鐘自我介紹交點桃園 Vol.01 兩分鐘自我介紹
交點桃園 Vol.01 兩分鐘自我介紹交點
 
Test de adherencia de Sistemas a Procesos
Test de adherencia de Sistemas a ProcesosTest de adherencia de Sistemas a Procesos
Test de adherencia de Sistemas a ProcesosSusana Silberberg
 
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdt
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdtPresentación de Walter Tojo en Universidad Di Tella - Seminario TIdt
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdtSusana Silberberg
 
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdt
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdtPresentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdt
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdtSusana Silberberg
 
Anatomia coluna cervical
Anatomia coluna cervicalAnatomia coluna cervical
Anatomia coluna cervicalAndressa Thiago
 
Poesía Romántica
Poesía RománticaPoesía Romántica
Poesía RománticaFirst second
 
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDemo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDigiLocker
 

Andere mochten auch (15)

交點台北Vol.9 - Allen - 如何操作夢
交點台北Vol.9 - Allen - 如何操作夢交點台北Vol.9 - Allen - 如何操作夢
交點台北Vol.9 - Allen - 如何操作夢
 
交點桃園 Vol.02 兩分鐘自我介紹
交點桃園 Vol.02 兩分鐘自我介紹交點桃園 Vol.02 兩分鐘自我介紹
交點桃園 Vol.02 兩分鐘自我介紹
 
ASSASSINO %22Rendezvous%22
ASSASSINO %22Rendezvous%22ASSASSINO %22Rendezvous%22
ASSASSINO %22Rendezvous%22
 
Resume
ResumeResume
Resume
 
Article Noleggio Auto Milano (193)
Article   Noleggio Auto Milano (193)Article   Noleggio Auto Milano (193)
Article Noleggio Auto Milano (193)
 
希望之國簡介
希望之國簡介希望之國簡介
希望之國簡介
 
Estudio y..
Estudio y..Estudio y..
Estudio y..
 
Algoritmos programacion psm
Algoritmos   programacion psm Algoritmos   programacion psm
Algoritmos programacion psm
 
交點桃園 Vol.01 兩分鐘自我介紹
交點桃園 Vol.01 兩分鐘自我介紹交點桃園 Vol.01 兩分鐘自我介紹
交點桃園 Vol.01 兩分鐘自我介紹
 
Test de adherencia de Sistemas a Procesos
Test de adherencia de Sistemas a ProcesosTest de adherencia de Sistemas a Procesos
Test de adherencia de Sistemas a Procesos
 
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdt
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdtPresentación de Walter Tojo en Universidad Di Tella - Seminario TIdt
Presentación de Walter Tojo en Universidad Di Tella - Seminario TIdt
 
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdt
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdtPresentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdt
Presentación de Omar Vigetti en Universidad Torcuato Di Tella - Comunidad TIdt
 
Anatomia coluna cervical
Anatomia coluna cervicalAnatomia coluna cervical
Anatomia coluna cervical
 
Poesía Romántica
Poesía RománticaPoesía Romántica
Poesía Romántica
 
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLockerDemo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
Demo: How to get your Digital Aadhaar (eAadhaar) in DigiLocker
 

Ähnlich wie NoSQL Evolution

System design fundamentals CAP.pdf
System design fundamentals CAP.pdfSystem design fundamentals CAP.pdf
System design fundamentals CAP.pdfUsmanAhmed269749
 
Relational and non relational database 7
Relational and non relational database 7Relational and non relational database 7
Relational and non relational database 7abdulrahmanhelan
 
Understanding data
Understanding dataUnderstanding data
Understanding dataShahd Salama
 
No sql databases
No sql databases No sql databases
No sql databases Ankit Dubey
 
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...Big Data Storage Concepts from the "Big Data concepts Technology and Architec...
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...raghdooosh
 
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...Qian Lin
 
NoSQLDatabases
NoSQLDatabasesNoSQLDatabases
NoSQLDatabasesAdi Challa
 
NoSQL Database
NoSQL DatabaseNoSQL Database
NoSQL DatabaseSteve Min
 
NoSQL - Not Only SQL
NoSQL - Not Only SQLNoSQL - Not Only SQL
NoSQL - Not Only SQLEasyData
 
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...DataStax Academy
 
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?Clustrix
 
مقدمة عن NoSQL بالعربي
مقدمة عن NoSQL بالعربيمقدمة عن NoSQL بالعربي
مقدمة عن NoSQL بالعربيMohamed Galal
 
Handling Massive Writes
Handling Massive WritesHandling Massive Writes
Handling Massive WritesLiran Zelkha
 
Maximizing performance via tuning and optimization
Maximizing performance via tuning and optimizationMaximizing performance via tuning and optimization
Maximizing performance via tuning and optimizationMariaDB plc
 

Ähnlich wie NoSQL Evolution (20)

Hbase hive pig
Hbase hive pigHbase hive pig
Hbase hive pig
 
System design fundamentals CAP.pdf
System design fundamentals CAP.pdfSystem design fundamentals CAP.pdf
System design fundamentals CAP.pdf
 
Relational and non relational database 7
Relational and non relational database 7Relational and non relational database 7
Relational and non relational database 7
 
MongoDB
MongoDBMongoDB
MongoDB
 
Understanding data
Understanding dataUnderstanding data
Understanding data
 
No sql databases
No sql databases No sql databases
No sql databases
 
NoSQL and Couchbase
NoSQL and CouchbaseNoSQL and Couchbase
NoSQL and Couchbase
 
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...Big Data Storage Concepts from the "Big Data concepts Technology and Architec...
Big Data Storage Concepts from the "Big Data concepts Technology and Architec...
 
NoSql
NoSqlNoSql
NoSql
 
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
A Survey of Advanced Non-relational Database Systems: Approaches and Applicat...
 
Azure data platform overview
Azure data platform overviewAzure data platform overview
Azure data platform overview
 
NoSQLDatabases
NoSQLDatabasesNoSQLDatabases
NoSQLDatabases
 
NoSQL Database
NoSQL DatabaseNoSQL Database
NoSQL Database
 
NoSQL - Not Only SQL
NoSQL - Not Only SQLNoSQL - Not Only SQL
NoSQL - Not Only SQL
 
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
Tales From The Front: An Architecture For Multi-Data Center Scalable Applicat...
 
Master.pptx
Master.pptxMaster.pptx
Master.pptx
 
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?
Tech Talk Series, Part 2: Why is sharding not smart to do in MySQL?
 
مقدمة عن NoSQL بالعربي
مقدمة عن NoSQL بالعربيمقدمة عن NoSQL بالعربي
مقدمة عن NoSQL بالعربي
 
Handling Massive Writes
Handling Massive WritesHandling Massive Writes
Handling Massive Writes
 
Maximizing performance via tuning and optimization
Maximizing performance via tuning and optimizationMaximizing performance via tuning and optimization
Maximizing performance via tuning and optimization
 

Mehr von Abdul Manaf

MySQL HA Sharding-Fabric
MySQL HA Sharding-FabricMySQL HA Sharding-Fabric
MySQL HA Sharding-FabricAbdul Manaf
 
What's New In MySQL 5.6
What's New In MySQL 5.6What's New In MySQL 5.6
What's New In MySQL 5.6Abdul Manaf
 
Talend AS A Product
Talend AS A ProductTalend AS A Product
Talend AS A ProductAbdul Manaf
 
MySQL Replication Basics
MySQL Replication BasicsMySQL Replication Basics
MySQL Replication BasicsAbdul Manaf
 
MySQL Architecture and Engine
MySQL Architecture and EngineMySQL Architecture and Engine
MySQL Architecture and EngineAbdul Manaf
 
MariaDB Galera Cluster
MariaDB Galera ClusterMariaDB Galera Cluster
MariaDB Galera ClusterAbdul Manaf
 

Mehr von Abdul Manaf (6)

MySQL HA Sharding-Fabric
MySQL HA Sharding-FabricMySQL HA Sharding-Fabric
MySQL HA Sharding-Fabric
 
What's New In MySQL 5.6
What's New In MySQL 5.6What's New In MySQL 5.6
What's New In MySQL 5.6
 
Talend AS A Product
Talend AS A ProductTalend AS A Product
Talend AS A Product
 
MySQL Replication Basics
MySQL Replication BasicsMySQL Replication Basics
MySQL Replication Basics
 
MySQL Architecture and Engine
MySQL Architecture and EngineMySQL Architecture and Engine
MySQL Architecture and Engine
 
MariaDB Galera Cluster
MariaDB Galera ClusterMariaDB Galera Cluster
MariaDB Galera Cluster
 

NoSQL Evolution

  • 1. Rise of NoSQL February 15, 2016 Abdul Manaf
  • 2. Agenda • DBMS • Constraints & Problems with RDBMS – They are not constraints they are features of RDBMS • The Rise of NoSQL – History • NoSQL – A Alternative DBMS / Features • NoSQL – Categories • NoSQL – Benefits • NoSQL – Use Cases
  • 3. DBMS Storage and retrieval of data • Flat file systems • RDBMS – Structured data • OLAP – Cubes • NoSQL – Collections
  • 5. Relational Dominance • Store data persistently • Concurrency control • Transactions • Mostly standard interfaces and mechanisms to integrate application data • Reporting
  • 7. The RDBMS Bottleneck Here comes the Problems , Performance Bottleneck • My application is crawling • Queries are pretty slow • A single query takes hours to complete • Need to add a column to 1 TB of table Scale your Database • Vertical – Buy bigger boxes • Horizontal – Distributed systems General Problems • Not easy to scale after certain extent • The Natural Act – Pretty complex to manage • Cost of scaling is too high for Enterprise boxes – CPU Cycles – Memory – Disk – I/O Relational databases were not designed to run efficiently on clusters.
  • 8. NoSQL Movement • 3 V’s : Volume , Variety and Velocity • Movement away from using databases as integration points in favor of encapsulating databases with applications and integrating using services.
  • 9. NoSQL – Common Characteristics • Faster development Cycles
  • 15. Graph
  • 16. The CAP Theorem The CAP Theorem : It works for Distributed Systems • RDBMS v/s NoSQL • ACID v/s BASE
  • 17. CAP Theorem 1/2 ● It is impossible for a distributed computer system to simultaneously provide all three of the following guarantees: ○ Consistency (all nodes see the same data at the same time) ○ Availability (a guarantee that every request receives a response about whether it was successful or failed) ○ Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) • A distributed system can satisfy any two of these guarantees • at the same time, but not all three.
  • 18. CAP Theorem 2/2 ● In other words, CAP can be expressed as "If the network is broken, your database won’t work" ○ "won't work" = down OR inconsistent ● In RDBMS we do not have P (network partitions) ○ Consistency and Availability are achieved ● In NoSQL we want to have P ○ Need to select either C or A ○ Drop A -> Accept waiting until data is consistent ○ Drop C -> Accept getting inconsistent data sometimes
  • 20. ACID vs BASE Scalability and better performance of NoSQL is achieved by sacrificing ACID compatibility. Atomic, Consistent, Isolated, Durable NoSQL is having BASE compatibility instead. Basically Available, Soft state, Eventual consistency
  • 21. ACID -- Requirement for SQL DBs • Atomicity. All of the operations in the transaction will complete, or none will. • Consistency. Transactions never observe or result in inconsistent data. • Isolation. The transaction will behave as if it is the only operation being performed upon the database (i.e. uncommitted transactions are isolated) • Durability. Upon completion of the transaction, the operation will not be reversed (i.e. committed transactions are permanent)
  • 22. BASE -- Basically Available ● Use replication and sharding to reduce the likelihood of data unavailability and use sharding, or partitioning the data among many different storage servers, to make any remaining failures partial. ● The result is a system that is always available, even if subsets of the data become unavailable for short periods of time.
  • 23. BASE and Availability ● The availability of BASE is achieved through supporting partial failures without total system failure. ● Example. If users are partitioned across five database servers, BASE design encourages crafting operations in such a way that a user database failure impacts only the 20 percent of the users on that particular host. ○ This leads to higher perceived availability of the system. Even though a single node is failing, the interface is still operational.
  • 24. BASE -- Eventually Consistent ● Although applications must deal with instantaneous consistency, NoSQL systems ensure that at some future point in time the data assumes a consistent state. ● In contrast to ACID systems that enforce consistency at transaction commit, NoSQL guarantees consistency only at some undefined future time. ○ Where ACID is pessimistic and forces consistency at the end of every operation, BASE is optimistic and accepts that the database consistency will be in a state of flux.
  • 25. BASE and Consistency ● As DB nodes are added while scaling up, need for synchronization arises ● If absolute consistency is required, nodes need to communicate when read/write operations are performed on a node ○ Consistency over availability -> bottleneck ● As a trade-off, "eventual consistency" is used ● Consistency is maintained later ○ Numerous approaches for keeping up "distributed consistency" are available ■ Amazon Dynamo - consistent hashing ■ CouchDB - asynchronous master-master replication ■ MongoDB - auto-sharding+replication cluster with a master server
  • 26. BASE -- Soft State ● While ACID systems assume that data consistency is a hard requirement, NoSQL systems allow data to be inconsistent and relegate designing around such inconsistencies to application developers. ● In other words, soft state indicates that the state of the system may change over time, even without input. ○ This is because of the eventual consistency model (the acronym is a bit contrived).
  • 27. NoSQL • What is Missing • What is there
  • 29. When Not to Use
  • 31. Conclusion • All the choice provided by the rise of NoSQL databases does not mean the demise of RDBMS databases. • We are entering an era of polyglot persistence, a technique that uses different data storage technologies to handle varying data storage needs. • Polyglot persistence can apply across an enterprise or within a single application.