# Series Cardinales
Comprender qué es la cardinalidad, cómo medirla, sus implicaciones en el rendimiento y las mejores prácticas para controlarla es clave para un uso óptimo de InfluxDB.
## **¿Qué es la Cardinalidad de Series en InfluxDB?**
La *cardinalidad de series* se refiere al número de combinaciones únicas de bucket, measurement, conjunto de tags y campos (field keys) almacenadas en la base de datos. En otras palabras, es la cantidad de series únicas que existen, donde cada serie se define por un conjunto específico de etiquetas (tags) y el nombre de la medición (measurement).
Por ejemplo, si tienes 100 dispositivos (tag `device_id`) y cada uno reporta 10 tipos de métricas (field keys) en 5 ubicaciones diferentes (tag `location`), la cardinalidad sería:
> 100 dispositivos×5 ubicaciones×10 métricas=5,000 series
Cada combinación única de tags y fields crea una nueva serie.
### Consumo de recursos en InfluxDB 2.x según el grupo de cardinalidad de series
| Cardinality Level | Memory Usage (RAM) | Write Throughput | Write Latency |
| ------------------- | ------------------ | ---------------------- | ------------- |
| 10,000 series | \~700 MB | 500,000 points/segundo | 0.5 ms |
| 1 millón de series | \~8.5 GB | 100,000 points/segundo | 2.5 ms |
| 100 millones series | 145 GB+ | 10,000 points/segundo | 25 ms+ |
### **Importancia de la Cardinalidad en el Rendimiento**
* **Impacto en recursos:** Una cardinalidad alta incrementa el uso de memoria y disco, ya que InfluxDB debe mantener índices para cada serie única.
* **Rendimiento:** Consultas y escrituras pueden ralentizarse notablemente si la cardinalidad es muy elevada, llegando incluso a provocar caídas del sistema si se sobrepasan los límites de recursos.
* **Escalabilidad:** Un diseño inadecuado puede hacer que la base de datos no escale correctamente, especialmente en sistemas SCADA donde el número de dispositivos y variables puede crecer.
### **Causas Comunes de Alta Cardinalidad**
* Uso de tags con valores altamente variables o únicos (por ejemplo, IDs únicos, hashes, strings aleatorios, timestamps).
* Escribir mensajes de log o información detallada y única en tags en lugar de fields.
* Crecimiento no controlado de dispositivos o fuentes de datos, especialmente en entornos IoT o SCADA.
### **Ejemplo Práctico de Control de Cardinalidad**
Supón que tienes sensores de temperatura en 1,000 máquinas, cada una en 10 ubicaciones distintas, la cardinalidad será:
Resultado
### 1,000 máquinas × 10 ubicaciones × 1 (temperatura) = 10,000 series
Si el número de maquinas no es necesario para las consultas, es mejor guardarlo como field y no como tag, reduciendo así la cardinalidad a solo 10 series (una por ubicación).
### **Diagnóstico y Resolución de Problemas de Cardinalidad**
* **Identifica los tags problemáticos:** Usa las consultas de cardinalidad para encontrar qué tags generan más combinaciones únicas.
* **Refactoriza el esquema:** Modifica el modelo de datos para mover información de tags a fields cuando sea posible.
* **Elimina series innecesarias:** Borra buckets o series que ya no sean relevantes para liberar recursos.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://darioaplicano.gitbook.io/influxdb2.x/sesion-1/guion-de-la-sesion/documentacion/conceptos-clave-de-influxdb/series-cardinales.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.