MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

O que saber ao começar a trabalhar com o MongoDB em produção - dez dicas

Aprender MongoDB requer muito raciocínio preciso. Muitas vezes, pouca consideração é feita em empreendimentos essenciais que poderiam comprometer o desempenho do banco de dados no modo de produção.

MongoDB é um SGBD NoSQL que segue literalmente um padrão diferente dos bancos de dados SQL, especialmente nas linhas de segurança e estrutura. Embora alguns dos recursos integrados promovam seu desempenho e o tornem um dos melhores dos últimos tempos, alguns dos recursos representam ameaças potenciais que podem arruinar seu desempenho se não forem levados em consideração.

Em uma experiência recente de “pior caso”, eu estava tentando consultar uma coleção com documentos que tinham grandes arrays e demorei muito para obter os resultados. Resolvi escrever este blog porque sabia que se alguém passasse por esses mesmos problemas que este blog seria de grande ajuda.

Principais considerações para o MongoDB em produção

  1. Segurança e autenticação.
  2. Indexando seus documentos
  3. Como usar um esquema em suas coleções
  4. Coleção limitada
  5. Tamanho do documento
  6. Tamanho da matriz para documentos incorporados
  7. Estágios do pipeline de agregação
  8. Ordem das chaves no objeto hash
  9. 'undefined' e 'null' no MongoDB
  10. Operação de gravação

Segurança e autenticação do MongoDB

Os dados variam de várias maneiras e você obviamente precisará manter algumas informações confidenciais. Por padrão, as instalações do MongoDB não definem o requisito de autenticação como obrigatório, mas isso não lhe dá permissão para usá-lo, especialmente quando dados confidenciais, como registros financeiros e médicos, estão envolvidos. Em uma estação de trabalho de desenvolvimento, não é grande coisa, mas devido ao envolvimento de vários usuários no modo de produção, é uma boa prática definir os certificados de autenticação. O método mais comum e fácil de usar são as credenciais padrão de nome de usuário e senha do MongoDB.

Os dados são gravados em arquivos que podem ser acessados ​​por meio de uma ferramenta de terceiros, ainda mais se não forem criptografados. Os dados podem ser alterados sem o seu conhecimento se alguma pessoa anônima tiver acesso aos arquivos do sistema. Hospedar o banco de dados em um servidor dedicado e atribuir um único usuário que terá acesso total aos arquivos de dados economizará o truque.

Proteger dados de ataques de injeção externa também é uma tarefa essencial. Alguns operadores como $group, $whereby e as operações mapReduce são javascript(js) desenvolvidos, portanto, propensos à manipulação de js. Para evitar qualquer instância de integridade de dados como resultado, você pode desabilitar a configuração arbitrária de JS configurando o parâmetro javascriptEnabled:false no arquivo de configuração se você não tiver usado nenhum dos operadores mencionados. Além disso, você pode reduzir o risco de acesso a dados por meio de violações de rede empregando alguns dos procedimentos destacados na Lista de verificação de segurança do MongoDB.

Indexando seus documentos

A indexação geralmente é atribuir um valor de identificação exclusivo a cada documento em uma coleção do MongoDB. A indexação traz atualização de desempenho nas operações de leitura e gravação. Por padrão, ele está ativado e deve-se sempre manter essa configuração. Sem indexação, o banco de dados precisa verificar vários documentos do início ao fim e, infelizmente, a operação custará muito tempo para documentos que estão no final, resultando em baixa latência para a consulta. Em algum momento, no final do aplicativo, os usuários podem experimentar um atraso e podem pensar que o aplicativo não está realmente funcionando. A indexação é útil em operações de consulta de classificação e pesquisa, não deixando de fora a própria operação de localização. A classificação é uma operação comum para muitos documentos devolvidos. Muitas vezes, é realizado como o estágio final após a filtragem dos documentos, de modo que uma pequena quantidade de dados precise ser classificada. Um índice neste caso ajudará a classificar os dados por natureza de entrada e restringirá os dados retornados a um limite de 32 MB. Se não houver indexação, as chances do limite de 32 memórias no tamanho combinado de documentos retornados serão excedidas e sempre que o banco de dados atingir esse limite, ele lançará um erro além de retornar um conjunto de registros vazio.

A operação $lookup também é suportada com a indexação em vigor. Um índice no valor da chave usado como chave estrangeira é essencial para o processamento dos estágios anteriores.

Usando um esquema em suas coleções

MongoDB não precisa de um para definir campos (colunas) assim como pode exigir que você faça para dbms SQL. Por mais que você não precise definir os campos, para evitar inconsistência de dados e alguns contratempos que possam surgir, definir um esquema é sempre uma boa prática. O design do esquema permite determinar que tipo de dados vai para um determinado campo, qual campo deve ser fornecido com um valor e geralmente aprimora a validação dos dados antes da entrada ou atualização, promovendo assim a integridade e consistência dos dados. Um design de esquema também direcionará você para referenciar ou incorporar dados. Como iniciante, você pode pensar que o único modelo será "Um para N" que facilitará a existência de entradas de matriz de subdocumento, mas esse não é o caso.

Você precisa entender a relação de cardinalidade entre os documentos antes de fazer seu modelo. Algumas das regras que ajudarão você a ter um esquema ideal são:

  1. Para reduzir o número de consultas que você precisará executar antes de acessar alguns dados e se poucos campos ou elementos de matriz estiverem envolvidos, você poderá incorporar subdocumentos. Veja um exemplo do modelo abaixo:
    1. {
       Name: ‘John Doh’,
       Age:20
       Addresses:[
         {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’},
         {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’},
       ]
      }
      
  2. Para documentos atualizados com frequência, use desnormalização . Se algum campo for atualizado com frequência, haverá a tarefa de encontrar todas as instâncias que precisam ser atualizadas. Isso resultará em um processamento de consulta lento, sobrecarregando até mesmo os méritos associados à desnormalização.
  3. Consultas complexas, como pipeline agregado, levam mais tempo para serem executadas quando muitos subdocumentos estão envolvidos e há necessidade de buscar um documento separadamente.
  4. Elementos de matriz com grande conjunto de dados de objeto não devem ser incorporados, obviamente, porque podem crescer e, consequentemente, exceder o tamanho do documento.

A modelagem de um esquema geralmente é determinada pelo padrão de acesso do aplicativo. Você pode encontrar mais procedimentos que podem ajudar no design do seu modelo no blog 6 Rules of Thumb for MongoDB Schema Design

Usar uma coleção limitada para prioridade de documentos recentes

O MongoDB fornece muitos recursos, como a coleção limitada. Infelizmente alguns acabam não sendo utilizados. Uma coleção limitada tem um tamanho fixo e é conhecida por oferecer suporte a operações de alto rendimento que inserem e recuperam documentos com base no pedido de inserção. Quando seu espaço é preenchido, os documentos antigos são excluídos para dar espaço aos novos.

Exemplo de caso de uso de coleção limitada:

  • Armazenamento em cache de dados acessados ​​com frequência, pois a coleção em si é pesada para leitura e não para gravação. Você precisa garantir que a coleção esteja sempre em desempenho.
  • Informações de log para sistemas de alto volume. A coleção limitada geralmente não usa um índice e isso é vantajoso porque a velocidade de gravação é bastante rápida, assim como a gravação em um arquivo.

Preste atenção ao tamanho do documento MongoDB

Todo documento MongoDB é limitado a um tamanho de 16 megabytes. No entanto, é ideal que o documento atinja ou se aproxime desse limite, pois isso apresentará alguns problemas de desempenho terríveis. O próprio MongoDB funciona melhor quando o tamanho dos documentos é de alguns kilobytes. Se o tamanho do documento for grande o suficiente,   uma solicitação de projeção complexa levará muito tempo e a consulta poderá expirar.

Preste atenção ao tamanho da matriz de documentos incorporados

Pode-se enviar subdocumentos para um campo em um documento, criando assim um valor de matriz nesse campo. Como mencionado anteriormente, você precisa manter o tamanho dos subdocumentos baixo. É igualmente importante garantir que o número de elementos da matriz esteja abaixo de quatro dígitos. Caso contrário, o documento crescerá além de seu tamanho e precisará ser realocado no disco. Um outro problema associado a tal operação é que cada documento precisará ser reindexado. Além disso, cada subdocumento também precisará ser reindexado. Isso significa que haverá muitas gravações de índice que resultarão em operações lentas. Para tamanhos de subdocumentos grandes, é importante manter os registros em uma nova coleção do que embutir.

Estágios do pipeline de agregação 

Além das operações normais de consulta do MongoDB, existe um framework de agregação usado para manipular e retornar dados de acordo com algumas especificações como ordenação e agrupamento. O MongoDB não possui um otimizador de consulta, portanto, precisa de um para ordenar as consultas adequadamente. Com a estrutura de agregação, verifique se os estágios do pipeline estão bem ordenados. Comece reduzindo a quantidade de dados com os quais você está lidando usando o operador $match e possivelmente $sort no final, se precisar classificar. Você pode usar ferramentas de terceiros, como o Studio 3T, para otimizar sua consulta de agregação antes de integrá-la ao seu código. A ferramenta permite que você veja a entrada e saída de dados em qualquer uma das etapas, sabendo com o que está lidando.

Usar $limit e $sort deve sempre fornecer os mesmos resultados toda vez que a consulta for executada. Caso você use $limit, os dados retornados não serão determinísticos e podem gerar alguns problemas difíceis de rastrear.

Verifique a ordem das chaves em objetos de hash

Considere ter dois documentos grandes com dados de amostra

{

   FirstName: ‘John’,

   LastName: ‘Doh’

}

Se você fizer uma operação de busca com a consulta {FirstName:'John', LastName:'Doh'}, a operação não corresponde à consulta {LastName:'Doh' FirstName:'John' }. Portanto, você precisa manter a ordem dos pares de nome e valor em seus documentos.

Evite 'undefined' e 'null' no MongoDB

MongoDB usa o formato BSON para seus documentos. Com a validação JSON, 'undefined' não é suportado e você deve evitar usá-lo. $null vem como uma solução, mas você deve evitá-lo também.

Considere as operações de gravação

Você pode definir o MongoDB para gravações de alta velocidade, mas isso representa um revés, pois uma resposta é retornada mesmo antes de os dados serem gravados. O diário deve ser ativado para evitar esse cenário. Além disso, no caso de uma quebra de banco de dados, os dados ainda estarão disponíveis e criarão um ponto de verificação que pode ser usado no processo de recuperação. A configuração para a duração das gravações de diário pode ser definida usando o parâmetro commitIntervalMs.

Conclusão


O sistema de banco de dados deve garantir a integridade e consistência dos dados, além de ser resiliente a falhas e malícias. No entanto, para chegar a esses fatores, é preciso entender o próprio banco de dados e os dados que ele contém. O MongoDB funcionará bem quando os fatores mencionados acima forem levados em consideração. O principal deles está usando um esquema. Um esquema permite validar seus dados antes da entrada ou atualização e como você modelará esses dados. A modelagem de dados geralmente é orientada pelo padrão de acessibilidade do aplicativo. Tudo isso somado oferecerá um melhor desempenho do banco de dados.