NoSQL
“NOT ONLY SQL”
Rahul P
CPS 5
Roll No:36
Why NoSQL
 The term “NoSQL” was first used by Carlo Strozzi
 The term “NoSQL” is often interpreted as “Not only SQL”
 Technical limitations shared by the majority of relational
database implementations
 Unprecedented transaction volumes
 Expectations of low-latency access to massive datasets,
 Nearly perfect service availability while operating in an
unreliable environment
 scalability, latency, and availability
DEFINITION
A NoSQL (often interpreted as Not Only
SQL) database provides a mechanism for storage
and retrieval of data that is modeled in means other
than the tabular relations used in
relational databases.
Features
 Schema-less
 Shared nothing architecture
 Sharding
 Asynchronous replication
 Follows CAP or BASE instead of ACID
Types of Nosql Databases
 Key-value store Database
Eg: Redis, Riak, Voldemort, MemCached
 Column-Family Database
Eg: BigTable, HBase, Cassandra
 Document store Database
Eg: SimpleDB, MongoDB, CouchDB
 Graph Database
Eg: Neo4j
Key-value store Database
 The simplest type of NoSQL Database
 Use Key-Value pairs in a hash table
 Unique Key as pointer to a Value
 RDBs pre-define the data structure
 Treat the data as a single opaque collection which may have different fields
for every record
When not use
 Relationships among Data
 Multi operation Transactions
 Query by Data
 Operations by Sets
When use
 Storing Session Information
 User Profiles, Preferences
 Shopping Cart Data
Column-Family Database
 Data stores in the cells that grouped in columns of data rather than as rows of
data
 Columns are grouped logically into column families
 Columns families can contains a virtually unlimited number of columns
 columnar storage is compression efficiency
 Minimizing storage
 Massively Parallel Processing (MPP) capability
When not use
 Systems that require ACID transaction
When use
 Event Logging
 Content Management Systems, Blogging Platforms
 Counters
 Expiring Usage
Document store Database
 Very similar to Key-Value database
 It are inherently a subclass of the key-value store
 Storing documents like XML ,JSON,BSON AND Custom
 It can do much more than the Key-value Store database
 DB must understand the content of the doc
 No database schema
When not use
 Complex Transactions Spanning Different Operations
 Queries against Varying Aggregate Structure
When use
 Event Logging
 Content Management Systems, Blogging
 Web Analytics or Real-Time Analytics
 E-Commerce Application
Graph Database
 Vertices and edges –Schema free
 It consists of Node, Edges and Properties
 Adjacency list
 similar to 1970s network-model databases
 Efficient querying of data in a network
 Often Used to store information about networks ,such as social connections
 It is much more faster than RDBMS
 Graph is stored in a format similar to a database index, minimizing its size
and retrieval time
When not use
 When you want to update all or a subset of entities
When use
 Connected Data
 Routing, Dispatch, and Location-Based Services
 Recommendation Engines
BANK DATABASE
Key Value
1 ID:1
Joining Date: 15-July-1985
Designation: Cashier
2 ID:2
Joining Date: 19-March-1982
Designation: Manager
3 ID:3
Joining Date: 4-April-1988
Designation: Front Desk Officer
Graph
Performance Scalability Flexibility Complexity Functionality
Key-Value
Stores
high high high none variable (none)
Column Stores high high moderate low minimal
Document
Stores
high variable(high) high low variable (low)
Graph
Databases
variable variable high high graph theory
Relational
Databases
variable variable low moderate relational algebra
ACID
 Atomicity
 Consistency
 Isolation
 Durability
BASE
 Basically Available
This constraint states that the system does guarantee the availability of the
data as regards CAP Theorem
 Soft state
The state of the system could change over time, so even during times without
input there may be changes going on due to ‘eventual consistency,’
 Eventual consistency
The system will eventually become consistent once it stops receiving input.
CAP
 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.
SQL vs NoSQL
 complex queries
 The type of data to be stored
 Scalability
 High transactional based application
 Support
 Properties
 DB types
NoSQL Databases
Advantages
 Non-Relational means table-less
 Mostly Open Source
 Easier scalability through support for Map Reduce
 Big data applications
 No need to develop a detailed database model
Disadvantages
 Lack of community
 Lack of reporting tools
 Doesn’t conform to ACID properties
 Lack of standardization
Question…......
Thank You

NoSQL(NOT ONLY SQL)

  • 1.
  • 2.
    Why NoSQL  Theterm “NoSQL” was first used by Carlo Strozzi  The term “NoSQL” is often interpreted as “Not only SQL”  Technical limitations shared by the majority of relational database implementations  Unprecedented transaction volumes  Expectations of low-latency access to massive datasets,  Nearly perfect service availability while operating in an unreliable environment  scalability, latency, and availability
  • 3.
    DEFINITION A NoSQL (ofteninterpreted as Not Only SQL) database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.
  • 4.
    Features  Schema-less  Sharednothing architecture  Sharding  Asynchronous replication  Follows CAP or BASE instead of ACID
  • 5.
    Types of NosqlDatabases  Key-value store Database Eg: Redis, Riak, Voldemort, MemCached  Column-Family Database Eg: BigTable, HBase, Cassandra  Document store Database Eg: SimpleDB, MongoDB, CouchDB  Graph Database Eg: Neo4j
  • 6.
    Key-value store Database The simplest type of NoSQL Database  Use Key-Value pairs in a hash table  Unique Key as pointer to a Value  RDBs pre-define the data structure  Treat the data as a single opaque collection which may have different fields for every record
  • 7.
    When not use Relationships among Data  Multi operation Transactions  Query by Data  Operations by Sets When use  Storing Session Information  User Profiles, Preferences  Shopping Cart Data
  • 8.
    Column-Family Database  Datastores in the cells that grouped in columns of data rather than as rows of data  Columns are grouped logically into column families  Columns families can contains a virtually unlimited number of columns  columnar storage is compression efficiency  Minimizing storage  Massively Parallel Processing (MPP) capability
  • 9.
    When not use Systems that require ACID transaction When use  Event Logging  Content Management Systems, Blogging Platforms  Counters  Expiring Usage
  • 10.
    Document store Database Very similar to Key-Value database  It are inherently a subclass of the key-value store  Storing documents like XML ,JSON,BSON AND Custom  It can do much more than the Key-value Store database  DB must understand the content of the doc  No database schema
  • 11.
    When not use Complex Transactions Spanning Different Operations  Queries against Varying Aggregate Structure When use  Event Logging  Content Management Systems, Blogging  Web Analytics or Real-Time Analytics  E-Commerce Application
  • 12.
    Graph Database  Verticesand edges –Schema free  It consists of Node, Edges and Properties  Adjacency list  similar to 1970s network-model databases  Efficient querying of data in a network  Often Used to store information about networks ,such as social connections  It is much more faster than RDBMS  Graph is stored in a format similar to a database index, minimizing its size and retrieval time
  • 13.
    When not use When you want to update all or a subset of entities When use  Connected Data  Routing, Dispatch, and Location-Based Services  Recommendation Engines
  • 14.
    BANK DATABASE Key Value 1ID:1 Joining Date: 15-July-1985 Designation: Cashier 2 ID:2 Joining Date: 19-March-1982 Designation: Manager 3 ID:3 Joining Date: 4-April-1988 Designation: Front Desk Officer Graph
  • 15.
    Performance Scalability FlexibilityComplexity Functionality Key-Value Stores high high high none variable (none) Column Stores high high moderate low minimal Document Stores high variable(high) high low variable (low) Graph Databases variable variable high high graph theory Relational Databases variable variable low moderate relational algebra
  • 16.
  • 17.
    BASE  Basically Available Thisconstraint states that the system does guarantee the availability of the data as regards CAP Theorem  Soft state The state of the system could change over time, so even during times without input there may be changes going on due to ‘eventual consistency,’  Eventual consistency The system will eventually become consistent once it stops receiving input.
  • 18.
    CAP  Consistency All nodessee 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.
  • 19.
    SQL vs NoSQL complex queries  The type of data to be stored  Scalability  High transactional based application  Support  Properties  DB types
  • 20.
  • 21.
    Advantages  Non-Relational meanstable-less  Mostly Open Source  Easier scalability through support for Map Reduce  Big data applications  No need to develop a detailed database model
  • 22.
    Disadvantages  Lack ofcommunity  Lack of reporting tools  Doesn’t conform to ACID properties  Lack of standardization
  • 23.
  • 24.