Attualmente, l’archiviazione principale per i post del forum, gli account utente e altro è il database PostgreSQL.
Posso suggerire gentilmente di utilizzare come formato di archiviazione principale per i contenuti del forum semplici file di testo?
A causa di problemi al database difficili da risolvere database issues (difficili per me, in quanto utente), ritengo che il rischio di perdere tutti i dati del forum sia elevato a causa del formato binario apparentemente/opaco dei database SQL. Sembra che nessuno possa riparare un database gravemente danneggiato (che non sarà un problema visibile come quello sopra citato) o che il costo sia troppo alto per i non esperti.
Sono certo che ci siano ottime ragioni per utilizzare database come PostgreSQL, ad esempio per le prestazioni. Tuttavia, propongo un formato di testo leggibile dall’uomo per i backup come ultima risorsa di emergenza nel caso in cui le funzionalità di backup e ripristino del database siano danneggiate o non funzionanti.
Probabilmente non c’è bisogno di convincervi su quanto sia fantastico Git, dato che lo state già utilizzando. I contenuti del forum potrebbero essere archiviati come sottocartelle e numerosi file di testo. In questo modo, l’intera cartella potrebbe essere posta sotto controllo versione di Git. Se vengono introdotti bug, sarà molto più semplice tracciare quale commit li abbia causati.
Poiché i database (inaffidabili e complessi) sono probabilmente ancora necessari, questi file di testo (semplici e affidabili) potrebbero servire come modello per ricreare il database “dalla fonte”. Se l’archiviazione di nuovi post nei file di testo è troppo lenta in tempo reale, è possibile attivare l’opzione di backup su file di testo su richiesta o quando il sistema è inattivo. (Scrittura ritardata / cache di scrittura.)
I dati pubblici (post pubblici del forum) sarebbero in una cartella diversa rispetto ai dati privati degli utenti, come le password crittografate. Un vantaggio aggiuntivo sarebbe che la parte pubblica (i post) potrebbe persino essere pubblicata su un repository Git remoto per coloro che lo ritengono utile (archiviazione). I dati degli utenti rimarrebbero in un repository Git locale (o in un repository Git remoto, privato e crittografato personalizzato).
C’è qui un’economia di scala. Un tale cambiamento ingegneristico è significativo. Se quanto sopra fosse possibile, le implicazioni sulle prestazioni farebbero sì che i costi operativi aggiuntivi superassero probabilmente il costo di un consulente per risolvere il problema del tuo database.
I database esistono perché sono molto più efficienti dell’alternativa, ovvero i file di testo semplici.
Il software è gratuito, ma solo fino a un certo punto. Farai molto meglio a investire a breve termine in un argomento del Marketplace piuttosto che promuovere un approccio che rende Discourse troppo costoso da gestire.
Negli anni '90 ho lavorato con software per forum internet (BBS Telnet) basato su file di testo. Avevamo continuamente il desiderio di avere funzionalità migliori e più avanzate. Avevamo bisogno di aggiungere “colonne” ai dati. Aggiungevamo un TAB e poi inserivamo la colonna extra. Dovevamo farlo su tutti i file esistenti. Poi volevamo rimuovere un’altra parte dei dati. Abbiamo scritto uno script awk per scorrere tutti i file ed eliminare questa parte di dati. Nel frattempo dovevamo mettere il software in modalità manutenzione, perché il software si trovava di fronte a file di testo con un numero diverso di campi. È stato un inferno. Desideravamo così tanto un sistema migliore, ma dovevamo poter eseguire il software con risorse minime, quindi avevamo solo un file system. Avevamo bisogno… di un database.
Tuttavia, le prestazioni non sono l’unico problema. Anche i file di testo possono corrompersi, ad esempio se due processi scrivono su di essi contemporaneamente.
C’è anche qualcosa chiamato integrità referenziale, che garantisce l’esistenza di riferimenti interni (ad esempio, questo post appartiene al topic #152787 e all’utente #406).
E poi ci sono le transazioni, gli snapshot, la replica e il bilanciamento del carico.
Certo, il tuo database può bloccarsi. La mia auto si è guastata ieri perché il software di controllo ABS, troppo complesso, è davvero vulnerabile a piccoli problemi apparentemente non correlati. È impossibile ripararlo da solo. Devo sborsare una somma significativa per farlo riparare. Ma offre molti vantaggi rispetto a spostarsi a piedi ovunque. È inaffidabile? No. I freni funzionano ancora e sono stato immediatamente avvisato dall’indicatore sulla plancia.
I database sono stati progettati per l’affidabilità, perché i file di testo non lo erano.
L’analogia di Richard è appropriata. Tenere aggiornati i dati di Discourse in file di testo sarebbe impossibile.
Anche aggiungere il supporto per un altro database costerebbe dell’ordine di 200.000 dollari all’anno.
Potrebbe essere meglio decidere un budget e chiedere nel canale Marketplace a qualcuno di riparare il tuo database. È un lavoro difficile da quotare perché non è immediatamente chiaro se si tratti di un indice corrotto con poche voci da correggere o di diversi indici con decine di voci da sistemare.
Gli indici corrotti in PG10 sono qualcosa su cui stiamo tenendo un occhio attento e faremo assolutamente tutto il possibile per aiutare, nel thread che hai linkato, a beneficio di tutti. Spero che PG12 sia più resistente a questo problema e che l’aggiornamento lo risolva nel lungo termine.
Tuttavia, sono convinto che “tornare ai file di testo semplice” non sia una soluzione appropriata a questo problema.
Postgres offre una soluzione di backup in testo semplice, pg_dump.
pg_dump è un’utilità per eseguire il backup di un database PostgreSQL.
I dump degli script sono file di testo semplice contenenti i comandi SQL necessari per ricostruire il database allo stato in cui si trovava al momento del salvataggio.
