Um dos recursos mais anunciados do MongoDB é sua capacidade de ser “sem esquema”. Isso significa que o MongoDB não impõe nenhum esquema em nenhum documento armazenado em uma coleção. Normalmente, o MongoDB armazena documentos em um formato JSON para que cada documento possa armazenar vários tipos de esquema/estrutura. Isso é benéfico para os estágios iniciais de desenvolvimento, mas nos estágios posteriores, você pode querer impor alguma validação de esquema ao inserir novos documentos para melhor desempenho e escalabilidade. Resumindo, “Sem esquema” não significa que você não precisa projetar seu esquema. Neste artigo, discutirei algumas dicas gerais para planejar seu esquema MongoDB.
Descobrir o melhor design de esquema que se adapta ao seu aplicativo pode se tornar tedioso às vezes. Aqui estão alguns pontos que você pode considerar ao projetar seu esquema.
Evite documentos crescentes
Se o seu esquema permitir a criação de documentos que aumentam de tamanho continuamente, você deve tomar medidas para evitar isso, pois isso pode levar à degradação do desempenho de E/S do banco de dados e do disco. Por padrão, o MongoDB permite um tamanho de 16 MB por documento. Se o tamanho do seu documento aumentar mais de 16 MB durante um período de tempo, isso é um sinal de design de esquema ruim. Às vezes, pode levar à falha de consultas. Você pode usar buckets de documentos ou técnicas de pré-alocação de documentos para evitar essa situação. Caso seu aplicativo precise armazenar documentos com tamanho superior a 16 MB, considere usar a API MongoDB GridFS.
Evite atualizar documentos inteiros
Se você tentar atualizar o documento inteiro, o MongoDB reescreverá o documento inteiro em outro lugar da memória. Isso pode degradar drasticamente o desempenho de gravação do seu banco de dados. Em vez de atualizar todo o documento, você pode usar modificadores de campo para atualizar apenas campos específicos nos documentos. Isso acionará uma atualização in-loco na memória, portanto, melhor desempenho.
Tente evitar associações no nível do aplicativo
Como todos sabemos, o MongoDB não suporta junções no nível do servidor. Portanto, temos que obter todos os dados do banco de dados e, em seguida, realizar a junção no nível do aplicativo. Se você estiver recuperando dados de várias coleções e juntando uma grande quantidade de dados, precisará chamar o DB várias vezes para obter todos os dados necessários. Obviamente, isso exigirá mais tempo, pois envolve a rede. Como solução para esse cenário, se seu aplicativo depende muito de junções, a desnormalização do esquema faz mais sentido. Você pode usar documentos incorporados para obter todos os dados necessários em uma única chamada de consulta.
Use a indexação adequada
Ao fazer pesquisas ou agregações, geralmente classificamos os dados. Mesmo que você se inscreva para classificar no último estágio de um pipeline, ainda precisa de um índice para cobrir a classificação. Se o índice no campo de classificação não estiver disponível, o MongoDB será forçado a classificar sem um índice. Há um limite de memória de 32 MB do tamanho total de todos os documentos envolvidos na operação de classificação. Se o MongoDB atingir esse limite, ele poderá produzir um erro ou retornar um conjunto vazio.
Tendo discutido a adição de índices, também é importante não adicionar índices desnecessários. Cada índice que você adiciona no banco de dados, você precisa atualizar todos esses índices enquanto atualiza os documentos na coleção. Isso pode prejudicar o desempenho do banco de dados. Além disso, cada índice ocupará algum espaço e memória, portanto, o número de índices pode levar a problemas relacionados ao armazenamento.
Mais uma maneira de otimizar o uso de um índice é substituir o campo _id padrão. A única finalidade deste campo é manter um campo único por documento. Se seus dados contiverem um carimbo de data/hora ou qualquer campo de ID, você poderá substituir o campo _id e salvar um índice extra.
Vários noves Torne-se um DBA do MongoDB - Trazendo o MongoDB para a produçãoSaiba mais sobre o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o MongoDBBaixe gratuitamente
Proporção de leitura x gravação
Projetar o esquema para qualquer aplicativo depende muito se um aplicativo é pesado de leitura ou de gravação. Por exemplo, se você estiver criando um painel para exibir dados de séries temporais, deverá projetar seu esquema de forma a maximizar a taxa de transferência de gravação. Se o seu aplicativo for baseado em comércio eletrônico, a maioria das operações serão operações de leitura, pois a maioria dos usuários estará passando por todos os produtos e navegando em vários catálogos. Nesses casos, você deve usar o esquema desnormalizado para reduzir o número de chamadas ao banco de dados para obter dados relevantes.
Tipos de dados BSON
Certifique-se de definir os tipos de dados BSON para todos os campos corretamente ao projetar o esquema. Porque quando você altera o tipo de dados de qualquer campo, o MongoDB reescreverá todo o documento em um novo espaço de memória. Por exemplo, se você tentar armazenar (int)0 no lugar do campo (float)0.0, o MongoDB reescreverá todo o documento em um novo endereço devido à alteração no tipo de dados BSON.
Conclusão
Em poucas palavras, é aconselhável projetar um esquema para seu banco de dados Mongo, pois isso apenas melhorará o desempenho de seu aplicativo. A partir da versão 3.2, o MongoDB começou a dar suporte à validação de documentos, onde você pode definir quais campos são necessários para inserir um novo documento. A partir da versão 3.6, o MongoDB introduziu uma maneira mais elegante de impor a validação de esquema usando JSON Schema Validation. Usando esse método de validação, você pode impor a verificação de tipo de dados junto com a verificação de campo obrigatória. Você pode usar as abordagens acima para verificar se todos os documentos estão usando o mesmo tipo de esquema ou não.
