1. NoSQL Database

2. Name : NoSQL ? ? ? ? SQL Adherence to Relational Schema
Poor response time
Problem : Database grew with Internet Giants
SQL
Adherence to Relational Schema
Strict to fixed schema
Support ACID
Traditional database
Analysis to find solution:
‘Big Data’ of variety of ‘small data’
(not fixed structured data collection)
NoSQL
Allow semi structure schema
Backend not need to only SQL
(Not Only SQL)
Do not guarantee ACID
Better scalability => performance
NewSQL
Allow semi structure schema
Support ACID

3. Database Traditional Data Mgt. task (1970’s): Recording Transactions
Advanced trend with time: Understand data and find patterns, trends,
Extract relevant information i.e. OLAP
 Required : Higher Horizontal scalability
Availability
RDBMS :
Traditional data store
+ ve : well-suited C/S programming, ACID properties, for structured data storage
Business Data procesing
ve : Little capable for Horizontal scalability
NoSQL : to achieve higher scalability and availability

4. Not suitable for Complex transaction
NoSQL
Scalability
Flexible schema
Simple interface
Share Nothing
NoSQL
No Join
Key lookup
Availability
Not suitable for Complex transaction
Not guaranteed ACID
BaSE
Performance

5. NoSQL Database First Introduced by Carlo Strozzi (1998),
concept : Relational Data Model + Not using SQL Interface
Major Focus : Horizontal scalability, Availability
Key features of Emerged Solution:
+ve : Higher Throughput
- ve : negotiate level of ACID degree to achieve performance and scalability
- ve : Not suitable for complex transaction
BASE (Basic Availability , Soft state , Eventually consistency)
“Share nothing” Horizontal scaling - replicate/partition over servers
key lookups, read/write 1 record / small set of records, simple selection
Efficient use of distributed indexes and RAM
simple call level interface (unlike SQL)
Flexible schema (Different records can have different schema)
No Join Support, No complex transaction support, No constraints support => But at application level

6. Vertical vs Horizontal scaling
Vertical Scaling
Horizontal Scaling
Basic Approach
Moving application to larger computer
Two vector :
Functional scaling ( Function groups across DBs)
Shading : data belongs to same Functional group
Performance
Better
Higher (based on local Function and Data)
Scalability
Limited due to outgrowing capacity of largest system
Higher (Independent functional scalability)
Cost
Expensive :
Need to purchase next larger system for increased capability support
Migration cost
Give up consistency for
Better performance
CAP Theorem (Eric Brewer):
“Web services cannot ensure all three of the following properties at once”
Consistency Ensures that a set of operations has occurred all at once.
Availability Every operation must terminate in an intended response.
Partition tolerance. Operations will complete, even if individual components are unavailable

7. Popular Categories of NoSQL Databases
Key-value Stores : store data values and index to find them
Document Stores : store documents; documents are indexed
Extensible Record Stores : Partitioning record over multiple data stores
Ref : Rick Cattell : Scalable SQL and NoSQL Data Stores.

8. CAP Theorem and NOSQL

9. Categories of NoSQL Databases
Category
Key-Value Store
Tabular
(Column-Family / BigTable)
Document Database
Graph Database
Based on
Amazon’s Dynamo Paper
Google’s BigTable Paper
Lotus Notes
Euler & Graph theory
Data Modal
Global Collection of K-V pair
BigTable,
Column Families
K-V collections
Nodes, Rels, K-V on both
Data Size Handling (scalability)
Highest
(stores only K-V
so, distributed to multiple nodes)
Next Higher
Smallest
(Limited to single node)
Data Complexity (connectivity /relationship) -
Little
Document link
Example
Riak, Voldemort, (Tokyo
Hbase, Hypertable, Cassendra (column-family), MonetDB
CouchDB, MongoDB
Neo4j, Allergo , Sones

10. Common concepts in NoSQL DB
Sharding :Partitioning mechanism, where records stored across servers according some keys
s.t. records on same node accessed together
Consistent Hashing : Same Hash Function for both Object hashing and node hashing
MAP-reduce : To process on large data sets using distributed computing on clusters
map function : processes key/value pair
intermediate results are consistently hashed as regular data
reduce function : merge all intermediate values associated with the same key
Vector -clocks : distributed data sets, No strict consistency,
versioning for concurrent updates (i.e. vi[0] = clock value of first node for ith data)
MVCC (Multiversion concurrency control): periodically sweep and delete old (obsolete) objects