Documentos volumosos
Lauren Schaefer, Daniel Coupal6 min read • Published Feb 12, 2022 • Updated May 31, 2022
Avalie esse Artigo
Bem-vindo (ou bem-vindo de volta): à série MongoDB Schema Anti-Patterns! Estamos na metade da série. Até agora, mencionamos três antipadrão: arraysmassivas, número massivo de collectionse índices desnecessários.
Hoje, vamos discutir o tamanho do documento. O MongoDB tem um limite de tamanho de documento MB16 . Mas você deve usar todos os 16 MBs? Talvez não. Vamos descobrir o motivo.
Se seu cérebro estiver inchado por causa de muita leitura, sente-se, relaxe e assista a este vídeo.
As chances são muito boas de que você queira que suas queries sejam rápidas. O MongoDB quer que suas queries sejam muito rápidas também.
Para manter suas queries em execução o mais rápido possível, oWiredTiger (o storage engine padrão do MongoDB) mantém todos os índices e os documentos acessados com mais frequência na RAM. Nos referimos a esses documentos e páginas de índice acessados com frequência como conjunto de trabalho. Quando o conjunto de trabalho cabe na alocação de RAM, o MongoDB pode consultar da RAM em vez do disco. As queries da RAM são mais rápidas, portanto, o objetivo é manter seus documentos mais populares pequenos o suficiente para caber no espaço de RAM.
A alocação de RAM do conjunto de trabalho é a maior de:
- 50% de (RAM - 1 GB)
- 256 MB.
Para obter mais informações sobre as especificações de armazenamento, consulte Uso de memória. Se você estiver usando o MongoDB Atlas para hospedar seu banco de dados, consulte Dimensionamento do Atlas e seleção de nível: memória.
Uma das regras práticas que você ouvirá com frequência ao discutir o projeto do esquema do MongoDB é que os dados acessados juntos devem ser armazenados juntos. Observe que isso não diz que dados relacionados entre si devem ser armazenados juntos.
Às vezes, os dados relacionados entre si não são realmente acessados juntos. Você pode ter documentos grandes e inchados que contêm informações relacionadas, mas que não são acessadas juntas com frequência. Nesse caso, separe as informações em documentos menores em collections separadas e use referências para conectar esses documentos.
O oposto do Anti-Padrão Bloated Documents é o Padrão de Subconjunto. O Padrão de Subconjunto incentiva o uso de documentos menores que contêm os dados acessados com mais frequência. Confira esta publicação sobre o Padrão de Subconjunto para saber mais sobre como aproveitar esse padrão com sucesso.
Vamos revisitar o site de Leslie para mulheres inspiradoras que discutimos no post anterior . Leslie atualiza a página inicial para exibir uma lista dos nomes das mulheres inspiradoras 100 selecionadas aleatoriamente. Quando um usuário clica no nome de uma mulher inspiradora, ele é direcionado para uma nova página com todas as informações biográficas detalhadas sobre a mulher que selecionou. Leslie preenche o site com 4,704 mulheres inspiradoras, incluindo ela mesma.
Inicialmente, leslie decide criar uma coleção denominada InpirationalWomen e cria um documento para cada mãe e modelo. O documento contém todas as informações desta mãe. Abaixo está um documento que ela cria para SallyRide.
Leslie percebe que sua página inicial está atrasada. A página inicial é a página mais visitada em seu site e, se a página não carregar rápido o suficiente, os visitantes abandonarão seu site completamente.
leslie está hospedando seu banco de dados no MongoDB Atlas e está usando um cluster dedicado M10 . Com um M10, ela obtém 2 GB de RAM. Ela faz alguns cálculos rápidos e descobre que seu conjunto de trabalho precisa caber em 0.5 GB. (Lembre-se que o conjunto de trabalho dela pode ser até 50% de (2 GB de RAM - 1 GB) = 0.5 GB ou 256 MB, o que for maior).
Leslie não tem certeza se seu conjunto de trabalho caberá atualmente em 0.5 GB de RAM, então ela navega até o Atlas Data Explorer. Ela pode ver que sua coleção InpirationalWomen é 580.29 MB e o tamanho do índice é 196 KB. Quando ela adiciona esses dois, ela pode ver que excedeu 0.5 GB.
Leslie tem duas opções: ela pode reestruturar seus dados de acordo com o padrão de subconjunto para remover os documentos inchados ou pode migrar para um cluster dedicado M20 , que tem 4 GB de RAM. Leslie considera suas opções e decide que o mais importante é que a página inicial e os documentos femininos inspiradores mais populares sejam carregados rapidamente. Ela decide que não há problema em fazer com que as páginas femininas visualizadas com menos frequência demorem um pouco mais para carregar.
Ela começa a determinar como reestruturar seus dados para otimizar o desempenho. A consulta na página inicial de Leslie só precisa recuperar o nome e o sobrenome de cada mulher. Ter essas informações no conjunto de trabalho é crucial. As outras informações sobre cada mulher (incluindo uma longa biografia) não precisam necessariamente estar no conjunto de trabalho.
Para garantir que sua página inicial seja carregada em um passo rápido, ela decide dividir as informações em sua collection
InspirationalWomen em duas collections: InspirationalWomen_Summary e InspirationalWomen_Details. Ela cria uma referência manual entre os documentos correspondentes nas collections. Abaixo estão seus novos documentos para SallyRide.Leslie atualiza sua consulta na página inicial que recupera o nome e o sobrenome de cada mulher para usar a coleção
InspirationalWomen_Summary. Quando um usuário seleciona uma mulher para saber mais sobre ela, o código do site de Leslie consulta um documento na coleção InspirationalWomen_Detailsusando o id armazenado no campoinspirationalwomen_id.Leslie retorna ao Atlas e inspeciona o tamanho de seus databases e collections. Ela pode ver que o tamanho total do índice para ambas as collections é 276 KB (180 KB + 96 KB). Ela também pode ver que o tamanho de sua collection
InspirationalWomen_Summary é de cerca 455 KB. A soma dos índices e esta collection é de cerca 731 KB, que é significativamente menor do que a alocação de RAM do conjunto de trabalho de 0.5 GB. Por esse motivo, muitos dos documentos mais populares da collectionInspirationalWomen_Details também se encaixam no conjunto de trabalho.
No exemplo acima, leslie está duplicando todos os dados da collection
InspirationalWomen_Summary na collection InspirationalWomen_Details. Você pode estar se contraindo com a ideia de duplicação de dados. Tradicionalmente, a duplicação de dados é mal vista devido a restrições de espaço, bem como aos desafios de manter os dados atualizados em ambas as coleções. O armazenamento é relativamente barato, então não precisamos necessariamente nos preocupar com isso aqui. Além disso, é improvável que os dados duplicados sejam alterados com muita frequência.Na maioria dos casos, você não precisará duplicar todas as informações em mais de uma collection; você poderá armazenar algumas das informações em uma collection e o restante nas outras. Tudo depende do seu caso de uso e de como você está usando os dados.
Certifique-se de que os índices e os documentos usados com mais frequência caibam na alocação de RAM do seu banco de dados para obter queries super rápidas. Se o seu conjunto de trabalho estiver excedendo a alocação de RAM, verifique se seus documentos estão inchados com informações extras que você realmente não precisa no conjunto de trabalho. Separe os dados usados com frequência dos dados usados com pouca frequência em diferentes collection para otimizar o desempenho.
Volte em breve para a próxima postagem desta série de antipadrões de design de esquema!
Confira os seguintes recursos para obter mais informações:
Avalie esse Artigo
{Parte de uma série