Acerca de los datos de series de tiempo

Internamente, MongoDB optimiza los datos de series temporales al agrupar los documentos en una colección de series temporales en función de criterios comunes. metaField Valores. Seleccionar uno útil optimiza significativamente la densidad de almacenamiento y el rendimiento de las consultas. Para más información, consulte metaCampos.

Propiedades de los datos de series de tiempo

Los datos de series de tiempo tienen varias propiedades que los diferencian de otros formatos de datos:

Los documentos llegan en orden, lo que requiere frecuentes operaciones de inserción para agregarlos.
Las operaciones de actualización son poco frecuentes, ya que cada documento representa un único punto en el tiempo.
Las operaciones de borrado son poco frecuentes si la aplicación se beneficia de tener un amplio registro histórico.
Los datos se indexan por tiempo y un identificador, como un ticker de acciones, que identifica la serie de tiempo única a la que pertenece.
Los datos tienen un gran volumen, ya que cada serie de tiempo individual requiere un gran número de documentos en constante aumento.
En colecciones de series de tiempo, los documentos no requieren un campo _id único porque MongoDB no crea un índice en el campo _id.

Para tener en cuenta estos factores, MongoDB utiliza un formato columnar especializado que agrupa documentos de cada serie de tiempo. Esto tiene los siguientes beneficios:

Reducción del almacenamiento y del tamaño de los índices
Mejora en la eficiencia de los query
Reducción de E/S para operaciones de lectura
Mayor uso de la caché en memoria de WiredTiger, mejorando aún más la velocidad del query
Reducción de la complejidad para trabajar con datos de series de tiempo

Comparación de la colección de series de tiempo con la colección regular

En una colección regular, los datos se almacenan secuencialmente como bloques en el disco, optimizando la velocidad de guardado. Sin embargo, requiere un índice para cada punto de datos, lo cual crece rápidamente y se vuelve muy grande. También requiere un segundo índice que contenga el identificador de la serie de tiempo y las marcas de tiempo en sí mismas, para que los usuarios puedan realizar un query de una sola serie. Para leer estos datos, MongoDB debe procesar todos los bloques de la base de datos y del disco que los contienen, incluso si un bloque solo contiene un único documento relevante.

Este modelo está optimizado para operaciones CRUD y actualizaciones frecuentes. El saldo de la cuenta bancaria solo debe reflejar el estado actual, por lo que el documento de cada titular de cuenta se actualiza a medida que cambia esa información.

Compare esto con una colección de series de tiempo. Las colecciones de series de tiempo guardan datos en orden, lo que significa que las transacciones recientes pueden mantenerse en memoria para una recuperación mucho más rápida. Dado que se escriben en secuencia, los documentos se almacenan juntos, por lo que no es necesario leer cada bloque de disco una vez que un documento ya no está en la memoria. Los datos se indexan por metaField, lo que hace que los índices sean mucho más pequeños.

¿Cómo funciona el bucketing?

Cuando creas una colección de series de tiempo, MongoDB crea automáticamente grupos, o cubos, de documentos. MongoDB agrupa los documentos que tienen ambos:

Un valor metaField idéntico, que debería identificar de forma única una serie de tiempo. Si un metaField es un objeto o un arreglo, MongoDB agrupa solo si todos los campos del objeto o los elementos del arreglo coinciden.
timeField valores que están próximos entre sí. Los parámetros granularity, bucketMaxSpanSeconds y bucketRoundingSeconds de la colección de series de tiempo controlan el lapso de tiempo cubierto por cada cubo. Para obtener más información, consulta Configuración de la granularidad para los datos de series de tiempo.

Por ejemplo, con una granularidad de seconds, MongoDB agrupa documentos dentro de la misma hora. Si un bucket contiene un documento con un valor metaField de sensorA y un valor timeField de 2024-08-01T18:23:21Z, un documento entrante con un metaField de sensorB va a un bucket separado independientemente del tiempo. Un documento entrante de sensorA va al mismo bucket solo si su timeField está entre 2024-08-01T18:00:00Z y 2024-08-01T18:59:59Z.

Si un documento con un tiempo de 2023-03-27T16:24:35Z no encaja en un bucket existente, MongoDB crea uno nuevo con un tiempo mínimo de 2023-03-27T16:00:00Z y un tiempo máximo de 2023-03-27T16:59:59Z.

Nota

Puede modificar la granularidad de una colección de series de tiempo, pero solo para cambiar de medidas más finas a más gruesas, como extender la cobertura del bucket de minutos a horas. Esto actualiza la definición de la vista de la colección, pero no cambia cómo se almacenan los datos en los buckets existentes.

Cómo afecta el metaField al agrupamiento

Debido a que los valores metaField deben coincidir exactamente para agrupar documentos, el número de buckets en una colección de series de tiempo depende del número de valores metaField únicos. Las colecciones con valores metaField granulares o cambiantes generan muchos buckets escasamente empaquetados y de corta duración. Esto conduce a una disminución del almacenamiento y de la eficiencia del query.

Por ejemplo, en el siguiente documento, metadata es una buena opción de metaField, ya que facilita el query de datos de un sensor meteorológico determinado. Usando estos campos, MongoDB agrupa las lecturas de un solo sensor.

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

El catálogo de buckets

El catálogo de buckets es una caché especializada en memoria en WiredTiger. Rastrea los buckets para minimizar la latencia y coordinar las operaciones de guardado concurrentes.

Para cada bucket abierto, el catálogo mantiene información como el metaField, los escritores activos, el período cubierto, el número de documentos, el tamaño y las operaciones recientes. Debido a que MongoDB crea buckets separados para documentos con un metaField diferente, generalmente se abren varios buckets al mismo tiempo.

Para evitar inconsistencias causadas por condiciones de competencia, los buckets pueden cerrarse y eliminarse del catálogo de buckets cuando se ejecuta una operación conflictiva. Al reiniciar mongod se cierran todos los buckets y se restablece el catálogo de buckets.

Creación

MongoDB crea un nuevo bucket si no hay uno adecuado para un documento entrante. Esto ocurre cuando se cumple alguna de las siguientes condiciones:
- El documento metaField no coincide con ningún bucket activo.
- La marca de tiempo del documento está fuera del rango de todos los buckets activos.
- El documento excede el tamaño restante o el límite de documentos de todos los buckets activos.
La marca de tiempo inicial de un nuevo bucket se redondea hacia abajo según la granularidad de la colección. Esto gestiona casos en los que los documentos con marcas de tiempo desordenadas llegan en sucesión cercana.

Cierre

MongoDB cierra un bucket en cualquiera de las siguientes circunstancias:

El tiempo se ha movido hacia adelante o hacia atrás del período cubierto, como lo indica una marca de tiempo del documento entrante que cae fuera de los límites del contenedor. Estos límites están determinados por la configuración de granularidad de la colección.
El bucket ha alcanzado el límite de documentos (por defecto 1000).
El bucket ha excedido su límite de tamaño de almacenamiento. Esto ocurre cuando:
- El tamaño excede el máximo permitido (por defecto 125 KiB).
- El número de documentos está por debajo de un número mínimo (por defecto 10) y el tamaño es inferior a 12 MiB.
  Este es un límite interno establecido que optimiza el rendimiento cuando los datos consisten en menos documentos de mayor tamaño.
- El conjunto de buckets activos no cabe dentro del tamaño permitido de la caché del motor de almacenamiento. Puedes revisar esta información usando el comando de base de datos collStats.
El catálogo de cubos excede su asignación total de memoria permitida (por defecto, 2.5% de la memoria disponible del sistema)
Una operación en conflicto, como una migración de fragmentos o una actualización, cambia el estado en disco de un bucket.
mongod se reinicia. Esto cierra todos los buckets.

Eliminación

MongoDB borra un bucket cuando:

La marca de tiempo máxima permitida es menor que la hora actual menos el parámetro expireAfterSeconds de la colección. Esto es equivalente al tiempo de vida de una colección TTL.
Un comando delete o db.collection.deleteMany() borra el último documento del bucket.

Volver

Inicio rápido

Considerations