Actualmente, el almacenamiento principal para las publicaciones del foro, las cuentas de usuario, etc., es la base de datos PostgreSQL.
¿Podría sugerir, por favor, que el formato de almacenamiento principal para el contenido del foro sean archivos de texto simples?
Debido a problemas de base de datos difíciles de corregir (enlaces) (difíciles para mí, como usuario), creo que el riesgo de perder todos los datos del foro es alto debido al formato binario aparentemente/effectivamente opaco de las bases de datos SQL. Parece que nadie puede reparar una base de datos gravemente dañada (lo cual no será un problema visible como el mencionado anteriormente) o resulta demasiado costoso para los no expertos.
Estoy seguro de que existen razones muy válidas para utilizar bases de datos como PostgreSQL, como el rendimiento. Sin embargo, propongo un formato de texto transparente y legible por humanos para las copias de seguridad como último recurso de emergencia en caso de que la funcionalidad de copia de seguridad y restauración de la base de datos esté corrupta o rota.
Probablemente no necesiten convencerse de lo increíble que es Git, ya lo están utilizando. El contenido del foro podría almacenarse como subcarpetas y en numerosos archivos de texto. De este modo, toda la carpeta podría someterse al control de versiones de Git. Si se introducen errores, será mucho más fácil rastrear qué commit los causó.
Dado que las bases de datos (poco fiables y complejas) probablemente sigan siendo necesarias, estos archivos de texto (simples y fiables) podrían servir como plantilla para recrear la base de datos “desde el origen”. Si el almacenamiento de nuevas publicaciones en archivos de texto es demasiado lento en tiempo real, pueden habilitar la opción de copia de seguridad en archivos de texto bajo demanda o cuando el sistema esté inactivo. (Escritura diferida / caché de escritura.)
Los datos públicos (publicaciones públicas del foro) estarían en una carpeta diferente a los datos privados de los usuarios, como las contraseñas hasheadas. Una ventaja adicional sería que la parte pública (publicaciones) podría incluso publicarse en un repositorio remoto de Git para aquellos que lo consideren útil (archivo). Los datos de los usuarios permanecerían en un repositorio de Git local (o en un repositorio Git remoto, privado y cifrado personalizado).
Aquí hay una economía de escala. Un cambio de ingeniería de este tipo es significativo. Si lo anterior fuera posible, las implicaciones en el rendimiento harían que tus costos operativos adicionales probablemente superaran el costo de contratar a un consultor para solucionar tu base de datos.
Las bases de datos existen porque son mucho más eficientes que la alternativa: archivos de texto planos.
El software es gratuito, pero eso es todo. Te convendrá mucho más hacer una inversión a corto plazo en un tema del Marketplace que promover un enfoque que haga que Discourse sea demasiado costoso de ejecutar.
En los años 90 trabajé con software de foros de internet (BBS por telnet) basado en archivos de texto. Estábamos continuamente deseando más y mejores funcionalidades. Necesitábamos agregar “columnas” a los datos. Añadíamos una TAB y luego la columna extra. Necesitábamos aplicarlos a todos los archivos existentes. Luego queríamos eliminar (otra) pieza de datos. Escribimos un script en awk para recorrer todos los archivos y eliminar esa pieza de datos. Mientras tanto, teníamos que poner el software en modo de mantenimiento porque el software vería archivos de texto con un número diferente de campos. Fue un infierno. Deseábamos tanto un sistema mejor, pero necesitábamos poder ejecutar el software con recursos mínimos, por lo que solo teníamos un sistema de archivos. Necesitábamos… una base de datos.
Sin embargo, el rendimiento no es el único problema. Los archivos de texto también pueden corromperse, por ejemplo, si dos procesos escriben en ellos al mismo tiempo.
También existe algo llamado integridad referencial, que garantiza que las referencias internas existan (por ejemplo, esta publicación pertenece al tema #152787 y al usuario #406).
Y luego están las transacciones, los instantáneos, la replicación y el equilibrio de carga.
Por supuesto, tu base de datos puede fallar. Mi coche se averió ayer porque el software de control ABS, demasiado complejo, es realmente vulnerable a problemas pequeños y aparentemente no relacionados. Es imposible repararlo yo mismo. Tengo que desembolsar una cantidad significativa de dinero para que lo reparen. Pero tiene tantas ventajas sobre ir caminando a todas partes. ¿Es poco fiable? No. Todavía frena y me advirtió inmediatamente el indicador en el tablero.
Las bases de datos se construyeron para ser fiables porque los archivos de texto no lo eran.
La analogía de Richard es acertada. Mantener al día los datos de Discourse en archivos de texto sería imposible.
Incluso añadir soporte para otra base de datos costaría del orden de 200.000 dólares al año.
Quizás te convenga más definir un presupuesto y preguntar en Marketplace si alguien puede arreglar tu base de datos. Es un trabajo difícil de presupuestar porque no queda claro de inmediato si tienes un índice corrupto con unos pocos registros que reparar o varios de ellos con docenas de registros que solucionar.
Los índices corruptos en PG10 son algo que estamos vigilando de cerca y, en el tema que vinculaste, haremos todo lo posible para ayudar, en beneficio de todos. Espero que PG12 sea más resistente a este problema y que la actualización lo elimine a largo plazo.
Sin embargo, siento que “volver a archivos de texto plano” no es una solución adecuada para este problema.
Postgres ofrece una solución de copia de seguridad en texto plano, pg_dump.
pg_dump es una utilidad para realizar copias de seguridad de una base de datos PostgreSQL.
Los volcados de script son archivos de texto plano que contienen los comandos SQL necesarios para reconstruir la base de datos al estado en el que se encontraba en el momento en que se guardó.
Estrictamente hablando, un montón de archivos de texto es una base de datos, solo que no es una que quieras usar para algo crítico o que requiera alto rendimiento.
