Je ne me pense pas supérieur aux autres, loin de là, mais je n'ai pas la bêtise de penser que des gens qui ont pensé, codé, maintenu en vie pendant de nombreuses année un système d'exploitation étaient plus crétins que le dernier péquin à la mode qui publie un logiciel.
Si ça reste comme c'est, c'est que les avantages apportés par le changement ne contrebalancent pas le coût du changement. Faut arrêter de prendre les gens pour des endives réfractaires et dogmatiques. La vraie raison au fait qu'on utilise toujours des logs en mode texte, c'est bêtement que ça marche suffisamment bien dans plein de cas et que les avantages apportés par le format binaire ne contrebalancent pas le coût du changement.
La réalité de la base de données est que, dans un usage généraliste, elle n'est que marginalement plus utile que des fichiers textes parcequ'il n'y a aucune raison au monde pour que la question qu'on se pose en examinant les logs soit facile à traduire en SQL – tenant compte du schéma utilisé, en plus. Typiquement si on se pose une question un peu compliquée, on recherche des suites d'évènements et il faut écrire un parser travaillant sur un langage dont chaque ligne de log – les évènements sont les léxèmes. Ici avoir les logs dans une base de données n'apporte absolument rien.
Dans certaines situations spécialisées[], la base de données va donner de bien meilleurs résultats, mais dans une utilisation *généraliste, elle n'apporte qu'un petit plus. Sélectionner les logs entre deux dates avec un SQL plutôt qu'avec un filtre sed ou afficher les requêtes venant d'une IP donnée avec SQL plutôt qu'avec awk est plus rapide et plus fiable, mais pas au point d'inciter tout le monde à stocker les logs dans une base de données.
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Michaël (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 9.
Si ça reste comme c'est, c'est que les avantages apportés par le changement ne contrebalancent pas le coût du changement. Faut arrêter de prendre les gens pour des endives réfractaires et dogmatiques. La vraie raison au fait qu'on utilise toujours des logs en mode texte, c'est bêtement que ça marche suffisamment bien dans plein de cas et que les avantages apportés par le format binaire ne contrebalancent pas le coût du changement.
La réalité de la base de données est que, dans un usage généraliste, elle n'est que marginalement plus utile que des fichiers textes parcequ'il n'y a aucune raison au monde pour que la question qu'on se pose en examinant les logs soit facile à traduire en SQL – tenant compte du schéma utilisé, en plus. Typiquement si on se pose une question un peu compliquée, on recherche des suites d'évènements et il faut écrire un parser travaillant sur un langage dont chaque ligne de log – les évènements sont les léxèmes. Ici avoir les logs dans une base de données n'apporte absolument rien.
Dans certaines situations spécialisées[], la base de données va donner de bien meilleurs résultats, mais dans une utilisation *généraliste, elle n'apporte qu'un petit plus. Sélectionner les logs entre deux dates avec un SQL plutôt qu'avec un filtre sed ou afficher les requêtes venant d'une IP donnée avec SQL plutôt qu'avec awk est plus rapide et plus fiable, mais pas au point d'inciter tout le monde à stocker les logs dans une base de données.
[*] Par exemple la mienne. :D