MODULE 4:

NoSQL Databases
(Not only SQL)

Manu Ratheesh – GEC Wayanad 1

Why we need NoSQL systems
 Platforms like Facebook, Instagram manage huge amounts of data
from millions or billions of users.

 SQL databases are good for structured data with fixed tables, but
social media stores many types of data:
Posts: Text posts, images, videos
User profiles and relationships (friends, followers)

 Much of this data is unstructured or semi-structured, so strict

tables are hard to use.

 NoSQL databases are flexible and scalable, making it easy to store

and manage large, varied data.

 They also allow faster storage and retrieval, which is crucial for
platforms with millions of users. Manu Ratheesh – GEC Wayanad 2
Unstructured & Semi structured data
Semi-Structured Data:
 Information that does not reside in a relational database
 With some process, you can store them in the relational
database.
Example: XML data, JSON (JavaScript Object Notation), HTML
files

Unstructured data:
 These data do not have a predefined structure that database or
programs can easily interpret.
 Not a good fit for a relational database.
 Examples: PDF, Word, photos, videos, voice messages.
 Each piece is different in size, type, or content.
Manu Ratheesh – GEC Wayanad 3
What are NoSQL systems ?
 NoSQL systems are non-relational database systems designed
to store and manage large amounts of unstructured or semi-
structured data.

 NoSQL databases do not use the traditional table-based

structure like SQL databases. Instead, they offer flexible ways
to store data and can easily grow to handle large amounts of
information.

Manu Ratheesh – GEC Wayanad 4

NoSQL systems of Major companies
 Google created Google Bigtable, a NoSQL database used in
services like Gmail and Google Maps.

 Amazon developed Amazon DynamoDB, introducing key-value

data store databases.

 Facebook created Apache Cassandra, combining features of key-

value and column-based systems.

 Document-based NoSQL databases include MongoDB and

Apache CouchDB.

Manu Ratheesh – GEC Wayanad 5

Characteristics of NoSQL systems
1. Non-relational:
 NoSQL databases never follow the relational model
 Never provide tables with flat fixed-column rows
 Doesn’t require data normalization
 No complex features like query language, joins, referential
integrity constraints, ACID etc.

2. No Schema Required:
 NoSQL databases are either schema-free or have relaxed
schemas.
 NoSQL databases don’t need a fixed structure for data. Each
record can have different fields. For example, one record can
have a name and email, another can have name, email, and
interests.
 Do not require any sort of definition of the
Manu schema of the data. 6
Ratheesh – GEC Wayanad
Characteristics of NoSQL systems
3. Scalability:
 NoSQL systems support horizontal scalability, which means the
system can grow by adding more nodes (servers) to handle
increasing amounts of data and workload.
 Instead of upgrading a single machine (vertical scalability), new
nodes are added and the data is distributed among them without
stopping the system.
 This allows NoSQL databases to manage large-scale data
efficiently.
 Systems like MongoDB and Apache Cassandra scale horizontally
by distributing data across multiple servers.

Manu Ratheesh – GEC Wayanad 7

Characteristics of NoSQL systems
4. Availability, Replication, and Eventual Consistency:

 NoSQL systems are designed to provide high availability,

meaning the system continues to operate even if some nodes fail.
 To achieve this, data is replicated across two or more nodes. If
one node fails, the data can still be accessed from another node.
(Replication)
 However, write operations may be slower because updates must
be applied to all copies of the data.
 Instead of strict consistency, many NoSQL systems use eventual
consistency, where all copies of the data will become consistent
after a short period of time.

Manu Ratheesh – GEC Wayanad 8

Characteristics of NoSQL systems
5. High-Performance Data Access:
 NoSQL systems often store millions of records, so quickly finding
a specific record is important.

 Most systems use keys to locate data. The main technique used:
Hashing: A hash function is applied to the key, and the result
determines which node stores the record. This makes finding a
record very fast.

Example: If a database stores 10 million user records, a user’s

record can be quickly found using its unique key. NoSQL systems
like MongoDB and Cassandra use hashing techniques for fast and
efficient data access.

Manu Ratheesh – GEC Wayanad 9

Characteristics of NoSQL systems
6. Less Powerful Query Languages:
 Many NoSQL applications don’t need a complex query language
like SQL.
 Instead of SQL, NoSQL databases provide APIs (sets of functions)
that let programmers create, read, update, and delete data—these
are called CRUD operations.
 Some NoSQL systems also offer a query language, but it is simpler
than SQL.

Manu Ratheesh – GEC Wayanad 10

Characteristics of NoSQL systems
7. Versioning:
 Some NoSQL databases can store multiple versions of the same
data, along with the time each version was created.
 This lets the system keep a history of changes and retrieve older
versions when needed.

Example: In column-based NoSQL databases like Cassandra, you can

look at earlier versions of a record to see how the data has changed
over time.

Manu Ratheesh – GEC Wayanad 11

Difference between SQL and NoSQL systems

Relational Databases NoSQL database

Supports powerful query Supports very simple query
language language

It has a fixed schema No fixed schema

Follows ACID properties Follows BASE properties
(Atomicity, Consistency, (Basically Available, Soft State,
Isolation, Durability) Eventually Consistent)

Supports structured data Supports structured, semi-

structured & unstructured data

Manu Ratheesh – GEC Wayanad 12

CAP Theorem (Brewer’s Theorem)
 The CAP theorem states that it is not possible to guarantee all
three of the desirable properties—Consistency, Availability,
and Partition tolerance—at the same time in a distributed
system with data replication.

 The distributed system designer would have to choose two

properties out of the three to guarantee.

Manu Ratheesh – GEC Wayanad 13

Consistency (C):
 Every read receives the most recent write, and all
nodes/servers have the same copy of a replicated data at the
same time.
 Guarantees data correctness across all servers. Any update
operation on one node is immediately reflected on all other
nodes.

Example: Two ATMs for the same account: you withdraw $50
from ATM 1. ATM 2 must immediately show the updated balance
of $50.

 Every copy of the data is always up-to-date and consistent

across all nodes.

Manu Ratheesh – GEC Wayanad 14

Availability (A):
 Every request - whether reading or writing data - receives a
response, even if some servers are down.
 Focuses on keeping the system up and responsive at all times.
 Does not guarantee the data is the most recent; temporary
differences may exist.

Example: ATM 1 works, but ATM 2 is offline. You can still

withdraw money from ATM 1 without waiting.

Manu Ratheesh – GEC Wayanad 15

Partition tolerance (P):
 The system continues to operate correctly even if there are
network failures or communication breakdowns between
nodes.
 Ensures the system continues to provide service during
network problems.

Example: Two ATMs in different cities cannot communicate due

to network failure. Both ATMs still allow withdrawals, but
balances may temporarily differ until synchronization occurs.

Manu Ratheesh – GEC Wayanad 16

CAP theorem = No distributed system can have C, A and P all at
once.
Availability + Partition Tolerance (A + P): ATMs always let you
withdraw money, even if the network is broken. Balances may
temporarily differ (Inconsistency), but they sync later (Eventual
Consistency).

Consistency + Partition Tolerance (C + P): ATMs always show the

correct balance, even if the network is down. But withdrawals may
be blocked until nodes can sync. (Unavailability)

Consistency + Availability (C+A): To maintain both consistency and

availability, the system cannot tolerate network failures. Both can
be achieved only when the network connection between the nodes is
working.

Many modern distributed systems (Ex: social media) choose

Availability + Partition Tolerance instead ofManu
strict consistency.
Ratheesh – GEC Wayanad 17
BASE properties in NoSQL Databases
BA – Basically Available
 The system guarantees that every request receives a response,
even if some nodes fail or data is temporarily unavailable.
 The main goal is to keep the system running and accessible at all
times, even if not all data is fully updated.
 Connection to CAP: This corresponds to Availability (A).

Example: On Facebook, your feed loads immediately, even if some

new likes or posts haven’t updated everywhere yet.
In short: The app works right away, even if not all data is fully
updated.

Manu Ratheesh – GEC Wayanad 18

BASE properties in NoSQL Databases
S – Soft State
 In a NoSQL system, the data stored on different servers may
temporarily have different values. This can happen due to
network failures or replication delays, which may prevent
nodes from immediately sharing updates.

 The state of the system may change over time, even without
new input, due to data propagation and updates across nodes.

 It is called “soft” because the data is temporary and flexible,

eventually converging to a stable state through data
propagation and synchronization.

Manu Ratheesh – GEC Wayanad 19

BASE properties in NoSQL Databases
E – Eventually Consistent
 Eventual consistency means that all copies of the data in a
distributed system will become the same over time, even if they
are temporarily different.

 Updates may not appear on all nodes immediately. The system

allows temporary differences between replicas. After some
time, through synchronization, all copies converge to the same
value.

Manu Ratheesh – GEC Wayanad 20

Use Cases of NoSQL Databases
NoSQL databases are best when:
Data is unstructured or semi-structured
Applications need fast read/write performance
Systems must scale horizontally to millions of users
High availability is more important than strict consistency

1. Social Media Platforms: Social media generates huge

amounts of varied data, like user profiles, posts, likes,
comments, images, and videos. Relationships between users
(friends, followers, groups) are also complex. NoSQL can store
different types of data together without a fixed schema and
scale easily as users grow.
Example: Facebook, Instagram
Manu Ratheesh – GEC Wayanad 21
Use Cases of NoSQL Databases
2. Content & Media Platforms: Websites or apps manage
articles, videos, and multimedia files that may have different
structures. NoSQL can handle flexible data formats and large
media files.
Example: YouTube, Netflix

3. Internet of Things (IoT): IoT devices produce continuous

streams of sensor data that can be semi-structured or
unstructured. NoSQL can store and process massive amounts of
time-stamped data efficiently.
Example: Smart homes, connected cars, wearable fitness devices

Manu Ratheesh – GEC Wayanad 22

Use Cases of NoSQL Databases
4. E-Commerce Platforms: E-commerce sites store millions of
products, customer info, and orders, all with different attributes. A
flexible database makes it easy to update products and allows fast
searches and recommendations.
Example: Amazon, Flipkart

5. Gaming applications: Online games must keep track of player

profiles, scores, leaderboards, and in-game purchases instantly.
NoSQL allows fast reading and writing of data for millions of
players at the same time.
Example: PUBG

Manu Ratheesh – GEC Wayanad 23

Use Cases of NoSQL Databases

6. Messaging and Collaboration Platforms: Messaging apps

handle billions of messages, media files, notifications, and user
statuses daily. NoSQL supports high-speed storage and retrieval
and ensures availability even under heavy load.
Example: WhatsApp

Manu Ratheesh – GEC Wayanad 24

Limitations of NoSQL Systems
1. Limited Consistency: Many NoSQL systems follow eventual
consistency instead of strict consistency. Hence different nodes
may temporarily show different data.

Example: In a social media app, a friend’s like or comment might

not appear immediately on all devices.

2. No Complex Queries: NoSQL databases often don’t support

SQL-style joins or advanced queries easily. Combining data from
multiple collections or creating detailed reports can be more
difficult.

For example, creating a single report that includes orders,

customers, and products can be more complicated.
Manu Ratheesh – GEC Wayanad 25
Limitations of NoSQL Systems
3. Lack of Standardization: NoSQL comes in many types: key-
value, document, column, graph. Each system has different APIs
and query methods, making it hard to switch between databases.
Example: Moving from MongoDB (document) to Cassandra
(column) requires redesigning data and queries.

4. Limited Transaction Support: Most NoSQL systems do not

fully support ACID transactions. So, financial applications need
special methods to make sure all related updates happen
correctly.

Manu Ratheesh – GEC Wayanad 26

Limitations of NoSQL Systems
5. Memory and Storage Overhead: Many NoSQL systems store
multiple replicas for reliability. This increases storage
requirements and memory usage compared to traditional SQL
systems.

6. Eventual Data Convergence Delays: Updates take time to

propagate across nodes. Data may temporarily differ until the
system synchronizes all copies.

7. Steep Learning Curve: NoSQL databases often require

learning new data models, query methods, and APIs. Teams
experienced in SQL may take time to adapt and use NoSQL
efficiently.

Manu Ratheesh – GEC Wayanad 27

Types of NoSQL Systems

1. Document based NoSQL systems

2. Key-value based NoSQL systems
3. Column based NoSQL systems
4. Graph based NoSQL systems

Manu Ratheesh – GEC Wayanad 28

1. Document based NoSQL systems
 Document-based NOSQL systems typically store data as
collections of similar documents.
 These types of systems are also sometimes known as document
stores.

Ex: Students Collection

These documents are stored together in the Students collection.

Manu Ratheesh – GEC Wayanad 29

Documents are similar but not exactly the same
 Although the documents in a collection should be similar, they
can have different data elements (attributes).

Document 2 has an extra field email.

This is allowed in document databases.
In relational databases this would normally require changing the
table schema, but here it works [Link] Ratheesh – GEC Wayanad 30
No fixed schema required
 Traditional databases require a schema (structure defined before
storing data). All rows must follow the same columns.
Employee(Eid int, Ename varchar(20), Age int, Salary int)

 But document databases do not require this fixed structure. This

is called schema-less or flexible schema. New documents can
have new data elements that do not exist in any of the current
documents in the collection.

Manu Ratheesh – GEC Wayanad 31

Self-describing documents:
Documents contain both the data and the field names, so the system
understands the structure automatically.

name tells what the value "Rahul" represents

age tells what 20 represents

Manu Ratheesh – GEC Wayanad 32

Document formats
Documents can be stored in different formats, such as: XML, JSON
(most common)
XML format:

JSON format:

 JSON is very popular because it is simple, lightweight, and easy to

use with web applications.
Real examples of document databases: MongoDB, CouchDB
They store data as collections of JSON-like documents.
Manu Ratheesh – GEC Wayanad 33
A document-based NoSQL database stores data as
documents (like JSON objects) in collections. Each
document can have different fields, there is no fixed
schema, and documents are self-describing, making
the database very flexible.

Manu Ratheesh – GEC Wayanad 34

MongoDB Data Model
 In MongoDB, documents are stored inside collections. Each
collection contains many documents.
 To create a collection, the command createCollection is used.

"project" is the name of the collection.

The second part specifies options for the collection.
capped: true : Creates a capped collection. A capped collection has
fixed limits.
size: 1310720 → Maximum storage space allowed for the collection
(in bytes).
max: 500 → Maximum number of documents allowed in the collection.

Create another document collection called worker to store

information about the employees who work on each project.
Manu Ratheesh – GEC Wayanad 35
 In MongoDB, every document in a collection has a unique field called
_id. The _id field uniquely identifies each document, similar to a
primary key in relational databases.

 The value of _id can be:

User-defined (given by the user), or
System-generated if the user does not provide one.

 A system-generated _Id is a 16-byte value.

Every MongoDB document has a unique _id field, which can be

generated by the system or provided by the user, and it works like a
primary key.

Manu Ratheesh – GEC Wayanad 36

Design Options for Storing Project and Worker Data in
MongoDB:
[Link] Design (Embedded documents): Related data is
stored together in one document using embedded subdocuments. In
this case, a separate worker collection is not needed. The workers are
stored as an array inside the project document. This makes data
retrieval faster because all related information is in one place.

Manu Ratheesh – GEC Wayanad 37

2. Reference Design: Related data is stored in separate documents.
One document stores references (ObjectIds) to other documents.
Example: The project document stores worker IDs. The worker details
are stored in separate worker documents.

Manu Ratheesh – GEC Wayanad 38

3. Normalized Design: Project and worker data are stored in separate
documents. Each worker document includes a ProjectId to indicate
which project the worker belongs to.

Data insertion:

Manu Ratheesh – GEC Wayanad 39

MongoDB CRUD Operations with Project and Worker
Collections
1. Create (Insert):

2. Read (Find):
Ex: Find all workers with the role "Developer":

Manu Ratheesh – GEC Wayanad 40

MongoDB CRUD Operations with Project and Worker
Collections
3. Update
Ex: Update worker role in the worker collection:

4. Delete
Ex: Delete a worker from the worker collection:

Manu Ratheesh – GEC Wayanad 41

2. Key-Value based NoSQL systems

 These systems are designed to provide: High performance, High

availability & High scalability.

 A key-value database (key-value store) stores and manages data

using a simple key-value pair method. (key → value)

 Each data item is stored as a pair:

Key : a unique identifier
Value : the actual data associated with the key

Ex: S101 → {Name: “Rahul”, Age: 20, Course: “CSE”}

(Key : S101)

Manu Ratheesh – GEC Wayanad 42

Flexible Value Formats: (schema-less)
The value can have different formats depending on the key–value
system.
The value is simply a string or array of bytes:

Data may be stored in formats such as JSON.

Data may be rows similar to relational tuples. (structured data)

Manu Ratheesh – GEC Wayanad 43

 Unique Keys:
Every data item must have a unique key.
If the same key is used again, the existing value may be
overwritten.

 Fast Data Retrieval:

Data is retrieved directly using the key.
When the system receives a key, it directly retrieves the
associated value/data.
Ex: GET(S101) Output: {Name: “Rahul”, Age: 20, Course: “CSE”}
Because the value is accessed directly through the key, data
retrieval is extremely fast.

Manu Ratheesh – GEC Wayanad 44

Comparison with Document-Based NoSQL Databases
Document Database:
Data is stored as documents.
The database understands the fields inside the document.
Queries can be performed on individual fields.
Ex:

Key–Value Database:
Database retrieves the value using the key:
GET(S101)
The system generally does not query individual fields
inside the value.
To the database system, the value is usually treated as one single object.
S101 → "some data“
The database does not analyze fields like Name, Age, Course.
Manu Ratheesh – GEC Wayanad 45
DynamoDB
 DynamoDB is a NoSQL key–value database service developed by
Amazon
 Even though DynamoDB follows the key–value model, it organizes
data using three concepts: Tables, Items(rows) & Attributes
 A table is the main container that stores data in DynamoDB. A table
contains a collection of items (rows). (visual representation)
 DynamoDB tables do not require a fixed schema. Items in the
same table can have different attributes. Only the primary key
(Key in the key-value model) attribute is mandatory.

 Internally the database stores key-value pairs:

S101 → {Name: Rahul, Age: 20, Course: CSE}
S102 → {Name: Anu, Age: 21, Course: ECE, Email: anu@[Link]}
So although the data appears in table form, it is actually stored as
key–value pairs. Manu Ratheesh – GEC Wayanad 46
Summary:
 A Key–Value NoSQL database stores data as unique key–value
pairs, enabling extremely fast data retrieval.

 DynamoDB is a widely used key–value database that organizes data

using tables, items (rows), and attributes.

 Each item (row) is identified by a primary key, which acts as the key
in the key–value model, while the rest of the item represents the
value.

 Although DynamoDB displays data in a table-like structure,

internally it still follows the key → value storage model, allowing it
to provide high performance.

Manu Ratheesh – GEC Wayanad 47

Applications of Key–Value NoSQL Databases
 Because key–value databases store data as Key → Value pairs, the
system can directly retrieve the value using the key without performing
complex searches.
User Session Management:
Step 1: When a user logs into a website, the browser sends login
information to the web server.

Step 2: If the credentials are correct, the server creates a session to

remember the user. The server creates: a sessionID (unique identifier)
and session data.

Step 3: In a Key–Value database, this is stored as:

Session12345: Key
Session data: Value Manu Ratheesh – GEC Wayanad 48
Step 4: SessionID Sent to the Browser
The server sends the SessionID to the user's browser, usually stored in a
cookie.
cookie: SessionID = Session12345
The browser automatically sends this SessionID with every request.

Step 5: User Performs an Action (Click View Profile)

Suppose the user clicks “View Profile”. The browser sends a request to the
server along with the SessionID.

Step 6: Server Retrieves Session Data from the database

The server retrieves the session information from the Key–Value database.
Operation: GET(Session12345)
Database returns:
{ UserID : 101 Username : “Rahul” LoginTime : 10:30 AM}
Step 7: Using the session information, the server performs the requested
action. Example: Show user profile
Manu Ratheesh – GEC Wayanad 49
Why Key-Value databases for session management?

1. Very Fast Data Retrieval: When a user performs an action (like clicking
view profile), the system must quickly identify the user. The system
retrieves the session data using the SessionID key, which makes the lookup
very fast.
GET(Session12345)

2. Simple Key-Based Access: Session data is accessed using a single key

(SessionID). The system only needs the key to retrieve or update the session.

3. Handling Millions of Sessions: Large websites may have millions of users

logged in simultaneously. Key–Value databases can distribute sessions across
multiple servers, allowing the system to handle a large number of sessions
efficiently.

Manu Ratheesh – GEC Wayanad 50

3. Column based/Wide Column NoSQL systems

 Column-based NoSQL systems (also called wide column stores) are

designed to handle very large volumes of data efficiently.

 Instead of storing data strictly row-by-row like relational databases,

these systems store data column-wise instead of row-wise.

 Instead of storing an entire row together, the database stores each

value separately with its column information.

 Ex: Google BigTable, Apache HBase, Apache Cassandra etc.

Manu Ratheesh – GEC Wayanad 51

Data storage in Column based NoSQL Systems/Hbase
1. Problem with Traditional Row-Based Storage (Relational db)

Issues:
 Many columns may contain NULL values.
 Every row must follow the same structure.
 If we want to add a new attribute like Phone, we must modify the
table structure. This becomes inefficient when storing billions of
records.
Manu Ratheesh – GEC Wayanad 52
2. Column-Based Storage
 Column-based systems store data column-wise instead of row-wise.

 Instead of storing an entire row together, the database stores each

value separately with its column information.

 In Apache HBase, data is stored using:

Table + Row Key + Column Family + Column Qualifier +
Timestamp -> Value(or data)

Manu Ratheesh – GEC Wayanad 53

3. Important Concepts in Hbase/Column based Storage:

Table: Data is stored in tables.

Example table: EMPLOYEE

Row Key: Each row has a unique identifier called Row Key.
Example: row1
row2
row3
Rows are stored in sorted order, which helps in fast data retrieval.
Column Family: Columns are grouped into column families.
Example column families: Name
Details
They must be defined when the table is created.
Example command:
create 'EMPLOYEE’, 'Name’, 'Details' Manu Ratheesh – GEC Wayanad 54
Column Qualifier:
Column qualifiers are the actual column names inside a column
family.
Example: Name family:
Fname
Lname
Mname
Details family:
Job
Salary

Column qualifiers do not need to be predefined. They can be added

dynamically when inserting data.

Manu Ratheesh – GEC Wayanad 55

4. Data storage
Data is stored as individual cells rather than full rows. Each cell is
identified by:

create 'EMPLOYEE’, 'Name’, 'Details’

put 'EMPLOYEE’, 'row1’, 'Name:Fname’, 'John’

put 'EMPLOYEE’, 'row1’, 'Name:Lname’, 'Smith’
put 'EMPLOYEE’, 'row1’, 'Details:Job’, 'Engineer’
Internally stored as:

RowKey ColumnFamily ColumnQualifier Value

row1 Name Fname John

row1 Name Lname Smith

row1 Details Job Engineer

Each value is stored individually.

Manu Ratheesh – GEC Wayanad 56
4. Storage flexibility
The flexibility comes from Column Qualifiers.
In HBase: Only Column Families are fixed. Column Qualifiers can be
added anytime.

Row1: RowKey Column Value

row1 Name: Fname John
row1 Name: Lname Smith
row1 Details: Job Engineer
Row2:
RowKey Column Value
row2 Name:Fname Alicia
row2 Name:Mname Jennifer
row2 Name:Lname Zelaya
row2 Details:Job DBA
Row2 has Mname, but Row1 does not.
In relational databases this is not possible without altering the
table. In HBase it is allowed naturally. Manu Ratheesh – GEC Wayanad 57
Row3:
RowKey Column Value
row3 Name:Fname James
row3 Name:Lname Borg
row3 Details:Job CEO
row3 Details:Salary 1000000
Here Salary exists only for row3. Other rows do not store salary.
No NULL values are stored

Rows do not need the same structure. This is why the model is
flexible.

Manu Ratheesh – GEC Wayanad 58

5. Versioning using Timestamps
HBase can store multiple versions of the same data.

RowKey Column Value Timestamp

row1 Details: Salary 50000 t1
row1 Details: Salary 60000 t2

The system usually returns the latest version.

Manu Ratheesh – GEC Wayanad 59

6. Basic CRUD Operations in HBase
Create Table:

Insert Data:

Retrieve One Row:

Retrieve All Rows:

Manu Ratheesh – GEC Wayanad 60

 Key–Value Document Column-Based
Feature Graph Databases
Databases Databases Databases

Stores data as key → Stores data as Stores data by columns

Stores data as nodes
value pairs. Data is documents (JSON-like instead of rows,
Basic Idea (entities) and edges
retrieved quickly using objects) containing grouping columns into
(relationships).
the key. multiple fields. column families.

Data stored using

Very simple structure: a Each document RowKey + Data represented as
Data Structure key uniquely identifies a contains a set of fields- ColumnFamily + graph data structures
value. value pairs. ColumnQualifier → showing relationships.
Value.
Semi-flexible: column Highly flexible; nodes
Flexible schema,
Schema-less, values can families fixed, but and relationships can
Schema Flexibility documents may contain
store any type of data. columns can vary per have different
different fields.
row. properties.

Very limited; mainly key- Rich queries on Supports queries on Powerful relationship-
Query capability
based lookups. document fields. columns and ranges. based queries.

Big data storage, mail Social networks,

Caching, session Web applications, user
Typical Applications apps, large distributed recommendation
management etc. profiles.
systems. engines etc.

Apache HBase, Apache

Examples Amazon DynamoDB MongoDB, CouchDB Neo4j
Cassandra
Manu Ratheesh – GEC Wayanad 61