NoSQL Database Notes and Sample Questions
1. Overview and History of NoSQL Databases
What is NoSQL?
• “NoSQL” stands for Not Only SQL.
• It is a class of database management systems that do not strictly follow the
relational model.
• Supports schema-less storage, horizontal scalability, and works well for semi-
structured/unstructured data.
Why did it emerge?
• Traditional RDBMS were built for structured data and transactional systems.
• Web 2.0 applications (social media, e-commerce, IoT) generated massive,
diverse, fast-changing datasets.
• Relational databases struggled with scalability, performance, and flexibility.
Historical milestones:
• 1970s: Edgar F. Codd proposed relational model → became industry standard.
• 1980s–90s: Relational DBs (Oracle, MySQL, PostgreSQL, DB2, SQL Server)
dominated.
• 2000s: Big players like Google (BigTable), Amazon (DynamoDB), and Facebook
(Cassandra) created internal distributed storage systems.
• 2009: Johan Oskarsson popularized the term “NoSQL” at a developer meetup.
• Now: NoSQL is mainstream, used with or alongside SQL (polyglot persistence).
Four Types of NoSQL Databases
1. Key-Value Stores
• Simplest model: Data stored as pairs → {Key : Value}.
• Optimized for speed (fast reads/writes).
• Examples: Redis, Riak, Amazon DynamoDB.
Use cases:
▪Caching (storing temporary results).
▪Session storage (e.g., user login sessions).
▪Real-time leaderboards in gaming.
2. Document Stores
• Store documents (JSON, BSON, or XML).
• Schema-free → Each document may have different fields.
• Examples: MongoDB, CouchDB.
Use cases:
▪ Product catalogs (e-commerce).
▪ Blogging/content management.
▪ IoT sensor logs.
3. Column-Family Stores
• Data organized into rows and dynamic columns grouped in families.
• Efficient for analytical queries and large-scale data.
• Examples: Apache Cassandra, HBase.
Use cases:
▪ Time-series data.
▪ Analytics over large datasets.
▪ Telecom call-record storage.
4. Graph Databases
• Store data as nodes (entities) and edges (relationships).
• Excellent for traversing relationships.
• Examples: Neo4j, Amazon Neptune, OrientDB.
Use cases:
▪ Social networks.
▪ Fraud detection.
▪ Recommendation systems.
3. The Value of Relational Databases
• Advantages:
• Structured, tabular storage → easy to understand.
• Uses SQL, a universal query language.
• Strong ACID properties ensure data integrity.
• Mature ecosystem (backups, replication, security).
• Limitations:
• Schema rigidity: Hard to adapt to fast-changing requirements.
• Vertical scaling: Adding CPU/RAM → expensive, limited.
• Joins across huge datasets = performance bottlenecks.
• Not designed for unstructured data (images, JSON, logs).
4. Getting at Persistent Data
• Persistent data = survives beyond program execution, stored on non-volatile media.
• In RDBMS: Stored in tables → requires object-relational mapping (ORM) for applications.
• In NoSQL: Stored closer to application structures:
o Key-Value → HashMap in code.
o Document DB → JSON-like objects in code.
o Graph DB → nodes/edges directly map to class relationships.
• Advantage: Reduces impedance mismatch, simplifies programming.
5. Concurrency
• RDBMS approach:
• Uses locks and transactions → ensures consistency, but may cause bottlenecks.
• Example: Two bank users withdrawing from same account → system locks record
until transaction completes.
• NoSQL approach:
• Often adopts eventual consistency.
• Multiple copies of data across distributed nodes → updates may propagate with
slight delay.
• Example: In DynamoDB, user A may see old value while user B sees updated
value, but both converge eventually.
6. Integration
• Traditional RDBMS:
• Centralized databases used by multiple applications → “integration databases.”
• Rigid schema = harder to integrate new, fast-changing data sources.
• NoSQL:
• Application-specific databases → optimized for that app/service.
• Easier integration with varied data sources (IoT, logs, social feeds).
• Fits modern microservices architectures.
7. Impedance Mismatch
• Definition:
• Mismatch between object-oriented application models and relational data
models.
• Example:
• Object “Student” with nested “Subjects” and “Grades” → must be split into
multiple tables in RDBMS.
• Requires ORM frameworks (Hibernate, JPA) → extra complexity.
• Solution in NoSQL:
• Store “Student” as a single JSON document containing nested lists.
• Natural mapping to application code → simpler, faster development.
8. Application vs Integration Databases
• Application Databases:
• Local to a specific application.
• Flexible schemas → developers can adapt quickly.
• Example: MongoDB used by an e-commerce cart service.
• Integration Databases:
• Shared by multiple applications.
• Requires strict schema and strong consistency.
• Example: ERP system storing HR, finance, and sales in one RDBMS.
• Trend: Microservices → use of application-specific NoSQL DBs with APIs for integration.
9. Attack of the Clusters
• Problem:
• Traditional RDBMS designed for single-server deployments.
• Web-scale applications needed hundreds of servers.
• Solution: Distributed clusters
• Sharding: Data split into chunks across servers.
• Replication: Copies of data kept across nodes.
• Load balancing: Queries distributed across servers.
• Impact:
• NoSQL databases are cluster-first systems.
• Built for horizontal scaling across commodity hardware.
10. Emergence of NoSQL
• Reasons:
• Big Data (huge datasets, real-time analytics).
• Cloud-native distributed apps.
• Mobile and IoT generating high-velocity data.
• Industry adoption:
• Google → BigTable.
• Amazon → DynamoDB.
• Facebook → Cassandra.
• Twitter → Redis, MySQL mix.
• Present:
• NoSQL used alongside RDBMS (polyglot persistence).
• Example: SQL for transactions + NoSQL for analytics.
11. Key Points
• SQL vs NoSQL:
• SQL → structured, ACID, reliable, but less flexible.
• NoSQL → schema-free, scalable, BASE, fits unstructured data.
• Four main NoSQL types: Key-Value, Document, Column-Family, Graph.
• Advantages of NoSQL:
• Handles unstructured data.
• Built for distributed systems.
• Reduces impedance mismatch.
• Applications: Social media, IoT, e-commerce, real-time analytics, cloud systems.
1. Comparison of Relational Databases vs New NoSQL Stores
Relational Databases (RDBMS)
• Schema: Fixed schema (tables, rows, columns).
• Query Language: SQL (standardized, powerful for joins and aggregations).
• Transactions: Strict ACID properties.
• Scaling: Vertical scaling (more CPU/RAM).
• Best suited for: Banking, ERP, transactional systems.
NoSQL Databases
• Schema: Schema-less, flexible.
• Query Model: APIs, JSON-like queries.
• Transactions: BASE properties, eventual consistency.
• Scaling: Horizontal scaling across clusters.
• Best suited for: Big Data, IoT, e-commerce, real-time analytics.
Key Point: RDBMS = reliable & structured. NoSQL = flexible & scalable.
2. Popular NoSQL Databases – Use and Deployment
• MongoDB (Document Store):
• JSON/BSON documents.
• Flexible schema, supports indexing, aggregation, and replication.
• Used for product catalogs, content management, real-time analytics.
• Cassandra (Column-Family Store):
• Based on Google BigTable.
• Designed for large-scale deployments, fault-tolerant.
• Used in Netflix, Facebook for large-scale time-series and user activity data.
• HBase (Column-Family Store):
• Built on top of Hadoop HDFS.
• Integrates with Hadoop ecosystem (MapReduce, Spark).
• Used for analytics over big datasets.
• Neo4j (Graph Database):
o Stores data as nodes & relationships.
o Query language: Cypher.
o Used for social networks, fraud detection, recommendation engines.
3. Applications
• NoSQL Databases:
• E-commerce catalogs → MongoDB.
• Real-time recommendation → Neo4j.
• Sensor/IoT data → Cassandra, HBase.
• Caching, leaderboards → Redis.
• RDBMS:
• Financial transactions.
• Enterprise systems (ERP, HR, Payroll).
• Applications needing strict ACID compliance.
4. RDBMS Approach vs NoSQL Approach
• RDBMS Approach:
• Normalize data to avoid redundancy.
• Complex joins to retrieve related information.
• Strong consistency, weaker scalability.
• NoSQL Approach:
• Aggregate-Oriented Design: Keep related data together (denormalization).
• Focus on high availability & partition tolerance.
• Eventual consistency in distributed systems.
5. Key-Value and Document Data Models
• Key-Value Model:
• Data stored as key–value pairs.
• Extremely fast for lookups.
• Example: Redis, DynamoDB.
• Use cases: Caching, session storage.
• Document Model:
• Data stored in JSON/BSON documents.
• Supports nested fields, schema-less design.
• Example: MongoDB, CouchDB.
• Use cases: E-commerce product catalogs, blogging, user profiles.
6. Column-Family Stores
• Based on Google’s BigTable model.
• Data stored in rows, but columns grouped into families.
• Efficient for analytical queries across very large datasets.
• Examples: Cassandra, HBase.
• Use cases: Telecom data storage, log analytics, time-series databases.
7. Aggregate-Oriented Databases
• Aggregate: A collection of data that is treated as a single unit.
• In NoSQL, aggregates are stored together → reduces need for joins.
• Example: A “Customer” document storing personal info + order history.
• Improves efficiency in distributed databases.
8. Replication and Sharding
• Replication:
• Keeping multiple copies of the same data on different nodes.
• Ensures fault tolerance and high availability.
• Sharding:
• Splitting database into smaller chunks distributed across servers.
• Improves scalability.
• Combining Sharding + Replication:
• Each shard replicated → ensures both scalability and reliability.
• Used in large-scale deployments like Facebook, Google.
9. MapReduce on Databases
• Programming model for distributed data processing.
• Map phase: Apply function to each piece of data (e.g., extract word counts).
• Reduce phase: Aggregate results (e.g., sum counts).
• Supported in MongoDB, Hadoop ecosystem.
• Example: Count total sales by product category across terabytes of logs.
10. Distribution Models in NoSQL
1. Single Server Model:
• All data stored on one server.
• Limited scalability, suitable for small deployments.
2. Sharding (Horizontal Partitioning):
• Data split across multiple servers.
• Example: User A’s data on server 1, User B’s data on server 2.
3. Master-Slave Replication:
• Master node = handles writes.
• Slave nodes = replicate data, handle reads.
• Advantage: reduces read load on master.
4. Peer-to-Peer Replication:
• Every node can act as master.
• Provides high availability.
• Example: Cassandra, DynamoDB.
5. Combining Sharding + Replication:
• Large datasets sharded across nodes.
• Each shard replicated for safety.
• Balances load + fault tolerance.
Key Challenges in Deploying NoSQL Databases
1. Data Modeling – Choosing the right model (Key-Value, Document, Column, Graph) is
complex; schema-less design may cause inconsistencies.
2. Lack of Standardization – No universal query language like SQL; each system has its own
syntax.
3. Consistency Issues – Eventual consistency may lead to stale reads and conflict resolution
problems (CAP theorem).
4. Scalability Setup – Sharding and replication need careful planning to avoid hotspots.
5. Security & Compliance – Weaker support for encryption, auditing, and regulatory needs
compared to RDBMS.
6. Integration & Migration – Shifting from RDBMS requires re-design and adapting
applications.
7. Operational Complexity – Managing distributed clusters, replication lag, and node
failures is difficult.
Sample question Answer
Q. Describe the architecture and working of master-slave replication. How does it ensure data
availability?
Master-Slave Replication: Architecture
Master-Slave replication is a database replication model where:
• Master Node
o The primary server that handles all write operations (INSERT, UPDATE, DELETE).
o Acts as the authoritative source of truth.
• Slave Nodes
o One or more secondary servers that receive a copy of the master’s data.
o Typically handle read operations (SELECT queries).
o Updated continuously from the master.
Architecture Flow:
1. Application sends write queries → Master.
2. Master executes changes and logs them (binary log / write-ahead log).
3. Slave servers read this log and apply the changes locally.
4. Applications can send read queries → Slave nodes to reduce load on the master.
2. Working Mechanism
1. Write Operation
o Master processes the write (e.g., INSERT INTO orders…).
o Records the change in a replication log (binlog in MySQL, WAL in PostgreSQL).
2. Log Shipping
o Slaves connect to the master and pull new changes from the log.
o Changes are transmitted asynchronously or semi-synchronously.
3. Apply Changes
o Slave nodes update their local database to stay consistent with the master.
4. Read Operations
o Applications route read-heavy queries to slaves.
o Improves performance and load balancing.
3. Ensuring Data Availability
• Redundancy:
o Data exists on multiple slave nodes in addition to the master.
o If the master fails, one slave can be promoted to master (manual or automatic
failover).
• High Availability:
o Slaves continue serving read queries even if the master is temporarily
unavailable.
o Reduces downtime during maintenance or failure.
• Disaster Recovery:
o Slaves act as backups since they maintain copies of the data.
o Useful for recovery in case of corruption or accidental data loss on the master.
• Scalability with Availability:
o Read operations can be scaled horizontally across multiple slaves.
o Ensures that system performance does not degrade even under heavy load.
4. Limitations
• Replication Lag: In asynchronous replication, slaves may fall behind the master.
• Single Point of Failure (Master): If the master crashes before syncing, some data may be
lost.
• Write Scalability: Writes are limited to a single master.
Q. Discuss the emergence of NoSQL in detail. Why did large companies move away from
RDBMS?
Answer:
• Web 2.0 apps generated large, diverse, high-velocity data.
• RDBMS struggled with: schema rigidity, expensive joins, vertical scaling limits.
• Companies like Google (BigTable), Amazon (Dynamo), and Facebook (Cassandra)
designed NoSQL systems.
• Key features: schema-less, horizontal scaling, BASE properties, cluster-first design.
• Result: NoSQL became essential for Big Data, IoT, and distributed apps.
Q. Compare Key-Value Stores, Document Stores, Column-Family Stores, and Graph Databases.
Provide real-world applications.
Answer:
• Key-Value: Simple lookups, used for caching, session management (Redis).
• Document: Flexible, JSON-like docs, used in e-commerce catalogs (MongoDB).
• Column-Family: Wide-column storage, used for analytics/logs (Cassandra, HBase).
• Graph: Relationships as first-class citizens, used in fraud detection, social networks
(Neo4j).
Q. Explain in detail replication and sharding, and why both are necessary in large-scale
distributed databases.
Answer:
• Replication ensures availability and fault tolerance. If one node fails, another
replica serves requests.
• Sharding ensures scalability, distributing data across many nodes.
• Together, they balance performance, reliability, and cost.
• Example: Facebook uses sharding for user data and replication for high availability.
Q. What are the challenges of RDBMS in Big Data environments, and how do NoSQL
databases solve them?
Answer:
• Challenges in RDBMS:
• Schema rigidity → unsuitable for changing datasets.
• Expensive joins for large data.
• Vertical scaling = costly.
• Poor handling of unstructured data (logs, images).
• NoSQL Solutions:
• Schema-less design (flexible).
• Aggregate-oriented storage reduces joins.
• Horizontal scaling → cheap commodity servers.
• Supports unstructured and semi-structured data.
Q. Compare relational databases with NoSQL databases in terms of schema design, scalability,
consistency, and use cases.
Answer:
• Schema Design:
• RDBMS: Rigid, predefined schema (tables, columns). Schema changes require
migrations.
• NoSQL: Schema-less or dynamic schema. Documents and key-value stores allow
flexible attributes.
• Scalability:
• RDBMS: Vertical scaling (adding more resources to one server). Costly and has
hardware limits.
• NoSQL: Horizontal scaling (adding more servers). Inherently distributed and cloud-
friendly.
• Consistency:
• RDBMS: Ensures strong ACID properties → strict consistency.
• NoSQL: Follows BASE → eventual consistency, prioritizing availability and
scalability.
• Use Cases:
• RDBMS: Banking, ERP, payroll, inventory management.
• NoSQL: Big Data, IoT, e-commerce catalogs, real-time analytics, social networks
Q. Explain MongoDB, Cassandra, HBase, and Neo4j with their architectures and real-world
applications.
Answer:
• MongoDB (Document Store):
• Stores data in JSON/BSON documents.
• Flexible schema, supports CRUD, indexing, and aggregation.
• Use Case: Product catalogs, content management.
• Cassandra (Column-Family Store):
• Based on Google’s BigTable model.
• Peer-to-peer architecture, no single point of failure.
• Use Case: Netflix user activity logging, Facebook Inbox search.
• HBase (Column-Family Store):
• Built on Hadoop HDFS.
• Integrates with Hadoop ecosystem (MapReduce, Spark).
• Use Case: Telecom data analytics, time-series data storage.
• Neo4j (Graph Database):
• Uses nodes (entities) and edges (relationships).
• Query language: Cypher.
• Use Case: Fraud detection, social network analysis, recommendation engines.
Q. What are aggregate-oriented databases? Explain their role in NoSQL design with examples.
Answer:
• Definition:
• Aggregate = a collection of related data treated as one unit.
• In NoSQL, instead of normalizing data across multiple tables, related information
is stored together.
• Importance:
• Reduces need for joins → faster queries in distributed environments.
• Works well with sharding since data chunks are self-contained.
• Examples:
• In MongoDB, a “Customer” document contains name, address, and complete
order history.
• In Cassandra, a wide row may store user and all login timestamps together.
• Advantages:
• Improves performance for distributed queries.
• Simplifies application logic (less ORM mapping).
• Supports microservices: Each service can manage its own aggregate DB.
Q. Explain replication and sharding in NoSQL databases. Why are they important? Provide
examples of databases that implement them.
Answer:
• Replication:
• Multiple copies of data are stored across nodes.
• Ensures high availability and fault tolerance.
• Example: MongoDB replica sets, Cassandra replication.
• Sharding:
• Horizontal partitioning of data across multiple servers.
• Improves scalability by distributing workload.
• Example: MongoDB sharding (by range or hash), HBase regions.
• Combining Both:
• Each shard is replicated → balances performance and fault tolerance.
• Example: Cassandra uses both peer-to-peer replication and partitioning.
• Importance:
• Large datasets cannot fit on a single machine.
• Ensures system can handle millions of queries per second.
Q. Explain the CAP theorem and its relevance to NoSQL system design. Provide examples of
databases favoring C, A, or P.
Answer:
• CAP Theorem (Eric Brewer, 2000): In a distributed system, it is impossible to
simultaneously guarantee all three:
1. Consistency (C): All nodes see the same data at the same time.
2. Availability (A): Every request gets a response (no failures).
3. Partition Tolerance (P): System continues to work despite network failures.
• Implication: Only two out of three can be fully guaranteed.
• Examples:
o CP (Consistency + Partition Tolerance): HBase → guarantees consistent reads but
may sacrifice availability.
o AP (Availability + Partition Tolerance): Cassandra, DynamoDB → always available
but allow eventual consistency.
o CA (Consistency + Availability): Traditional RDBMS (single-server) but not
partition tolerant.
Q. What is MapReduce in databases? Explain its working with an example.
Answer:
• Definition:
• A programming model for distributed data processing.
• Popularized by Google, integrated with Hadoop and MongoDB.
• Working:
1. Map Phase: Apply function to each record → outputs intermediate key-value pairs.
2. Shuffle Phase: Groups data by key.
3. Reduce Phase: Aggregates results.
• Example:
o Suppose we want to count sales per product category:
▪ Map: Emit (category, saleAmount).
▪ Shuffle: Group by category.
▪ Reduce: Sum amounts per category.
• Applications:
o Log analysis.
o Sales analytics.
o Large-scale indexing (Google Search).
Q. Why are relational databases still widely used despite the rise of NoSQL?
Why Relational Databases Are Still Widely Used
1. Maturity and Reliability
o RDBMS like Oracle, MySQL, PostgreSQL are stable and time-tested.
o Trusted in mission-critical industries such as banking and healthcare.
2. ACID Transactions
o Provide strong consistency and reliability for financial or transactional systems.
o Essential for operations like payments, inventory, and reservations.
3. Structured Data & Relationships
o Best suited when data is tabular and interrelated.
o Powerful joins and aggregations built into SQL.
4. Standard Query Language (SQL)
o SQL is a global standard, easy to learn and widely supported.
o Enables ad-hoc queries, analytics, and reporting.
5. Rich Ecosystem & Tools
o Mature support for ORMs, BI tools, backup, monitoring, and performance tuning.
o Large community and enterprise support available.
6. Regulatory & Compliance Support
o Built-in auditing, security, and logging features.
o Aligns with industry regulations (HIPAA, PCI DSS, GDPR).
7. Evolving Capabilities
o Modern RDBMS (e.g., PostgreSQL, MySQL) now support JSON and semi-
structured data.
o NewSQL systems combine RDBMS consistency with NoSQL scalability.
8. High Migration Costs
o Organizations already invested in RDBMS infrastructure and training.
o Migrating to NoSQL requires redesigning applications and retraining staff.
Q. Explain distribution models in NoSQL databases with examples.
Answer:
1. Single Server Model:
oAll data on one node.
oSimple but poor scalability.
oExample: Early MySQL deployments.
2. Master-Slave Replication:
o Master node handles writes, slaves replicate data for reads.
o Example: MySQL replication.
3. Peer-to-Peer Replication:
o All nodes equal, handle both reads and writes.
o Example: Cassandra, DynamoDB.
4. Sharding (Horizontal Partitioning):
o Data split across servers based on keys.
o Example: MongoDB sharding.
5. Sharding + Replication:
o Each shard replicated across nodes.
o Ensures fault tolerance + scalability.
o Example: Facebook, Google internal systems.
Q. Define replication and sharding in databases. Explain how these techniques improve
database scalability and fault tolerance.
Replication in Databases
Replication is the process of storing copies of the same data on multiple servers (nodes).
• Each replica contains the same dataset.
• If one server fails, another replica can quickly take over.
• Replication can be synchronous (data written to all replicas at once) or asynchronous
(data written first to a primary node, then later propagated to others).
Benefits:
• Fault Tolerance: If one node crashes, the system continues using other replicas.
• High Availability: Read queries can be spread across replicas, reducing load on the primary.
• Disaster Recovery: Replicas serve as backups.
Sharding in Databases
Sharding is the technique of splitting a large dataset into smaller, more manageable parts
(shards), each stored on a separate server.
• Each shard holds only a portion of the total data.
• Together, all shards form the complete dataset.
• A shard key (e.g., user ID, region) decides how data is divided.
Benefits:
• Scalability: Different shards can be distributed across many servers, allowing the system
to handle very large datasets and high transaction volumes.
• Load Balancing: Queries are directed to specific shards, reducing workload per server.
• Performance: Smaller datasets per shard mean faster queries and indexing.
How They Improve Scalability and Fault Tolerance
• Scalability:
• Replication: Helps with scaling reads (by directing read queries to replicas).
• Sharding: Helps with scaling writes and storage (by spreading data across servers).
• Fault Tolerance:
• Replication: Provides redundancy—if one replica fails, others serve the data.
• Sharding: Prevents a single server from becoming a bottleneck; with replication on
shards, the system remains operational even if one shard’s server fails.
Q. Explain database clustering in detail. What are its benefits, challenges, and role in improving
database scalability?
Database clustering is the process of linking two or more servers (nodes) together so they
function as a single database system.
• All nodes work on the same dataset or coordinate to provide services.
• Clustering focuses on high availability, load balancing, and scalability.
• A cluster manager (middleware or built-in database functionality) handles
communication, synchronization, and failover between nodes.
There are two main types:
1. Shared-Nothing Cluster – Each node has its own memory and disk. Data is partitioned
(sharded) across nodes.
2. Shared-Disk Cluster – All nodes share the same storage system, but each has its own
processor and memory.
Benefits of Database Clustering
a. Scalability
• Allows horizontal scaling (adding more nodes instead of upgrading a single machine).
• Workload is distributed across nodes, reducing bottlenecks.
b. High Availability & Fault Tolerance
• If one node fails, another can take over seamlessly (failover).
• Reduces downtime and improves reliability.
c. Load Balancing
• Incoming queries are spread across multiple nodes.
• Prevents overload on a single server and ensures consistent performance.
d. Improved Performance
• Parallel query processing across multiple nodes.
• Faster response times for large datasets and complex queries.
e. Maintenance Flexibility
• Nodes can be upgraded or maintained individually without taking the whole system
offline.
Challenges of Database Clustering
a. Complexity of Setup & Management
• Requires specialized configuration, monitoring, and administration tools.
• Synchronizing nodes (especially for write-heavy workloads) can be tricky.
b. Data Consistency Issues
• Ensuring ACID compliance across multiple nodes can introduce latency.
• Conflicts may arise if multiple nodes attempt simultaneous writes.
c. Cost
• Requires multiple servers, high-speed networking, and sometimes shared storage
infrastructure.
• Licensing costs can increase with cluster size.
d. Network Latency
• Inter-node communication may slow down query execution if not optimized.
e. Application Compatibility
• Some applications may need redesign to take advantage of clustering features.
4. Role in Improving Database Scalability
• Horizontal Scaling: Instead of buying one powerful server, organizations can add multiple
nodes to handle growth.
• Read/Write Separation: Some clusters allow read queries to be handled by replicas, while
writes go to the primary node.
• Distributed Processing: Queries can be parallelized across nodes, making large-scale
analytics faster.
• Elastic Growth: Cloud-based clusters (e.g., Amazon Aurora, Google Cloud Spanner,
Cassandra) let organizations scale on demand.
5. Examples of Database Clustering
• MySQL Cluster (NDB Cluster) – Shared-nothing architecture, suitable for telecom and
real-time apps.
• Oracle Real Application Clusters (RAC) – Shared-disk clustering with high availability.
• Cassandra / MongoDB Clusters – Shared-nothing clusters with built-in sharding +
replication.
• PostgreSQL Clusters (with Patroni or Citus) – Adds replication and scaling features.