Unit 4 – NoSQL Databases

Theory

1. What is NoSQL

NoSQL stands for "Not Only SQL" and refers to a class of database management systems that provide a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. NoSQL databases are designed to handle large volumes of unstructured, semi-structured, and structured data at massive scale.

NoSQL databases emerged in the late 2000s to address the limitations of traditional RDBMS when dealing with Big Data, real-time web applications, and distributed computing environments. They prioritize scalability, flexibility, and availability over the strict consistency guarantees of relational databases.

Key Point: NoSQL databases are not a replacement for SQL databases but rather a complementary technology. They excel in scenarios requiring horizontal scaling, flexible schemas, and high availability across distributed systems.
1
NoSQL Database Overview
graph TD A[NoSQL Databases] --> B[Document] A --> C[Key-Value] A --> D[Column-Family] A --> E[Graph] B --> B1[JSON/BSON Documents] B --> B2[MongoDB, CouchDB] C --> C1[Simple Key-Value Pairs] C --> C2[Redis, DynamoDB] D --> D1[Wide Column Tables] D --> D2[Cassandra, HBase] E --> E1[Nodes & Edges] E --> E2[Neo4j, Amazon Neptune] classDef decision fill:#d97706,stroke:#f59e0b,color:#fff,font-size:18px,font-weight:bold classDef process fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef success fill:#22c55e,stroke:#4ade80,color:#fff,font-size:18px,font-weight:bold classDef warning fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef info fill:#8b5cf6,stroke:#a78bfa,color:#fff,font-size:18px,font-weight:bold class A decision class B,C,D,E process class B1,C1,D1,E1 success class B2,C2,D2,E2 info
NoSQL databases are categorized into four main types based on their data model. Each type is optimized for specific use cases and access patterns.

2. Types of NoSQL Databases

NoSQL databases are classified into four primary types based on their underlying data model:

1. Document Store: Stores data as JSON/BSON documents with nested structures. Each document is a self-contained unit with its own schema. Ideal for content management, user profiles, and catalogs. Examples: MongoDB, CouchDB, Amazon DocumentDB.

2. Key-Value Store: Simplest NoSQL model storing data as key-value pairs. Highly optimized for fast reads and writes. Used for caching, session management, and real-time data. Examples: Redis, Amazon DynamoDB, Memcached.

3. Column-Family Store: Organizes data into rows and column families rather than fixed columns. Excellent for large-scale analytical queries and time-series data. Examples: Apache Cassandra, HBase, Google Bigtable.

4. Graph Database: Stores data as nodes (entities) and edges (relationships). Optimized for traversing relationships and pattern matching. Used for social networks, fraud detection, and recommendation engines. Examples: Neo4j, Amazon Neptune, ArangoDB.

Key Point: The choice of NoSQL database type depends on your data model, query patterns, consistency requirements, and scalability needs. Document stores offer the most flexibility, while graph databases excel at relationship-heavy queries.

3. Document Store – MongoDB

MongoDB is the most popular document-oriented NoSQL database, storing data in flexible JSON-like BSON documents. It provides rich query language, secondary indexes, aggregation framework, and horizontal scaling through sharding.

Key Features: Dynamic schema, embedded documents and arrays, rich query operators, aggregation pipeline, replica sets for high availability, and auto-sharding for horizontal scaling. MongoDB Atlas provides a fully managed cloud database service.

Use Cases: Content management systems, product catalogs, user profile management, IoT data storage, real-time analytics, and mobile app backends. MongoDB handles high write throughput and complex document structures efficiently.

Key Point: MongoDB stores data in collections (similar to tables) containing documents (similar to rows). Each document can have a different structure, enabling rapid iteration and schema evolution without downtime.

4. Column-Family – Cassandra & HBase

Apache Cassandra is a distributed column-family database designed for extreme scalability and high availability. It uses a masterless architecture with peer-to-peer nodes, eliminating single points of failure. Cassandra follows an eventual consistency model and excels at write-heavy workloads.

Apache HBase is a column-oriented database built on top of Hadoop HDFS. It provides real-time random read/write access to large datasets and integrates well with the Hadoop ecosystem. HBase uses a master-slave architecture with HMaster and RegionServers.

Key Differences: Cassandra uses a ring architecture with no master node, while HBase relies on a master node. Cassandra is better for multi-datacenter deployments, while HBase integrates more naturally with Hadoop MapReduce for batch processing.

Key Point: Cassandra is used by companies like Apple, Netflix, and Instagram handling petabytes of data across thousands of nodes. HBase powers Facebook's messaging infrastructure and Twitter's timeline storage.
2
NoSQL Database Types & Use Cases
graph TD A[NoSQL Types] --> B[Document Store] A --> C[Key-Value Store] A --> D[Column-Family] A --> E[Graph Database] B --> B1[Content Management] B --> B2[Product Catalogs] B --> B3[MongoDB, CouchDB] C --> C1[Caching & Sessions] C --> C2[Real-time Data] C --> C3[Redis, DynamoDB] D --> D1[Time-Series Data] D --> D2[Analytics at Scale] D --> D3[Cassandra, HBase] E --> E1[Social Networks] E --> E2[Fraud Detection] E --> E3[Neo4j, Neptune] classDef decision fill:#d97706,stroke:#f59e0b,color:#fff,font-size:18px,font-weight:bold classDef process fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef success fill:#22c55e,stroke:#4ade80,color:#fff,font-size:18px,font-weight:bold classDef warning fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef info fill:#8b5cf6,stroke:#a78bfa,color:#fff,font-size:18px,font-weight:bold class A decision class B,C,D,E process class B1,C1,D1,E1 success class B2,C2,D2,E2 success class B3,C3,D3,E3 info
Each NoSQL type serves specific use cases. Document stores are versatile, key-value stores are fast, column-family databases scale massively, and graph databases excel at relationships.

5. CAP Theorem

The CAP Theorem, formulated by Eric Brewer in 2000, states that a distributed data store can provide only two of the following three guarantees simultaneously:

Consistency (C): Every read receives the most recent write or an error. All nodes see the same data at the same time.

Availability (A): Every request receives a non-error response, without guaranteeing it contains the most recent write. The system is always operational.

Partition Tolerance (P): The system continues to operate despite network partitions (communication breakdowns between nodes). In distributed systems, partitions are inevitable.

Since network partitions are unavoidable in distributed systems, real-world systems must choose between Consistency and Availability during a partition. This leads to three main categories: CP (Consistent & Partition-tolerant), AP (Available & Partition-tolerant), and CA (Consistent & Available – only possible without network partitions).

Key Point: Most NoSQL databases are either CP or AP. MongoDB and HBase are CP systems prioritizing consistency, while Cassandra and DynamoDB are AP systems prioritizing availability. Understanding CAP helps in choosing the right database for your use case.

6. SQL vs NoSQL

Understanding the differences between SQL and NoSQL databases is crucial for choosing the right technology:

Data Model: SQL uses rigid tabular structures with predefined schemas, while NoSQL supports flexible models (documents, key-value pairs, columns, graphs) with dynamic schemas.

Scalability: SQL databases scale vertically (bigger hardware), while NoSQL databases scale horizontally (adding more machines). NoSQL is designed for distributed, clustered environments.

Consistency: SQL follows ACID properties (Atomicity, Consistency, Isolation, Durability) for strong consistency. NoSQL often follows BASE model (Basically Available, Soft state, Eventual consistency) for higher availability.

Query Language: SQL uses standardized Structured Query Language. NoSQL databases have proprietary query languages or APIs (e.g., MongoDB's MQL, Cassandra's CQL).

Best For: SQL excels at complex joins, transactions, and structured data. NoSQL excels at massive scale, flexible schemas, and high-speed read/write operations.

Key Point: Modern applications often use polyglot persistence – combining both SQL and NoSQL databases to leverage the strengths of each. For example, using MySQL for transactional data and MongoDB for product catalogs.
3
SQL vs NoSQL Decision Flow
graph TD A[Data Storage Need] --> B{Complex Joins Required?} B -->|Yes| C[SQL Database] B -->|No| D{Schema Flexibility Needed?} D -->|Yes| E[NoSQL Database] D -->|No| F{Horizontal Scaling Needed?} F -->|Yes| E F -->|No| C C --> C1[MySQL, PostgreSQL] C --> C2[Oracle, SQL Server] E --> E1{Data Model?} E1 -->|Documents| E2[MongoDB] E1 -->|Key-Value| E3[Redis] E1 -->|Column-Family| E4[Cassandra] E1 -->|Graph| E5[Neo4j] classDef decision fill:#d97706,stroke:#f59e0b,color:#fff,font-size:18px,font-weight:bold classDef process fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef success fill:#22c55e,stroke:#4ade80,color:#fff,font-size:18px,font-weight:bold classDef warning fill:#f59e0b,stroke:#fbbf24,color:#1e1b4b,font-size:18px,font-weight:bold classDef info fill:#8b5cf6,stroke:#a78bfa,color:#fff,font-size:18px,font-weight:bold class A decision class B,D,F decision class C,E process class C1,C2,E1 info class E2,E3,E4,E5 success
Use this decision flow to choose between SQL and NoSQL based on your specific requirements. Consider data complexity, schema flexibility, scalability needs, and query patterns.