Understanding NoSQL: MongoDB Replication Models and Index Types Explained

NoSQL Introduction

NoSQL data management systems are popular non‑relational, distributed databases that do not follow ACID design principles. Their simple data models, separation of metadata and data, eventual consistency, high throughput, strong scalability, and ability to run on low‑end hardware make them attractive, with MongoDB being a widely used implementation.

Common NoSQL Storage Models

Column‑oriented model

Use case: Distributed databases that provide random read/write separation on top of distributed file systems.

Typical products: HBase, Hypertable, Cassandra.

Data model: Column‑centric storage, grouping the same columns together.

Advantages: Fast queries, high scalability, easy distributed expansion.

Document model

Use case: Web applications that do not require strong transactions.

Typical products: MongoDB, Elasticsearch, CouchDB.

Data model: Key‑value with documents.

Advantages: Schema‑less data model; no need to define structure in advance.

Key‑Value model

Use case: Content caching for high‑load scenarios with massive concurrent data access.

Typical products: DynamoDB, Redis, Riak.

Data model: Hash‑table based key‑value storage.

Advantages: Very fast query speed.

Graph model

Use case: Social networks, recommendation systems, knowledge graphs.

Typical products: Neo4j, Infinite Graph, TITAN.

Data model: Graph structures.

Advantages: Suited for graph‑centric computations.

MongoDB Replication Features

First type: Master/Slave model, similar to MySQL replication.

Second type: Replica set (multiple MongoDB instances serving the same dataset). Compared with MySQL master‑slave, it offers higher efficiency.

Requirements: At least three nodes, and the total number of nodes must be odd.

If node count is insufficient, an arbiter participates in elections.

Heartbeat runs every 2 seconds to monitor node health and trigger automatic failover.

Special node types in a MongoDB replica set:

Priority 0 node: A cold‑standby node that cannot become primary but can vote.

Hidden node: A priority‑0 secondary that is invisible to clients.

Delayed node: A priority‑0 secondary that replicates with a fixed lag behind the primary.

Arbiter: A node without data that only participates in elections.

MongoDB replication architecture components:

oplog: Stored in the local database (default size 1 GB). Only the primary can write to it; secondaries read from it. The oplog resides in the collection oplog.rs and its size depends on the OS and file system, but can be customized via oplogSize.

heartbeat: Mechanism that monitors the status of each node during replication.

MongoDB replication process:

Initial sync: Clone all databases, apply all changes from the dataset, replay the oplog to the local copy, and finally build indexes for all collections.

Post‑rollback catch‑up: Synchronize after a rollback event.

Sharding chunk migration: Moving chunks between shards during scaling.

MongoDB index types:

Single‑field index, compound (multi‑field) index, multikey index, geospatial index, text index, and hash index.