Why NO-SQL ?

➢ Three interrelated megatrends

➢ Big Data
➢ Big Users
➢ Cloud Computing
are driving the adoption of NoSQL technology.
 Why NO-SQL ?
•Google, Amazon, Facebook, and LinkedIn were among the
first companies to discover the serious limitations of
relational database technology for supporting these new
application requirements.
 Why NO-SQL ?
•1,000 daily users of an application was a lot and 10,000 was an extreme
case.

•Today, most new applications are hosted in the cloud and

available over the Internet, where they must support global
users 24 hours a day, 365 days a year.
 Why NO-SQL ?
•More than 2 billion people are connected to the Internet worldwide

•– and the amount time they spend online each day is steadily growing

•– creating an explosion in the number of concurrent users.

•Today, it’s not uncommon for apps to have millions of different users a
day.
 Introduction
•New Generation Databases mostly addressing some of the points
–being non-relational
– distributed
–Opensource
–and horizontal scalable.
–Multi-dimensional rather than 2-D (relational)

➢ The movement began early 2009 and is growing rapidly.

▪ characteristics :
▪ schema-free
▪ Decentralized Storage System
▪ easy replication support
▪simple API, etc.
 Introduction
Application needs have been changing
dramatically, due in large part to three trends:
growing numbers of users that applications
must support growth in the volume and variety
of data that developers must work with; and the
rise of cloud computing.
• NoSQL technology is rising rapidly among
Internet companies and the enterprise because
it offers data management capabilities that
meet the needs of modern application:
 No-SQL (Examples)
•Cassandra
•MongoDB
•Ealsticsearch
•Hbase
•CouchDB
•BigTable (Google)
• Etc.
No-SQL
 Cassandra
•Cassandra is a distributed storage system for managing
very large amounts of data spread out across many
commodity servers.
•while providing highly available service with no single
point of failure.
•Cassandra aims to run on top of an infrastructure of
hundreds of nodes At this scale, small and large components
fail continuously.
•The way Cassandra manages the persistent state in the face
 Cassandra
•Facebook runs the largest social networking platform that
serves hundreds of millions users at peak times using tens of
thousands of servers located in many data centers around
the world.
•There are strict operational requirements on Facebook's
platform in terms of performance, reliability and efficiency,
and to support continuous growth the platform needs to be
highly scalable.
•Dealing with failures in an infrastructure comprised of
 Cassandra
•Cassandra is now deployed as the backend storage system
for multiple services within Facebook.

•To meet the reliability and scalability needs described

above Facebook has developed Cassandra.
•Cassandra was designed to full the storage needs of the
Search problem.
 Data Model (Cassandra)
•Cassandra is a distributed key-value store.
•A table in Cassandra is a distributed multi dimensional map
indexed by a key. The value is an object which is highly
structured.
•The row key in a table is a string with no size restrictions,
although typically 16 to 36 bytes long.
•Every operation under a single row key is atomic per
replica no matter how many columns are being read or
written into.
 Architecture (Cassandra)
•Cassandra is designed to handle big data workloads across multiple nodes with
no single point of failure.

• Its architecture is based in the understanding that system and hardware failure
can and do occur.

• Cassandra addresses the problem of failures by employing a peer-to-peer

distributed system where all nodes are the same and data is distributed among all
nodes in the cluster.

• Each node exchanges information across the cluster every second.

•A commit log on each node captures write activity to ensure data durability.
 Architecture (Cassandra)
•Data is also written to an in-memory structure, called a
memtable, and then written to a data file called an SStable
on disk once the memory structure is full.
•All writes are automatically partitioned and replicated
throughout the cluster.
•Client read or write requests can go to any node in the
cluster.
•When a client connects to a node with a request, that node
serves as the coordinator for that particular client operation.
 Cassandra (Properties)
•Written in: Java
•Main point: Best of BigTable and Dynamo
•License: Apache
•Querying by column
•BigTable-like features: columns, column families
•Writes are much faster than reads
•Map/reduce possible with Apache Hadoop.
 MongoDB
•What is?
•MongoDB is an open source, document-oriented database
designed with both scalability and developer agility in mind.
• Instead of storing data in tables and rows like as relational
database, in MongoDB store JSON-like documents with
dynamic schemas(schema-free, schemaless).
 MangoDB (Introduction)
•Written in: C++
•Main point: Retains some friendly properties of SQL
•License: AGPL (Drivers: Apache)
•Master/slave replication (auto failover with replica sets)
•Sharding built-in
•Queries are javascript expressions
•Run arbitrary javascript functions server-side
•Better update-in-place than CouchDB
•Uses memory mapped files for data storage
•An empty database takes up 192Mb
 Data Model
Data model: Using BSON (binary JSON), developers can
easily map to modern object-oriented languages without a
complicated ORM layer.
BSON is a binary format in which zero or more key/value
pairs are stored as a single entity.
lightweight, traversable, efficient.
 Schema Design
•{
• "_id" : ObjectId("5114e0bd42…"),
• "first" : "John",
• "last" : "Doe",
• "age" : 39,
• "interests" : [
• "Reading",
• "Mountain Biking ]
• "favorites": {
• "color": "Blue",
Supported Languages
 Architecture (MangoDB)
1. Replication
Replica Sets and Master-Slave
replica sets are a functional superset of master/slave.
 Architecture (Write process)
•All write operation go through primary, which applies the
write operation.
• write operation than records the operations on primary’s
operation log “oplog”
• Secondary are continuously replicating the oplog and
applying the operations to themselves in a asyn0chronous
process.
 Why replica sets
Data Redundancy
Automated Failover
Read Scaling
Maintenance
Disaster Recovery(delayed secondary)
 Architecture
2. Sharding
Sharding is the partitioning of data among multiple
machines in an order-preserving manner.(horizontal scaling )
 Features
•Document-Oriented storege
•Full Index Support
•Replication & High Availability
•Auto-Sharding
•Querying
•Fast In-Place Updates
•Map/Reduce
 HBase
•HBase was created in 2007 at Powerset and was initially part of the contributions in Hadoop.

•Since then, it has become its own top-level project under the Apache Software Foundation
umbrella.

• It is available under the Apache Software License, version 2.0.

 Hbase
Features
–non-relational
– distributed
–Opensource
–and horizontal scalable.
–Multi-dimensional rather than 2-D (relational)
▪ schema-free
▪ Decentralized Storage System
▪ easy replication support
▪simple API, etc.
 Basic Architecture
Tables, Rows, Columns, and Cells
–the most basic unit is a column.

– One or more columns form a row that is addressed uniquely by a row key.

– A number of rows, in turn, form a table, and there can be many of them.

– Each column may have distinct value contained in a separate cell.

 Architecture
•All rows are always sorted lexicographically by
their row key.
 Architecture
•Rows are composed of columns, and those, in turn, are grouped into
column families.
•All columns in a column family are stored together in the same low level
storage file, called an HFile.

•millions of columns in a particular column family.

•There is also no type nor length boundary on the column values.

Rows and Columns in HBase
Thanks