Tu peux eviter la rigidite avec une rdb qui supporte le json (genre postgres), mais on en droit de questionner la pertinence du relationel pour stocker du pur document, sans compter que pg va pas etre jouasse si tu fais que des requete sur le contenu du json. Un format dedie te permet d'extraire l'index en dehors de la partie donnees.
Exactement, sans compter que tu apporterais en prime tous les problèmes bien connus depuis 20 ans qui affectent les DB relationels et qui a été à l'origine des mouvements NoSQL des dernières années: problème de scalabilité horizontale, localité, throughput, replications..
La système de gestions des logs s'apparentent bien plus à un data warehouse + analytics ( on stock tout, on remonte les éléments important, et aprés on analyse en différé) que d'une base de donnée relationel ( où on structure/process/index en temps réel pour rester consistent ).
Ce n'est pas pour rien que toute les infras de logs modernes s'orientent vers une architecture type rsyslog/journald + logstash + elasticsearch avec souvent un stockage des données brute.
Ça a beaucoup d'avantage :
- Distribué orienté message passing => ça scale
- On garde les logs brutes, ce qui autorise à réinterpréter les données quand c'est nécessaire
- Ça donne une grande flexibilité sur le schéma des données.
- On a à la fois les avantages du format texte (les données brutes) et du binaires (les index).
Utiliser une DB relationnel pour faire du stockage de log, c'est plus ou moins utiliser un couteau suisse pour couper un arbre: Ça marchera oui, mais c'est pas pour rien qu'on a inventé la tronçonneuse :D
[^] # Re: Je sais qu’on est vendredi mais...
Posté par Firwen (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 5.
Exactement, sans compter que tu apporterais en prime tous les problèmes bien connus depuis 20 ans qui affectent les DB relationels et qui a été à l'origine des mouvements NoSQL des dernières années: problème de scalabilité horizontale, localité, throughput, replications..
La système de gestions des logs s'apparentent bien plus à un data warehouse + analytics ( on stock tout, on remonte les éléments important, et aprés on analyse en différé) que d'une base de donnée relationel ( où on structure/process/index en temps réel pour rester consistent ).
Ce n'est pas pour rien que toute les infras de logs modernes s'orientent vers une architecture type rsyslog/journald + logstash + elasticsearch avec souvent un stockage des données brute.
Ça a beaucoup d'avantage :
- Distribué orienté message passing => ça scale
- On garde les logs brutes, ce qui autorise à réinterpréter les données quand c'est nécessaire
- Ça donne une grande flexibilité sur le schéma des données.
- On a à la fois les avantages du format texte (les données brutes) et du binaires (les index).
Utiliser une DB relationnel pour faire du stockage de log, c'est plus ou moins utiliser un couteau suisse pour couper un arbre: Ça marchera oui, mais c'est pas pour rien qu'on a inventé la tronçonneuse :D