Unit 1: Introduction to NoSQL and MongoDB

I. Foundations of NoSQL — Data Models Beyond the Relational Model

NoSQL (“Not Only SQL”) emerged in the late 2000s as a practical response to large-scale web data, distributed computing, and rapidly changing application requirements. It describes database systems that do not depend primarily on the relational table-and-join model.

A. Introduction to NoSQL Databases

NoSQL databases store and retrieve data through non-relational models optimized for particular access patterns, scalability needs, or data structures.

• Defining properties: Most NoSQL systems emphasize flexible schemas, distributed operation, horizontal scaling, and model-specific queries.
  • Flexible schema: Records in one collection may contain different fields.
  • Horizontal scaling: Capacity increases by adding servers rather than only upgrading one server.
  • Denormalization: Related data may be stored together to avoid expensive distributed joins.
• Major models: The principal categories are key-value, column-oriented, document, and graph databases; each organizes relationships differently.
• Design assumption: The application’s dominant queries should influence data structure. For example, an order document may embed line items when they are usually read together.
• Typical uses: NoSQL supports content catalogs, event streams, user sessions, recommendation networks, telemetry, and applications whose fields evolve frequently.
• Important qualification: “NoSQL” does not mean “no query language,” “no schema,” or “no transactions.” Many systems enforce validation and provide atomic operations or multi-record transactions.

II. Relational and Non-Relational Systems — Choosing the Appropriate Guarantees

Relational and NoSQL databases differ chiefly in data modeling, query mechanisms, scaling strategies, and the trade-offs they make for consistency and flexibility.

A. Comparison: SQL vs. NoSQL

SQL databases favor normalized relations and standardized querying, whereas NoSQL databases favor specialized models and distribution-friendly access patterns.

1. SQL databases:
   • Structure: Data occupies tables with rows, columns, primary keys, and foreign keys; a Customer row can be linked to many Order rows.
   • Schema: A predefined schema commonly controls column types and constraints through Data Definition Language statements.
   • Queries: Standard SQL supports joins, grouping, filtering, and aggregation across relations.
   • Transactions: ACID properties provide atomicity, consistency, isolation, and durability, making relational systems strong choices for accounting and inventory.
   • Scaling: Traditional deployments scale vertically, although modern relational databases can also replicate and partition.
2. NoSQL databases:
   • Structure: Data may be represented as documents, key-value pairs, wide rows, or graphs.
   • Schema: Flexible records permit gradual field changes, though production systems still require governance and validation.
   • Queries: APIs and query languages vary by product and model; cross-entity joins may be limited or handled through embedding.
   • Distribution: Sharding and replication are often first-class features.
   • Selection rule: Use requirements, not labels. Complex joins may favor SQL; a geographically distributed catalog with variable attributes may favor a document database.

III. MongoDB — A General-Purpose Document Database

MongoDB is an open-source document database first released in 2009. It stores BSON documents in collections and combines flexible modeling with indexing, aggregation, replication, sharding, and transactions.

A. Overview of MongoDB

MongoDB represents an application object as a BSON document, allowing nested objects and arrays to remain together.

• Document: A record consists of field-value pairs, such as {"name":"Asha","skills":["Java","Python"]}.
• BSON: Binary JSON extends JSON with types including ObjectId, date, decimal, and binary data.
• Collection: A collection groups documents and roughly corresponds to a relational table, but documents need not have identical fields.
• Identifier: Every document has a unique _id; MongoDB commonly generates a 12-byte ObjectId.
• Operations: CRUD means create, read, update, and delete.

db.students.insertOne({ name: "Asha", semester: 1 })
db.students.find({ semester: 1 })
db.students.updateOne({ name: "Asha" }, { $set: { semester: 2 } })

• Capabilities: Secondary indexes accelerate queries; aggregation pipelines transform data; replica sets improve availability; sharding distributes large datasets.

IV. Distributed Consistency — Limits Expressed by CAP

The CAP theorem, associated with Eric Brewer and formally proved by Seth Gilbert and Nancy Lynch, states that a distributed data store cannot simultaneously guarantee consistency and availability while a network partition is occurring.

A. CAP Theorem and its trade-offs

CAP requires a system facing a partition to choose between consistent responses and continuously available responses.

• Consistency (C): Every read observes the latest successful write or an error; this is commonly interpreted as single-copy, linearizable behavior.
• Availability (A): Every request reaching a non-failing node receives a non-error response, although the response might not contain the newest write.
• Partition tolerance (P): The system continues operating despite lost or delayed messages between network segments.
• CP choice during partition: A system may reject or delay operations that cannot be confirmed, preserving one authoritative value at the cost of availability.
• AP choice during partition: Both sides may accept operations, preserving availability but requiring later reconciliation of divergent values.
• Normal operation: CAP is not a permanent selection of only two letters. The C-versus-A decision becomes unavoidable specifically during a partition; latency and consistency trade-offs also exist without one.
• MongoDB connection: Replica sets use a primary for writes. If a majority cannot elect a primary, writes stop, favoring consistency over write availability; read preferences can alter read behavior.

V. NoSQL Data Models — Structures Matched to Workloads

Each NoSQL model gives different operations a natural and efficient representation, so model selection should begin with entities, relationships, and query patterns.

A. Key-value databases

A key-value database maps each unique key directly to an opaque or structured value, enabling simple and fast lookup.

• Form: The logical operation is GET(key) -> value; for example, session:8F2A may map to serialized cart data.
• Strengths: Direct key access, easy partitioning by key, and low latency suit caches, sessions, shopping carts, and feature flags.
• Examples: Redis, Amazon DynamoDB, and Riak provide key-oriented access, though their additional capabilities differ.
• Limitation: Querying arbitrary fields or relationships is difficult when the database treats the value as opaque.

B. Column-oriented databases

Column-oriented NoSQL databases, often called wide-column stores, organize sparse values by row key, column family, and column rather than requiring every row to share fixed columns.

• Form: A row such as device-17 can contain timestamped temperature columns while another row contains different measurements.
• Strengths: Distributed writes, sparse data, and range scans make the model useful for telemetry, time-series workloads, and large event datasets.
• *Examples