UNIT – III: KEY–VALUE STORE CONCEPTS

Q1. Explain the architecture and characteristics of a Key-Value Store with neat
examples.

Answer:
A Key-Value Store is the simplest and most fundamental form of a NoSQL database that
stores data as a collection of unique key–value pairs. The architecture is based on a
hash table, where the key acts as a unique identifier and the value holds the actual
data, which may be text, JSON, XML, or binary objects. The key–value model enables
constant-time data retrieval (O(1)) because lookups are done directly through hashing
mechanisms.

In distributed environments, data is partitioned (sharded) across multiple servers to

achieve horizontal scalability. Each node handles a subset of keys, and replication
ensures fault tolerance. Systems like Redis or Amazon DynamoDB maintain data in-
memory for faster access.

Characteristics: Key-Value stores are schema-less, support high throughput, and allow
atomic operations such as GET, PUT, and DELETE. They are ideal for applications
requiring rapid read/write operations.
Example:
"user:101" → {"name": "Alice", "email": "alice@[Link]", "age": 25}
This shows how a user record can be accessed instantly by key.

Q2. Describe di erent features of Key-Value Stores and discuss how they achieve
scalability and performance.

Answer:
Key-Value Stores are designed for simplicity, speed, and scalability. Their key features
include:

1. Schema-less Structure: No predefined schema is required; values can be

strings, JSON, or binary objects.

2. E icient Lookup: Constant-time retrieval (O(1)) through hashing techniques.

3. Horizontal Scalability: Data is partitioned across multiple nodes using

sharding or consistent hashing, ensuring balanced load and minimal
downtime.

4. Replication: Redundant data copies across nodes improve fault tolerance and
availability.
 5. High Performance: Many key-value stores (e.g., Redis, Memcached) use in-
memory caching to handle millions of operations per second.

Performance is achieved through reduced complexity (no joins or transactions),

asynchronous writes, and distributed caching. Systems like Amazon DynamoDB
automatically adjust partitions to handle workload increases.

In essence, the combination of replication, sharding, and in-memory caching makes

key-value stores extremely fast and scalable for large-scale, real-time applications such
as caching, session management, and IoT systems.

Q3. Analyze the di erent consistency models (strong, eventual, causal, session)
supported in Key-Value Stores with suitable examples.

Answer:
In distributed Key-Value stores, consistency defines how quickly updates propagate
across replicas.

 Strong Consistency: Ensures every read reflects the latest write. Suitable for
financial systems where correctness is critical. However, it may reduce
performance and availability.

 Eventual Consistency: Updates are propagated asynchronously; all replicas

converge over time. This is used in systems like Amazon DynamoDB, which
favors high availability.

 Causal Consistency: Guarantees that operations with cause–e ect

relationships appear in the same order to all clients. Ideal for collaborative or
social media applications.

 Session Consistency: Ensures a client sees its own updates within a session,
enhancing user experience.

The CAP theorem explains that a distributed system can only guarantee two out of
three: Consistency, Availability, and Partition Tolerance. Key-value stores typically
prioritize Availability and Partition Tolerance (AP) to achieve scalability.

Example: DynamoDB allows developers to choose between “eventually consistent”

and “strongly consistent” reads based on application needs.

Q4. Explain how transactions are handled in Key-Value Stores. Illustrate with
examples from Redis or DynamoDB.
Answer:
Transactions in Key-Value Stores ensure atomicity and consistency during multiple
operations. Most systems provide single-key atomic operations, meaning each GET,
PUT, or DELETE happens entirely or not at all.

 Single-Key Transactions: Atomic updates on a single item. Example:

SET balance:101 500
INCRBY balance:101 100 → updates are atomic in Redis.

 Multi-Key Transactions: Systems like Redis support the MULTI/EXEC block to

group operations. All commands execute sequentially and commit together.

 MULTI

 SET balance:1 100

 SET balance:2 200

 EXEC

Either both succeed or none do.

 DynamoDB Transactions: O er full ACID compliance across multiple items and

tables. These ensure consistency even in distributed setups.

Transactions rely on optimistic concurrency control (OCC), replication, and write-

ahead logs (WAL) to maintain durability and rollback in case of failure.

Q5. Discuss the query features available in Key-Value databases and compare
them with relational query capabilities.

Answer:
Key-Value databases o er simple yet e icient query capabilities focused on key-based
access.

Basic Operations:

 GET(key) retrieves a value.

 PUT(key, value) inserts or updates.

 DELETE(key) removes a key-value pair.

Advanced Queries:
Some systems allow range queries, composite keys, or secondary indexes for filtering
on attributes. Example: user:1001:order:05 fetches specific user order data.

Comparison with Relational Databases:

Feature Key-Value Store Relational DB

Query Type By key only Complex SELECT with WHERE/JOIN

Schema None Fixed

Joins Not supported Fully supported

Aggregation Application-level SQL-level support

While relational systems provide complex query functionality, Key-Value stores

prioritize speed and simplicity, trading query richness for performance and scalability.

Q6. Explain the structure of data in Key-Value Stores with examples for session
management or caching applications.

Answer:
In a Key-Value Store, data is stored as unique key–value pairs. The key acts as an
identifier, and the value can hold any structured or unstructured data such as JSON or
binary objects. The database functions like a large distributed dictionary.

Structure:

 Key → Value

 Example:
session:abc123 → {"user_id":101, "last_login":"2025-11-02"}

In session management, web applications store temporary user data (login tokens,
preferences) for quick access without constant database hits.
In caching, frequently accessed data is stored in-memory using tools like Redis or
Memcached.

The schema-less design supports di erent value structures for each key, enabling
flexibility. This makes key-value databases highly suitable for dynamic web and cloud-
based applications that demand low-latency access.

Q7. Describe how scaling is achieved in Key-Value Stores using sharding,

replication, and consistent hashing.

Answer:
Scaling in Key-Value Stores is crucial for handling massive data and high throughput.
 1. Sharding (Partitioning): The dataset is divided across multiple servers based on
hash or key range. Example: Redis Cluster partitions keys to di erent nodes
using hash slots.

2. Replication: Data copies are maintained across nodes (master–slave or peer-to-

peer). This ensures fault tolerance and high availability.

3. Consistent Hashing: A mathematical function distributes keys evenly across

nodes. When nodes are added or removed, minimal data reshu ling is needed,
ensuring balanced load.

These mechanisms together allow horizontal scalability — new nodes can be added
dynamically to increase capacity. For example, Amazon DynamoDB automatically
partitions and replicates data across multiple regions to maintain low latency and
continuous uptime.

Q8. Explain the suitable use cases for Key-Value Stores and justify why they are
preferred in applications like shopping carts or IoT systems.

Answer:
Key-Value Stores are ideal for scenarios requiring fast, simple lookups with massive
scalability.

Use Cases:

1. Session Management: Stores user sessions (e.g., login tokens).

2. Shopping Carts: Each user’s cart can be represented as {UserID → CartItems};

quick retrieval and updates make shopping experiences seamless.

3. Caching: Frequently accessed data cached in memory for faster load times.

4. IoT Applications: Sensor data like {device_id → reading} stored e iciently.

5. Real-Time Analytics: Used for leaderboard or gaming data.

Why Preferred:
They o er extremely fast reads/writes, horizontal scalability, and no schema
restrictions. Systems like Redis and DynamoDB provide durability and in-memory
caching, which is vital for performance-critical systems.
 UNIT – IV: DOCUMENT DATABASES

Q1. Explain the key characteristics of a document database, including schema-less

design, collection-oriented storage, and rich data representation. Illustrate with a
JSON document example for a customer entity.

Answer:
A document database is a type of NoSQL system designed to store, retrieve, and
manage semi-structured or unstructured data in the form of documents. Unlike
relational databases that use rigid tables and columns, document databases are
schema-less, allowing each document to have a di erent structure. Documents are
stored in standard formats such as JSON, BSON, or XML, making them easily readable
by modern web applications.

In a document database, records are organized into collections, which are logical
groupings similar to tables in SQL. However, collections impose no fixed schema,
o ering high flexibility. Each document is self-contained, storing all necessary
information about a single entity. This eliminates the need for complex joins.

Documents can include nested structures and arrays, enabling rich and hierarchical
data representation. For example:

"_id": "C1001",

"name": "Alice Johnson",

"email": "alice@[Link]",

"address": {"city": "Chennai", "zip": "600001"},

"orders": [{"order_id": "O101", "amount": 450}]

This single document encapsulates all customer details, demonstrating flexible

schema and nested data handling — key features of document databases like MongoDB
or CouchDB.

Q2. Discuss the advantages of document databases over relational databases,

focusing on flexibility, ease of development, high performance, and scalability.
Provide a comparison table highlighting how nested structures reduce the need for
joins.
Answer:
Document databases o er several advantages compared to traditional relational
databases.

1. Flexibility:
Schema-less structure allows developers to store documents with varying fields.
This adaptability supports fast-changing applications without schema
migrations.

2. Ease of Development:
The JSON/BSON format naturally integrates with programming languages like
JavaScript and Python, simplifying application development.

3. High Performance:
Data retrieval is faster because related information is embedded within a single
document — no need for time-consuming joins.

4. Scalability:
Supports horizontal scaling through sharding and replication, handling very
large datasets e iciently.

Feature Document DB Relational DB

Schema Dynamic Fixed

Joins Not required Required

Scaling Horizontal Vertical

Data Format JSON/BSON Tables/Rows

By embedding nested documents (like address or order lists) inside one record,
document databases reduce cross-table dependencies, achieving high performance in
web, e-commerce, and real-time analytics applications.

Q3. Di erentiate between strong consistency and eventual consistency in

document databases. Explain the CAP theorem trade-o s and describe
mechanisms like atomic writes and replication protocols used to achieve
consistency.

Answer:
Consistency in document databases ensures that all users view an accurate and up-
to-date version of data.
  Strong Consistency: Every read returns the most recent write. It guarantees
correctness but sacrifices availability in distributed systems. Example: A
MongoDB cluster with majority write acknowledgment ensures strong
consistency.

 Eventual Consistency: Updates propagate to replicas asynchronously; users

may temporarily read stale data, but replicas eventually converge. Systems like
CouchDB use this model to maintain high availability.

According to the CAP Theorem, a distributed system can ensure only two of three
properties — Consistency (C), Availability (A), and Partition Tolerance (P). Document
databases typically favor Availability and Partition Tolerance (AP) for scalability.

Mechanisms for Consistency:

1. Atomic Writes: Operations on a single document are atomic — either all

updates succeed or none do.

2. Replication Protocols: Data is copied across nodes (master–slave or multi-

master), and synchronization ensures consistency.

3. Versioning & Conflict Resolution: Multi-Version Concurrency Control (MVCC)

prevents data corruption during concurrent updates.

Thus, document databases achieve a balance between consistency and availability

depending on the application’s tolerance for stale data.

Q4. Describe the ACID properties in the context of document databases. Compare
single-document transactions with multi-document transactions, including
techniques like optimistic concurrency control and an example of a multi-
document transaction in MongoDB.

Answer:
Document databases support ACID properties to ensure data integrity.

 Atomicity: Every transaction completes entirely or not at all.

 Consistency: Data remains valid and follows constraints.

 Isolation: Transactions occur independently.

 Durability: Once committed, changes persist even after failures.

Single-Document Transactions are fully atomic. Each document update (like

modifying a customer profile) either succeeds or rolls back. Because documents are
self-contained, single updates are simple and fast.
Multi-Document Transactions (supported in MongoDB 4.0+) allow atomic updates
across multiple collections. However, they are more complex and slower due to
coordination overhead.

Example:

const session = [Link]();

[Link]();

try {

[Link]({_id:1}, {$inc:{balance:-50}}, {session});

[Link]({_id:2}, {$inc:{balance:50}}, {session});

[Link]();

} catch (e) {

[Link]();

Optimistic Concurrency Control (OCC) detects conflicting writes and retries

transactions. Such mechanisms ensure data consistency while maintaining scalability
in distributed document stores.

Q5. Elaborate on availability in document databases, including replication

methods such as master-slave and multi-master replication. Discuss the
consistency vs. availability trade-o and provide examples from MongoDB and
CouchDB.

Answer:
Availability in document databases means the system remains responsive even if
some nodes fail. It is achieved mainly through replication and clustering.

1. Replication Methods:

o Master–Slave (Primary–Secondary): A primary node handles all writes;

secondaries replicate data and serve reads. Example: MongoDB Replica
Sets automatically failover when the master fails.

o Multi-Master Replication: All nodes can accept writes simultaneously.

Conflicts may occur and are resolved using timestamps or merge rules.
Example: CouchDB employs multi-master replication with built-in
conflict resolution.
 2. Trade-O (CAP Theorem):

o Prioritizing Consistency (C) reduces availability during failures.

o Prioritizing Availability (A) allows continued operations but may serve

slightly stale data.

Example Systems:

 MongoDB: Ensures high availability using automatic failover and replica sets.

 CouchDB: Optimized for o line-first synchronization, prioritizing availability and

partition tolerance.

Thus, replication architectures balance uptime, fault tolerance, and data accuracy,
depending on system requirements.

Q6. Explain scaling strategies in document databases, including vertical and

horizontal scaling. Detail sharding with shard keys, its advantages, challenges like
hot spots, and the role of replication for read scaling. Include benefits for big data
applications.

Answer:
Scaling enables document databases to handle growing data and user demands
e iciently.

1. Vertical Scaling (Scaling Up): Upgrading server resources (CPU, RAM, storage).
It is simple but limited by hardware capacity.

2. Horizontal Scaling (Scaling Out): Distributing data across multiple servers

using sharding.

o Sharding: Divides data based on a shard key (e.g., user ID, region).

o Advantages: Balances workload, improves performance, and allows

near-linear growth.

o Challenges: Poor shard-key choice may cause hot spots, where some
nodes handle disproportionate tra ic.

Replication for Read Scaling: Secondary nodes replicate data to handle read-only
queries, improving throughput and availability.

Example:
MongoDB’s sharded cluster distributes collections across shards and maintains
replicas for fault tolerance.

Benefits for Big Data Applications:

  Supports large, rapidly changing datasets.

 Ensures consistent performance across distributed systems.

 Provides elastic growth with minimal downtime.

Q7. Outline the query features in document databases, covering basic queries (key-
based, field-based, comparison operators), advanced queries (range, pattern
matching, nested, array), and aggregation pipelines. Provide MongoDB examples
for student records and a comparison table with SQL equivalents.

Answer:
Document databases support both simple and advanced query mechanisms.

Basic Queries:

 Key-based Lookup: Retrieve by unique document ID.

[Link].find({_id:101})

 Field-based Query: Filter documents using conditions.

[Link].find({age:20})

Comparison Operators: $lt, $lte, $gt, $gte, $eq, $ne.

Example: [Link].find({marks:{$gt:50}})

Advanced Queries:

 Range Queries: Retrieve documents within value ranges.

 Pattern Matching: Using regex for text search — {name:{$regex:"^A"}}.

 Nested Queries: Query inside embedded documents —

{"[Link]":"Chennai"}.

 Array Queries: Match elements in arrays using $elemMatch.

Aggregation Pipelines:
Perform transformations like grouping and summarization —

[Link]([

{$match:{dept:"CSE"}},

{$group:{_id:"$dept", avgMarks:{$avg:"$marks"}}}

]);
SQL MongoDB

SELECT * FROM students WHERE marks>50 find({marks:{$gt:50}})

SELECT dept, AVG(marks) FROM students GROUP BY dept aggregate([...])

These rich query features make document databases powerful for analytics and
application data modeling.

Q8. Discuss suitable use cases for document databases such as event logging,
content management systems, blogging platforms, web analytics, and e-
commerce applications. For each, explain how flexible schema and nested
structures provide advantages over RDBMS, with document examples.

Answer:
Document databases are widely used where flexibility, scalability, and rapid schema
evolution are required.

1. Event Logging:
Applications like monitoring systems store log entries as JSON documents. Each
log can have di erent fields (timestamp, event, status), enabling flexible
analytics.

2. Content Management Systems (CMS) & Blogging Platforms:

Posts, authors, and comments can be stored in nested documents. Example:

3. { "title":"Post1", "author":"Keerthi", "comments":[{"user":"A","text":"Great!"}] }

This structure simplifies retrieval of entire content hierarchies in one query.

4. Web Analytics / Real-Time Analytics:

Document stores handle dynamic schemas where attributes like click data or
browser info vary between sessions.

5. E-Commerce Applications:
Product details with variable attributes (size, color, reviews) fit perfectly into
flexible JSON documents.

Compared to RDBMS, document databases remove join overhead, support hierarchical

data, and scale horizontally. This makes them ideal for fast-changing and data-rich
environments.
 UNIT – V: GRAPH DATABASES

Q1. Define a graph database and explain its core concepts: nodes (vertices), edges
(relationships), properties, and labels. Represent a social network example using
G=(V,E) notation, including relationships like FRIEND_OF and LIKES.

Answer:
A graph database is a specialized type of NoSQL database designed to represent and
store data as nodes and edges, focusing on the relationships between entities. It
follows a mathematical graph structure represented as G = (V, E), where V is the set of
vertices (nodes) and E is the set of edges (relationships).

 Nodes (Vertices): Represent entities such as users, products, or locations.

 Edges (Relationships): Connect nodes, showing how they interact, e.g.,

FRIEND_OF, PURCHASED, LIKES.

 Properties: Attributes assigned to both nodes and edges (e.g., name, date,
weight).

 Labels: Define categories or types of nodes (like Person, Movie, City).

Example – Social Network:

Let V = {Alice, Bob, Charlie} and E = { (Alice–FRIEND_OF→Bob), (Bob–LIKES→Post1) }.
This graph represents social relationships stored e iciently for traversal.

Graph databases such as Neo4j store and query relationships natively, providing
powerful relationship-based queries. The structure enables e icient traversal and
analytics in domains like social networks, recommendation engines, and fraud
detection.

Q2. Discuss the basics of graphs, including types (undirected, directed, weighted),
representation methods (adjacency matrix vs. list), basic terminology (degree,
path, cycle), and applications. Explain their relation to graph databases with
examples.

Answer:
A graph is a data structure that models relationships between entities. It consists of
nodes (vertices) and edges (connections).

Types of Graphs:

 Undirected Graph: Edges have no direction (e.g., mutual friendship).

 Directed Graph (Digraph): Edges have direction (e.g., FOLLOWS).

  Weighted Graph: Edges carry a value or cost (e.g., distance, rating).

Representation Methods:

1. Adjacency Matrix: A 2D matrix storing edges between nodes.

2. Adjacency List: A collection of lists showing each node’s connections — more

memory-e icient for sparse graphs.

Basic Terminology:

 Degree: Number of edges connected to a node.

 Path: A sequence of connected nodes.

 Cycle: A closed loop of edges.

Applications:
Graphs are used in social networks, transportation systems, web link analysis, and
recommendation engines.

Relation to Graph Databases:

Graph databases store data exactly in this format, allowing direct traversal using query
languages like Cypher or Gremlin. For example:

MATCH (a:Person {name:"Alice"})-[:FRIEND_OF]->(b)

RETURN [Link];

This query directly follows relationships in a social graph.

Q3. Describe the features of graph databases, including schema-free model,

relationship-oriented storage, e icient traversal, index-free adjacency, query
languages (Cypher, Gremlin, SPARQL), and ACID transactions. Provide a Cypher
query example for creating nodes and relationships in a movie scenario.

Answer:
Graph databases possess several features that di erentiate them from relational or
document databases:

1. Schema-Free Model: No rigid schema — nodes can have di erent sets of

properties, allowing flexibility.

2. Relationship-Oriented Storage: Relationships are stored as first-class entities,

not derived through joins.

3. E icient Traversal: Graphs can directly navigate from node to node in O(1) time
using pointers.
 4. Index-Free Adjacency: Each node directly references its adjacent nodes,
enabling high-speed traversal.

5. Query Languages:

o Cypher (Neo4j) – declarative pattern-based queries.

o Gremlin – procedural graph traversal language.

o SPARQL – used for RDF-based triple stores.

6. ACID Transactions: Supports atomic, consistent, isolated, and durable

operations for data integrity.

Example (Cypher Query – Movie Scenario):

CREATE (a:Actor {name:'Tom Hanks'})

CREATE (m:Movie {title:'Forrest Gump'})

CREATE (a)-[:ACTED_IN]->(m);

This example creates nodes for an actor and a movie and links them with a relationship,
demonstrating how graph databases natively store interconnected data.

Q4. Explain consistency models in graph databases (strong vs. eventual), CAP
theorem implications, and mechanisms like atomic transactions and replication
for data integrity in distributed environments.

Answer:
In graph databases, consistency ensures that all nodes and relationships remain
accurate across distributed systems.

 Strong Consistency: Every query returns the most updated data. Systems like
Neo4j Enterprise use synchronous replication for strong consistency.

 Eventual Consistency: Updates propagate asynchronously; replicas eventually

synchronize. This model is used by large-scale distributed systems such as
JanusGraph.

According to the CAP theorem, graph databases can guarantee only two of the
following at a time: Consistency (C), Availability (A), or Partition Tolerance (P). Most
graph databases opt for Consistency and Partition Tolerance (CP) since relationship
accuracy is vital.

Mechanisms Ensuring Consistency:

 1. Atomic Transactions: Operations like node creation or relationship updates are
atomic.

2. Replication: Data is copied across nodes to prevent data loss.

3. Write Quorums: Ensures a majority of replicas confirm a write before

committing.

4. Version Control: Tracks changes to prevent conflicting updates.

Such mechanisms ensure reliable, fault-tolerant graph data across distributed

environments while maintaining integrity and performance.

Q5. Elaborate on transactions and availability in graph databases, covering ACID

compliance (e.g., Neo4j), replication strategies (master-slave, multi-master), and
trade-o s. Provide examples from fraud detection systems.

Answer:
Graph databases like Neo4j maintain ACID compliance to ensure transaction
reliability.

ACID Properties:

 Atomicity: Each transaction executes entirely or not at all.

 Consistency: Maintains valid graph structures (no orphan edges).

 Isolation: Transactions run independently without interference.

 Durability: Committed changes persist despite failures.

Replication Strategies:

 Master–Slave (Leader–Follower): A master node processes all writes, and

replicas handle reads.

 Multi-Master: Multiple nodes handle writes simultaneously, requiring conflict

resolution mechanisms.

Availability Trade-o :
Prioritizing consistency may lower availability under network partitions (CAP theorem).
Some graph databases choose eventual consistency for continuous uptime.

Example – Fraud Detection:

In financial systems, a graph database can track transactions as relationships between
accounts. ACID compliance ensures that if a suspicious transaction rollback occurs,
data remains consistent across replicas. Replication ensures the fraud detection
system remains operational even during node failures.
Thus, graph databases maintain balance between data integrity and availability,
crucial for real-time, mission-critical analytics.

Q6. Discuss scaling in graph databases, including vertical vs. horizontal scaling,
sharding challenges for connected data, and the role of partitioning/replication in
large-scale networks like recommendation engines.

Answer:
Scaling in graph databases is more complex than in key-value or document stores due
to interconnected data.

 Vertical Scaling (Scaling Up): Adding more CPU, RAM, or storage to a single
machine. It o ers simplicity but limited scalability.

 Horizontal Scaling (Scaling Out): Distributing data across multiple servers or

clusters.

Sharding Challenges:
In graph databases, splitting data across servers (sharding) is di icult because
relationships may span shards. Traversing a path that crosses shard boundaries
increases latency. Maintaining referential integrity across partitions is also complex.

Solutions:

1. Data Partitioning: Group related nodes (e.g., users of the same region) within
the same shard.

2. Replication: Copy subgraphs to multiple nodes to improve performance and

fault tolerance.

3. Hybrid Scaling: Combine vertical and horizontal scaling for balanced e iciency.

Example – Recommendation Engines:

In systems like Netflix or Amazon, user–item relationships form massive graphs.
Replicated partitions allow parallel queries to compute recommendations e iciently.

Scaling thus ensures performance and fault tolerance for graph databases managing
billions of interconnected entities.

Q7. Outline query features in graph databases, including traversal queries,

pathfinding, and aggregation using Cypher. Provide examples for shortest path and
community detection, and compare with SQL joins in a performance table.

Answer:
Graph databases use query languages specifically designed to explore relationships.
Query Features:

1. Traversal Queries: Navigate relationships between connected nodes.

2. Pathfinding: Discover relationships such as shortest or longest paths.

3. Aggregation: Summarize patterns like degree count or community detection.

Examples (Cypher – Neo4j):

 Shortest Path:

 MATCH p=shortestPath((a:Person {name:'Alice'})-[*]-(b:Person {name:'Bob'}))

 RETURN p;

 Community Detection (e.g., mutual friends):

 MATCH (a:Person)-[:FRIEND_OF]->(b:Person)<-[:FRIEND_OF]-(c:Person)

 RETURN [Link], [Link], COUNT(b) AS mutualFriends;

Performance Comparison:

Feature Graph Query SQL Equivalent

Relationship Traversal Constant-time lookup Multi-join, slow

Path Search Built-in algorithms Complex recursive queries

Aggregation Pattern-based Table-based

Graph databases outperform SQL systems for highly connected data because they
avoid expensive joins by storing relationships natively.

Q8. Discuss suitable use cases for graph databases (connected data,
routing/dispatch/location-based services, recommendation engines) and when not
to use them. Explain advantages of native relationship storage with examples and a
use case mapping table.

Answer:
Graph databases excel when data is highly connected and relationships are first-class
citizens.

Suitable Use Cases:

1. Connected Data / Social Networks: Represent friendships, likes, or followers.

Example: (User)-[:FRIEND_OF]->(User).
 2. Routing & Logistics: Use weighted edges for shortest route or optimal delivery
paths (e.g., GPS navigation).

3. Recommendation Engines: Analyze relationships between users and products

to suggest similar items. Example: (User)-[:BOUGHT]->(Product) relationships
reveal buying patterns.

4. Fraud Detection: Identify suspicious transaction networks using pattern

queries.

When Not to Use:

For tabular or independent records (e.g., payroll, billing), relational or document
databases are more e icient.

Advantages:

 Direct traversal of relationships without joins.

 Fast querying of complex patterns.

 Intuitive representation of real-world networks.

Use Case Graph DB Advantage

Social Networks E icient relationship traversal

Routing Pathfinding algorithms

Recommendations Relationship-based filtering

Fraud Detection Pattern discovery

By leveraging native relationship storage, graph databases provide unparalleled

performance for connection-rich datasets.