Il y a des limites théoriques, comme je le montrerai ci-dessous, mais même la limite inférieure est jolie haute. Il n'est pas facile de calculer correctement les limites, mais l'ordre de grandeur devrait être suffisant.
mmapv1
La limite réelle dépend de quelques éléments comme la longueur des noms de partitions et autres (cela résume si vous en avez quelques centaines de milliers), mais voici un calcul approximatif avec des données réelles.
Chaque partition a besoin d'espace dans la base de données de configuration, qui est limitée comme toute autre base de données à 32 To sur une seule machine ou dans un jeu de répliques. Sur les serveurs que j'administre, la taille moyenne d'une entrée dans config.shards est de 112 octets. De plus, chaque morceau nécessite environ 250 octets d'informations de métadonnées. Supposons des tailles de bloc optimales proches de 64 Mo.
Nous pouvons avoir au maximum 500 000 morceaux par serveur. 500 000 * 250 octets équivaut à 125 Mo pour les informations de bloc par partition. Ainsi, par partition, nous avons 125,000112 Mo par partition si nous maximisons tout. En divisant 32 To par cette valeur, nous pouvons avoir un maximum d'un peu moins de 256 000 shards dans un cluster.
Chaque fragment peut à son tour contenir 32 To de données. 256 000 * 32 To correspond à 8,19200 exaoctets ou 8 192 000 téraoctets. Ce serait la limite pour notre exemple.
Disons ses 8 exaoctets. À partir de maintenant, cela peut facilement se traduire par "Assez pour toutes les fins pratiques". Pour vous donner une impression :toutes les données détenues par la Bibliothèque du Congrès (sans doute l'une des plus grandes bibliothèques au monde en termes de taille de collection) contiennent une taille estimée de données d'environ 20 To, y compris des documents audio, vidéo et numériques. Vous pourriez intégrer cela dans notre cluster MongoDB théorique environ 400 000 fois. Notez qu'il s'agit de la limite inférieure de la taille maximale, en utilisant des valeurs conservatrices.
Tigre filaire
Maintenant, pour la bonne partie :le moteur de stockage WiredTiger n'a pas cette limitation :la taille de la base de données n'est pas limitée (puisqu'il n'y a pas de limite sur le nombre de fichiers de données pouvant être utilisés), nous pouvons donc avoir un nombre illimité de fragments. Même lorsque nous avons ces partitions en cours d'exécution sur mmapv1 et que seuls nos serveurs de configuration sur WT, la taille d'un devient presque illimitée - la limitation à 16,8 Mo de RAM sur un système 64 bits peut causer des problèmes quelque part et provoquer les indices du config.shard collection à échanger sur le disque, ce qui bloque le système. Je ne peux que deviner, puisque ma calculatrice refuse de travailler avec des nombres dans cette zone (et je suis trop paresseux pour le faire à la main), mais j'estime la limite ici dans la zone à deux chiffres yottabyte (et l'espace nécessaire pour l'héberger quelque part de la taille du Texas).
Conclusion
Ne vous souciez pas de la taille maximale des données dans un environnement partitionné. Quoi qu'il en soit, c'est de loin suffisant, même avec l'approche la plus conservatrice. Utilisez le sharding, et vous avez terminé. Au fait :même 32 To, c'est beaucoup de données :la plupart des clusters que je connais contiennent moins de données et de fragments, car l'utilisation des IOPS et de la RAM a dépassé la capacité d'un seul nœud.
