Vad är maxstorleken på samlingen i mongodb

Det finns teoretiska gränser, som jag kommer att visa nedan, men även den nedre gränsen är snäll hög. Det är inte lätt att beräkna gränserna korrekt, men storleksordningen bör vara tillräcklig.

mmapv1

Den faktiska gränsen beror på några saker som längden på skärvnamn och liknande (det sammanfattar om du har ett par hundra tusen av dem), men här är en grov beräkning med verkliga data.

Varje shard behöver lite utrymme i config db, som är begränsad som vilken annan databas som helst till 32TB på en enda dator eller i en replikuppsättning. På de servrar jag administrerar, den genomsnittliga storleken på en post i config.shards är 112 byte. Dessutom behöver varje bit cirka 250 byte metadatainformation. Låt oss anta optimala chunkstorlekar på nära 64MB.

Vi kan ha högst 500 000 bitar per server. 500 000 * 250 byte motsvarar 125 MB för bitinformation per skärva. Så per shard har vi 125,000112 MB per shard om vi maxar allt. Att dividera 32 TB med det värdet visar att vi maximalt kan ha något under 256 000 skärvor i ett kluster.

Varje skärva kan i sin tur innehålla 32 TB data. 256 000 * 32 TB är 8,19 200 exabyte eller 8 192 000 terabyte. Det skulle vara gränsen för vårt exempel.

Låt oss säga att det är 8 exabyte. Från och med nu kan detta enkelt översättas till "Tillräckligt för alla praktiska ändamål". För att ge dig ett intryck:All data som innehas av Library of Congress (förmodligen ett av de största biblioteken i världen när det gäller samlingsstorlek) innehåller en uppskattad datastorlek på cirka 20 TB, inklusive ljud, video och digitalt material. Du skulle kunna passa in det i vårt teoretiska MongoDB-kluster cirka 400 000 gånger. Observera att detta är den nedre gränsen för den maximala storleken, med konservativa värden.

WiredTiger

Nu till den goda delen:WiredTiger-lagringsmotorn har inte denna begränsning:Databasstorleken är inte begränsad (eftersom det inte finns någon gräns för hur många datafiler som kan användas), så vi kan ha ett obegränsat antal skärvor. Även när vi har dessa skärvor som körs på mmapv1 och bara våra konfigurationsservrar på WT, blir storleken på a nästan obegränsad – begränsningen till 16,8 M TB RAM på ett 64-bitarssystem kan orsaka problem någonstans och orsaka indexen för config.shard samling som ska bytas till disk, vilket stoppar systemet. Jag kan bara gissa, eftersom min kalkylator vägrar att arbeta med siffror i det området (och jag är för lat för att göra det för hand), men jag uppskattar gränsen här i det tvåsiffriga yottabyte-området (och utrymmet som behövs för att vara värd för det någonstans i storleken av Texas).

Slutsats

Oroa dig inte för den maximala datastorleken i en delad miljö. Oavsett vad är det överlägset tillräckligt, även med det mest konservativa tillvägagångssättet. Använd skärning och du är klar. Btw:till och med 32TB är en jäkla massa data:De flesta kluster jag känner innehåller mindre data och skärvor eftersom IOPS- och RAM-användningen överskred en enda nodkapacitet.