No SQL - A Simple Intro

NO SQL NO SQL

- What, Why , How, Where, Which- What, Why , How, Where, Which

What is NoSql..?What is NoSql..?

It is an approach to data management and It is an approach to data management and database design that's useful for very large database design that's useful for very large sets of distributed data.  sets of distributed data.  

Important Characteristics of NoSql Important Characteristics of NoSql DB are:DB are:

◦Non – Relational.◦ Distributed Architecture.◦ Horizontally Scalable(Shards).◦ Schema –Free.◦Open – Source.◦ Asynchronous Inserts & Updates.

Example :Example :

Types of NoSql Data Store:Types of NoSql Data Store:

Types of NoSql Data Store:Types of NoSql Data Store:

RedisDynamoMamCacheDB

CassandraBigTableHbase

MongoDBCouchDBSimpleDB

Graph Database:

Types of NoSql Data Store:Types of NoSql Data Store:

Neo4JBigData

Why NoSql..?Why NoSql..?

• RDBMS - ACID (Atomicity, Consistency, Isolation, and Durability).

The ACID properties of RDBMS guaranteed reliability by locking records while being updated.

• NoSQL - BASE (Basically Available, Soft-state, and Eventually Consistent)

This means while you can scale up your database and make it highly available, the consistency of data may not be immediate.

Features NoSql :Features NoSql :

Features NoSql :Features NoSql :

Scale Out (horizontal).Simpler data model (less joins).Redundancy/Reliability.Schema less.Rapid Development / coder friendly.Flexibility / semi-structured /

unstructured / structured

What NoSql Gives Up.. !:What NoSql Gives Up.. !:

Joins, group by, order by…No complex transactional support.A General Lack Of Maturity.Analytics and BI (It doesn’t play nice with

Analytics).Support / expertise availability.

How to Choose NoSql..?How to Choose NoSql..?

CAP Theorem : CAP Theorem :

http://www.brainsins.com/en/blog/main-big-data-technologies-nosql/2381

How to choose No Sql ? How to choose No Sql ?

Three primary concerns are, According to the CAP Theorem, you can only pick two.

◦ Consistency means that each client always has the same view of the data.

◦ Availability means that all clients can always read and write.

◦ Partition tolerance means that the system works well across physical network partitions.

Consistent, Available (CA) Systems Consistent, Available (CA) Systems have trouble with partitions and typically have trouble with partitions and typically deal with it with replication. deal with it with replication.

◦ Traditional RDBMSs like Postgres, MySQL, etc (relational)◦ Vertica (column-oriented)◦ Aster Data (relational)◦ Greenplum (relational)

Consistent, Partition-Tolerant (CP) Systems Consistent, Partition-Tolerant (CP) Systems have trouble with availability while keeping data have trouble with availability while keeping data consistent across partitioned nodes.consistent across partitioned nodes.

◦ BigTable  (column-oriented/tabular)◦ Hypertable  (column-oriented/tabular)◦ Hbase  (column-oriented/tabular)◦ MongoDB  (document-oriented) Redis (key-value)◦ Scalaris (key-value)◦ MemcacheDB (key-value)◦ Berkeley DB (key-value)

Available, Partition-Tolerant (AP) Systems Available, Partition-Tolerant (AP) Systems achieve "eventual consistency" through achieve "eventual consistency" through replication and verification. replication and verification.

◦ Dynamo (key-value)◦ Voldemort (key-value)◦ Cassandra (column-oriented/tabular)◦ CouchDB (document-oriented)◦ SimpleDB (document-oriented)◦ Riak (document-oriented)

Where to Use NoSql..?Where to Use NoSql..?

When we have scalability issues with your RDBMS, achieving scale at an acceptable cost

We have an application where data models change frequently and you cannot fix them, a pre-requisite for a RDBMS implementation

We deal with temporary data which does not get stored in the main transaction tables.

We can allow temporary inconsistencies of data e.g. updates on social networking sites can take time to be visible to all users

We need to query data which is non-hierarchical.

We have de-normalized data in your RDBMS.

Which is Better..?Which is Better..?

NoSQL SQL

Queries . +

Transactions . +

Consistency . +

Scalability + .

Management + .

Schema + .

SQL : SQL : Works Great, Can’t scale for Large Data

NoSQL :NoSQL :Works Great, Can’t fit for All

SQL + NoSQLSQL + NoSQL

Sineario1:

Transaction DB Aggregated Reporting DB

Report DB Session or Caching DB

Sineario 2:

Content DB

Sineario 4:

Sineario 3:

Transaction DB

ArchiveDB

Loging DB