About Time Series Data关于时间序列数据

Comparing Time Series Collections to Regular Collections时间序列集合与常规集合的比较

In a regular collection, data is stored sequentially as blocks on disk, optimizing write speed. However, it requires one index for each data point, which quickly grows very large. 在常规集合中，数据作为块按顺序存储在磁盘上，优化了写入速度。然而，它要求每个数据点都有一个索引，这个索引会迅速增长到非常大。It also requires a second index that contains the time series identifier and timestamps themselves, so that users can query for a single series. To read this data, MongoDB has to process all of the database and disk blocks that contain it, even if a block only contains a single relevant document.它还需要第二个索引，其中包含时间序列标识符和时间戳本身，以便用户可以查询单个序列。为了读取这些数据，MongoDB必须处理包含它的所有数据库和磁盘块，即使一个块只包含一个相关文档。

This model is optimized for CRUD operations and frequent updates. A bank account balance only needs to reflect the current state, so each account holder's document is updated as that information changes.该模型针对CRUD操作和频繁更新进行了优化。银行账户余额只需要反映当前状态，因此每个账户持有人的文件都会随着信息的变化而更新。

Compare this to a time series collection. Time series collections write data in order, meaning recent transactions can be kept in memory for much faster retrieval. Since they are written in sequence, documents are stored together, so there's no need to read every disk block after a document is no longer in memory. 将其与时间序列集合进行比较。时间序列集合按顺序写入数据，这意味着最近的事务可以保存在内存中，以便更快地检索。由于它们是按顺序写入的，文档被存储在一起，因此在文档不再在内存中后，不需要读取每个磁盘块。Data is indexed by the metaField, leading to much smaller indexes.数据由metaField索引，从而产生更小的索引。

How the metaField Affects Bucketing元字段如何影响桶

Because metaField values must match exactly to group documents, the number of buckets in a time series collection depends on the number of unique metaField values. 因为metaField值必须与组文档完全匹配，所以时间序列集合中的桶数取决于唯一metaField值的数量。Collections with fine-grained or changing metaField values generate many sparsely packed, short-lived buckets. This leads to decreased storage and query efficiency.具有细粒度或不断变化的metaField值的集合会生成许多稀疏、短命的桶。这会导致存储和查询效率降低。

For example, in the following document, metadata is a good choice of metaField since it makes it easy to query data from a given weather sensor. Using these fields, MongoDB buckets readings from a single sensor together.例如，在下面的文档中，metadata是metaField的一个不错的选择，因为它使查询给定天气传感器的数据变得容易。使用这些字段，MongoDB将单个传感器的读数放在一起。

{
   timestamp: ISODate("2021-05-18T00:00:00.000Z"),
   metadata: { sensorId: 5578, type: 'temperature' },
   temp: 12,
   _id: ObjectId("62f11bbf1e52f124b84479ad")
}

Creation创造

• MongoDB creates a new bucket if there isn't a suitable one for an incoming document. This occurs when any of the following are true:如果传入文档没有合适的桶，MongoDB会创建一个新的桶。当以下任何一项为真时，就会发生这种情况：

  • The document metaField doesn't match any active buckets.文档metaField与任何活动桶都不匹配。
  • The document timestamp is outside of the range of all active buckets.文档时间戳超出了所有活动桶的范围。
  • The document exceeds the remaining size or document limit of all active buckets.文档超出了所有活动桶的剩余大小或文档限制。

  The starting timestamp of a new bucket is rounded down based on the collection's granularity. 新桶的开始时间戳根据集合的粒度进行四舍五入。This handles cases where documents with out-of-order timestamps arrive in close succession.这可以处理具有乱序时间戳的文档连续到达的情况。

Closure闭包

MongoDB closes a bucket under any of the following circumstances:MongoDB在以下任何一种情况下都会关闭桶：

• Time has moved forward or backward past the covered time span, as indicated by an incoming document timestamp that falls outside of the bucket's bounds. These bounds are determined by the collection's granularity setting.时间已向前或向后移动超过覆盖的时间跨度，如落在桶边界之外的传入文档时间戳所示。这些边界由集合的粒度设置决定。
• The bucket has hit the document limit (default 1000).桶已达到文档限制（默认值1000）。

• The bucket has exceeded its storage size limit. This happens when:桶已超过其存储大小限制。当发生以下情况时，会发生这种情况：

  • The size exceeds the allowed maximum (default 125KiB).大小超过了允许的最大值（默认值125KiB）。

  • The number of documents is below a minimum number (default 10) and the size is below 12MiB.文档数量低于最小值（默认值为10），大小低于12MiB。

    This is a set, internal limit that optimizes performance when data consists of fewer, larger documents.这是一组内部限制，当数据由更少、更大的文档组成时，可以优化性能。

  • The set of active buckets doesn't fit within the allowed storage engine cache size. You can review this information using the collStats database command.活动桶集不符合允许的存储引擎缓存大小。您可以使用collStats数据库命令查看此信息。
• The bucket catalog exceeds its allowed total memory allocation (by default, 2.5% of available system memory)桶目录超出了其允许的总内存分配（默认情况下为可用系统内存的2.5%）
• A conflicting operation, such as a chunk migration or update, changes a bucket's on-disk state.冲突操作（如块迁移或更新）会改变桶在磁盘上的状态。
• mongod restarts. This closes all buckets.重新启动。这将关闭所有水桶。

Deletion删除

MongoDB deletes a bucket when:MongoDB在以下情况下删除桶：

• Its maximum allowed timestamp is less than the current time minus the collection's expireAfterSeconds parameter. This is equivalent to a TTL collection's time to live.其允许的最大时间戳小于当前时间减去集合的expireAfterSeconds参数。这相当于TTL集合的生存时间。
• A delete or db.collection.deleteMany() command deletes the last document in the bucket.delete或db.collection.deleteMany()命令删除桶中的最后一个文档。