Existem limites teóricos, como mostrarei abaixo, mas mesmo o limite inferior é bonito Alto. Não é fácil calcular os limites corretamente, mas a ordem de grandeza deve ser suficiente.
mmapv1
O limite real depende de algumas coisas, como comprimento de nomes de fragmentos e similares (isso se resume se você tiver algumas centenas de milhares deles), mas aqui está um cálculo aproximado com dados da vida real.
Cada fragmento precisa de algum espaço no banco de dados de configuração, que é limitado como qualquer outro banco de dados a 32 TB em uma única máquina ou em um conjunto de réplicas. Nos servidores que administro, o tamanho médio de uma entrada em
config.shards é 112 bytes. Além disso, cada pedaço precisa de cerca de 250 bytes de informações de metadados. Vamos supor tamanhos ótimos de blocos de cerca de 64 MB. Podemos ter no máximo 500.000 pedaços por servidor. 500.000 * 250 bytes equivalem a 125 MB para as informações do fragmento por estilhaço. Portanto, por estilhaço, temos 125,000112 MB por estilhaço se maximizarmos tudo. Dividir 32 TB por esse valor nos mostra que podemos ter no máximo um pouco menos de 256.000 shards em um cluster.
Cada estilhaço, por sua vez, pode conter 32 TB de dados. 256.000 * 32 TB são 8,19200 exabytes ou 8.192.000 terabytes. Esse seria o limite para o nosso exemplo.
Digamos que são 8 exabytes. A partir de agora, isso pode ser facilmente traduzido para "Suficiente para todos os fins práticos". Para você ter uma ideia:todos os dados mantidos pela Biblioteca do Congresso (indiscutivelmente uma das maiores bibliotecas do mundo em termos de tamanho de coleção) contêm um tamanho estimado de dados de cerca de 20 TB, incluindo áudio, vídeo e materiais digitais. Você poderia encaixar isso em nosso cluster teórico do MongoDB cerca de 400.000 vezes. Observe que este é o limite inferior do tamanho máximo, usando valores conservadores.
Tigre com fio
Agora a parte boa:O mecanismo de armazenamento WiredTiger não tem essa limitação:O tamanho do banco de dados não é limitado (já que não há limite de quantos arquivos de dados podem ser usados), então podemos ter um número ilimitado de shards. Mesmo quando temos esses shards rodando no mmapv1 e apenas nossos servidores de configuração no WT, o tamanho de a torna-se quase ilimitado – a limitação de 16,8 M TB de RAM em um sistema de 64 bits pode causar problemas em algum lugar e causar os índices do
config.shard coleção seja trocada para o disco, travando o sistema. Só posso adivinhar, já que minha calculadora se recusa a trabalhar com números nessa área (e tenho preguiça de fazer isso manualmente), mas estimo o limite aqui na área de yottabyte de dois dígitos (e o espaço necessário para hospedar isso em algum lugar no tamanho do Texas). Conclusão
Não se preocupe com o tamanho máximo dos dados em um ambiente fragmentado. Não importa o que aconteça, é de longe o suficiente, mesmo com a abordagem mais conservadora. Use sharding e pronto. Btw:até 32 TB são muitos dados:a maioria dos clusters que conheço contém menos dados e fragmentos porque a utilização de IOPS e RAM excedeu a capacidade de um único nó.
