limites du nombre de collections dans les bases de données
Quelqu'un peut-il dire qu'il y a des limites pratiques au nombre de collections dans mongodb? Ils écrivent ici https://docs.mongodb.com/manual/core/data-model-operations/#large-number-of-collections :
Généralement, le fait d'avoir un grand nombre de collections n'a pas de pénalité de performance significative et se traduit par de très bonnes performances.
Mais pour une raison quelconque, mongodb a défini la limite 24000 pour le nombre d'espaces de noms dans la base de données, il semble qu'il puisse être augmenté, mais je me demande pourquoi il a une certaine limite dans la configuration par défaut si le fait d'avoir de nombreuses collections dans la base de données ne cause aucune performance peine?
Cela signifie-t-il que c'est une solution viable d'avoir un nombre pratiquement illimité de collections dans une base de données, par exemple, d'avoir une collection de données d'un compte dans une base de données pour l'application multi-locataire, ayant, par exemple, des centaines de milliers de collections dans la base de données? Si c'est la solution viable d'avoir un très grand nombre de collections pour une base de données pour chaque locataire, quels sont les avantages par exemple par rapport à avoir des documents de chaque locataire dans une collection? Merci beaucoup pour vos réponses.
Cette réponse est tardive mais les autres réponses semblent un peu ... faibles en termes de fiabilité et d'informations factuelles donc je vais essayer d'y remédier un peu.
Mais pour une raison quelconque, mongodb a défini la limite 24000 pour le nombre d'espaces de noms dans la base de données,
Il s'agit simplement du paramètre par défaut. Oui, il existe un paramètre par défaut.
Cela dit sur la page des limites que 24000 est la limite ( http://docs.mongodb.org/manual/reference/limits/#Number%20of%20Namespaces ), comme s'il n'y avait aucun moyen d'élargir cela, mais il y a.
Cependant, il existe une limite maximale sur la taille d'un fichier d'espace de noms ( http://docs.mongodb.org/manual/reference/limits/#Size%20of%20Namespace%20File ) qui est de 2 Go . Cela vous donne environ 3 millions d'espaces de noms avec lesquels jouer dans la plupart des cas, ce qui est assez impressionnant et je ne sais pas si beaucoup de gens atteindront cette limite rapidement.
Vous pouvez modifier la valeur par défaut pour aller au-delà de 16 Mo en utilisant le paramètre nssize dans la configuration ( http://docs.mongodb.org/manual/reference/configuration-options/#nssize ) ou lors de l'exécution en manipulant la commande utilisée pour exécuter MongoDB ( http://docs.mongodb.org/manual/reference/mongod/#cmdoption-mongod--nssize ).
Il n'y a aucune vraie raison pour laquelle MongoDB implémente 16 Mo par défaut pour sa taille NSS pour autant que je sache, je n'ai jamais entendu parler de la devise de "ne pas déranger l'utilisateur avec chaque détail", donc je n'achète pas celui-là.
Je pense que, à mon avis, la principale raison pour laquelle MongoDB cache cela est parce que même si, comme l'indique la documentation:
Les collections distinctes sont très importantes pour le traitement par lots à haut débit.
L'utilisation de plusieurs collections comme moyen d'évoluer verticalement plutôt qu'horizontalement à travers un cluster, comme MongoDB est conçu pour, est considérée (assez souvent) comme une mauvaise pratique pour les sites Web à grande échelle; en tant que telles, les collections 12K sont normalement considérées comme quelque chose que les gens ne vérifieront jamais et ne devraient jamais vérifier.
Plus de limites!
Comme d'autres réponses l'ont indiqué - cela est déterminé par la taille du fichier d'espace de noms. C'était auparavant un problème, car il avait une limite par défaut de 16 Mo et un maximum de 2 Go. Cependant, avec la sortie de MongoDB 3.0 et du moteur de stockage WiredTiger, il semble que cette limite a été supprimée. WiredTiger semble être meilleur à presque tous égards, donc je ne vois aucune raison pour quiconque d'utiliser l'ancien moteur, sauf pour des raisons de support héritées. Depuis le site:
Pour le moteur de stockage MMAPv1, les fichiers d'espace de noms ne peuvent pas dépasser 2047 mégaoctets.
Par défaut, les fichiers d'espace de noms font 16 mégaoctets. Vous pouvez configurer la taille à l'aide de l'option nsSize.
Le moteur de stockage WiredTiger n'est pas soumis à cette limitation.
Un peu d'histoire:
Chaque fois que mongo crée une base de données, il crée un fichier d'espace de noms (db.ns) pour cela. Le fichier d'espace de noms (ou collections comme vous voudrez peut-être l'appeler) contient les métadonnées de la collection. Par défaut, le fichier d'espace de noms a une taille de 16 Mo, mais vous pouvez augmenter la taille manuellement. Les métadonnées de chaque collection sont de 648 octets + quelques octets de surcharge. Divisez cela par 16 Mo et vous obtenez environ 24 000 espaces de noms par base de données. Vous pouvez démarrer mongo en spécifiant un fichier d'espace de noms plus grand et cela vous permettra de créer plus de collections par base de données.
L'idée derrière toute configuration par défaut est de ne pas déranger l'utilisateur avec chaque détail (et bouton configurable) et de choisir celui qui fonctionne généralement pour la plupart des gens. En outre, la viabilité va de pair avec les meilleures/bonnes pratiques de conception. Comme l'a dit Chris, réfléchissez à la forme de vos données et décidez en conséquence.
Comme d'autres le mentionnent, la taille par défaut de l'espace de noms est de 16 Mo et vous pouvez obtenir environ 24 000 entrées d'espace de noms. En fait, mon instance 64 bits dans Ubuntu a dépassé 23684 en utilisant le fichier d'espace de noms par défaut de 16 Mo.
Une chose importante qui n'est pas mentionnée dans le FAQ est que les index utilisent également des emplacements d'espace de noms.
Vous pouvez compter les entrées d'espace de noms avec:
db.system.namespaces.count()
Et il est également intéressant de jeter un œil à ce qui s'y trouve:
db.system.namespaces.find()
Définissez votre limite plus haut que ce dont vous pensez avoir besoin car une fois qu'une base de données est créée, le fichier d'espace de noms ne peut pas être étendu (si je comprends bien - s'il y a un moyen, dites-le moi !!!).
Pratiquement, je n'ai jamais croisé un maximum. Mais je n'ai certainement jamais dépassé la limite de 24 000 collectes. Je suis presque sûr de n'avoir jamais touché plus de 200, sauf quand je testais les performances de la chose. Je dois admettre, je pense que cela ressemble à beaucoup de chaos d'avoir autant de collections dans une seule base de données, plutôt que de regrouper des données similaires dans leurs propres collections.
Tenez compte de la forme de vos données et de vos règles métier. Si vos données doivent être disposées de telle sorte que vous devez les séparer en différents regroupements logiques pour votre application multi-locataire, vous devriez probablement envisager d'autres magasins de données. Parce que même si Mongo est génial, le fait qu'ils imposent une limite à la quantité de collections me dit qu'ils savent qu'il existe une limite théorique à laquelle les performances sont affectées.
Vous devriez peut-être envisager un magasin qui correspondrait à la forme des données? Riak, par exemple, dispose d'un nombre illimité de "seaux" (sans maximum théorique) que vous pouvez avoir dans votre application. Un compartiment par compte est parfaitement réalisable, mais vous sacrifiez une certaine querabilité en allant dans cette direction.
Sinon, vous voudrez peut-être suivre un modèle plus relationnel de regroupement comme avec comme. À mon avis, Mongo se sent à mi-chemin entre les bases de données relationnelles et les magasins de valeurs-clés. Cela signifie qu'il est plus facile de le conceptualiser à partir d'un monde de bases de données relationnelles.
Il semble y avoir un énorme surcoût pour maintenir les collections. Je viens de réduire une base de données qui contenait environ 1,5 million de documents dans 11 000 collections à une avec le même nombre de documents dans environ 300 collections; cela a réduit la taille de la base de données de 8 Go à 1 Go. Je ne suis pas familier avec le fonctionnement interne de MongoDB, donc cela peut être évident, mais je pense que cela mérite d'être noté dans ce contexte.