Opção de usar arquivos de backup planos/texto em vez do backend SQL (Postgres)

Contribuir Funcionalidade
1

Atualmente, o armazenamento primário para posts do fórum, contas de usuários etc. é o banco de dados PostgreSQL.

Posso sugerir, por favor, que o formato de armazenamento principal para o conteúdo do fórum seja arquivos de texto simples?

Devido a problemas de banco de dados difíceis de corrigir (difíceis para mim, como usuário), acho que o risco de perder todos os dados do fórum é alto devido ao formato binário aparentemente/efetivamente opaco dos bancos de dados SQL. Parece que ninguém consegue corrigir um banco de dados seriamente corrompido (o que não será um problema visível como no caso acima) ou é muito caro para leigos.

Tenho certeza de que existem razões muito boas para usar bancos de dados como o PostgreSQL, como desempenho. No entanto, proponho um formato de texto legível por humanos para backups como último recurso de emergência, caso a funcionalidade de backup e restauração do banco de dados esteja corrompida ou quebrada.

Você provavelmente não precisa ser convencido sobre o quão incrível o Git é; você já o utiliza. O conteúdo do fórum poderia ser armazenado como subpastas e muitos arquivos de texto. Assim, toda a pasta poderia ser colocada sob controle de versão do Git. Se qualquer bug for introduzido, será muito mais fácil rastrear qual commit o causou.

Como os bancos de dados (inconfiáveis, complexos) provavelmente ainda serão necessários, esses arquivos de texto (simples, confiáveis) poderiam servir como modelo para recriar o banco de dados “a partir do código fonte”. Se o armazenamento de novos posts em arquivos de texto for muito lento em tempo real, você pode ativar a opção de backup em arquivo de texto sob demanda ou quando o sistema estiver ocioso. (Gravação atrasada / cache de gravação.)

Dados públicos (posts públicos do fórum) estariam em uma pasta diferente dos dados privados de usuários, senhas hashadas. Uma vantagem adicional seria que a parte pública (posts) poderia até ser publicada em um repositório remoto do Git para aqueles que acharem isso útil (arquivamento). Os dados dos usuários permaneceriam em um repositório Git apenas local (ou personalizado, remoto, privado, criptografado).

2

Há uma economia de escala aqui. Uma mudança de engenharia dessa magnitude é significativa. Se o que foi mencionado acima fosse possível, as implicações de desempenho seriam tais que seus custos operacionais adicionais provavelmente superariam o custo de contratar um consultor para corrigir seu banco de dados.

Os bancos de dados existem porque são muito mais eficientes do que a alternativa: arquivos de texto planos.

O software é gratuito, mas é só isso. Você terá muito mais vantagem ao fazer um investimento de curto prazo em um tópico do Marketplace do que em promover uma abordagem que torna o Discourse muito caro para operar.

5 curtidas
3

TL;DR Não, você não quer isso. De verdade.

Entendo sua necessidade por mais simplicidade.

Mas.

Nos anos 1990, trabalhei com software de fórum na internet (BBS via telnet) baseado em arquivos de texto. Estávamos constantemente ávidos por mais e melhores funcionalidades. Precisávamos adicionar “colunas” aos dados. Adicionávamos uma TAB e depois inseríamos a coluna extra. Precisávamos fazer isso em todos os arquivos existentes. Depois, queríamos remover (outro) trecho de dados. Escrevemos um script awk para percorrer todos os arquivos e remover essa parte. Enquanto isso, precisávamos colocar o software em modo de manutenção, pois ele encontraria arquivos de texto com número diferente de campos. Foi um inferno. Nós ansiávamos tanto por um sistema melhor, mas precisávamos executar o software com recursos mínimos e, portanto, só tínhamos o sistema de arquivos. Precisávamos… de um banco de dados.

No entanto, o desempenho não é o único problema. Arquivos de texto também podem corromper, por exemplo, se dois processos estiverem escrevendo neles ao mesmo tempo.

Existe também algo chamado integridade referencial, que garante que as referências internas existam (por exemplo, este post pertence ao tópico #152787 e ao usuário #406).

E depois há transações, snapshots, replicação e balanceamento de carga.

Claro, seu banco de dados pode falhar. Meu carro quebrou ontem porque o software de controle ABS excessivamente complexo é realmente vulnerável a pequenos problemas aparentemente não relacionados. É impossível consertá-lo sozinho. Preciso desembolsar uma quantia significativa para fazer o reparo. Mas ele tem tantas vantagens sobre andar a pé em todos os lugares. É pouco confiável? Não. Ainda freia e fui imediatamente avisado pelo indicador no painel.

Bancos de dados foram construídos para confiabilidade porque arquivos de texto não eram.

16 curtidas
4

A analogia de Richard é apropriada. Manter os dados do Discourse em arquivos de texto seria impossível.

Mesmo adicionar suporte a outro banco de dados custaria na ordem de US$ 200.000 por ano.

Talvez seja melhor definir um orçamento e perguntar no Marketplace se alguém pode corrigir seu banco de dados. É um trabalho difícil de licitar, pois não fica imediatamente claro se você tem apenas um índice corrompido com alguns registros para corrigir ou vários deles com dezenas de registros para arrumar.

7 curtidas
5

Os índices corrompidos no PG10 são algo que estamos monitorando de perto e, com certeza, ajudaremos da melhor forma possível, no tópico que você vinculou, para o benefício de todos. Espero que o PG12 seja mais resistente a esse problema e que a atualização o resolva a longo prazo.

Mas, com certeza, sinto que “voltar a usar arquivos de texto simples” não é uma solução adequada para esse problema.

10 curtidas
6

O Postgres oferece uma solução de backup em texto simples, o pg_dump.

pg_dump é um utilitário para fazer backup de um banco de dados PostgreSQL.

Os dumps de script são arquivos de texto simples contendo os comandos SQL necessários para reconstruir o banco de dados no estado em que estava no momento em que foi salvo.

5 curtidas
7

Muito obrigado pela sua consideração e pelas respostas! Muito apreciado! :slight_smile:

3 curtidas
8

Estritamente falando, um conjunto de arquivos de texto é um banco de dados, apenas não um que você gostaria de usar para algo crítico ou de alto desempenho.

2 curtidas