MongoDB NoSQL Database

Core NoSQL Concepts

What is NoSQL?

NoSQL, which stands for "Not Only SQL," refers to database systems that do not rely on a traditional relational schema of tables with predefined rows and columns. These systems store, retrieve, and manage data in flexible, non-tabular formats. They were designed to overcome the limitations of traditional SQL databases, particularly when dealing with very large datasets, high-velocity data streams, and unstructured or semi-structured data.

NoSQL vs. Relational Databases (SQL)

Understanding the differences is crucial for choosing the right tool for the job. The table below compares key features.

The 4 Main Types of NoSQL Databases

NoSQL is not a single technology but a category of databases classified into four primary data models.

1. Document Databases (e.g., MongoDB)

• Concept: Data is stored in documents (usually JSON or BSON format). Each document contains key-value pairs, where values can be simple types or complex structures like arrays or nested objects.
• Analogy: Think of a file cabinet. Each drawer (collection) holds multiple files (documents). The content inside each file varies in format and size.
• Use Case: User profiles, product catalogs, content management systems.

2. Key-Value Stores (e.g., Redis, Amazon DynamoDB)

• Concept: The simplest model. Data is stored as a collection of key-value pairs, where the key is a unique identifier and the value is the data.
• Analogy: A dictionary or hash map. You look up a word (key) to get its definition (value).
• Use Case: Session management, caching, real-time recommendations.

3. Wide-Column Stores (e.g., Apache Cassandra, HBase)

• Concept: Data is stored in tables, rows, and dynamic columns. Unlike relational tables, columns vary per row, and data is grouped by row keys.
• Analogy: A spreadsheet where each row has different column names.
• Use Case: Time-series data, IoT sensor data, large-scale applications requiring high write throughput.

4. Graph Databases (e.g., Neo4j, Amazon Neptune)

• Concept: Data is stored as nodes (entities) and edges (relationships). The focus is on the connections between data points.
• Analogy: A social network map where people (nodes) are connected by friendships (edges).
• Use Case: Social networks, fraud detection, recommendation engines.

Architectural Principles of NoSQL

NoSQL databases are built on specific architectural foundations to handle modern data challenges.

1. BASE vs. ACID

• ACID (SQL Default):
  • Atomicity: Transactions are all-or-nothing.
  • Consistency: Data is valid before and after a transaction.
  • Isolation: Concurrent transactions do not interfere.
  • Durability: Once saved, data remains saved.
• BASE (NoSQL Default):
  • Basically Available: The system guarantees availability.
  • Soft State: The state of the system may change over time, even without input (e.g., due to replication lag).
  • Eventual Consistency: The system will eventually become consistent once it stops receiving input.
• Note: MongoDB provides multi-document ACID transactions in recent versions, bridging the gap.

2. Schema Flexibility

• SQL (Schema-on-write): You must define the table structure before inserting data. Changing it requires migrations.
• NoSQL (Schema-on-read): The database does not enforce a structure. You can insert data with different fields into the same collection. The application logic handles data validation and interpretation when reading.

3. Horizontal Scaling (Sharding)

• Vertical Scaling: Adding more power (CPU, RAM) to a single server. Limited by hardware costs.
• Horizontal Scaling: Adding more servers to a pool and distributing data across them.
• Sharding: The process of breaking up a large dataset into smaller chunks (shards) stored on different servers. Each shard holds a subset of the total data.
  • Example: If you have 100 million user records, sharding might split them so that users A-M are on Server 1, and N-Z are on Server 2.

4. Replication

• Concept: Copying data across multiple servers to ensure high availability and fault tolerance.
• Replica Set (MongoDB term): A group of servers that maintain the same data set. If the primary server fails, a secondary server automatically becomes the new primary.
• Benefit: If one server goes down, the application continues running using the other servers.

Practical Implications and Trade-offs

Choosing NoSQL is not always the right answer. It involves trade-offs.

• When to use NoSQL:

  • Rapidly changing data requirements (e.g., startup MVP).
  • Handling massive volumes of unstructured data.
  • High write/read throughput (e.g., logging, real-time analytics).
  • Data that doesn't fit well into a relational model (deep nesting, polymorphic data).

• When to stick with SQL:

  • Complex queries involving multiple joins across massive datasets.
  • Systems requiring strict transactional integrity (banking, financial ledgers).
  • Data structure is stable and well-defined.
  • Tools that rely on standard SQL reporting and business intelligence.

Summary of Concepts for MongoDB

While the principles apply to all NoSQL, MongoDB (a document database) uses specific terminology:

• Database: A container for collections (similar to a schema in SQL).
• Collection: A group of documents (similar to a table).
• Document: A set of key-value pairs (similar to a row).
• BSON: Binary JSON. MongoDB uses BSON to store documents, allowing for efficient data types like Date, Binary, and Int32/Int64.

Key Notes

• NoSQL is not a replacement for SQL; it is an alternative for different use cases.
• Eventual Consistency is a fundamental concept in distributed NoSQL systems; data might be temporarily out of sync between replicas.
• Schema-on-read allows flexibility but shifts the burden of data integrity to the application layer.
• Horizontal Scaling via Sharding is the primary method NoSQL databases use to handle "Big Data."
• CAP Theorem: In distributed systems, you can only pick two: Consistency, Availability, Partition Tolerance. NoSQL databases often prioritize Availability and Partition Tolerance (AP) over strict Consistency (CP).