Entendendo o limite de tamanho do documento MongoDB BSON

Do MongoDB O Guia Definitivo:

Documentos maiores que 4 MB (quando convertidos em BSON) não podem ser salvos no banco de dados. Esse é um limite um tanto arbitrário (e pode ser aumentado no futuro); é principalmente para evitar o mau design do esquema e garantir um desempenho consistente.

Eu não entendo esse limite. Isso significa que um documento contendo uma postagem de blog com muitos comentários que, por coincidência, é maior que 4 MB, não pode ser armazenado como um único documento?

Também isso conta os documentos aninhados também?

E se eu quisesse um documento que audita as alterações em um valor. (Eventualmente, poderá crescer, excedendo o limite de 4 MB.)

Espero que alguém explique isso corretamente.

Comecei a ler sobre o MongoDB (primeiro banco de dados nosql que estou aprendendo).

Obrigado.

Primeiro, isso realmente está sendo levantado na próxima versão para 8MBou 16MB... mas acho que para colocar isso em perspectiva, Eliot da 10gen (que desenvolveu o MongoDB) coloca da melhor maneira:

EDIT: O tamanho foi oficialmente 'aumentado' para16MB

Portanto, no exemplo do seu blog, 4 MB são na verdade muitos. Por exemplo, o texto descompactado completo de "Guerra dos Mundos" tem apenas 364k (html): http://www.gutenberg.org/etext/36

Se o seu blog é muito longo com tantos comentários, eu não o leio :)

Para trackbacks, se você dedicar 1 MB a eles, poderá facilmente ter mais de 10k (provavelmente mais perto de 20k)

Portanto, exceto em situações verdadeiramente bizarras, funcionará muito bem. E no caso de exceção ou spam, realmente não acho que você desejaria um objeto de 20 MB. Acho que limitar os trackbacks com mais ou menos 15k faz muito sentido, independentemente do desempenho. Ou pelo menos invólucro especial, se isso acontecer.

-Eliot

Acho que seria muito difícil atingir o limite ... e, com o tempo, se você atualizar ... precisará se preocupar cada vez menos.

O ponto principal do limite é que você não gaste toda a RAM do seu servidor (pois você precisará carregar todos os MBs do documento na RAM ao consultá-lo.)

Portanto, o limite é de alguns% da RAM utilizável normal em um sistema comum ... que continuará crescendo ano a ano.

Nota sobre o armazenamento de arquivos no MongoDB

Se você precisar armazenar documentos (ou arquivos) maiores do que 16MBvocê pode usar a API do GridFS, que dividirá automaticamente os dados em segmentos e os transmitirá de volta para você (evitando assim o problema com limites de tamanho / RAM).

Em vez de armazenar um arquivo em um único documento, o GridFS divide o arquivo em partes ou partes e armazena cada parte como um documento separado.

O GridFS usa duas coleções para armazenar arquivos. Uma coleção armazena os blocos de arquivos e a outra armazena metadados de arquivos.

Você pode usar esse método para armazenar imagens, arquivos, vídeos etc. no banco de dados, da mesma forma que você pode em um banco de dados SQL. Eu usei isso para armazenar até arquivos de vídeo com vários gigabytes.

Muitos na comunidade preferem não ter limites com avisos sobre desempenho, veja este comentário por um argumento bem fundamentado: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

Na minha opinião, os desenvolvedores principais são teimosos sobre esse problema porque decidiram que esse era um "recurso" importante desde o início. Eles não vão mudar isso tão cedo, porque seus sentimentos estão magoados por alguém ter questionado. Outro exemplo de personalidade e política que prejudica um produto em comunidades de código aberto, mas esse não é realmente um problema prejudicial.

Para postar uma resposta de esclarecimento aqui para quem é direcionado aqui pelo Google.

O tamanho do documento inclui tudo no documento, incluindo subdocumentos, objetos aninhados etc.

Então, um documento de:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Tem um tamanho máximo de 16meg.

Sbudocuments e objetos aninhados são contados para o tamanho do documento.

Ainda não vi um problema com o limite que não envolvia arquivos grandes armazenados no próprio documento. Já existe uma variedade de bancos de dados que são muito eficientes para armazenar / recuperar arquivos grandes; eles são chamados de sistemas operacionais. O banco de dados existe como uma camada sobre o sistema operacional. Se você estiver usando uma solução NoSQL por motivos de desempenho, por que você deseja adicionar sobrecarga de processamento adicional ao acesso aos seus dados colocando a camada de banco de dados entre o aplicativo e os dados?

JSON é um formato de texto. Portanto, se você estiver acessando seus dados por meio do JSON, isso é especialmente verdadeiro se você tiver arquivos binários, pois eles precisam ser codificados em uuencode, hexadecimal ou Base 64. O caminho da conversão pode parecer

arquivo binário <> JSON (codificado) <> BSON (codificado)

Seria mais eficiente colocar o caminho (URL) para o arquivo de dados no seu documento e manter os dados em binário.

Se você realmente deseja manter esses arquivos de tamanho desconhecido no seu banco de dados, provavelmente seria melhor colocá-los no GridFS e não correr o risco de matar sua simultaneidade quando os arquivos grandes forem acessados.

Profundidade aninhada para documentos BSON: MongoDB suporta não mais de 100 níveis de aninhamento para documentos BSON.

Mais informações info vist

Talvez armazenar um post -> comentários relação em um banco de dados não-relacional não é realmente o melhor design.

Provavelmente, você deve armazenar os comentários em uma coleção separada nas postagens do blog.

[editar]

Veja os comentários abaixo para uma discussão mais aprofundada.

De acordo com https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Se você espera que uma postagem no blog ultrapasse o limite de 16Mb de documento, extraia os comentários em uma coleção separada e faça referência à publicação no comentário e faça uma associação no nível do aplicativo.

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]