Minha pergunta é direcionada ao Postgres, mas as respostas podem ser boas o suficiente vindas de qualquer base de dados.
Minhas suposições estão corretas:
- Os discos têm um tamanho de bloco fixo?
- O controlador RAID pode ter um tamanho de bloco diferente? Um bloco RAID é dividido em vários blocos de disco reais?
- O sistema de arquivos também possui um tamanho de bloco independente que novamente é dividido no tamanho do bloco RAID?
- O Postgres trabalha com blocos fixos de 8k. Como o mapeamento para o tamanho do bloco do sistema de arquivos acontece aqui? Os blocos Postgres 8k são agrupados pelo sistema de arquivos?
Ao configurar um sistema, é melhor ter todos os blocos em 8k? Ou as configurações não importam? Eu também queria saber se algumas configurações de tamanho de bloco "erradas" poderiam colocar em risco a integridade dos dados em caso de falha? Talvez se um bloco Postgres 8k tiver que ser dividido em vários blocos de disco?
Ou nada é agrupado e, portanto, perco espaço em disco a cada incompatibilidade entre tamanhos de bloco definidos?
Setores de disco
Um disco tem um tamanho de setor fixo, normalmente 512 bytes ou 4096 bytes em alguns discos modernos; esses discos também terão um modo em que emulam setores de 512 bytes. O disco terá trilhas com números variados de setores; as faixas mais próximas da parte externa do disco têm mais setores, pois têm mais espaço para uma determinada densidade de bits. Isso permite um uso mais eficiente do espaço em disco; normalmente uma trilha terá algo como 1.000 setores de 512 bytes em um disco moderno.
Algumas estruturas de formatação também podem incluir informações de correção de erros nos secotrs, que se manifestam nos discos sendo formatados em baixo nível com setores de 520 ou 528 bytes. Neste caso, o setor ainda possui 512 bytes de dados do usuário. Nem o Windows nem o Linux suportam isso diretamente, embora o i5OS (IBM iSeries) e vários controladores SAN o façam.
Normalmente, o setor/cabeça/faixa é traduzido em um endereço de bloco lógico; devido a problemas históricos de compatibilidade com versões anteriores, a geometria (cabeças x setores x trilhas) vista pelo sistema operacional (principalmente em discos IDE e SATA) normalmente tem pouco a ver com sua estrutura física.
Tamanho da faixa RAID
Um controlador RAID pode ter um tamanho de distribuição para uma matriz usando distribuição (por exemplo, RAID-5 ou RAID-10). Se a matriz tiver (por exemplo) uma faixa de 128k, cada disco terá 128k de dados contíguos e o próximo conjunto de dados estará no próximo disco. Normalmente, você pode esperar obter aproximadamente uma faixa por rotação do disco, portanto, o tamanho da faixa pode afetar o desempenho em determinadas cargas de trabalho.
Alinhamento de partição
Uma partição de disco pode ou não se alinhar exatamente com uma faixa RAID e pode causar degradação do desempenho devido a leituras divididas se não estiver alinhada. Alguns sistemas (por exemplo, servidor Windows 2008) configurarão automaticamente as partições para alinhá-las com os tamanhos de distribuição do volume do disco. Alguns (por exemplo, servidor Windows 2003) não, e você tem que usar um utilitário de partição que suporte o alinhamento de distribuição para garantir que eles o façam.
Tamanho do Bloco do Sistema de Arquivos
O sistema de arquivos alocará blocos de armazenamento em blocos de um determinado tamanho. Geralmente isso é configurável - por exemplo, o NTFS suportará unidades de alocação de (IIRC) 4K a 64K. O desalinhamento de partições e blocos do sistema de arquivos com faixas RAID pode fazer com que uma única leitura de bloco do sistema de arquivos gere vários acessos ao disco, onde apenas um seria necessário se os blocos do sistema de arquivos estivessem alinhados corretamente com as faixas RAID.
Tamanho do bloco de banco de dados
O banco de dados alocará espaço em uma tabela ou índice em um determinado tamanho de bloco. No caso do SQL Server, é 8K e 8K é o padrão em muitos sistemas. Em alguns sistemas como o Oracle, isso é configurável e no PostgreSQL é uma opção de tempo de compilação. Na maioria dos sistemas, a alocação de espaço para tabelas normalmente é feita em blocos maiores, com blocos alocados dentro desses blocos.
O desalinhamento do sistema de arquivos e dos blocos de alocação de dados pode gerar várias E/Ss para uma única gravação de bloco, o que pode gerar uma penalidade de desempenho.
Fragmentação de E/S
Normalmente, um DBMS realmente fará sua E/S em blocos de mais de um bloco. Por exemplo, no SQL Server, toda a E/S é feita em blocos de 8 blocos, 64k no total). No Oracle isso é configurável. A inspeção casual dos documentos do PostgreSQL não revela uma descrição específica sobre se o PostgreSQL faz isso, então não tenho certeza de como ele funciona nesta plataforma.
Quando o bloco de E/S é maior que o tamanho do bloco do sistema de arquivos ou está desalinhado com os limites da faixa RAID, uma gravação de disco do banco de dados pode causar várias gravações de disco, o que gera uma penalidade de desempenho.
Uso do espaço em disco
Nenhum espaço em disco é desperdiçado - a E/S do banco de dados usará uma ou mais operações físicas de E/S no disco para concluir - mas a E/S ajustada incorretamente pode gerar ineficiências que tornarão o banco de dados mais lento. Os principais itens que devem estar alinhados são:
Faixas e partições RAID - a partição deve começar em um limite de faixa RAID.
Alocação de E/S do sistema de arquivos e limites de partição/partição RAID - um limite de faixa RAID deve se alinhar com uma unidade de alocação do sistema de arquivos e deve ser um múltiplo do tamanho da unidade de alocação do sistema de arquivos.
Tamanho de gravação do disco e tamanho da unidade de alocação do sistema de arquivos. Deve haver uma relação 1:1 entre as operações de E/S do banco de dados e as operações de E/S do sistema de arquivos.
O desalinhamento não cria um problema maior de integridade de dados do que estaria presente de outra forma. O banco de dados e o sistema de arquivos possuem mecanismos para garantir que as operações do sistema de arquivos sejam atômicas. Geralmente, uma falha de disco resultará em perda de dados, mas não em problemas de integridade de dados.