Quão atômico é o uso de banco de dados de Berkeley?

Question

Estou escrevendo um aplicativo simples com 24 itens em um hash para ser persistente nas execuções do programa, para que o Berkeley DB (DBM) seja adequado para esta tarefa.

E é apenas por diversão.

Mas eu me pergunto se usá-lo (com Ruby), então quando o usuário pressiona Ctrl-C, a execução é interrompida. Nesse caso, os dados não podem ser confusos?

Por exemplo, se o valor em dB for 63, e eu o incremento em 1 (para ser 64)

63 =  111111 (in binary)  
64 = 1000000 (in binary)

Então, o Ctrl-C poderia ocorrer exatamente quando o 1 "mais significativo" é escrito e, mas os 0s não foram escritos? Nesse caso, o valor no banco de dados será 127 em vez de 63 ou 64. E se não for rubi, mas em C, e o usuário usa "WHELL WAND" ou "matar" para matar o processo? Pense bem, o disco rígido provavelmente escreve este byte (ou 4 bytes) para a superfície do disco rígido de uma só vez, para que isso não aconteça.

Se o Ctrl-C não fará com que isso aconteça, uma queda de energia ou eu chutando o plugue de energia pode fazer com que isso aconteça? Por exemplo, quando o valor é em cache na RAM e, embora seja escrito no disco rígido, chuto o plugue de energia e o disco rígido perde energia antes que os 0s sejam gravados. Eu sei um em um milhão de vezes, isso não vai acontecer, mas isso é apenas uma questão de curiosidade.

Por outro lado, se meu script for

1. Diminuir o valor da moeda
2. Dê ao usuário um "hambúrguer" em seu inventário

Então, quando o usuário pressiona Ctrl-C, e isso acontece entre (1) e (2) acima, o usuário terá menos moeda e não receberá hambúrguer.

Para impedir que tudo isso aconteça, seria usar o método transacional usando Sleepycat, Sqlite ou MySQL, e nenhum deles acontecerá?

Answer 1

Nenhum bom sistema de banco de dados (uma categoria que inclui Berkley DB) pode ser interrompida da maneira como você sugere, com um valor parcialmente atualizado. Quando você pressiona o Control-C, você não pode interromper a inseguro da CPU. Sempre há algum nível de granularidade na interrupção, e bancos de dados bem escritos aproveitam esse fato para se proteger contra o banco de dados em um estado inconsistente.

O potencial de corrupção e perda de dados existe quando a energia acaba, mas os detalhes sobre se os dados seriam perdidos ou corrompidos têm mais a ver com o sistema de arquivos no qual os arquivos do banco de dados são armazenados. Um bom sistema de arquivos de diário, por exemplo, escreve o que vai fazer em um "diário", então faz isso e depois escreve no diário que o fez. Portanto, se ele perder energia durante uma operação de gravação, por exemplo, ele analisa o diário para ver se há algo que precisa terminar antes de permitir o acesso ao sistema de arquivos. Esta é uma simplificação excessiva, mas você pode obter os detalhes verificando o EXT3 na Wikipedia, por exemplo.