Las colecciones de series temporales generalmente se comportan como colecciones normales, pero con excepciones adicionales. Para obtener información sobre el comportamiento y la estructura de las colecciones de series temporales, consulte Colecciones de series temporales.
Consideraciones sobre el metaField
A metaField Debe cambiar con poca frecuencia y puede ser de cualquier tipo de dato. Un metaField puede ser un objeto y contener subcampos. Una vez definido un campo como metaField, se puede cambiar el valor de metaField, pero no se puede redefinir metaField como otro campo. Por ejemplo, si se crean documentos de series temporales con metaField definido como campo A, no se puede convertir posteriormente un campo B en metaField. Sin embargo, si el valor de A es un objeto, se pueden añadir nuevos subcampos a A.
Nota
Usar un arreglo como metaField puede causar un comportamiento inesperado de la colección porque la igualdad de los arreglos depende de un orden específico.
MongoDB utiliza metaField para dividir los datos y organizarlos y recuperarlos de manera eficiente. Cuando se crea una colección de series de tiempo, MongoDB agrupa los documentos en buckets. Los documentos dentro de un bucket comparten un valor de metaField idéntico y tienen valores timeField muy cercanos entre sí.
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 de granularidad fina o dinámicos pueden generar más buckets de corta duración y dispersos que las colecciones con valores metaField simples que rara vez o nunca cambian. Los valores metaField detallados y dinámicos suelen reducir la eficiencia del almacenamiento y los queries.
metaField Mejores prácticas
Selecciona los campos que casi nunca o nunca cambian como parte de tu metaField.
Si es posible, selecciona identificadores u otros valores estables que sean frecuentes en las expresiones de filtro como parte de tu metaField.
Evita seleccionar campos que no se usen para filtro como parte de tu metaField. En su lugar, utiliza esos campos como mediciones.
Almacenamiento y cardinalidad
Al insertar datos en una colección de series de tiempo, la colección interna organiza automáticamente los datos en un formato de almacenamiento optimizado utilizando buckets. Si existe un bucket adecuado, MongoDB inserta nuevos datos en ese bucket. Si no existe un bucket adecuado, MongoDB crea un bucket nuevo. Para optimizar el almacenamiento, se elige un metaField que rara vez cambie para crear colecciones de series de tiempo con menos buckets y más densos.
Las colecciones con valores metaField de granularidad fina o que cambian generan muchos buckets de corta duración y dispersos, aumentando la cardinalidad de la colección. El aumento de la cardinalidad reduce la eficiencia del almacenamiento y los queries.
Granularidad
Se puede utilizar el parámetro granularity para especificar con qué frecuencia MongoDB agrupa en buckets los datos de series de tiempo según la tasa de ingestión de datos. La siguiente tabla muestra el intervalo de tiempo máximo incluido en un depósito de datos cuando se utiliza un valor granularity determinado:
granularity | granularity límite de bucket |
|---|---|
| 1 hora |
| 24 horas |
| 30 días |
Por defecto, granularity está configurado como seconds. Se puede mejorar el rendimiento configurando el valor granularity en la coincidencia más próxima al intervalo de tiempo entre las mediciones entrantes de la misma fuente de datos. Por ejemplo, si se está realizando un registro de datos meteorológicos de miles de sensores pero solo se efectúa un registro de datos de cada sensor una vez cada 5 minutos, se debe configurar granularityen "minutes". Cuanto menos frecuente sea la incorporación de nuevos documentos, mayores serán los beneficios de almacenamiento y rendimiento al utilizar una granularidad más gruesa.
Cuando se establece lagranularity en hours, se agrupa hasta un mes de eventos de data ingest en un solo bucket, lo que genera tiempos de recorrido más largos y queries más lentos. Si se establece en seconds, se generan varios buckets por intervalo de sondeo, muchos de los cuales pueden incluir solo un documento.
También se debe tener en cuenta los queries típicas a la hora de elegir el valor granularity. Por ejemplo, si se espera que los queries obtengan 1 días de datos a la vez, se utiliza "minutos". Una granularidad más fina, como "segundos", crea buckets que cubren una hora. Esto requiere más depósitos para representar los mismos datos, lo que afecta negativamente el almacenamiento y el rendimiento de los queries. Una granularidad más amplia, como "horas" (que tiene un intervalo de depósito de 30días), requiere que los queries obtengan 30 días de datos a la vez y luego se filtre la mayor parte.
Para ver ejemplos, se puede consultar Configurar la granularidad de los datos de series de tiempo.
Compresión y Hardware
Algunas colecciones de series temporales utilizan un formato de contenedor comprimido al añadir datos a contenedores abiertos o reabiertos. La compresión de datos de series temporales en la caché admite cargas de trabajo de alta cardinalidad, a la vez que preserva el rendimiento eficiente de las consultas.
Partición por zonas
La partición por zonas no admite colecciones de series de tiempo. El balanceador siempre distribuye los datos en colecciones de series de tiempo fragmentadas de manera uniforme en todos los fragmentos del clúster.