Er zijn theoretische limieten, zoals ik hieronder zal laten zien, maar zelfs de ondergrens is mooi hoog. Het is niet eenvoudig om de limieten correct te berekenen, maar de orde van grootte zou voldoende moeten zijn.
mmapv1
De werkelijke limiet hangt af van een paar dingen, zoals de lengte van shard-namen en dergelijke (dat is een som als je er een paar honderdduizenden hebt), maar hier is een ruwe berekening met gegevens uit het echte leven.
Elke shard heeft wat ruimte nodig in de configuratiedatabase, die net als elke andere database beperkt is tot 32 TB op een enkele machine of in een replicaset. Op de servers die ik beheer, de gemiddelde grootte van een item in config.shards is 112 bytes. Bovendien heeft elk blok ongeveer 250 bytes aan metadata-informatie nodig. Laten we uitgaan van optimale chunk-groottes van bijna 64 MB.
We kunnen maximaal 500.000 chunks per server hebben. 500.000 * 250byte is gelijk aan 125 MB voor de chunk-informatie per shard. Dus per shard hebben we 125.000112 MB per shard als we alles maximaal benutten. Als we 32 TB delen door die waarde, zien we dat we maximaal iets minder dan 256.000 shards in een cluster kunnen hebben.
Elke scherf kan op zijn beurt 32 TB aan gegevens bevatten. 256.000 * 32TB is 8.19200 exabytes of 8.192.000 terabytes. Dat zou de limiet zijn voor ons voorbeeld.
Laten we zeggen dat het 8 exabytes is. Vanaf nu kan dit gemakkelijk worden vertaald naar "Genoeg voor alle praktische doeleinden". Om u een indruk te geven:alle gegevens in het bezit van de Library of Congress (wat betreft collectiegrootte misschien wel een van de grootste bibliotheken ter wereld) bevatten een geschatte hoeveelheid gegevens van ongeveer 20 TB, inclusief audio, video en digitaal materiaal. Je zou dat zo'n 400.000 keer in ons theoretische MongoDB-cluster kunnen passen. Merk op dat dit de ondergrens is van de maximale grootte, met conservatieve waarden.
WiredTiger
Nu voor het goede deel:de WiredTiger-opslagengine heeft deze beperking niet:de databasegrootte is niet beperkt (aangezien er geen limiet is voor het aantal gegevensbestanden dat kan worden gebruikt), dus we kunnen een onbeperkt aantal shards hebben. Zelfs als we die shards op mmapv1 hebben en alleen onze configuratieservers op WT, wordt de grootte van a bijna onbeperkt - de beperking tot 16,8 miljoen TB RAM op een 64-bits systeem kan ergens problemen veroorzaken en de indices van de config.shard collectie die naar schijf moet worden geruild, waardoor het systeem vastloopt. Ik kan alleen maar gissen, aangezien mijn rekenmachine weigert te werken met getallen in dat gebied (en ik ben te lui om het met de hand te doen), maar ik schat de limiet hier in het tweecijferige yottabyte-gebied (en de ruimte die nodig is om dat ergens te hosten ter grootte van Texas).
Conclusie
Maak je geen zorgen over de maximale gegevensgrootte in een shard-omgeving. Wat er ook gebeurt, het is ver genoeg, zelfs met de meest conservatieve benadering. Gebruik sharding en je bent klaar. Trouwens:zelfs 32 TB is een enorme hoeveelheid gegevens:de meeste clusters die ik ken bevatten minder gegevens en shard omdat het IOPS- en RAM-gebruik de capaciteit van één knooppunt overschreed.