Gestionar la biblioteca STL después del escaneo

Adoptar un archivo grande es un proyecto con final. Operarlo no lo es, y los fallos son distintos. El primer escaneo hace ruido y termina; todo lo que viene después es una deriva lenta, en la que la taxonomía deja de encajar con cómo buscas, los escaneos cuestan en silencio más de lo que devuelven, y la copia de seguridad que nunca has restaurado resulta que excluye justo los archivos que más te importaban.

Si todavía estás en la fase de adopción, organizar miles de archivos STL cubre la migración. Esto empieza donde eso acaba.

El primer escaneo es el caro, y debería seguir siéndolo

Un escaneo completo calcula el hash de cada archivo compatible, lo analiza y genera vistas previas de las mallas, y por eso la primera pasada sobre una raíz grande es donde aparecen los límites de memoria. Los escaneos en régimen estable deberían ser mucho más baratos, porque casi nada ha cambiado.

Eso solo se cumple si la programación encaja con cómo se comporta la carpeta de verdad. Un recurso compartido de un NAS que recibe un puñado de archivos por semana no gana nada con escaneos cada hora, y el coste es real: cada pasada recorre el árbol entero. Donde el sistema de archivos lo permite, la vigilancia local detecta los cambios en el momento y hace redundantes los escaneos programados frecuentes. Fija la programación según el ritmo de cambio, no según la sensación de que más a menudo es más seguro.

Hay un comportamiento de seguridad que conviene conocer antes de que se active. Si la raíz montada vuelve inesperadamente vacía, la reconciliación se aborta en lugar de tratar cada archivo como borrado, que es lo que evita que un recurso NFS desmontado borre un índice en una sola pasada.

La taxonomía se degrada despacio

Las etiquetas se degradan de una forma concreta. La lista crece, se acumulan sinónimos y al final dejas de fiarte de un filtro porque no recuerdas si la etiqueta que quieres es needs-supports o support-needed o las dos. En ese punto la taxonomía te cuesta tiempo de búsqueda en lugar de ahorrártelo.

El arreglo es borrar, y duele menos de lo que parece. Ordena las etiquetas por cuántos modelos las llevan y mira la cola. Una etiqueta en dos modelos de ocho mil no es una categoría, es una nota que escribiste una vez, y borrarla no te cuesta nada que estuvieras usando. Unificar las supervivientes en una sola forma de escribirlas es un filtro y una edición en bloque, hasta 500 modelos por pasada.

Resístete a volver a etiquetar lo que el parser ya sabe. Material, boquilla, altura de capa, temperaturas y estimaciones salen del propio G-code y se actualizan cuando relaminas, mientras que una etiqueta que dice lo mismo no, así que en un mes las dos se contradicen.

Lo que cuesta de verdad ser grande en la interfaz

Navegar por una biblioteca grande solía implicar que el navegador descargara todas las páginas antes de poder ordenar. En la v0.11.4 eso cambió: la biblioteca filtrada completa se ordena por fecha, nombre, éxito de impresión, última impresión, duración, filamento o coste mediante paginación por cursor, sin vaciar antes las páginas. Los recuentos de facetas y los totales de la bóveda se resuelven cada uno con una única consulta agregada, y el sondeo de trabajos en segundo plano se detiene cuando no hay trabajo en lugar de seguir indefinidamente.

La consecuencia práctica es que las vistas guardadas pasan a ser la interfaz principal, por delante del scroll. Un filtro que reconstruyes cada vez es un filtro que acabas por no usar, y las combinaciones que merece la pena guardar son las que ya has escrito tres veces.

La vista previa de mallas sigue siendo la parte que consume memoria, a cualquier tamaño. Si el host es pequeño, cuenta con que ahí es donde las bibliotecas grandes se resisten primero, algo que sobrevivir a la falta de memoria con mallas grandes trata en detalle.

Comprueba el índice contra la realidad de vez en cuando

Una biblioteca que lleva un año funcionando acumula incoherencias: miniaturas que faltan, metadatos que no se pudieron analizar, estado de revisiones que ya no tiene sentido. Una auditoría rápida o completa de la bóveda encuentra todo eso, lo agrupa por gravedad y repara lo que se puede arreglar, y además puede verificar la estructura de un archivo de copia de seguridad y su correspondencia con el manifiesto antes de que confíes en él.

Esa última parte es la que conviene usar de verdad. Verificar un archivo no es lo mismo que restaurarlo, pero es la comprobación barata que puedes hacer a menudo, frente a la cara que deberías seguir haciendo de vez en cuando.

El límite de las copias de seguridad que sorprende a la gente

Una copia de seguridad completa de PrintStash cubre la base de datos, los blobs que le pertenecen, los documentos, las miniaturas y un manifiesto. No copia los bytes fuente indexados desde un volumen compartido, y eso es deliberado, no un descuido: esos archivos son tuyos, están en tu NAS en sus rutas originales, y copiar decenas de miles de mallas en cada copia de seguridad dejaría el archivo inservible.

La consecuencia es que una biblioteca grande necesita dos copias de seguridad, no una. PrintStash respalda lo que le pertenece, y tu NAS sigue necesitando su propia rutina para los archivos que guarda. Una restauración que recupera el índice contra archivos fuente que ya no existen te deja un catálogo de modelos que faltan.

Dos límites más que conviene conocer a escala. El flujo integrado de copia y restauración solo admite SQLite, así que las instalaciones con Postgres usan pg_dump y las herramientas normales de operación. Y la topología admitida es un proceso de API por bóveda, algo que se impone al arrancar mediante un bloqueo de la bóveda, así que escalar una biblioteca con mucho uso significa un host más grande y no más réplicas.

Preguntas que suelen surgir

¿Cada cuánto deberían ejecutarse los escaneos programados en una biblioteca grande?

Ajusta la programación a la frecuencia con la que cambia la carpeta, no a su tamaño. Un recurso compartido que gana unos pocos archivos por semana se cubre bien con un escaneo nocturno o incluso semanal, porque cada pasada recorre el árbol completo por poco que haya cambiado, y en una raíz grande ese recorrido es el coste. Donde el sistema de archivos permita vigilancia local, actívala y deja la programación como una red de seguridad poco frecuente, ya que el vigilante detecta los cambios en el momento. Reserva los escaneos frecuentes para una carpeta que de verdad reciba archivos a lo largo del día.

Mi lista de etiquetas ha llegado a doscientas entradas. ¿Y ahora qué?

Borra la mayoría, empezando por las menos usadas. Ordénalas por cuántos modelos llevan cada etiqueta y trata la cola larga como notas y no como categorías, porque una etiqueta aplicada a dos modelos de varios miles nunca va a ser aquello por lo que filtres. Después unifica los duplicados y los casi sinónimos en una sola forma cada uno, que es un filtro más una edición en bloque en lugar de trabajo manual. Cuenta con que el estado sano final quede bastante por debajo de treinta etiquetas, todas ellas juicios que un parser no habría podido hacer, ya que cualquier cosa que describa material o ajustes es ya un campo estructurado.

¿La biblioteca se vuelve más lenta a medida que crece?

Navegar y ordenar no deberían, porque ordenar la biblioteca filtrada completa se hace con paginación por cursor en vez de obligar al navegador a descargar todas las páginas primero, y los recuentos de facetas y los totales se resuelven cada uno con una única consulta agregada. Lo que sí escala con el tamaño es el escaneo y la generación de vistas previas, porque los dos hacen trabajo real por archivo. El renderizado de mallas es donde un host pequeño se queda sin sitio de verdad, así que si estás dimensionando hardware para una biblioteca grande, presupuesta memoria para el indexado antes que para la carga de consultas.

¿Qué no está en mi copia de seguridad?

Los bytes fuente que viven en un volumen compartido, que en la mayoría de las bibliotecas grandes son la inmensa mayoría de los datos por tamaño. Una copia de seguridad completa contiene la base de datos, los blobs que PrintStash posee, los documentos, las miniaturas y un manifiesto, así que restaurarla reconstruye el catálogo, los metadatos, la taxonomía y el historial de impresión, y apunta a archivos que tienen que seguir existiendo en tu NAS. Haz copia de ese almacenamiento por separado. También conviene saber que la ruta integrada de copia y restauración solo cubre SQLite, así que una instalación con Postgres necesita pg_dump y tu propio procedimiento de restauración.

Fuentes

• Las capacidades de PrintStash para la navegación por cursor, las vistas guardadas, los límites de la edición en bloque y la auditoría de la bóveda, y las limitaciones conocidas para la topología de un solo proceso y el límite de las copias de seguridad en PostgreSQL.
• Copia de seguridad y restauración para saber qué contiene una copia completa, y volúmenes compartidos para la programación de escaneos, la vigilancia y el aborto con raíz vacía.
• El comportamiento de rendimiento descrito arriba llegó en la v0.11.4.

Para el ensayo de restauración en lugar de la copia, copias de seguridad que sí se restauran. Para elegir el enfoque desde el principio, cómo organizar una biblioteca STL.