O Postgres protege o disco rígido de gravações repetidas nas mesmas células de memória?

Introdução:

O que deve ser apreciado é que o PostgreSQL não sabe nada sobre os discos subjacentes (se eles estão girando ferrugem ou SSDs, configurados para RAID ou qualquer outra coisa ). O PostgreSQL entrega os dados ao SO e confia no SO para cuidar deles ( às vezes não é uma boa ideia)!

Para SSDs, há dois fatores a serem considerados aqui:

• Nivelamento de desgaste

• TRIM-ming

É importante notar que nenhum deles tem nada a ver com aplicativos (ou seja, PostgreSQL, qualquer outro servidor de banco de dados ou qualquer aplicativo) que sejam executados no sistema! O primeiro é estritamente uma propriedade/capacidade do próprio SSD, o último um "método de cooperação" entre o SO e o SSD.

Nivelamento de desgaste:

Mensagem para levar para casa: O SSD distribui as gravações para diferentes blocos uniformemente porque os blocos SSD só podem sofrer um limited number of erase cycles before becoming unreliable!

Da Wiki :

O nivelamento de desgaste tenta contornar essas limitações organizando os dados para que as rasuras e as regravações sejam distribuídas uniformemente pela mídia. Dessa forma, nenhum bloco de apagamento único falha prematuramente devido a uma alta concentração de ciclos de gravação. 3 Na memória flash, um único bloco no chip é projetado para uma vida útil mais longa do que os outros, para que o controlador de memória possa armazenar dados operacionais com menos chance de corrupção. 4

Assim, o SSD decide onde realmente colocar os dados provenientes do sistema operacional (observação: não há menção de quais aplicativos esses dados podem vir). A ideia simples é que ele espalhe essas gravações ao redor da unidade para equalizar o desgaste em todos os blocos do disco para que alguns blocos não falhem prematuramente!

Isso pode se tornar complicado muito rapidamente - veja o wiki para mais detalhes:

TRIM-ming:

Mensagem para levar para casa: devido à estrutura subjacente dos SSDs, apenas blocos vazios podem ser gravados - se já houver dados em um bloco, esses dados antigos devem ser lidos e regravados no bloco junto com os novos dados - isso contribui para escrever-amplificação .

Se o sistema operacional informar ao disco (pós-exclusão) que os dados no bloco x não são mais necessários, o disco pode realizar a coleta de lixo (pode ser agendada) e o bloco ficará vazio e pronto para gravação sem amplificação de gravação . Não totalmente diferente de desfragmentar um HDD.

(novamente do Wiki - desculpas pela longa citação, mas é necessário):

Os SSDs armazenam dados em células de memória flash que são agrupadas em páginas tipicamente de 4 a 16 kiB, agrupadas em blocos de 128 a 512 páginas. Exemplo: blocos de 512 kiB que agrupam 128 páginas de 4 kiB cada. 7 As células de memória flash NAND podem ser gravadas diretamente somente quando estiverem vazias. Se eles contiverem dados, o conteúdo deve ser apagado antes de uma operação de gravação. Uma operação de gravação de SSD pode ser feita em uma única página, mas, devido a limitações de hardware, os comandos de apagamento sempre afetam blocos inteiros; 7consequentemente, gravar dados em páginas vazias em um SSD é muito rápido, mas diminui consideravelmente quando as páginas gravadas anteriormente precisam ser substituídas. Como é necessário apagar as células na página antes que ela possa ser gravada novamente, mas apenas blocos inteiros podem ser apagados, uma sobregravação iniciará um ciclo de leitura-exclusão-modificação-gravação:[7][12] o conteúdo de todo o bloco é armazenado em cache, então o bloco inteiro é apagado do SSD, então a(s) página(s) sobrescrita(s) é(ão) gravada(s) no bloco em cache e só então todo o bloco atualizado pode ser gravado na mídia flash. Esse fenômeno é conhecido como amplificação de gravação.[13][14]

Operação O comando TRIM permite que um sistema operacional notifique o SSD de páginas que não contêm mais dados válidos. Para uma operação de exclusão de arquivo, o sistema operacional marcará os setores do arquivo como livres para novos dados e, em seguida, enviará um comando TRIM para o SSD. Após o corte, o SSD não preservará nenhum conteúdo do bloco ao gravar novos dados em uma página de memória flash, resultando em menos amplificação de gravação (menos gravações), maior taxa de transferência de gravação (sem necessidade de uma sequência de leitura-exclusão-modificação), aumentando assim a vida útil da unidade.

O futuro do armazenamento:

Há muita pesquisa interessante em andamento re. armazenamento e, por motivos óbvios, armazenamento em bancos de dados. Embora isso esteja ficando acima do meu nível de especialização, se você pesquisar termos como "disco endereçável por byte", encontrará sites como aqui , que abriga um kit de ferramentas de memória persistente (endereçável por byte) ( Intel Optane pode suportar seu aparentemente), então os dias de leitura e escrita de dados pelo bloco podem estar contados?

Para uma explicação de por que temos blocos em primeiro lugar, veja este tópico sobre engenharia de software e veja aqui uma discussão interessante sobre o acesso direto ao hardware no modo de usuário, "ignorando" o sistema operacional... todas coisas fascinantes! io_uring (e eBPF) parecem ser os novos garotos no bloco Linux, mas você pode ler isso à vontade.

Respondendo as perguntas:

Se eu tiver a mesma linha na mesma coluna na mesma tabela na qual escrevo 4 bytes (um inteiro) 100.000 vezes por dia, isso desgastará o SSD? Para um SSD, 400 kb por dia não é nada, mas gravá-lo na mesma célula de memória o faria.

Minha opinião sobre o que foi dito acima é que o SSD espalharia as gravações por muitos blocos - levando a muito trabalho. Como exatamente isso seria feito dependeria dos algoritmos de nivelamento de desgaste do SSD.

O sistema de gerenciamento de banco de dados Postgres manipula essas células de alguma forma?

Absolutamente não ! O PostgreSQL apenas entrega os dados ao sistema de arquivos e permite que o FS & OS cuidem do armazenamento (embora veja aqui onde esse processo falhou devido a uma falha no Linux). Isto é como deveria ser – separação de interesses .

Ou os chips SSD modernos fazem isso no hardware?

Minhas leituras nesta área me levam a acreditar que é o firmware SSD que cuida do nivelamento de desgaste e do TRIM-ming.

Ou tudo é gravado na mesma célula de memória e apenas trocamos SSDs mortos com o passar do tempo?

Normalmente, há uma pequena área de alta tolerância ao desgaste no SSD onde os dados de gravação do bloco são mantidos e alguns deles podem ter áreas de reserva para quando os blocos começam a falhar - obviamente, quanto mais sofisticado seu SSD, mais você pagará isto.

Para reiterar: o PostgreSQL não tem conhecimento ou controle sobre o que acontece com os dados quando os entrega ao sistema operacional - eles são armazenados em buffer, direto para o disco, perdidos com todas as mãos?

Isso dependerá dos algoritmos de agendamento do próprio sistema operacional e da carga sob a qual ele está - outra área inteira da ciência da computação! :-) ps +1 para uma pergunta interessante que me fez aprender sobre isso (estava na lista de tarefas!).

O Postgres não grava o arquivo de dados para cada alteração. Como a maioria dos RDBMSs, ele usa Write-Ahead Logging e apenas ocasionalmente atualiza os arquivos de dados.

O uso do WAL resulta em um número significativamente reduzido de gravações em disco, porque apenas o arquivo de log precisa ser liberado para o disco para garantir que uma transação seja confirmada, em vez de todos os arquivos de dados alterados pela transação.

Portanto, mesmo sem o nivelamento de desgaste do SSD, você não verá um grande número de gravações no mesmo local em um arquivo porque os logs são gravados sequencialmente e os arquivos de dados são atualizados apenas durante um CHECKPOINT agendado ou outro processo em segundo plano.