Course contentsShow
← Databases & SQL
Lesson 1201 of 1,95311. NoSQL and Document ModelsFree lesson

Addressing One-to-Squillions

Determine how to architect data when the related set grows without a practical limit.

In this lesson, you will learn how to architect data relationships when the related set is so large that it exceeds the practical limits of embedding or simple referencing.

The Problem of "Squillions"

In our previous lessons, we discussed embedding data for "one-to-few" relationships and using references for "one-to-many." However, some relationships grow without bound—think of a sensor device generating millions of telemetry events, or a social media user with a massive, growing activity log.

If you embed these millions of records into a single document, you will hit the storage engine’s document size limit (e.g., the 16MB limit in MongoDB) and suffer from severe performance degradation because every update requires moving the entire document on disk.

The "Bucket" Pattern

To solve this, we move away from both raw embedding and singular referencing, adopting an approach known as Bucketing. Instead of one document per child item, we group related child items into "buckets" (a smaller array of records) tied to the parent.

Imagine a sensor_logs collection where each document represents a bucket of readings for a specific device:

{
  "sensor_id": "HVAC-001",
  "bucket_date": "2023-10-27",
  "readings": [
    { "timestamp": "2023-10-27T08:00:00Z", "value": 22.5 },
    { "timestamp": "2023-10-27T08:01:00Z", "value": 22.6 }
  ],
  "count": 2,
  "sum": 45.1
}

Why This Works

  1. Locality: By grouping entries by time or sequence, you keep related data together, which is highly efficient for range queries.
  2. Growth Control: Once a bucket reaches a predefined size or time threshold, the application simply creates a new document. You never hit the "one-to-squillions" bottleneck because the relationship is spread across a predictable, manageable number of documents.
  3. Aggregation: Storing summary fields like count or sum inside the bucket allows you to perform lightning-fast reads without scanning through millions of individual log entries.

This architectural shift moves the complexity from the storage engine's ability to handle massive documents to the application's ability to "route" incoming data into the correct, currently active bucket.

Key Takeaway: When a relationship grows without bound, use the Bucket Pattern to group related items into manageable, indexed documents rather than embedding them all or referencing them individually.