¿Deberías poner los metadatos de Immich en un SSD y los datos masivos en un HDD?

Sí, una implementación de Immich suele beneficiarse de mantener la base de datos y los datos generados sensibles a la latencia en un SSD, mientras se almacenan los archivos grandes de fotos y vídeos originales en un HDD, especialmente cuando la biblioteca es mucho más grande que el estado de la aplicación. La separación solo resulta útil si las rutas, los márgenes de espacio libre, las copias de seguridad y los pasos de recuperación siguen siendo claros.

La decisión no consiste en «metadatos rápidos, medios lentos». Immich utiliza varias funciones de almacenamiento de manera diferente: PostgreSQL gestiona muchas operaciones pequeñas de estado; las miniaturas y las vistas previas se leen con frecuencia al explorar; los vídeos codificados pueden ser grandes; y los originales priorizan la capacidad y la durabilidad. Mide esas funciones por separado antes de mover nada.

Separa el estado pequeño con E/S intensivas de los medios orientados a la capacidad

Haz un inventario de los datos de PostgreSQL, las miniaturas, las vistas previas, los vídeos codificados, la caché de modelos, los originales subidos, las bibliotecas externas y las copias de seguridad. Registra el tamaño actual, el crecimiento, la frecuencia de lectura y escritura, el coste de reconstrucción y si cada función debe sobrevivir a una restauración. Así evitarás que una etiqueta genérica como «metadatos» oculte varias cargas de trabajo muy diferentes.

El marco de almacenamiento de ZimaSpace para ubicar los metadatos de los medios y la caché activa establece una distinción útil: las bases de datos y los índices se benefician del almacenamiento de baja latencia, mientras que los medios de origen en bloque pueden permanecer en un almacenamiento de gran capacidad cuando su patrón de acceso no requiere los mismos IOPS. Si el HDD actual muestra una latencia baja durante las búsquedas, la exploración de la línea de tiempo y las tareas en segundo plano, mover todos los derivados al SSD puede aportar poca mejora perceptible para el usuario. Mantén la distribución actual hasta que una comparación controlada demuestre que la ruta de almacenamiento activa realmente está esperando.

Coloca PostgreSQL y los derivados consultados con frecuencia en un SSD cuando sean el cuello de botella

PostgreSQL y la exploración con muchas miniaturas generan numerosas lecturas y escrituras pequeñas que pueden sentirse lentas en un disco mecánico ocupado, especialmente mientras las importaciones o las copias de seguridad utilizan el mismo dispositivo.

En las distribuciones actuales de Immich, mantén la base de datos en un almacenamiento local de baja latencia y mueve deliberadamente las rutas de datos generados compatibles, en lugar de inventar montajes anidados arbitrarios.

El mecanismo de almacenamiento se entiende bien fuera de Immich: el ajuste del almacenamiento de PostgreSQL se beneficia de un acceso aleatorio mucho más económico que el de los discos giratorios. Eso no garantiza una mejora visible en Immich, pero explica por qué la base de datos y los índices son buenos candidatos para un SSD cuando la latencia del dispositivo es la espera medida.

Mide la mejora con el mismo álbum, búsqueda y muestra de importación antes y después. Si la latencia de la base de datos disminuye, pero la solicitud visible para el usuario sigue esperando la transferencia de red, la decodificación de imágenes o el aprendizaje automático, deja de atribuir la demora restante al HDD.

Mantén los originales en un HDD cuando la capacidad y la protección importen más que la E/S aleatoria

Las fotos y los vídeos originales suelen ser la clase de almacenamiento más grande y normalmente se leen como archivos completos, no como pequeñas páginas aleatorias de la base de datos. Por tanto, los grupos grandes de HDD pueden ser un lugar adecuado para los originales cuando proporcionan la fiabilidad, el rendimiento y la capacidad de copia de seguridad necesarios. El nivel HDD sigue necesitando espacio libre y una latencia saludable durante las cargas de importación y exploración simultáneas.

Una discusión de larga duración sobre el almacenamiento de Immich para separar las miniaturas de los medios refleja el mismo objetivo operativo: los recursos generados para la exploración y los originales en bloque tienen prioridades de acceso diferentes. No demuestra que todas las instalaciones necesiten dos dispositivos físicos; la ventaja depende de dónde esperan actualmente las solicitudes.

No coloques originales irremplazables en un HDD simplemente porque sea más barato para después considerar que el RAID es la copia de seguridad. Conserva una segunda copia y otra fuera del host o sin conexión, según el objetivo de protección del hogar. La organización por niveles de almacenamiento modifica el rendimiento y el coste; no reduce las consecuencias de perder la única copia de la biblioteca familiar.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Migra una función de almacenamiento cada vez y prueba los montajes tras reiniciar

Antes de mover una ruta, captura una copia de seguridad coherente de la base de datos y registra el mapa actual de montajes del host al contenedor. Mueve una sola función, inicia la pila, verifica los recursos antiguos y nuevos, ejecuta una búsqueda, reproduce un vídeo, sube un archivo desechable y confirma que las nuevas escrituras llegan al dispositivo previsto. No muevas la base de datos, las miniaturas, los originales y los destinos de copia de seguridad en un solo cambio.

Reinicia el host en lugar de limitarte a recrear los contenedores. Una distribución dividida que funcione correctamente activa los montajes del SSD y el HDD antes de que Immich escriba, conserva los usuarios y las relaciones, lee originales de muestra y mantiene la supervisión del espacio libre en ambos niveles. Un directorio de reemplazo vacío en un punto de montaje esperado es una condición para detenerse. Mantén la separación cuando mejore el cuello de botella medido y el mapa de recuperación siga siendo comprensible. Revierte los cambios si la distribución introduce rutas obsoletas, recursos ausentes, cambios de permisos o un proceso de copia de seguridad que protege solo un nivel. El mejor diseño de almacenamiento es el más rápido que aún puedes restaurar correctamente.