Structure MongoDB: collection unique vs collections multiples plus petites

j'ai une question générale sur la structure de la base de données. Dans mon scénario, il m'arrive d'être en utilisant mongodb.

je crée une application où un utilisateur peut télécharger une liste de chansons (Titre, Artiste, etc.) mais je ne suis pas sûr que je devrais avoir une collection de songList pour tous les utilisateurs ou une songList séparée.l'utilisateur# collection pour chaque utilisateur individuel. Les utilisateurs ne peuvent interroger que les chansons qui leur sont associées, de sorte que L'Utilisateur a ne connaîtra jamais les chansons de l'utilisateur B.

Code Exemples:

collections multiples par utilisateur

db.songList.userA.find()
{"title": "Some song of user A", "artist": "Some artist of user A"}

db.songList.userB.find()
{"title": "Some song of user B", "artist": "Some artist of user B"}
  • Pros
    • plus petite taille de la collection à interroger
  • Cons
    • Maintenabilité
      • 1,000 utilisateurs signifie 1,000 collections

vs collection unique avec un "utilisateur" propriétaire champ

db.songList.find({"user":"A"})
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"}
  • Pros
    • flexibilité pour interroger les utilisateurs en cas de besoin
  • Cons
    • Performances

j'essaye de construire une liste de pro/con mais toujours sur la clôture. Étant donné que les chansons de chaque utilisateur vont être isolées les unes des autres, quelle approche est la meilleure? Ma principale préoccupation est la maintenance et la performance des requêtes.

Merci à avance.

25
demandé sur Sushant Gupta 2012-12-10 07:25:52
la source

2 ответов

je recommanderais NOT faire une collecte séparée par utilisateur.

Lire le documentation

par défaut MongoDB a une limite d'environ 24.000 namespaces par la base de données. Chaque namespace est de 628 octets, le .le fichier ns est de 16MB par défaut.

chaque collection compte comme un espace de noms, comme le fait chaque index. Ainsi, si l' chaque collection avait un index, nous pouvons créer jusqu'à 12.000 collection. Le paramètre --nssize vous permet d'augmenter cette limite (voir ci-dessous).

Être conscient qu'il ya un minimum de frais généraux par collection -- quelques KO. En outre, tout indice exigera au moins 8KB d'espace de données comme la taille de la page de l'arbre b est de 8KB. Certaines opérations peuvent être lentes s'il y a beaucoup de collections et les méta-données sont transférées.

donc vous ne pourrez pas le gérer avec élégance si vos utilisateurs dépassent la limite de l'espace de noms. Aussi, il ne sera pas très haut sur la performance avec la croissance de votre wiki.

UPDATE

comme @Henry Liu l'a mentionné dans les commentaires. Pour Mongodb 3.0 ou plus utilisant le moteur de stockage WiredTiger, il ne sera plus la limite.

docs.mongodb.org/manual/reference/limits/#namespaces

12
répondu Sushant Gupta 2017-01-15 06:17:48
la source

MongoDB est excellent à l'échelle horizontale. Il peut partager une collection à travers un cluster dynamique pour produire une collecte rapide et fiable de vos données.

donc avoir une plus petite taille de collection n'est pas vraiment un pro et je ne suis pas sûr d'où vient cette théorie, ce n'est pas en SQL et ce n'est pas en MongoDB. La performance de sharding, si fait bien, devrait être relative à la performance de questionner une seule petite collecte de données (avec un petit frais généraux). Si ce n'est pas le cas, alors vous lors de la configuration de votre partage de mal.

MongoDB n'est pas très bon à l'échelle verticale, comme @Sushant l'a cité, la taille ns de MongoDB serait une limite sérieuse ici. Une chose que cite ne mentionne pas est que la taille de l'indice et le nombre ont aussi un effet sur la taille de la ns, d'où la raison pour laquelle il décrit cela:

ainsi, si chaque collection a un index, nous pouvons créer jusqu'à 12 000 collections. Le paramètre --nssize vous permet d'augmenter cette limite (voir ci-dessous).

9
répondu Sammaye 2012-12-10 12:24:04
la source

Autres questions sur