รูปแบบบักเก็ตและค่าที่คำนวณล่วงหน้า

Expert MongoDB engineers do not design schemas by instinct — they reach for a library of proven patterns that solve recurring challenges. These patterns encode hard-won lessons about how MongoDB's storage engine, index structure, and aggregation pipeline interact with different document shapes. The Bucket Pattern and Computed Pattern are two of the most impactful for performance-sensitive applications.

Consider an IoT system where each sensor reading is a separate document. A sensor producing one reading per second generates 86,400 documents per day. This means 86,400 index entries per sensor per day, enormous index sizes, and a huge number of operations when querying a day's data. Reading 24 hours of data requires fetching tens of thousands of tiny documents — very inefficient.

The Bucket Pattern groups related small documents into a single larger document (a 'bucket'). Instead of one document per reading, one document holds one hour's readings — reducing 3,600 documents to 1, and 3,600 index entries to 1. The bucket document contains an array of measurements plus summary statistics computed at write time. This dramatically reduces index size and improves range query performance.

When a new measurement arrives, find the current bucket document for the sensor and hour, and update it atomically using $push to append to the measurements array and $inc to increment the count. Use upsert: true so MongoDB creates a new bucket document if the current hour's bucket does not exist yet.

To retrieve all readings for a sensor over a time range, query the bucket documents by sensorId and date range, then either use the pre-computed summaries for aggregate results, or $unwind the measurements array for per-reading access. Querying 24 hours of data now reads 24 bucket documents instead of 86,400 individual ones — a 3,600x reduction in documents fetched.

The Computed Pattern pre-calculates expensive aggregations at write time and stores the result directly in the document. Instead of computing an average rating for a product by summing all reviews at read time, compute it whenever a new review is added and store avgRating alongside reviewCount in the product document. Reads become trivially cheap — just return the pre-computed field.

When a new review arrives, update the computed fields atomically in the same operation rather than recalculating from scratch. Increment reviewCount and ratingSum with $inc, then recompute avgRating. In MongoDB, you can do this with a pipeline-style update (MongoDB 4.2+) that uses $divide to set the average from the updated count and sum.

The Computed Pattern is most valuable when reads vastly outnumber writes and the computation would be expensive at read time. Product rating averages, leaderboard scores, article view counts, revenue totals — all are excellent candidates. The tradeoff is slightly increased write complexity and the need to keep computed values consistent when source data changes. If both reads and writes are frequent, consider background jobs that recompute periodically rather than synchronous updates.

The Bucket and Computed patterns are frequently used together. A sensor data system might group readings into hourly bucket documents (Bucket Pattern) and maintain a pre-computed daily summary document (Computed Pattern) that stores min/max/avg for the entire day. This tiered approach means dashboards showing daily trends read a single document, while drill-down queries scan only 24 hourly bucket documents.

Bucket documents should not grow without bound — MongoDB has a 16 MB document size limit. For sensors with high data rates, use time-bounded buckets (e.g., one per hour or one per day). The count: { $lt: 3600 } guard in the update filter prevents overfilling. If a bucket reaches capacity, the upsert creates a new bucket automatically. Monitor bucket fill rates in production to tune bucket size for your data rate.

The primary index on a bucket collection should cover the query pattern: { sensorId: 1, date: 1 }. This compound index means queries filtering by sensor and time range hit the index directly. Compared to indexing the timestamp field of 86,400 individual documents, the bucket collection's index holds only 24 entries per sensor per day — a 3,600x reduction in index size that drastically improves working-set fit in RAM.

In this lesson you learned: the Bucket Pattern groups many small documents into fewer larger ones, dramatically reducing index size and improving range query performance, the Computed Pattern pre-calculates expensive aggregations at write time so reads return pre-stored values instantly, and the two patterns combine effectively for multi-tier time series pipelines. Next up we explore the Extended Reference and Subset Patterns.