Las instantáneas del sistema de archivos pueden hacer que la compactación de vectores conserve tanto los bloques antiguos como los reescritos, retrasando la recuperación de espacio y aumentando la presión de copia al escribir durante las fusiones.
Una base de datos vectorial puede compactar segmentos para eliminar marcadores de borrado, fusionar archivos pequeños y mejorar la localidad de las consultas, eliminando los archivos obsoletos después de un reemplazo seguro. Una instantánea del sistema de archivos tomada antes de la fusión todavía hace referencia a sus bloques antiguos, por lo que el grupo de almacenamiento los conserva mientras también asigna la salida compactada. La instantánea mantiene la capacidad de recuperación, pero el comportamiento del espacio libre y la latencia difiere del de un sistema de archivos sin instantáneas.
La compactación reescribe los registros lógicos en archivos nuevos
Muchos almacenes vectoriales utilizan segmentos inmutables o componentes estructurados como registros. Las actualizaciones y eliminaciones añaden un nuevo estado; después, la compactación en segundo plano lee los registros activos, escribe archivos consolidados, actualiza los manifiestos y elimina los segmentos reemplazados tras una confirmación segura. Este efecto debe seguir siendo medible con la carga de trabajo prevista del servidor doméstico.
La compactación LSM fundamental describe los árboles de fusión estructurados como registros como una jerarquía que agrupa las escrituras y fusiona los componentes con el tiempo. Ese patrón de reescritura explica por qué la compactación necesita temporalmente tanto los datos de entrada como los de salida. La distinción importa cuando varias etapas de la canalización comparten el mismo almacenamiento y presupuesto de memoria.
Las estructuras específicas de los vectores añaden enlaces de grafos, listas de publicaciones, índices de carga útil y archivos de cuantización, por lo que los bytes compactados no tienen por qué equivaler a los bytes eliminados. La limpieza a nivel de base de datos y la recuperación de bloques a nivel del sistema de archivos son eventos independientes. Ese límite debe probarse con datos domésticos representativos en lugar de darse por supuesto.
Las instantáneas mantienen accesibles los bloques anteriores a la compactación
Una instantánea de copia al escribir registra un grafo de bloques en un momento determinado. Cuando la compactación escribe archivos nuevos, el sistema de archivos activo hace referencia a bloques nuevos, mientras que la instantánea sigue haciendo referencia a los segmentos antiguos; eliminar los nombres de archivo de la vista activa no puede liberar los bloques que la instantánea todavía necesita.
La retención de bloques de instantáneas de OpenZFS define las instantáneas como versiones de solo lectura de un sistema de archivos o volumen en un momento determinado. Su uso de espacio crece a medida que los datos activos divergen, que es exactamente lo que produce una compactación grande con muchas reescrituras.
Por tanto, un comando rápido de instantánea puede preceder a un crecimiento considerable del espacio utilizado. El coste aparece en las escrituras posteriores, no necesariamente al crear la instantánea, y persiste hasta que se elimina cada instantánea que mantiene esas referencias. Este efecto debe seguir siendo medible con la carga de trabajo prevista del servidor doméstico.
Un espacio libre reducido puede convertir la retención en latencia
La compactación necesita margen temporal, y la asignación mediante copia al escribir necesita bloques libres. Cuando las instantáneas conservan segmentos antiguos, el grupo de almacenamiento puede fragmentarse o acercarse a su capacidad, lo que ralentiza las escrituras y prolonga la compactación; a su vez, una compactación más larga deja más segmentos y trabajo de consulta.
La compactación vectorial de Milvus describe la compactación como la fusión de segmentos pequeños y la limpieza de datos eliminados para mejorar el almacenamiento y el comportamiento de las consultas. El mecanismo muestra por qué las bases de datos vectoriales pueden reescribir archivos importantes incluso cuando el cambio lógico consiste en un conjunto de eliminaciones.
El límite problemático consiste en suponer que el tamaño de la instantánea indicado al crearla predice su coste final. El volumen de compactación, la frecuencia de actualización, la compresión, los vectores eliminados, el espacio libre del grupo de almacenamiento y la duración de la instantánea determinan los bytes retenidos y la latencia de cola. La distinción importa cuando varias etapas de la canalización comparten el mismo almacenamiento y presupuesto de memoria.
Preguntas frecuentes sobre instantáneas y compactación vectorial
¿Deben desactivarse las instantáneas durante la compactación?
No automáticamente. Las instantáneas protegen los puntos de recuperación, pero programar las compactaciones grandes fuera de las ventanas de instantáneas puede reducir la divergencia retenida. Cualquier cambio debe conservar un plan probado de copias de seguridad y coherencia de la base de datos. Ese límite debe probarse con datos domésticos representativos en lugar de darse por supuesto.
¿Por qué el tamaño de la base de datos sigue siendo elevado después de compactar los vectores eliminados?
Los bloques antiguos pueden seguir estando referenciados por instantáneas, clones o copias de seguridad incluso después de que la base de datos activa elimine los segmentos obsoletos. Comprueba por separado los archivos de la base de datos y el espacio referenciado del sistema de archivos. Este efecto debe seguir siendo medible con la carga de trabajo prevista del servidor doméstico.
¿Puede una instantánea capturar un índice vectorial incoherente?
Sí, si los archivos de la base de datos, los registros de escritura anticipada, los manifiestos y los metadatos relacionados no se ponen en reposo ni se capturan atómicamente. Utiliza el mecanismo de punto de control o vaciado de la base de datos antes de la instantánea del sistema de archivos cuando sea necesario. La distinción importa cuando varias etapas de la canalización comparten el mismo almacenamiento y presupuesto de memoria.
Mide la divergencia de las instantáneas durante una fusión controlada
Clona un índice representativo, registra el tamaño lógico y físico, toma una instantánea y ejecuta después un ciclo medido de eliminación y compactación. Registra los bytes compactados, el pico de espacio temporal, los bytes referenciados por la instantánea, el espacio libre del grupo de almacenamiento, la latencia de escritura, la latencia de cola de las consultas y el tiempo necesario para recuperar el espacio tras eliminar la instantánea.
Compara el resultado con el mecanismo de bloqueo de instantáneas descrito en mecanismo de bloqueo de instantáneas. Repite la prueba sin instantánea y con distintas duraciones de retención, manteniendo constantes la versión de la base de datos, el índice, los datos, la compresión, la configuración del grupo de almacenamiento y la carga en segundo plano. Ese límite debe probarse con datos domésticos representativos en lugar de darse por supuesto.
Programa las instantáneas y la compactación a partir del margen medido, no por conveniencia. Conserva un punto de restauración coherente con la base de datos, reserva espacio para los segmentos antiguos y nuevos, y elimina las instantáneas únicamente según la política de retención establecida, en lugar de eliminar la protección para ocultar errores de planificación de capacidad.
Centro de Tecnología e IA
Más para leer

¿Pueden las cámaras domésticas sincronizar eventos sin servicios de hora en la nube?
Una explicación centrada en el mecanismo del tiempo de la cámara sin nube, sus compensaciones por recursos compartidos, tres preguntas frecuentes sobre la propagación...

¿Puede un servicio de IA local detectar capas de modelo dañadas antes de la inferencia?
Una explicación basada primero en los mecanismos de la detección de capas de modelo dañadas, sus compensaciones en recursos compartidos, tres preguntas frecuentes sobre...

¿Se puede restaurar un sistema RAG sin regenerar cada embedding?
Una explicación centrada primero en el mecanismo de la restauración de RAG sin volver a generar embeddings, sus compromisos en el uso compartido de...

