Ci sono limiti teorici, come mostrerò di seguito, ma anche il limite inferiore è carino alto. Non è facile calcolare correttamente i limiti, ma l'ordine di grandezza dovrebbe essere sufficiente.
mmapv1
Il limite effettivo dipende da alcune cose come la lunghezza dei nomi dei frammenti e simili (che si riassume se ne hai un paio di centinaia di migliaia), ma ecco un calcolo approssimativo con dati di vita reale.
Ogni shard necessita di spazio nel db di configurazione, che è limitato come qualsiasi altro database a 32 TB su una singola macchina o in un set di repliche. Sui server che amministra, la dimensione media di una voce in config.shards è 112 byte. Inoltre, ogni blocco necessita di circa 250 byte di informazioni sui metadati. Assumiamo che le dimensioni dei blocchi ottimali siano vicine a 64 MB.
Possiamo avere un massimo di 500.000 blocchi per server. 500.000 * 250 byte equivalgono a 125 MB per le informazioni sul blocco per shard. Quindi, per shard, abbiamo 125.000112 MB per shard se massimizziamo tutto. Dividendo 32 TB per quel valore, possiamo avere un massimo di poco meno di 256.000 shard in un cluster.
Ogni shard a sua volta può contenere 32 TB di dati. 256.000 * 32 TB corrispondono a 8,19200 exabyte o 8.192.000 terabyte. Questo sarebbe il limite per il nostro esempio.
Diciamo che sono 8 exabyte. A partire da ora, questo può essere facilmente tradotto in "Abbastanza per tutti gli scopi pratici". Per darti un'idea:tutti i dati detenuti dalla Library of Congress (probabilmente una delle più grandi biblioteche al mondo in termini di dimensioni della raccolta) contengono una dimensione stimata di dati di circa 20 TB, inclusi audio, video e materiali digitali. Potresti inserirlo nel nostro cluster MongoDB teorico circa 400.000 volte. Nota che questo è il limite inferiore della dimensione massima, utilizzando valori conservativi.
WiredTiger
Ora per la parte buona:il motore di archiviazione WiredTiger non ha questa limitazione:la dimensione del database non è limitata (poiché non c'è limite al numero di file di dati che possono essere utilizzati), quindi possiamo avere un numero illimitato di shard. Anche quando abbiamo quegli shard in esecuzione su mmapv1 e solo i nostri server di configurazione su WT, la dimensione di a diventa quasi illimitata:la limitazione a 16,8 M TB di RAM su un sistema a 64 bit potrebbe causare problemi da qualche parte e causare gli indici del config.shard raccolta da scambiare su disco, bloccando il sistema. Posso solo indovinare, dal momento che la mia calcolatrice si rifiuta di lavorare con i numeri in quell'area (e sono troppo pigro per farlo a mano), ma stimo il limite qui nell'area yottabyte a due cifre (e lo spazio necessario per ospitarlo da qualche parte grande quanto il Texas).
Conclusione
Non preoccuparti della dimensione massima dei dati in un ambiente partizionato. Non importa cosa, è di gran lunga sufficiente, anche con l'approccio più conservatore. Usa lo sharding e il gioco è fatto. A proposito:anche 32 TB sono un sacco di dati:la maggior parte dei cluster che conosco contengono meno dati e shard perché l'utilizzo di IOPS e RAM ha superato la capacità di un singolo nodo.
