NoSQL Databases

20-01-2026

UNIT II

UNIT:2

1. Comparison of relational databases to new NoSQL stores
2. MongoDB
3. Cassandra
4. HBASE
5. Neo4j use and deployment
6. Application RDBMS and NoSQL
7. RDBMS approach
8. NoSQL Challenges and approach,
9. Key-Value and Document Data Models,
10. Column-Family Stores
11. Aggregate-Oriented Databases
12. Replication and sharding
13. Map Reduce on databases
14. Distribution Models

,,

1. Single Server
2. Sharding,
3. Master-Slave Replication
4. Peer-to-Peer Replication

^20-01-5²⁰. ²⁶ Combining Sharding and Replication.

UNIT II

Comparison of relational databases to new NoSQL stores

UNIT II

20-01-2026

• Using Tables and Columns in Relational Databases

Comparison of relational databases to new NoSQL stores

UNIT II

20-01-2026

• Using Tables and Columns in Relational Databases
• RDBMS table has a few columns, sometimes tens of them-> Millions of rows could potentially be held in a relational table may bring the data access to a halt, unless special considerations like denormalization are applied.
• As you begin to use your table may need to alter it to hold a few additional attributes As newer records are stored may have null values for these attributes the existing records.
• Keeping greater variety of attributes the likelihood of sparse data sets sets with null in many cells becomes increasingly real.

Comparison of relational databases to new NoSQL stores

UNIT II

20-01-2026

Consider that this data is evolving and you have to store each version of the cell value as it evolves.

Think of it like a three-dimensional Excel spreadsheet, where the third dimension is time.

Then the values as they evolve through time could be thought of as cell values in multiple spreadsheets put one behind the other in chronological order.

Therefore

Altering the table as data evolves, storing a lot of sparse cells, and working through value versions can get complex

Comparison of relational databases to new NoSQL stores

UNIT II

20-01-2026

Comparison of relational databases to new NoSQL stores

UNIT II

20-01-2026

CONTRASTING COLUMN DATABASES WITH RDBMS

• First and foremost, a column-oriented database imposes minimal need for upfront schema definition and can easily accommodate newer columns as the data evolves.
• In a typical column-oriented store, you predefine a column-family and not a column.
• A column-family is a set of columns grouped together into a bundle.
• In a column database, a column-family is analogous to a column in an RDBMS.
• Both are typically defined before data is stored in tables and are fairly static in nature.
• Columns in RDBMS define the type of data they can store.
• Column-families have no such limitation; they can contain any number of columns, which can store any type of data, as far as they can be persisted as an array of bytes.

Comparison of RDB to new NoSQL stores

UNIT II

20-01-2026

• Each row of a column-oriented database table stores data values in only

those columns for which it has valid values.

Comparison of RDB to new NoSQL stores

UNIT II

20-01-2026

• Continuously evolving data would get stored in a column database as

shown in Figure

Comparison of RDB to new NoSQL stores

UNIT II

20-01-2026

• Select * from emp where id=1

Comparison of RDB to new NoSQL stores

UNIT II

20-01-2026

• Select first_namefrom emp where ssn=666

MONGODB Architecture

UNIT II

20-01-2026

MONGODB Architecture

UNIT II

20-01-2026

Replication in MONGODB

• MongoDB achieves replication using the concept replica sets
• A replica set is a group of mongodb instances that host the same data set.
• One of the nodes is selected as the primary or main node.
• The primary node receives all the operations from the user and the secondaries
• are updated from the primary one by using the same operation to maintain
• consistency.
• If the primary node goes down, one of the secondary nodes is selected as the
• primary node and the operations are carried forward.
• When the fallen node recovers, it joins the cluster as the secondary nodes.
• We can control our cluster of mongo instances using Mongo Atlas.

MONGODB Architecture

MONGODB sharding

UNIT II

20-01-2026

MONGODB Architecture

UNIT II

20-01-2026

Sharding in MONGODB

Sharding is used by MongoDB to store data across multiple machines.

It uses horizontal scaling to add more machines to distribute data and operation

with respect to the growth of load and demand.

Sharding arrangement in MongoDB has mainly three components:

​

1. Shards or replica sets
2. Configuration Servers
3. Query Router

MONGODB Architecture

Simple Sharding Setup

UNIT II

20-01-2026

MONGODB Architecture

A Redundant Sharding Configuration

UNIT II

20-01-2026

Cassandra Architecture

UNIT II

20-01-2026

Cassandra Architecture

UNIT II

20-01-2026

• Cassandra is designed such that it has no master or slave nodes.
• It has a ring type architecture, that is, its nodes are logically distributed like a ring.
• Data is automatically distributed across all the nodes.
• Data is replicated across the nodes for redundancy.
• Data is kept in memory and lazily written to the disk.
• Hash values of the keys are used to distribute the dataamong nodes in the cluster.

Cassandra Write Process

UNIT II

20-01-2026

Cassandra Write Process

UNIT II

20-01-2026

1. Data is written to a commitlog on disk.
2. The data is sent to a responsible node based on the hash value.
3. Nodes write data to an in memory table called memtable
4. From the memtable , data is written to an sstable in memory. Sstable stands for Sorted String table. This has a consolidated data of all the updates to the table.
5. From the sstable , data is updated to the actual
6. If the responsible node is down, data will be written to another node identified as tempnode . The tempnode will hold the data temporarily till the responsible node comes alive.

Cassandra Read Process

UNIT II

20-01-2026

Cassandra Read Process

UNIT II

20-01-2026

1. Data on the same node is given first preference and is considered data

local.

2. Data on the same rack is given second preference and is considered rack local.
3. Data on the same data center is given third preference and is considered

data center local.

4. Data in a different data center is given the least preference.
5. Data in the memtable and sstable is checked first so that thedata can be retrieved faster if it is already in memory.

Data Partitions

UNIT II

20-01-2026

1. Cassandra performs transparent distribution of data by horizontally

partitioning the data in the following manner:

2. A hash value is calculated based on the primary key of the data.
3. The hash value of the key is mapped to a node in the cluster
4. The first copy of the data is stored on that node.
5. The distribution is transparent as you can both calculate the hash value and determine where a particular row will be stored.

Data Partitions

UNIT II

20-01-2026

The following diagram depicts a four node cluster with token values of 0, 25,

50 and 75.

GOSSIP protocol

UNIT II

20-01-2026

• Cassandra uses a gossip protocol to communicate with nodes in a cluster.
• It is an inter node communication mechanism similar to the heartbeat protocol in Hadoop.
• The gossip process runs periodically on each node and exchanges state information with three other nodes in the cluster.
• Eventually, information is propagated to all cluster nodes.

HBASE Distributed Storage Architecture

UNIT II

20-01-2026

HBASE Distributed Storage Architecture

UNIT II

20-01-2026

HBase

UNIT II

20-01-2026

• HBase is a distributed column oriented database built on top of the

Hadoop file system

• It is an open source project and is horizontally scalable
• HBase is a data model that is similar to Google’s big table designed to provide quick random access to huge amounts of structured data
• It leverages the fault tolerance provided by the Hadoop File System (HDFS)
• It is a part of the Hadoop ecosystem that provides random real time read/write access to data in the Hadoop File System
• HBase deployment adheres to a master worker pattern
• Therefore, there is usually a master and a set of workers commonly known as region servers

HBase

UNIT II

20-01-2026

• HWhen HBase starts, the master allocates a set of regions to a region server
• Each region stores an ordered set of rows where each row is identified by a unique row key
• As the number of rows stored in a region grows in size beyond a configured threshold, the region is split into two and rows are divided between the two new ranges 35
• HBase stores columns in a column family together
• Therefore, each region maintains a separate store for each column family
• Each store in turn maps to a physical file that is stored in the underlying

distributed filesystem

• For each store, HBase abstracts access to the underlying filesystem with the help of a thin wrapper that acts as the intermediary between the store and the underlying physical file

HBase

UNIT II

20-01-2026

• Each region has an in memory store, or cache, and a write ahead log (WAL)
• When data is written to a region, it’s first written to the write ahead log.
• Soon afterwards, it’s written to the region’s in memory store.
• If thein memory store is full, data is flushed to disk and persisted in the underlying distributed storage.

Neo4j Architecture

UNIT II

20-01-2026

• Neo4j

Neo4j Architecture

UNIT II

20-01-2026

1. Reading the graph data from Neo4j Database
2. Loading (projecting) the data into an in memory graph
3. Running an algorithm on a projected graph
4. Writing the results back to Neo4j Database (if the algorithm runs in write mode)

Usecases

UNIT II

20-01-2026