Como é que os instantâneos do sistema de ficheiros afetam a compactação das bases de dados vetoriais?
Os snapshots do sistema de ficheiros podem fazer com que a compactação de vectores retenha blocos antigos e reescritos, atrasando a recuperação de espaço e aumentando a pressão de cópia na escrita durante as fusões.
Uma base de dados vectorial pode compactar segmentos para remover tombstones, fundir ficheiros pequenos e melhorar a localidade das consultas, eliminando ficheiros obsoletos após uma substituição segura. Um snapshot do sistema de ficheiros criado antes da fusão continua a referenciar os blocos antigos, pelo que o conjunto de armazenamento os mantém enquanto também aloca o resultado compactado. O snapshot preserva a capacidade de recuperação, mas o comportamento do espaço livre e da latência difere do de um sistema de ficheiros sem snapshots.
A compactação reescreve registos lógicos em ficheiros novos
Muitos sistemas de armazenamento vectorial utilizam segmentos imutáveis ou componentes estruturados em registo. As actualizações e eliminações acrescentam novo estado; depois, a compactação em segundo plano lê os registos activos, escreve ficheiros consolidados, actualiza os manifestos e remove os segmentos substituídos após uma confirmação segura. Este efeito deve continuar a ser mensurável na carga de trabalho prevista para o servidor doméstico.
A compactação LSM fundamental descreve as árvores de fusão estruturadas em registo como uma hierarquia que agrupa escritas e funde componentes ao longo do tempo. Esse padrão de reescrita explica por que motivo a compactação precisa temporariamente dos dados de entrada e de saída. A distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.
As estruturas específicas de vectores acrescentam ligações de grafos, listas de postings, índices de payload e ficheiros de quantização, pelo que os bytes compactados não têm necessariamente de ser iguais aos bytes eliminados. A limpeza ao nível da base de dados e a recuperação de blocos ao nível do sistema de ficheiros são eventos distintos. Esse limite deve ser testado com dados domésticos representativos, em vez de ser presumido.
Os snapshots mantêm acessíveis os blocos anteriores à compactação
Um snapshot de cópia na escrita regista um grafo de blocos num determinado momento. Quando a compactação escreve ficheiros novos, o sistema de ficheiros activo referencia blocos novos, enquanto o snapshot continua a referenciar os segmentos antigos; eliminar nomes de ficheiros da vista activa não pode libertar blocos que o snapshot ainda necessita.
A retenção de blocos dos snapshots do OpenZFS define os snapshots como versões só de leitura de um sistema de ficheiros ou volume num determinado momento. A utilização de espaço aumenta à medida que os dados activos divergem, que é precisamente o que uma compactação grande e intensiva em reescritas cria.
Assim, um comando rápido de criação de snapshot pode preceder um crescimento substancial do espaço utilizado. O custo surge nas escritas subsequentes, não necessariamente no momento da criação do snapshot, e persiste até todos os snapshots que fazem referência aos blocos serem removidos. Este efeito deve continuar a ser mensurável na carga de trabalho prevista para o servidor doméstico.
Pouco espaço livre pode transformar a retenção em latência
A compactação precisa de margem temporária, e a alocação de cópia na escrita precisa de blocos livres. Quando os snapshots preservam segmentos antigos, o conjunto de armazenamento pode fragmentar-se ou aproximar-se da capacidade máxima, tornando as escritas mais lentas e prolongando a compactação; uma compactação mais longa, por sua vez, mantém mais segmentos e trabalho de consulta.
A compactação vectorial do Milvus descreve a compactação como a fusão de segmentos pequenos e a limpeza de dados eliminados, para melhorar o comportamento do armazenamento e das consultas. O mecanismo mostra por que motivo as bases de dados vectoriais podem reescrever ficheiros substanciais mesmo quando a alteração lógica é apenas um conjunto de eliminações.
O limite de falha consiste em presumir que o tamanho do snapshot indicado no momento da criação prevê o seu custo final. O volume de compactação, a frequência das actualizações, a compressão, os vectores eliminados, o espaço livre do conjunto de armazenamento e a duração do snapshot determinam os bytes retidos e a latência de cauda. A distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.
Perguntas frequentes sobre snapshots e compactação vectorial
Os snapshots devem ser desactivados durante a compactação?
Não automaticamente. Os snapshots protegem pontos de recuperação, mas agendar compactações grandes fora das janelas de snapshots pode reduzir a divergência retida. Qualquer alteração deve preservar um plano de cópia de segurança e de consistência da base de dados que tenha sido testado. Esse limite deve ser testado com dados domésticos representativos, em vez de ser presumido.
Por que motivo o tamanho da base de dados permanece elevado depois de os vectores eliminados serem compactados?
Os blocos antigos podem continuar a ser referenciados por snapshots, clones ou cópias de segurança, mesmo depois de a base de dados activa remover os segmentos obsoletos. Verifique separadamente os ficheiros da base de dados e o espaço referenciado pelo sistema de ficheiros. Este efeito deve continuar a ser mensurável na carga de trabalho prevista para o servidor doméstico.
Um snapshot pode capturar um índice vectorial inconsistente?
Sim, se os ficheiros da base de dados, os registos write-ahead, os manifestos e os metadados relacionados não forem colocados em estado quiescente ou capturados atomicamente. Utilize o mecanismo de checkpoint ou de flush da base de dados antes do snapshot do sistema de ficheiros, quando necessário. A distinção é importante quando várias fases do pipeline partilham o mesmo orçamento de armazenamento e memória.
Meça a divergência do snapshot durante uma fusão controlada
Clone um índice representativo, registe o tamanho lógico e físico, crie um snapshot e execute depois um ciclo medido de eliminações e compactação. Registe os bytes compactados, o pico temporário de espaço, os bytes referenciados pelo snapshot, o espaço livre do conjunto de armazenamento, a latência das escritas, a latência de cauda das consultas e o tempo necessário para recuperar espaço depois de eliminar o snapshot.
Compare o resultado com o mecanismo de bloqueio de snapshots descrito em mecanismo de bloqueio dos snapshots. Repita sem snapshot e com diferentes durações de retenção, mantendo constantes a versão da base de dados, o índice, os dados, a compressão, as definições do conjunto de armazenamento e a carga em segundo plano. Esse limite deve ser testado com dados domésticos representativos, em vez de ser presumido.
Agende os snapshots e a compactação com base na margem medida, e não na conveniência. Mantenha um ponto de recuperação consistente com a base de dados, reserve espaço para os segmentos antigos e novos e expire os snapshots apenas ao abrigo da política de retenção estabelecida, em vez de eliminar a protecção para ocultar erros de planeamento de capacidade.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Um LLM local pode retomar a geração depois de o seu processo reiniciar?
Uma explicação da retoma da geração de LLM baseada primeiro no mecanismo, das suas concessões em termos de recursos partilhados, de três perguntas frequentes...
Pode um servidor doméstico executar embeddings e transcodificação de vídeo na mesma GPU integrada?
Uma explicação baseada primeiro no mecanismo dos embeddings partilhados da iGPU e da transcodificação, das suas cedências em termos de recursos partilhados, três perguntas...
Como é que o tempo de vida do token de acesso afeta a segurança e o atrito no agregado familiar?
Uma explicação baseada primeiro no mecanismo da duração dos tokens de acesso, os compromissos relativos aos recursos partilhados, três perguntas frequentes sobre a propagação...
