J'écris une application Web avec NodeJS pouvant être utilisée par d'autres applications pour stocker des journaux et accéder ultérieurement dans une interface Web ou par des applications elles-mêmes fournissant une API. Similaire à Graymog2 mais SCHEMA GRATUIT.
J'ai déjà essayé Couchdb dans lequel chaque document serait un doc, mais que je n'utilise pas vraiment des révisions, il me semble que je n'utilise pas toutes ses caractéristiques. Et à côté de cela, je pense que si les journaux dépassent une limite, il serait assez difficile de gérer dans Couchdb.
Qu'est-ce que je cherche vraiment, est une grande gamme de bûches pouvant être triées, filtrées, recherchées et plafonnées. Ensuite, les derniers événements d'accès accédaient. Il devrait être libre de schéma et l'écriture devrait être non bloquante.
J'envisage d'utiliser Cassandra (je ne le connais pas vraiment) en raison des points ici a dit. MongoDB semble bon ici aussi, car GrayLog2 utilise à Mongodb, dans ici Il a de bons points à ce sujet.
J'ai déjà vu cette question, mais pas satisfaite des réponses.
EDIT: Pour certaines raisons, je ne peux pas utiliser Cassandra dans la production, maintenant j'essaie Mongodb.
Une autre raison d'utiliser mongodb: http://www.slideshare.net/wombatination/logging- App-comportement-to-mongo-db
Plus d'édition:
Il est similaire à Graymog2, mais la différence que je veux apporter cela au lieu d'avoir un champ de message, ayant défini par le client, c'est pourquoi je veux que ce soit gratuit, et à cause de cela, j'ai peut-être besoin de interroger dans les champs définis par l'utilisateur. Nous pouvons le construire sur SQL, mais interroger sur les champs définis par l'utilisateur serait de réinventer la roue. Même va avec les fichiers.
Techniquement, ce que je recherche, c'est d'obtenir des données statistiques riches à la fin, ou un débogage facile et beaucoup d'autres choses que nous ne pouvons pas sortir des journaux.
3 Réponses :
Vous avez beaucoup de travail devant vous. Quelle que soit la base de données que vous utilisez, vous avez de nombreuses fonctionnalités que vous devez construire sur la fondation DB. Vous avez fait de bonnes recherches sur toutes vos options. On dirait que vous soupçonnez que tous ont des avantages et des inconvénients, mais tous sont imparfaits. Votre suspicion est correcte. À ce stade, il est probablement temps de commencer à écrire du code.
Vous pouvez simplement choisir une arbitraire et commencer à construire votre application. Si votre hypothèse était correcte que les avantages et les inconvénients s'équilibrent et c'est tout à peu près la même chose, alors pourquoi ne pas simplement commencer à construire immédiatement? Lorsque vous rencontrez des difficultés x sur votre base de données, rappelez-vous qu'il vous a donné une commodité Y et Z et c'est juste la vie.
Vous pouvez également établir le fondamental de votre application et mettre en œuvre divers prototypes sur chacune des bases de données. Cela pourrait vous donner une véritable perspicacité pour vous aider à discriminer les bases de données pour votre application spécifique. Par exemple, outre les questions de l'interface, de l'indexation et de la requête, qu'en est-il du déploiement? Qu'en est-il des sauvegardes? Qu'en est-il de la maintenance et de la sécurité? Peut-être que "gaspiller" le temps de construire le même prototype sur chaque plate-forme rendra la réponse très claire pour vous.
Je suppose que Couchdb est "Nosql" si vous le dites. Autres choses qui sont "no SQL" incluent des bananes, des poèmes et du cricket. Ce n'est pas un mot très significatif. Nous avons des langues générales et des langues spécifiques à un domaine; De même, Couchdb est une base de données . Il peut vous faire gagner du temps si vous avez besoin des fonctionnalités suivantes:
Donc, votre point est que je devrais continuer avec Apache Couchdb car il n'y a pas de meilleur choix?
Désolé, je n'étais pas clair. C'est vraiment deux points distincts, non étroitement liés à l'autre. Je travaille souvent avec Couchdb, donc en plus de mes sentiments de genearl, j'ai fourni certains des avantages que j'ai trouvés l'utiliser. J'ai ajouté des en-têtes de section pour le rendre plus clair.
Merci. Donne plus de sens pour moi.
Avez-vous envisagé Apache Kafka ?
Kafka est un système de messagerie distribué développé à LinkedIn pour Recueillir et livrer des volumes élevés de données de journal avec une faible latence. Notre système intègre des idées des agrégateurs de journaux existants et systèmes de messagerie et convient au message hors ligne et en ligne Consommation.
Pas une base de données, mais beaucoup mieux! Va penser si c'est API suffit à construire ma conception sur le dessus. Merci
Où sera-t-il stocké et comment sera-t-il récupéré?
Je suppose que cela dépend de la quantité de données que vous abordez. Si vous avez une énorme quantité (téraoctets et pétambytes par jour) de journaux, Apache Kafka, conçu pour permettre que les données soient tirées par HDFS en parallèle, est une solution intéressante - toujours dans la phase d'incubation. Je crois que si vous voulez consommer des messages de Kafka avec MongoDB, vous devez développer votre propre adaptateur pour l'ingérer comme un consommateur d'un sujet de Kafka particulier. Bien que les données MongoDB (par exemple, des éclats et des répliques) soient distribuées, il peut s'agir d'un processus séquentiel pour ingérer chaque message. Il peut donc y avoir un goulot d'étranglement ou même des conditions de course en fonction du taux et de la taille du trafic des messages. Kafka est optimisé pour pomper et ajouter que les données HDFS à HDFS utilisent rapidement les courtiers de messages. Ensuite, une fois dans HDFS, vous pouvez mapper / réduire pour analyser vos informations de différentes manières.
Si MongoDB peut gérer la charge d'ingestion, il s'agit d'une solution excellente, évolutive et en temps réel pour trouver des informations, en particulier des documents. Sinon, si vous avez plus de temps pour traiter les données (c'est-à-dire des processus par lots qui prennent des heures et parfois des jours), alors hadoop ou une autre carte réduire la base de données est justifiée. Enfin, Kafka peut distribuer cette charge de messages et de raccordement que le tuyau d'incendie à une variété de consommateurs. Globalement, ces nouvelles technologies répandent la charge et énormes quantités de données sur le matériel bon marché à l'aide de logiciels pour gérer l'échec et récupérer avec une très faible probabilité de perte de données.
Même avec une petite quantité de données, MongoDB est une option intéressante pour les solutions de base de données relationnelles traditionnelles nécessitant davantage de frais généraux de ressources de développeur pour concevoir, construire et entretenir.