Option d'utiliser des fichiers de support plats/textuels plutôt qu'un backend SQL (Postgres)

Contribuer Fonctionnalité
1

Actuellement, le stockage principal pour les messages du forum, les comptes utilisateurs, etc., est la base de données PostgreSQL.

Je suggère, s’il vous plaît, d’utiliser des fichiers texte simples comme format de stockage principal pour le contenu du forum.

En raison de problèmes de base de données difficiles à résoudre (difficiles pour moi en tant qu’utilisateur), je pense que le risque de perdre toutes les données du forum est élevé en raison du format binaire apparemment/effectivement opaque des bases de données SQL. Il semble que personne ne puisse réparer une base de données gravement endommagée (ce qui ne serait pas un problème visible comme le problème ci-dessus) ou que cela soit trop coûteux pour les non-spécialistes.

Je suis certain qu’il existe de très bonnes raisons d’utiliser des bases de données telles que PostgreSQL, notamment pour la performance. Cependant, je propose un format de texte lisible par l’homme pour les sauvegardes, en dernier recours d’urgence, au cas où les fonctionnalités de sauvegarde et de restauration de la base de données seraient corrompues ou défectueuses.

Vous n’avez probablement pas besoin d’être convaincu de l’incroyable puissance de Git, vous l’utilisez déjà. Le contenu du forum pourrait être stocké dans des sous-dossiers et de nombreux fichiers texte. Ainsi, l’ensemble du dossier pourrait être placé sous contrôle de version Git. Si des bogues sont introduits, il est beaucoup plus facile de tracer quel commit en est la cause.

Puisque les bases de données (peu fiables, complexes) seront probablement toujours nécessaires, ces fichiers texte (simples, fiables) pourraient servir de modèle pour recréer la base de données « à partir du code source ». Si le stockage des nouveaux messages dans des fichiers texte est trop lent en temps réel, vous pouvez activer l’option de sauvegarde dans des fichiers texte à la demande ou lorsque le système est inactif (écriture différée / cache d’écriture).

Les données publiques (messages publics du forum) seraient dans un dossier différent des données privées des utilisateurs, comme les mots de passe hachés. L’avantage supplémentaire serait que la partie publique (les messages) pourrait même être publiée sur un dépôt Git distant pour ceux qui trouvent cela utile (archivage). Les données des utilisateurs resteraient dans un dépôt Git local uniquement (ou un dépôt Git distant, privé et chiffré personnalisé).

2

Il y a ici une économie d’échelle. Un tel changement d’ingénierie est significatif. Si les scénarios ci-dessus étaient possibles, les implications en termes de performance seraient telles que vos coûts de fonctionnement supplémentaires dépasseraient probablement le coût d’un consultant pour corriger votre base de données.

Les bases de données existent parce qu’elles sont bien plus efficaces que l’alternative, à savoir les fichiers texte plats.

Le logiciel est gratuit, mais c’est là que s’arrête la gratuité. Vous feriez bien mieux d’investir à court terme dans un sujet du Marketplace que de promouvoir une approche qui rend Discourse trop coûteux à faire tourner.

5 « J'aime »
3

TL;DR : Non, vous ne voulez pas ça. Vraiment pas.

Je comprends votre besoin de plus de simplicité.

Mais.

Dans les années 1990, j’ai travaillé avec un logiciel de forum internet (BBS Telnet) basé sur des fichiers texte. Nous étions continuellement en quête de fonctionnalités plus nombreuses et meilleures. Nous avions besoin d’ajouter des « colonnes » aux données. Nous ajoutions une TABulation, puis la colonne supplémentaire. Nous devions appliquer cela à tous les fichiers existants. Ensuite, nous voulions supprimer (un autre) élément de données. Nous avons écrit un script awk pour parcourir tous les fichiers et retirer cet élément. Nous devions mettre le logiciel en mode maintenance pendant ce temps, car il rencontrait des fichiers texte avec un nombre de champs différent. C’était l’enfer. Nous désirions tant un meilleur système, mais nous devions pouvoir exécuter le logiciel avec des ressources minimales, et nous n’avions donc qu’un système de fichiers. Nous avions besoin… d’une base de données.

Cependant, la performance n’est pas le seul problème. Les fichiers texte peuvent aussi se corrompre, par exemple si deux processus y écrivent simultanément.

Il y a aussi ce qu’on appelle l’intégrité référentielle, qui garantit que les références internes existent (par exemple, ce message appartient au sujet #152787 et à l’utilisateur #406).

Et puis il y a les transactions, les instantanés, la réplication, l’équilibrage de charge.

Bien sûr, votre base de données peut tomber en panne. Ma voiture est tombée en panne hier parce que le logiciel de contrôle ABS, trop complexe, est vraiment vulnérable à de petits problèmes apparemment sans rapport. Il est impossible de la réparer moi-même. Je dois débourser une somme importante pour la faire réparer. Mais elle offre tellement d’avantages par rapport à la marche partout. Est-elle peu fiable ? Non. Elle freine toujours et j’ai été immédiatement averti par le témoin sur le tableau de bord.

Les bases de données ont été conçues pour la fiabilité, car les fichiers texte ne l’étaient pas.

16 « J'aime »
4

L’analogie de Richard est pertinente. Tenir à jour les données de Discourse dans des fichiers texte serait impossible.

Même ajouter le support d’une autre base de données coûterait de l’ordre de 200 000 $ par an.

Il vaudrait peut-être mieux définir un budget et demander dans Marketplace à quelqu’un de réparer votre base de données. C’est un travail difficile à chiffrer car il n’est pas immédiatement clair si vous avez un seul index corrompu avec quelques enregistrements à corriger ou plusieurs d’entre eux avec des dizaines à réparer.

7 « J'aime »
5

Les index corrompus dans PG10 sont un sujet que nous surveillons de près et nous ferons absolument ce qui est en notre pouvoir pour aider, dans le sujet que vous avez lié, pour le bénéfice de tous. J’espère que PG12 sera plus résistant à ce problème et que la mise à niveau le résoudra à long terme.

Mais je suis convaincu que « revenons aux fichiers texte simples » n’est pas une solution appropriée à ce problème.

10 « J'aime »
6

Postgres propose une solution de sauvegarde en texte brut, pg_dump.

pg_dump est un utilitaire pour sauvegarder une base de données PostgreSQL.

Les dumps de script sont des fichiers texte contenant les commandes SQL nécessaires pour reconstruire la base de données dans l’état où elle se trouvait au moment de la sauvegarde.

5 « J'aime »
7

Merci beaucoup pour votre attention et vos réponses ! Très apprécié ! :slight_smile:

3 « J'aime »
8

Stricto sensu, un ensemble de fichiers texte constitue une base de données, mais pas une que vous souhaiteriez utiliser pour des applications critiques ou exigeantes en performance.

2 « J'aime »