Pourquoi le système de fichiers est-il préféré pour les journaux au lieu du SGBDR?
La question doit être claire par son titre. Par exemple, Apache enregistre ses journaux d'accès et d'erreurs dans des fichiers au lieu de SGBDR, quelle que soit la taille à laquelle il est utilisé.
Pour RDMS, nous devons simplement écrire des requêtes SQL et il fera le travail tandis que pour les fichiers, nous devons décider d'un format particulier, puis écrire des expressions rationnelles ou peut être des analyseurs pour les manipuler. Et ceux-ci pourraient même échouer dans des circonstances particulières si un grand soin n'était pas apporté.
Pourtant, tout le monde semble préférer le système de fichiers pour maintenir les journaux. Je ne suis partisan d'aucune de ces méthodes, mais j'aimerais savoir pourquoi elle est pratiquée de cette façon. Est-ce la vitesse ou la maintenabilité ou autre chose?
Trop de choses peuvent échouer avec la base de données et l'enregistrement de ces échecs est également important.
À moins que vous n'ayez un système de base de données permettant des transactions autonomes (ou aucune transaction du tout), la journalisation nécessiterait une connexion distincte, de sorte qu'une restauration ou une validation de la journalisation n'interfère pas avec la restauration ou la validation dans l'application.
Beaucoup de choses qui méritent d'être enregistrées se produisent au démarrage, c'est-à-dire peut-être avant que la connexion à la base de données ne soit établie.
Dans ce qui pourrait être une configuration typique, un nouveau fichier journal est créé chaque jour, les anciens fichiers journaux sont compressés et conservés pendant 2 semaines, avant d'être finalement supprimés. Il n'est pas facile de faire de même dans un SGBDR.
J'ai déjà vu des journaux écrits dans la base de données (et parfois vous obtenez des options configurables pour la journalisation, où la trace va dans le fichier, les erreurs dans la base de données, les fatals dans le journal des événements Windows).
Les raisons principales sont la vitesse et la taille, l'activation d'un traçage peut produire de très grandes qualités de journalisation - j'ai parcouru des fichiers journaux de gigaoctets. L'autre raison principale est que la lecture des journaux doit être séquentielle, il n'y a pas vraiment besoin d'interroger le journal, sauf pour trouver une certaine erreur ou entrée - et la recherche dans le fichier fonctionne parfaitement bien pour cela.
La vitesse est une des raisons; d'autres sont:
- Éliminer les points de défaillance. Un système de fichiers échoue rarement dans des conditions où un SGBD ne le ferait pas, mais il y a beaucoup, beaucoup de conditions d'erreur dans les bases de données qui n'existent tout simplement pas dans les systèmes de fichiers.
- Accessibilité à faible technologie. Si les choses tournent vraiment mal, vous pouvez démarrer dans un shell de secours ou monter le disque sur un autre système, tout en disposant d'outils adéquats pour inspecter les fichiers journaux. S'il s'agit d'une base de données, vous n'êtes nulle part sans un serveur de base de données en cours d'exécution.
Tout d'abord.
Et ceux-ci pourraient même échouer dans des circonstances particulières si un grand soin n'était pas apporté.
Les transactions de base de données ne peuvent pas échouer lorsque vous ne faites pas attention?
L'écriture dans un fichier texte présente un certain nombre d'avantages, le plus important étant
- Le texte est lisible par l'homme. Tout le monde peut ouvrir un fichier journal avec un éditeur de texte de base et voir quels sont les messages. Vous n'avez pas besoin de comprendre comment la base de données est organisée.
- La vitesse. L'écriture de texte sur le disque est beaucoup plus rapide qu'un service de base de données qui détermine où va le texte dans une base de données, y écrit et s'assure que la transaction est terminée.
Vous soulevez spécifiquement Apache, je vais donc en discuter en détail.
Apache peut être configuré pour se connecter à une base de données, bien qu'il nécessite un plugin externe pour ce faire. L'utilisation d'un tel plugin peut faciliter l'analyse des journaux, mais uniquement si vous avez l'intention d'écrire votre propre logiciel d'analyse de journaux. Les analyseurs de journaux standard supposent que vos journaux sont dans des fichiers, vous ne pourrez donc pas les utiliser.
Lorsque je faisais cela, j'ai également rencontré des problèmes de fiabilité: si le tampon d'écriture du serveur de base de données était rempli (ce qui peut arriver avec mysql si vous utilisez votre quota de système de fichiers pour l'utilisateur sous lequel il s'exécute), il commence à mettre en file d'attente les requêtes jusqu'à ce qu'elles soient capables pour continuer, point auquel Apache commence à attendre sa fin, ce qui entraîne des requêtes bloquées sur votre site Web.
(Ce problème peut maintenant être résolu, bien sûr - il y a de nombreuses années, je l'ai fait)
Un système de fichiers est une base de données. C'est en effet une base de données hiérarchique plus simple au lieu d'un SGBD relationnel, mais c'est quand même une base de données.
La raison pour laquelle la connexion à un système de fichiers est populaire est que les journaux de texte correspondent bien à la philosophie Unix: "Le texte est l'interface universelle."
Unix avait développé avec de nombreux outils à usage général qui peuvent bien fonctionner avec les journaux de texte. Peu importe que les journaux de texte soient produits par mysql, Apache, votre application personnalisée, un logiciel tiers longtemps hors de support, le sysadmin peut utiliser des outils Unix standard comme grep, sed, awk, sort, uniq, cut, tail , etc, pour parcourir les journaux tout de même.
Si chaque application se connecte à sa propre base de données, une à MySQL, une autre à Postgres, une autre à Elasticsearch, une autre veut se connecter à ELK, une autre ne peut se connecter qu'à MongoDB, alors vous devrez apprendre vingt outils différents pour parcourir les journaux de chacun application. Le texte est un support universel auquel tout le monde peut se connecter.
Même lorsque vous parvenez à faire en sorte que tous les journaux soient stockés dans une seule base de données, par exemple MySQL, vous pouvez constater que chaque application voudra se connecter avec des schémas de table différents, vous devrez donc toujours écrire un outil personnalisé pour interroger les journaux pour chaque application. Et si vous avez en quelque sorte rempli toutes les applications pour vous connecter à un seul schéma, vous constaterez probablement que ce schéma générique ne pouvait pas vraiment vous raconter l'histoire complète de chaque application, vous devez donc toujours analyser les textes du journal de toute façon.
Souvent, la connexion à une base de données ne facilite pas vraiment les choses de manière significative.
La journalisation dans une base de données peut être utile lorsque vous avez une analyse spécifique à l'esprit, ou pour une exigence de rétention d'audit spécifique, pour laquelle vous pouvez concevoir un schéma de base de données spécifique pour collecter uniquement les données à ces fins spécifiques. Mais pour la criminalistique et le débogage et lorsque vous collectez des journaux sans objectif spécifique à l'esprit, les journaux de texte sont généralement suffisamment bons pour que le coût de l'apprentissage ou de la création des outils spécialisés n'en vaut souvent pas la peine.
Regardons cela sur quelques couches:
- Couche machine
- Couche du système d'exploitation
- Couche de service
- Couche d'application
En bref:
- Sur la couche machine, vous ne pouvez vraiment pas faire de journalisation autre qu'une sorte de vidage.
- Sur la couche OS, vous pouvez faire la journalisation mais vous n'avez vraiment que le système de fichiers disponible.
- Les services peuvent se connecter au système de fichiers, mais ils ne peuvent pas approuver l'exécution d'autres services, ils ne peuvent donc pas s'y connecter.
- Les applications peuvent se connecter aux services et au système de fichiers.
Ensuite, nous avons l'approche basée sur le cas d'utilisation:
Voulez-vous enregistrer les erreurs spécifiques à un nœud dans un SGBDR à l'échelle horizontale où vous devez faire le travail supplémentaire pour trouver l'erreur d'un nœud spécifique lorsque vous pouvez simplement ouvrir le capot pour un nœud et le voir là-bas? D'un autre côté, votre application devrait éventuellement se connecter à un SGBDR pour recueillir des erreurs et des notifications au niveau de l'application.
Que se passe-t-il lorsque le SGBDR doit effectuer la journalisation pour lui-même car la base de données ne peut pas être écrite?