Existují teoretické limity, jak ukážu níže, ale i spodní hranice je hezká vysoký. Není snadné správně vypočítat limity, ale řádová velikost by měla být dostatečná.
mmapv1
Skutečný limit závisí na několika věcech, jako je délka názvů fragmentů a podobně (to sečte, pokud jich máte několik set tisíc), ale zde je hrubý výpočet s reálnými daty.
Každý fragment potřebuje určité místo v konfigurační databázi, která je omezena jako každá jiná databáze na 32 TB na jednom počítači nebo v sadě replik. Na serverech, které spravuji, průměrná velikost položky v config.shards je 112 bajtů. Navíc každý blok potřebuje asi 250 bajtů informací o metadatech. Předpokládejme, že optimální velikosti bloků jsou blízké 64 MB.
Můžeme mít maximálně 500 000 kusů na server. 500 000 * 250 bajtů se rovná 125 MB pro informace o bloku na datový fragment. Takže na úlomek máme 125,000112 MB na útržek, pokud vše namaxujeme. Vydělením 32 TB touto hodnotou nám ukáže, že v clusteru můžeme mít maximálně lehce pod 256 000 fragmentů.
Každý fragment zase pojme 32 TB dat. 256 000 * 32 TB je 8 192 00 exabajtů nebo 8 192 000 terabajtů. To by byl limit pro náš příklad.
Řekněme jeho 8 exabajtů. Od této chvíle to lze snadno přeložit jako „Dost pro všechny praktické účely“. Chcete-li si udělat dojem:Všechna data v Knihovně Kongresu (pravděpodobně jedna z největších knihoven na světě, pokud jde o velikost sbírky) obsahuje odhadovanou velikost dat o velikosti přibližně 20 TB, včetně zvukových, obrazových a digitálních materiálů. Do našeho teoretického MongoDB clusteru byste to mohli vměstnat asi 400 000krát. Všimněte si, že se jedná o spodní hranici maximální velikosti s použitím konzervativních hodnot.
WiredTiger
A teď k tomu dobrému:Úložný engine WiredTiger nemá toto omezení:Velikost databáze není omezena (protože neexistuje žádné omezení počtu datových souborů, které lze použít), takže můžeme mít neomezený počet shardů. I když máme tyto fragmenty spuštěné na mmapv1 a pouze naše konfigurační servery na WT, velikost a se stává téměř neomezenou – omezení na 16,8 M TB RAM na 64bitovém systému může někde způsobit problémy a způsobit indexy config.shard sbírka, která má být prohozena na disk, zastavuje systém. Mohu se jen domnívat, protože moje kalkulačka odmítá pracovat s čísly v této oblasti (a já jsem příliš líný na to, abych to dělal ručně), ale odhaduji zde limit v oblasti dvoumístných yottabajtů (a prostoru potřebného k umístění toho někde ve velikosti Texasu).
Závěr
Nedělejte si starosti s maximální velikostí dat ve sdíleném prostředí. Bez ohledu na to je to dostačující, a to i při tom nejkonzervativnějším přístupu. Použijte sharding a máte hotovo. Btw:i 32 TB je sakra hodně dat:Většina clusterů, které znám, pojme méně dat a úlomků, protože využití IOPS a RAM přesáhlo kapacitu jednoho uzlu.