Tant que j'y suis dans les avantages longue durée du texte, il y a aussi celui-ci.
Supposons que l'on a beaucoup de log, et que l'on veut les conserver très longtemps. Il faut donc les compresser, la question ne se pose pas.
Choix 1 : log binaire, avec une structure de donnée efficace. On a un bon taux de compression.
Choix 2 : du texte. C'est verbeux, donc ça prend de la place. Mais, par ce qu'il y a un « mais », il y a une astuce. On manipule toujours les logs décompressé, comme ça on a besoin d'un seul outil (ou suite d'outils) pour les manipuler. En revanche pour le stockage, on les compresse. L'avantage, c'est que l'on peut avoir plusieurs types de compression. Je m'explique. Pour les logs récents ou récemment consultés, on utilise une compression très rapide (tel que lz4). On a donc un léger gain de place, et une faible perte de vitesse. Pour les logs anciens, et non récemment consultés, on peut utiliser un autre algo, avec des paramètres qui favorise le taux de compression. On a donc un très bon taux de compression en moyenne (la majorité des logs sont fortement voir très fortement compressé), tout en ayant en moyenne une très bonne vitesse de lecture (les logs récents sont en texte brut ou en lz4). De plus, les outils de compressions possèdent plusieurs implémentations documentées, et on possède des outils génériques en cas de corruption des archives.
Le double effet kiss cool, c'est que le jour ou on invente un nouvel algo de compression, avec les logs binaires, il faut tout mettre à jour : le format, et les outils pour les utiliser, ainsi qu'un convertisseur. Avec les logs textes, pas besoin de réinventer la roue. On utilise toujours les mêmes outils (ils ne savent lire que du texte décompressé de toute façon), et pour la migration, il suffit d'utiliser le décompresseur (qui existait déjà, vu que c'est celui que l'on utilisait avec l'ancien format de compression), puis de recompresser avec le nouvel algo (dans son implémentation standard). On n'a donc presque rien rajouté de spécifique dans notre code (seul les appels de fonctions compresse() et decompresse()), malgré une mise à jour significative de l'outil de stockage. Donc sur le très long terme (plus de 10 ans), ça peux être un avantage.
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 9.
Tant que j'y suis dans les avantages longue durée du texte, il y a aussi celui-ci.
Supposons que l'on a beaucoup de log, et que l'on veut les conserver très longtemps. Il faut donc les compresser, la question ne se pose pas.
Choix 1 : log binaire, avec une structure de donnée efficace. On a un bon taux de compression.
Choix 2 : du texte. C'est verbeux, donc ça prend de la place. Mais, par ce qu'il y a un « mais », il y a une astuce. On manipule toujours les logs décompressé, comme ça on a besoin d'un seul outil (ou suite d'outils) pour les manipuler. En revanche pour le stockage, on les compresse. L'avantage, c'est que l'on peut avoir plusieurs types de compression. Je m'explique. Pour les logs récents ou récemment consultés, on utilise une compression très rapide (tel que lz4). On a donc un léger gain de place, et une faible perte de vitesse. Pour les logs anciens, et non récemment consultés, on peut utiliser un autre algo, avec des paramètres qui favorise le taux de compression. On a donc un très bon taux de compression en moyenne (la majorité des logs sont fortement voir très fortement compressé), tout en ayant en moyenne une très bonne vitesse de lecture (les logs récents sont en texte brut ou en lz4). De plus, les outils de compressions possèdent plusieurs implémentations documentées, et on possède des outils génériques en cas de corruption des archives.
Le double effet kiss cool, c'est que le jour ou on invente un nouvel algo de compression, avec les logs binaires, il faut tout mettre à jour : le format, et les outils pour les utiliser, ainsi qu'un convertisseur. Avec les logs textes, pas besoin de réinventer la roue. On utilise toujours les mêmes outils (ils ne savent lire que du texte décompressé de toute façon), et pour la migration, il suffit d'utiliser le décompresseur (qui existait déjà, vu que c'est celui que l'on utilisait avec l'ancien format de compression), puis de recompresser avec le nouvel algo (dans son implémentation standard). On n'a donc presque rien rajouté de spécifique dans notre code (seul les appels de fonctions compresse() et decompresse()), malgré une mise à jour significative de l'outil de stockage. Donc sur le très long terme (plus de 10 ans), ça peux être un avantage.
bépo powered