Home Assistant no tiene un motor de «búsqueda» universal cuya velocidad disminuya con cada entidad añadida. El problema de escalabilidad más claro es el trabajo histórico de las consultas: el panel de Historial, las vistas similares al Registro, las estadísticas y otras funciones respaldadas por la base de datos deben recuperar y organizar los datos conservados por Recorder.
A medida que crece ese conjunto de datos, el coste de una solicitud depende de cuántas filas coinciden, de qué índices pueden acotar la búsqueda, de si es necesario combinar atributos, de cuántos datos ya están en memoria y de la rapidez con la que el almacenamiento puede proporcionar las páginas que faltan. El tamaño de la base de datos importa, pero la estructura de la consulta importa igual de mucho.
El historial lee de Recorder, no solo de la máquina de estados activa
Los valores actuales de los dispositivos se encuentran en el modelo de estados en tiempo de ejecución de Home Assistant, mientras que la integración Historial lee las observaciones almacenadas por Recorder. Por tanto, una tarjeta del panel que muestra la temperatura actual y un gráfico del Historial de cinco días utilizan rutas de datos diferentes.
Home Assistant documenta que Historial depende de Recorder y normalmente lee los datos sin procesar de Recorder dentro del periodo de conservación configurado. Cuando el intervalo seleccionado supera ese periodo para los sensores aptos, puede utilizar estadísticas históricas de largo plazo por hora.
Por eso una base de datos histórica grande puede hacer que el Historial parezca lento, mientras que una automatización local de una luz sigue reaccionando al instante.
Conservar más estados implica más filas, metadatos y trabajo de indexación
Cada actualización registrada añade información a la base de datos. Home Assistant reduce la duplicación separando los identificadores de entidad y los atributos compartidos en tablas relacionadas, pero una instalación con mucha actividad aún puede acumular un gran número de filas de estados.
El modelo de datos actual de Home Assistant muestra que los estados registrados hacen referencia a metadatos de entidad y a filas de atributos compartidos, e incluyen marcas de tiempo indexadas y relaciones utilizadas por las consultas históricas. Por tanto, las entidades que cambian con frecuencia aumentan más que el simple número de valores legibles para las personas.
El periodo de conservación y la frecuencia de actualización se multiplican entre sí. Un sensor que cambia cada segundo genera un conjunto de trabajo muy diferente al de uno que cambia dos veces al día, aunque ambos sean «una entidad».
Los índices reducen el trabajo de búsqueda, pero no hacen gratuito el tamaño del resultado
SQLite puede utilizar índices para evitar examinar cada fila en las restricciones y ordenaciones habituales de las consultas. Esto es esencial para el Historial, pero un índice no elimina el coste de devolver un intervalo grande de coincidencias ni de combinar los datos asociados.
La documentación del planificador de consultas de SQLite explica que los índices aceleran la búsqueda y la ordenación, mientras que los conjuntos de resultados grandes, las búsquedas de filas y las ordenaciones siguen requiriendo un trabajo proporcional a los datos seleccionados y al plan. El planificador elige entre las rutas disponibles basándose en el coste estimado.
Esto significa que «la base de datos tiene un índice» y «esta consulta tendrá un tiempo constante para siempre» no son afirmaciones equivalentes. Los intervalos de tiempo más amplios y las entidades con más cambios aún pueden hacer que sean relevantes más páginas y filas.
La conservación de Recorder controla el rendimiento y la capacidad
Home Assistant purga automáticamente los datos de Recorder para que los estados detallados no crezcan indefinidamente. Aumentar el periodo de conservación proporciona más historial a resolución completa, pero también incrementa el conjunto de trabajo histórico activo, el tamaño de las copias de seguridad y el trabajo de mantenimiento.
La documentación de Recorder advierte explícitamente que permitir que la base de datos crezca demasiado consume espacio en disco y puede ralentizar Home Assistant. Su comportamiento predeterminado de purga y compactación existe, en parte, para mantener limitado el crecimiento de la base de datos.
Por tanto, el periodo de conservación adecuado es un requisito del producto. Conserva los datos de alta resolución el tiempo suficiente para responder a preguntas domésticas reales, no simplemente porque haya espacio disponible en el disco.
El almacenamiento y la caché determinan cuánto cuesta la misma consulta
Una solicitud repetida del Historial puede ser más rápida porque las páginas de la base de datos y del sistema de archivos ya están en la memoria. La misma consulta después de reiniciar o bajo presión de memoria puede necesitar más lecturas físicas. Otro servicio que escriba intensivamente en el mismo SSD también puede aumentar la latencia sin modificar la solicitud SQL.
El análisis de ZimaSpace sobre el crecimiento de los metadatos y el historial de Home Assistant explica las causas relacionadas con las escrituras. El rendimiento de las consultas es la consecuencia relacionada con las lecturas: conservar más estados importa sobre todo cuando el intervalo seleccionado o el conjunto de trabajo realmente los utiliza.
Mide el tiempo de las consultas junto con la latencia del almacenamiento y la presión de memoria antes de mover las bases de datos o comprar hardware más rápido.
Reduce el coste de las consultas reduciendo los datos innecesarios, no el historial útil
- Excluye las entidades cuyos cambios históricos no aporten valor para la toma de decisiones.
- Reduce la frecuencia de actualización en el origen cuando los cambios de alta frecuencia no sean útiles.
- Ajusta la conservación de datos sin procesar al intervalo de tiempo que los usuarios consultan realmente.
- Utiliza estadísticas de largo plazo para periodos extensos cuando sean suficientes los agregados por hora.
- Mantén Recorder en un almacenamiento fiable y de baja latencia, con suficiente espacio libre.
- Compara el mismo intervalo del Historial antes y después de cada cambio.
La métrica útil no es solo el tamaño de la base de datos. Es cómo cambia la latencia de las consultas a medida que varían las filas conservadas, el intervalo solicitado, el estado de la caché y las condiciones del almacenamiento.
Preguntas frecuentes
¿Una base de datos de Recorder más grande hace automáticamente que las automatizaciones locales sean más lentas?
No. El control de los dispositivos en tiempo real y las consultas históricas siguen rutas independientes. Pueden afectarse indirectamente cuando el trabajo de Recorder provoca una competencia compartida por la CPU, la memoria o el almacenamiento, pero un gráfico del Historial lento no demuestra que el motor de automatizaciones sea lento.
Centro de Tecnología e IA
Más para leer

Estado de ejecución frente a estado persistente en Home Assistant: ¿qué debe sobrevivir al reinicio?
Home Assistant no conserva todos los valores en tiempo real; la configuración, los registros, los estados restaurados seleccionados, el historial y los datos de...

¿Cómo autentica Home Assistant las sesiones locales y remotas?
Las sesiones locales y remotas de Home Assistant utilizan el mismo modelo de identidad del servidor; el acceso remoto cambia la ruta y el...

¿Por qué Home Assistant reconstruye un estado diferente después de reiniciar un contenedor?
Reiniciar el contenedor no equivale a perder el estado: Home Assistant reconstruye el estado de ejecución a partir de la configuración persistente, las integraciones,...

