Enregistrement de l'accès au fichier avec MongoDB

Je conçois ma première base de données MongoDB (et la première base NoSQL) et souhaite stocker des informations sur les fichiers d'une collection. Dans le cadre de chaque document de fichier, je voudrais stocker un journal des accès aux fichiers (à la fois les lectures et les écritures).Enregistrement de l'accès au fichier avec MongoDB

J'envisage la création d'un tableau de messages du journal dans le cadre du document:

{ 
    "filename": "some_file_name", 
    "logs" : [ 
     { "timestamp": "2012-08-27 11:40:45", "user": "joe", "access": "read" }, 
     { "timestamp": "2012-08-27 11:41:01", "user": "mary", "access": "write" }, 
     { "timestamp": "2012-08-27 11:43:23", "user": "joe", "access": "read" } 
    ] 
}

Chaque message de journal contiendra un horodatage, le type d'accès, et le nom d'utilisateur de la personne qui accède au fichier. J'ai pensé que cela permettrait un accès très rapide aux journaux pour un fichier particulier, probablement l'opération la plus courante qui sera effectuée avec les journaux.

Je sais que MongoDB a une limite de taille de document de 16 Mo. J'imagine que les fichiers auxquels on accède très fréquemment pourraient pousser contre cette limite.

Existe-t-il un meilleur moyen de concevoir le schéma NoSQL pour ce type d'enregistrement?

Source

2012-08-27 Ralph

Une alternative serait une collection séparée 'logs' (où chaque entrée a le nom de fichier auquel elle fait référence). – Thilo

Lets essayer d'abord pour calculer la taille moyenne de l'enregistrement d'un journal:

horodatage mot = 18 , valeur d'horodatage = 8, mot d'utilisateur = 8, valeur d'utilisateur = 20 (10 caractères c'est max (ou avg pour sûr) je suppose), mot d'accès = 12, valeur d'accès 10. Donc total est 76 octets. Vous pouvez donc avoir ~ 220000 d'enregistrements de journaux.

Et la moitié de l'espace physique sera utilisée par les noms de champs. Dans le cas où vous nommerez timestamp = t, user = u, access = a - vous pourrez stocker ~ 440000 d'éléments de journal.

Donc, je pense que c'est suffisant pour la plupart des systèmes. Dans mes projets, j'essaie toujours d'intégrer plutôt que de créer une collection séparée, car c'est un moyen d'obtenir de bonnes performances avec mongodb. À l'avenir, vous pouvez déplacer vos enregistrements de journaux dans une collection séparée. Aussi pour la performance vous pouvez avoir comme 30 derniers enregistrements de journal (les dénormaliser simples) dans le document de dossier, pour la récupération rapide en plus de la collection de notations.

Aussi, si vous allez avec une collection, assurez-vous de ne pas charger les journaux lorsque vous n'en avez pas besoin (vous pouvez inclure/exclure des champs dans mongodb). Utilisez également $slice pour faire la pagination.

Et une dernière chose: Profitez de mongo!

Source

2012-08-27 12:09:44

Je pense que c'est un mauvais conseil. Les tableaux incorporés ne devraient pas croître tout le temps. Cela rend les mises à jour sur place impossibles et les mises à jour décalées sont particulièrement coûteuses avec ces énormes objets. Un ajout de 76 octets unique pourrait se terminer par une opération multi-MB. – Thilo

Si vous pensez que la limite de documents deviendra un problème, il existe peu d'alternatives.

Le plus évident est de créer un nouveau document pour chaque journal.

Vous aurez donc un "logs" collecton. Avec ce schéma.

{ 
    "filename": "some_file_name", 
    "timestamp": "2012-08-27 11:40:45", 
    "user": "joe", 
    "access": "read" 
}

Une requête pour trouver les fichiers « Joe » lire sera quelque chose comme le

db.logs.find({user: "joe", access: "read"})

Source

2012-08-27 12:00:18 saeed

Enregistrement de l'accès au fichier avec MongoDB

Répondre

Questions connexes