MongoDB
Explica cómo las time series collections almacenan mediciones por tiempo y metadata, aplican buckets internos y optimizan ingestión, retención y consultas temporales.
Las time series collections optimizan mediciones asociadas a un instante y a una serie estable. MongoDB agrupa internamente las mediciones en buckets comprimidos, pero la aplicación trabaja con documentos lógicos individuales.
db.createCollection('sensorReadings', {
timeseries: {
timeField: 'timestamp',
metaField: 'metadata',
granularity: 'seconds'
},
expireAfterSeconds: 60 * 60 * 24 * 30
});No todo documento con una fecha pertenece a una time series. Órdenes, usuarios o tickets tienen lifecycle y updates diferentes.
Campo Date que representa cuándo ocurrió la medición.
{ timestamp: new Date() }Debe conservar tipo consistente. Strings y timestamps inválidos rompen orden, buckets y retención.
Contiene atributos relativamente estables que identifican la serie:
metadata: {
businessId,
deviceId,
sensorType: 'temperature'
}No coloques valores que cambian en cada medición; fragmentarían los buckets y reducirían compresión.
Indica frecuencia aproximada de llegada. Ayuda a configurar buckets. La elección y opciones disponibles dependen de versión; cambiarla requiere comprobar compatibilidad y comportamiento.
{
timestamp: ISODate('2026-07-24T12:00:00Z'),
metadata: {
businessId: ObjectId('...'),
deviceId: 'sensor-42'
},
temperatureC: 21.4,
humidity: 0.58
}MongoDB administra la representación interna. No escribas directamente en la colección de buckets.
Características comunes:
Diseña desde filtros:
db.sensorReadings.createIndex({
'metadata.businessId': 1,
'metadata.deviceId': 1,
timestamp: -1
});Esto soporta lecturas de una serie por rango. Los índices adicionales aumentan coste de ingestión y almacenamiento.
db.sensorReadings.find({
'metadata.businessId': businessId,
'metadata.deviceId': deviceId,
timestamp: { $gte: start, $lt: end }
}).sort({ timestamp: 1 });Utiliza límites half-open para periodos y timezone solo al agrupar o presentar.
Promedio por hora:
db.sensorReadings.aggregate([
{
$match: {
'metadata.deviceId': deviceId,
timestamp: { $gte: start, $lt: end }
}
},
{
$group: {
_id: {
$dateTrunc: {
date: '$timestamp',
unit: 'hour',
timezone: 'America/Bogota'
}
},
averageTemperature: { $avg: '$temperatureC' },
samples: { $sum: 1 }
}
},
{ $sort: { _id: 1 } }
]);expireAfterSeconds elimina mediciones expiradas de forma eventual. No ocurre en el segundo exacto y no ejecuta lógica de negocio.
Antes de eliminar define:
Puede conservarse alta resolución 30 días y métricas agregadas por meses o años.
Mediciones pueden llegar después del evento. Define:
Guardar ambos tiempos ayuda:
{
timestamp: measuredAt,
receivedAt: new Date()
}Reintentos de dispositivos pueden insertar la misma medición. Una identidad como {deviceId, sequence} puede necesitar índice unique, pero verifica compatibilidad y coste en time series para la versión utilizada.
Otra opción es deduplicar en ingestión o aceptar duplicates y corregir en aggregation.
Las capacidades sobre time series han evolucionado. No asumas que todas las operaciones disponibles para colecciones normales tienen la misma compatibilidad o rendimiento. Verifica versión y FCV.
El modelo ideal sigue siendo append-heavy.
Time series sharded necesita una shard key compatible. Metadata suele participar para distribuir series; timestamp puro puede concentrar escrituras. Evalúa targeting, cardinalidad y versión.
createdAt;Time series collections optimizan datos temporales append-only mediante buckets internos. El diseño gira alrededor de timeField, metadata estable, frecuencia, retención y queries por rango. No sustituyen una colección normal para cualquier entidad con fecha.
GridFS y archivos.