Hay límites teóricos, como mostraré a continuación, pero incluso el límite inferior es bonito alto. No es fácil calcular los límites correctamente, pero el orden de magnitud debería ser suficiente.
mmapv1
El límite real depende de algunas cosas, como la longitud de los nombres de los fragmentos y similares (eso se resume si tiene un par de cientos de miles de ellos), pero aquí hay un cálculo aproximado con datos de la vida real.
Cada fragmento necesita algo de espacio en la base de datos de configuración, que está limitada como cualquier otra base de datos a 32 TB en una sola máquina o en un conjunto de réplicas. En los servidores que administro, el tamaño promedio de una entrada en config.shards es de 112 bytes. Además, cada fragmento necesita alrededor de 250 bytes de información de metadatos. Supongamos tamaños de fragmento óptimos de cerca de 64 MB.
Podemos tener como máximo 500.000 fragmentos por servidor. 500 000 * 250 bytes equivalen a 125 MB para la información de fragmentos por fragmento. Entonces, por fragmento, tenemos 125.000112 MB por fragmento si maximizamos todo. Dividir 32 TB por ese valor nos muestra que podemos tener un máximo de poco menos de 256 000 fragmentos en un clúster.
Cada fragmento, a su vez, puede contener 32 TB de datos. 256.000 * 32 TB son 8,19200 exabytes o 8.192.000 terabytes. Ese sería el límite para nuestro ejemplo.
Digamos que son 8 exabytes. A partir de ahora, esto se puede traducir fácilmente a "Suficiente para todos los propósitos prácticos". Para darle una impresión:todos los datos en poder de la Biblioteca del Congreso (posiblemente una de las bibliotecas más grandes del mundo en términos de tamaño de colección) tiene un tamaño estimado de datos de alrededor de 20 TB, incluidos audio, video y materiales digitales. Podría encajar eso en nuestro clúster teórico de MongoDB unas 400.000 veces. Tenga en cuenta que este es el límite inferior del tamaño máximo, usando valores conservadores.
Tigre cableado
Ahora, la parte buena:el motor de almacenamiento de WiredTiger no tiene esta limitación:el tamaño de la base de datos no está limitado (ya que no hay límite en la cantidad de archivos de datos que se pueden usar), por lo que podemos tener una cantidad ilimitada de fragmentos. Incluso cuando tenemos esos fragmentos ejecutándose en mmapv1 y solo nuestros servidores de configuración en WT, el tamaño de a se vuelve casi ilimitado:la limitación de 16,8 M TB de RAM en un sistema de 64 bits podría causar problemas en alguna parte y provocar los índices del config.shard colección para ser intercambiada al disco, deteniendo el sistema. Solo puedo adivinar, ya que mi calculadora se niega a trabajar con números en esa área (y soy demasiado perezoso para hacerlo a mano), pero estimo el límite aquí en el área de dos dígitos de yottabyte (y el espacio necesario para alojar eso en algún lugar del tamaño de Texas).
Conclusión
No se preocupe por el tamaño máximo de datos en un entorno fragmentado. Pase lo que pase, es lo suficientemente lejos, incluso con el enfoque más conservador. Usa fragmentación y listo. Por cierto:incluso 32 TB son una gran cantidad de datos:la mayoría de los clústeres que conozco contienen menos datos y fragmentos porque la utilización de IOPS y RAM superó la capacidad de un solo nodo.
