Après avoir analysé des gigaoctets de logfiles avec Grep et que je me demandais comment rendre cela plus facile en utilisant une base de données pour enregistrer les choses. Quelle base de données serait appropriée pour cette purpuse? Bien sûr, une base de données Vanillia SQL fonctionne, bien sûr, mais fournit de nombreuses garanties transactionnelles, etc. dont vous n'avez pas besoin ici et qui pourrait la ralentir si vous travaillez avec des gigaoctets de données et des taux d'insertion très rapides. Donc, une base de données NOSQL qui pourrait être la bonne réponse (comparer Cette réponse pour certaines suggestions). Certaines exigences pour la base de données seraient:
Mise à jour: Il y a déjà quelques-questions pour cela: Suggestion de base de données de traitement / rapport sur une grande quantité de données de fichier de journal et Quelles sont les bonnes solutions de base de données NOSQL et non relationnelles pour la base de données d'audit / de la journalisation . Cependant, je suis curieux que les bases de données répondent aux exigences.
3 Réponses :
Selon vos besoins Splunk pourrait être une bonne option. C'est plus qu'une simple base de données, mais vous obtenez toutes sortes de rapports. De plus, il est conçu pour être un remplacement de fichier journal afin d'avoir déjà résolu les problèmes de mise à l'échelle.
Il y a beaucoup d'options différentes que vous pourriez examiner. Vous pouvez utiliser Hive pour votre analyse et Flume pour consommer et charger les fichiers journaux. MongoDB pourrait également être une bonne option pour vous, jetez un coup d'œil à cet article sur Log Analytics avec MongoDb, Ruby et Google Graphiques
Après avoir essayé beaucoup de solutions NOSQL, mes meilleurs paris seraient:
échelle de recherche RIAK + RIAK facilement (vraiment!) et vous permet de vous libérer des requêtes sur vos données. Vous pouvez également mélanger facilement des schémas de données et peut-être même compresser des données avec Innostore en tant que backend.
MongoDB est gênant de faire échec sur plusieurs gigaoctets de données si vous voulez vraiment utiliser des index et ne pas ralentir à un crawl. Il s'agit vraiment d'envisager une performance de noeud unique et offre une création d'index. Dès que votre ensemble de données de travail ne correspond à plus dans la mémoire, cela devient un problème ...
MySQL / PostgreSQL reste assez rapide et permet aux requêtes de formulaire libre grâce aux index d'arbres B + habituels. Regardez Postgres pour Index partiels Si certains des champs ne s'affichent pas dans tous les enregistrement. Ils offrent également des tables compressées et, étant donné que le schéma est corrigé, vous ne sauvegardez pas vos noms de ligne encore et encore (c'est ce qui arrive généralement pour beaucoup de solutions NOSQL)
Couchdb est agréable si vous connaissez déjà les requêtes que vous souhaitez voir, leurs vues basées sur la carte / réduction progressive sont un excellent système pour cela.