diff options
Diffstat (limited to 'src/mongo/db/timeseries/README.md')
-rw-r--r-- | src/mongo/db/timeseries/README.md | 24 |
1 files changed, 22 insertions, 2 deletions
diff --git a/src/mongo/db/timeseries/README.md b/src/mongo/db/timeseries/README.md index 0be14e8d509..559df91856c 100644 --- a/src/mongo/db/timeseries/README.md +++ b/src/mongo/db/timeseries/README.md @@ -29,13 +29,13 @@ certain properties: ``` { - _id: <Object ID with time component equal to first measurement in this bucket>, + _id: <Object ID with time component equal to control.min.<time field>>, control: { // <Some statistics on the measurements such min/max values of data fields> version: 1, // Version of bucket schema. Currently fixed at 1 since this is the // first iteration of time-series collections. min: { - <time field>: <time of first measurement in this bucket>, + <time field>: <time of first measurement in this bucket, rounded down based on granularity>, <field0>: <minimum value of 'field0' across all measurements>, <field1>: <maximum value of 'field1' across all measurements>, ... @@ -142,6 +142,26 @@ inserted. On subsequent batch commits, we perform an update operation. Instead o full document (a so-called "classic" update), we create a DocDiff directly (a "delta" or "v2" update). +# Granularity + +The `granularity` option for a time-series collection can be set at creation to be 'seconds', +'minutes' or 'hours'. A later `collMod` operation can change the option from 'seconds' to 'minutes' +or from 'minutes' to 'hours', but no other transitions are currently allowed. This parameter is +intended to convey the rough time period between measurements in a given time-series, and is used to +tweak other internal parameters that affect bucketing. + +The maximum span of time that a single bucket is allowed to cover is controlled by `granularity`, +with the maximum span being set to one hour for 'seconds', 24 hours for 'minutes', and 30 days +for 'hours'. + +When a new bucket is opened by the `BucketCatalog`, the timestamp component of its `_id`, and +equivalently the value of its `control.min.<time field>`, will be taken from the first measurement +inserted to the bucket and rounded down based on the `granularity`. It will be rounded down to the +nearest minute for 'seconds', the nearest hour for 'minutes', and the nearest day for 'hours'. This +rounding may not be perfect in the case of leap seconds and other irregularities in the calendar, +and will generally be accomplished by basic modulus aritmetic operating on the number of seconds +since the epoch, assuming 60 seconds per minute, 60 minutes per hour, and 24 hours per day. + # References See: [MongoDB Blog: Time Series Data and MongoDB: Part 2 - Schema Design Best Practices](https://www.mongodb.com/blog/post/time-series-data-and-mongodb-part-2-schema-design-best-practices) |