sql >> Database teknologi >  >> NoSQL >> MongoDB

Hvad er den maksimale størrelse på samlingen i mongodb

Der er teoretiske grænser, som jeg vil vise nedenfor, men selv den nedre grænse er pæn høj. Det er ikke let at beregne grænserne korrekt, men størrelsesordenen burde være tilstrækkelig.

mmapv1

Den faktiske grænse afhænger af nogle få ting som længden af ​​skårnavne og lignende (det opsummerer, hvis du har et par hundrede tusinde af dem), men her er en grov beregning med virkelige data.

Hvert shard har brug for noget plads i config db, som er begrænset som enhver anden database til 32TB på en enkelt maskine eller i et replikasæt. På de servere, jeg administrerer, er den gennemsnitlige størrelse af en post i config.shards er 112 bytes. Desuden har hver chunk brug for omkring 250 bytes metadatainformation. Lad os antage optimale chunk-størrelser på tæt på 64 MB.

Vi kan maksimalt have 500.000 chunks pr. server. 500.000 * 250 byte er lig med 125 MB for chunkinformationen pr. shard. Så pr. shard har vi 125.000112 MB pr. shard, hvis vi maxer alt. At dividere 32 TB med denne værdi viser os, at vi maksimalt kan have lidt under 256.000 shards i en klynge.

Hvert shard kan igen rumme 32 TB data. 256.000 * 32TB er 8.19200 exabyte eller 8.192.000 terabyte. Det ville være grænsen for vores eksempel.

Lad os sige, det er 8 exabyte. Fra nu af kan dette nemt oversættes til "Nok til alle praktiske formål". For at give dig et indtryk:Alle data, der opbevares af Library of Congress (velsagt et af de største biblioteker i verden med hensyn til samlingsstørrelse) rummer en anslået størrelse af data på omkring 20 TB i størrelse inklusive lyd, video og digitale materialer. Du kunne passe det ind i vores teoretiske MongoDB-klynge omkring 400.000 gange. Bemærk, at dette er den nedre grænse for den maksimale størrelse ved at bruge konservative værdier.

WiredTiger

Nu til den gode del:WiredTiger-lagringsmotoren har ikke denne begrænsning:Databasestørrelsen er ikke begrænset (da der ikke er nogen grænse for, hvor mange datafiler der kan bruges), så vi kan have et ubegrænset antal shards. Selv når vi har disse shards kørende på mmapv1 og kun vores config-servere på WT, bliver størrelsen af ​​a næsten ubegrænset – begrænsningen til 16,8M TB RAM på et 64 bit system kan forårsage problemer et eller andet sted og forårsage indekserne for config.shard samling, der skal byttes til disk, hvilket standser systemet. Jeg kan kun gætte, da min lommeregner nægter at arbejde med tal i det område (og jeg er for doven til at gøre det i hånden), men jeg estimerer grænsen her i det tocifrede yottabyte-område (og den nødvendige plads til at hoste det et sted på størrelse med Texas).

Konklusion

Du skal ikke bekymre dig om den maksimale datastørrelse i et sønderdelt miljø. Uanset hvad, er det langt nok, selv med den mest konservative tilgang. Brug sharding, og du er færdig. Btw:selv 32TB er en helvedes masse data:De fleste klynger, jeg kender, rummer mindre data og skår, fordi IOPS- og RAM-udnyttelsen oversteg en enkelt nodes kapacitet.




  1. Redis værdiopdatering

  2. Sådan erstattes understreng i mongodb-dokument

  3. MongoDB $ trække fra

  4. Hvordan skal jeg strukturere mine indlejrede reactivemongo-kald i min play2-applikation?