Porque é que os ficheiros de base de dados e multimédia se comportam de forma diferente num NAS doméstico?

Os ficheiros de base de dados e de multimédia comportam-se de forma diferente num NAS doméstico porque um é uma coleção mutável de páginas enquanto o outro é geralmente um fluxo de bytes estável.

As bases de dados realizam pequenas leituras aleatórias, acrescentam registos de recuperação, atualizam índices e esperam por confirmações duráveis. A reprodução de multimédia lê longos intervalos por ordem e pode fazer pré-carregamento. Ambos podem ocupar o mesmo número de gigabytes, mas pressionam a latência, cache, registos do sistema de ficheiros e filas do disco de formas muito diferentes.

Ficheiros de Base de Dados São Páginas Mutáveis; Ficheiros de Multimédia São Fluxos Estáveis

Um motor de base de dados trata os seus ficheiros como páginas estruturadas. Uma consulta pode buscar uma página de índice estreita e depois saltar para várias páginas de dados não relacionadas. Uma atualização pode tocar nos dados, índice, registo de transações e mais tarde num ponto de verificação. Uma visão concisa dos padrões de I/O de base de dados explica porque é que os registos e ficheiros de dados podem ter perfis de latência diferentes dentro do mesmo motor.

Um ficheiro finalizado de filme ou música é geralmente imutável durante a reprodução. O leitor avança por longos intervalos e raramente precisa de reescrever bytes anteriores. Essa previsibilidade permite que o sistema operativo e o dispositivo de armazenamento combinem pedidos e façam pré-busca dos dados seguintes.

A Durabilidade Faz com que as Gravações na Base de Dados Esperem

Muitas bases de dados usam registo antecipado de escrita: um registo de alteração deve chegar ao armazenamento estável antes que a página de dados modificada possa ser considerada confirmada com segurança. A sequência de registo antecipado de escrita mostra porque é que um pequeno acréscimo sequencial ao registo pode estar no caminho crítico mesmo quando a sua largura de banda é pequena.

Os pontos de verificação depois descarregam páginas sujas em lotes, adicionando uma segunda forma de I/O. Isso significa que uma base de dados pode alternar entre confirmações curtas sensíveis a fsync e gravações pesadas em segundo plano. Um SSD pode melhorar ambos, mas os números de débito de multimédia ainda não prevêem o tempo de resposta da base de dados porque esta frequentemente espera pela latência de conclusão em vez de megabytes por segundo.

A Reprodução de Multimédia Beneficia da Leitura Antecipada e do Acesso por Intervalos

A deteção sequencial permite que o kernel busque dados antes do leitor os solicitar. Num exemplo NFS, aumentar a leitura antecipada do sistema de ficheiros de rede aumentou substancialmente o débito para ficheiros sequenciais grandes, enquanto o autor também alerta que o pré-carregamento excessivo pode desperdiçar trabalho em acessos semi-aleatórios.

Os leitores podem também solicitar intervalos de bytes selecionados ao iniciar ou procurar. Uma explicação prática dos pedidos de intervalo de vídeo mostra como o cliente salta para uma parte de um ficheiro grande sem descarregar tudo antes. Estes pedidos são maiores e mais previsíveis do que uma caminhada de índice de base de dados, mesmo quando ambos chegam pela rede.

As Bibliotecas de Multimédia Ainda Geram Trabalho Paralelo Semelhante a Bases de Dados

A carga útil de multimédia pode ser sequencial, mas a biblioteca à sua volta não é. Posters, miniaturas, legendas, histórico de visualização, índices de pesquisa e bases de dados de metadados criam atividade de ficheiros pequenos e de base de dados. Uma varredura pode ler todos os cabeçalhos de multimédia enquanto escreve milhares de derivados pequenos.

Isto explica porque a reprodução pode ser fluida enquanto a navegação na biblioteca ou a geração de miniaturas parece lenta. O caminho do ficheiro grande está saudável; a base de dados auxiliar está à espera de I/O aleatório ou de um diário ocupado. Testar apenas uma cópia de filme perde a carga de trabalho com que os utilizadores realmente interagem.

Um NAS Pode Servir Ambos, mas o Estrangulamento Muda

Use conjuntos de dados ou volumes específicos para a carga de trabalho quando a plataforma os suportar. Registos grandes e leitura antecipada podem servir multimédia estável, enquanto o armazenamento de base de dados beneficia de baixa latência, alinhamento adequado de páginas, cache conservador e gravações síncronas fiáveis. Pools físicos separados proporcionam isolamento mais forte quando uma varredura de multimédia bloqueia repetidamente o trabalho da base de dados.

Não ajuste apenas com base nas extensões dos ficheiros. Meça a latência de confirmação da base de dados e as falhas de cache ao lado do débito de leitura de multimédia e do pré-carregamento. Uma comparação atual de ajuste de leitura antecipada torna a fronteira útil: cargas de trabalho sequenciais de backup e vídeo podem beneficiar de pré-busca maior, enquanto o acesso aleatório a bases de dados pode desperdiçar largura de banda quando a mesma política é aplicada indiscriminadamente.

Perguntas Frequentes

Um benchmark rápido sequencial de NAS prova que uma base de dados será rápida?

Não. Mede uma carga de trabalho mais próxima da transferência de multimédia. O desempenho da base de dados depende muito de IOPS aleatórios, enfileiramento, latência do fsync, comportamento do cache e interferência de pontos de verificação.

Os ficheiros de multimédia e de base de dados devem usar sempre SSDs separados?

Nem sempre. Cargas de trabalho leves podem coexistir. A separação torna-se valiosa quando varreduras, transcodificações ou transferências causam picos repetidos de latência na base de dados que o agendamento e as políticas de conjuntos de dados não conseguem controlar.

Porque é que a navegação em multimédia pode atrasar quando a reprodução é fluida?

A navegação frequentemente consulta uma base de dados e abre muitas miniaturas ou ficheiros auxiliares. A reprodução normalmente lê alguns longos intervalos e faz pré-carregamento, por isso pressiona uma parte diferente do caminho de armazenamento.