Introduction to MongoDB

What’s in Store? (Chapter Overview)

This chapter introduces MongoDB, a popular NoSQL (Not only SQL) database, contrasting it with traditional relational databases (RDBMS). It explores MongoDB’s key features like Auto Sharding, Replication, its use of JSON/BSON, dynamic schemas, and CRUD operations.

6.1 What is MongoDB?

MongoDB is defined by these characteristics:

1. Cross-platform: Runs on multiple operating systems (Linux, macOS, Windows).
2. Open source: The source code is publicly available.
3. Non-relational: Doesn’t use the traditional table-based structure of RDBMS.
4. Distributed: Data can be spread across multiple servers.
5. NoSQL: Falls under the category of databases that don’t primarily use SQL.
6. Document-oriented data store: Stores data in flexible, JSON-like documents.

[Important Term] NoSQL: A broad class of database management systems that differ from the classic relational (SQL) model. They often excel in scalability, flexibility, and handling unstructured data. [Important Term] Document-oriented: Data is stored in “documents” (similar to JSON objects) rather than rows and columns.

6.2 Why MongoDB?

Traditional RDBMS face challenges with:

• Handling large volumes of data (Big Data).
• Managing diverse data types, especially unstructured data.
• Scaling efficiently (especially scaling out/horizontally).

MongoDB addresses these with features like:

• Scalability (Horizontal): Can distribute data across many servers (Sharding).
• Schema Flexibility: No rigid table structure; documents in a collection can have different fields (Dynamic Schema).
• Fault Tolerance: Can handle node failures (Replication).
• Consistency and Partition Tolerance: Balances data consistency with the ability to operate even if parts of the network fail (as per the CAP theorem, though MongoDB typically prioritizes Consistency and Partition Tolerance).
• Rich Query Language: Supports powerful queries.
• Fast In-Place Updates: Efficiently modifies existing data.
• High Availability: Replication ensures data is available even if some servers fail.
• Full Index Support: Allows indexing any field for faster queries.
• Document Oriented Storage: Uses BSON.
• Easy Scalability: Designed to grow with your data needs.

(See Figure 6.1 for a visual summary of these features)

6.2.1 Using JavaScript Object Notation (JSON) and BSON

• JSON (JavaScript Object Notation): A human-readable text format for data exchange. It’s expressive and easy to understand.
  • Example Journey:
    • .csv (Comma Separated Values): Simple, flat data. Gets messy with repeating values or nested data.

      FirstName, LastName, ContactNo
      John, Mathews, +12345678900
      Andrews, Symmonds, +45678901234
      Mable, Mathews, +78912345678

    • .xml (Extensible Markup Language): More structured, handles complexity better than CSV, but can be verbose. Defines how to define a format.
    • JSON: Solves the complexity issue more elegantly for many common data structures, like multiple contact numbers.

      {
        "FirstName": "John",
        "LastName": "Mathews",
        "ContactNo": ["+12345678900", "+12344445555"]
      }
      {
        "FirstName": "Andrews",
        "LastName": "Symmonds",
        "ContactNo": ["+45678901234", "+45666667777"]
      }
      {
        "FirstName": "Mable",
        "LastName": "Mathews",
        "ContactNo": ["+78912345678"]
      }

• BSON (Binary JSON): MongoDB actually uses BSON internally.
  • Binary format: More compact (uses less space) and faster to parse/process for machines than text-based JSON.
  • Open Standard: Like JSON.
  • Native Data Format Conversion: Easily converts to native data structures in various programming languages (C, C++, Java, Python, etc.) via MongoDB drivers.

[Important Term] JSON: Human-readable data format. [Important Term] BSON: Binary, machine-optimized version of JSON used by MongoDB for storage and network transfer.

6.2.2 Creating or Generating a Unique Key (_id)

• Every MongoDB document must have a unique _id field.
• Acts like a primary key in RDBMS.
• Used for uniquely identifying and searching documents.
• An index is automatically created on the _id field.
• You can either:
  1. Provide your own unique value for _id.
  2. Let MongoDB automatically generate a unique ObjectId value.
• Structure of Auto-Generated ObjectId (12 bytes): $$\boxed{\begin{array}{cccc}\text{4-byte timestamp}& \text{3-byte machine ID}& \text{2-byte process ID}& \text{3-byte counter}\end{array}}$$

[Important Term] _id: The mandatory unique identifier field for every MongoDB document, analogous to a primary key.

6.2.2.1 Database

• A container for collections.
• Created automatically when first referenced (e.g., when saving a document to a collection within it) or explicitly.
• Each database has its own set of files on the server’s file system.
• A single MongoDB server can host multiple databases.

6.2.2.2 Collection

• Analogous to a table in RDBMS.
• Holds a group of MongoDB documents.
• Exists within a single database.
• Created automatically when the first document is saved into it.
• Does not enforce a schema. (Very Important!)

6.2.2.3 Document

• Analogous to a row/record/tuple in RDBMS.
• A single data record stored in a collection.
• Composed of field-and-value pairs (like a JSON object).
• Has a dynamic schema.

[Important Term] Dynamic Schema: Documents within the same collection do not need to have the same set of fields, data types, or structure. Field order can also differ. This provides great flexibility.

(See Figure 6.2 for an example of a “students” collection with 3 documents, potentially having slightly different structures).

6.2.3 Support for Dynamic Queries

• MongoDB supports rich, dynamic queries on the data, similar to RDBMS.
• This contrasts with some other NoSQL databases (like CouchDB mentioned as a competitor) which might focus more on static queries (pre-defined views) against dynamic data.

6.2.4 Storing Binary Data (GridFS)

• For storing data larger than the BSON document size limit (16MB, though the text mentions 4MB - Note: The BSON limit is 16MB, GridFS is for larger files).
• Useful for images, audio, video clips, etc.
• GridFS Mechanism:
  1. Stores file metadata (filename, type, etc.) in a files collection.
  2. Breaks the binary data into smaller chunks (typically 255KB).
  3. Stores these chunks in a chunks collection.
• Provides scalability for large binary objects.

[Important Term] GridFS: MongoDB’s specification for storing and retrieving large files, such as images, audio, and video.

6.2.5 Replication

• Provides data redundancy (copies of data) and high availability.
• Helps recover from hardware failures and service interruptions.
• Replica Set: A group of MongoDB servers consisting of:
  • One Primary node: Receives all write operations.
  • Multiple Secondary nodes: Replicate data from the primary.
• Process:
  1. Client sends write request to the Primary.
  2. Primary executes the write and logs it in its Oplog (operations log).
  3. Secondaries continuously copy and apply operations from the Primary’s Oplog.
• Read Operations: Can be directed to the primary (default, ensures strongest consistency) or secondaries (read preference can be specified by the client, useful for scaling reads).

(See Figure 6.3 for a diagram of the replication process).

[Important Term] Replication: Keeping identical copies of data on multiple servers (replica set) for redundancy and availability. [Important Term] Replica Set: A cluster of MongoDB instances that host the same data set (one primary, multiple secondaries). [Important Term] Oplog: A special capped collection on the primary that logs all data-modifying operations, used by secondaries to replicate data.

6.2.6 Sharding

• Horizontal Scaling (scaling out): Distributing a large dataset across multiple servers (shards).
• Used when a dataset becomes too large for a single server or when write/read load is too high.
• Shard: An independent database server (or replica set) holding a portion of the total data.
• Collectively, all shards form a single logical database.
• Advantages:
  1. Reduces Data per Shard: Each shard stores/manages less data (e.g., 1TB database split across 4 shards means ~256GB per shard).
  2. Reduces Operations per Shard: Queries/writes can often be routed to only the relevant shard(s), distributing the load.

(See Figure 6.4 for a diagram illustrating a 1TB collection sharded across four 256GB shards).

[Important Term] Sharding: Partitioning data horizontally across multiple machines (shards) to scale out. [Important Term] Horizontal Scaling (Scale Out): Adding more servers to distribute the load, as opposed to Vertical Scaling (Scale Up - increasing resources like CPU/RAM on a single server).

6.2.7 Updating Information In-Place

• MongoDB typically updates data directly where it’s stored (in-place) when possible. This is efficient as it doesn’t require allocating new space or rewriting large parts of the document or indexes for small changes.
• Lazy Writes: MongoDB writes data changes to disk periodically (e.g., every 60 seconds by default, though the text mentions 1 second - Note: Journaling typically happens more frequently, full data flush less so). This improves performance because memory operations are much faster than disk operations.
• Tradeoff: There’s a small window where recently written data might be lost if the server crashes before the data is flushed to disk (unless using write concerns that guarantee disk persistence). This prioritizes performance.

---

6.3 Terms Used in RDBMS and MongoDB

A comparison of common terminology:

$$\boxed{\begin{array}{lll}\text{Concept}& \text{RDBMS Term}& \text{MongoDB Term}\\ \text{Database Container}& \text{Database}& \text{Database}\\ \text{Table}& \text{Table}& \text{Collection}\\ \text{Row/Record}& \text{Row / Record / Tuple}& \text{Document}\\ \text{Column}& \text{Column / Attribute}& \text{Field / Key-Value pair}\\ \text{Index}& \text{Index}& \text{Index}\\ \text{Table Relationships}& \text{Joins}& \text{Embedded Documents / Linking}\\ \text{Unique Identifier}& \text{Primary Key}& \text{Primary key (\_id field)}\end{array}}$$

Database Server/Client Comparison:

$$\boxed{\begin{array}{llll}\text{Component}& \text{MySQL}& \text{Oracle}& \text{MongoDB}\\ \text{Database Server}& \text{mysqld}& \text{Oracle (Instance)}& \text{mongod}\\ \text{Database Client}& \text{mysql}& \text{SQL*Plus / SQL Developer}& \text{mongo (or mongosh)}\end{array}}$$

Important Terms for Exams

• NoSQL: Database type differing from relational models.
• MongoDB: A specific document-oriented NoSQL database.
• Document-oriented: Stores data in JSON-like documents.
• JSON / BSON: Data formats (human-readable / binary).
• Database: Container for collections.
• Collection: Group of documents (like a table). No enforced schema.
• Document: Single record (like a row). Key-value pairs.
• _id: Mandatory, unique primary key field. Automatically indexed.
• Dynamic Schema: Flexibility in document structure within a collection.
• Replication: Data redundancy and high availability via replica sets (Primary/Secondary).
• Sharding: Horizontal scaling by distributing data across shards.
• GridFS: Storing large binary files.
• CRUD: Create (insert), Read (find), Update (update), Delete (remove/delete).
• Indexes: Data structures to improve query speed.
• mongod: The MongoDB server process.
• mongo / mongosh: The MongoDB client shell.
• Aggregation Pipeline: Framework for multi-stage data processing.
• Lazy Writes / In-Place Updates: Performance optimization techniques with durability tradeoffs.

---