Como otimizar o desempenho do MongoDB

• Padrões de design de esquema inadequados
• Uso inadequado ou não uso de estratégias de indexação
• Hardware inadequado
• Atraso de replicação
• Técnicas de consulta de baixo desempenho

Design de esquema

• Um para poucos
• Um para muitos

Um para poucos

{
      userName: "Brian Henry",
      Email : "[email protected]",
      grades: [
             {subject: ‘Mathematics’,  grade: ‘A’},
             {subject: English,  grade: ‘B’},
      ]
}

Um para muitos

{ 
    Full_name: “John Doh”,
    User_id: 1518787459607.0
}

{
    "_id" : ObjectId("5aa136f0789cf124388c1955"),
    "postTime" : "16:13",
    "postDate" : "8/3/2018",
    "postOwnerNames" : "John Doh",
    "postOwner" : 1518787459607.0,
    "postId" : "1520514800139"
}

Técnicas de otimização para design de esquema

1. 
   Empregue a incorporação de documentos o máximo possível, pois reduz o número de consultas que você precisa executar para um determinado conjunto de dados.
   
2. 
   Não use a desnormalização para documentos que são atualizados com frequência. Se um campo for atualizado com frequência, haverá a tarefa de encontrar todas as instâncias que precisam ser atualizadas. Isso resultará em processamento de consulta lento, sobrecarregando até mesmo os méritos associados à desnormalização.
   
3. 
   Se houver a necessidade de buscar um documento separadamente, não há necessidade de usar a incorporação, pois consultas complexas, como pipelining agregado, levam mais tempo para serem executadas.
   
4. 
   Se a matriz de documentos a serem incorporados for grande o suficiente, não os incorpore. O crescimento da matriz deve ter pelo menos um limite limitado.
   

Indexação adequada

db.collection.createIndex({“fields”: 1})

db.collection.createIndex({“filed1”: 1, “field2”:  1})

db.collection.find( {f: 1} ).sort( {m: 1} )

db.collection.totalIndexSize()

{ _id: ObjectId(), a: 6, b: "no", c: 45 }
{ _id: ObjectId(), a: 7, b: "gh", c: 28 }
{ _id: ObjectId(), a: 7, b: "cd", c: 58 }
{ _id: ObjectId(), a: 8, b: "kt", c: 33 }

{ _id: ObjectId(), a: 6, b: "no", c: 45 }
{ _id: ObjectId(), a: 7, b: "gh", c: 28 }
{ _id: ObjectId(), a: 8, b: "cd", c: 58 }
{ _id: ObjectId(), a: 9, b: "kt", c: 33 }

Aprovisionamento de recursos

Atraso de replicação

Retrocessos com atrasos de réplica

1. 
   Dados inconsistentes. Isso está especialmente associado a operações de leitura que são distribuídas entre secundários.
   
2. 
   Se a lacuna de atraso for grande o suficiente, muitos dados não replicados podem estar no nó primário e precisarão ser reconciliados no nó secundário. Em algum momento, isso pode ser impossível, especialmente quando o nó primário não pode ser recuperado.
   
3. 
   A falha em recuperar o nó primário pode forçar a execução de um nó com dados que não estão atualizados e, consequentemente, pode descartar todo o banco de dados para fazer com que o primário seja recuperado.
   

Causas da falha do nó secundário

1. 
   Superando a potência primária sobre a secundária em relação à CPU, IOPS de disco e especificações de E/S de rede.
   
2. 
   Operações de gravação complexas. Por exemplo, um comando como
   

   db.collection.update( { a: 7}  , {$set: {m: 4} }, {multi: true} )

   
   O nó primário registrará esta operação no oplog com rapidez suficiente. No entanto, para o nó secundário, ele precisa buscar essas operações, ler na RAM qualquer índice e páginas de dados para atender a algumas especificações de critérios, como o id. Como ele precisa fazer isso rápido o suficiente para manter a taxa com o nó primário que faz a operação, se o número de operações for grande o suficiente, haverá um atraso esperado.
   
3. 
   Bloqueio do secundário ao fazer um backup. Nesse caso, podemos esquecer de desabilitar o primário, portanto, continuaremos com suas operações normalmente. No momento em que o bloqueio for liberado, o atraso de replicação terá uma grande lacuna, especialmente ao lidar com uma grande quantidade de backup de dados.
   
4. 
   Construção de índice. Se um índice se acumular no nó secundário, todas as outras operações associadas a ele serão bloqueadas. Se o índice for de longa duração, o soluço de atraso de replicação será encontrado.
   
5. 
   Secundário não conectado. Às vezes, o nó secundário pode falhar devido a desconexões de rede e isso resulta em um atraso de replicação quando ele é reconectado.
   

Como minimizar o atraso de replicação

• 
  Use índices exclusivos além de sua coleção com o campo _id. Isso é para evitar que o processo de replicação falhe completamente.
  
• 
  Considere outros tipos de backup, como instantâneos point-in-time e do sistema de arquivos, que não necessariamente requerem bloqueio.
  
• 
  Evite construir índices grandes, pois eles causam a operação de bloqueio em segundo plano.
  
• 
  Faça o secundário poderoso o suficiente. Se a operação de gravação for leve, o uso de secundários com pouca potência será econômico. Mas, para cargas de gravação pesadas, o nó secundário pode ficar atrás do primário. Para ser mais secante, o secundário deve ter largura de banda suficiente para ajudar a ler os oplogs com rapidez suficiente para manter sua taxa com o nó primário.
  

Técnicas de consulta eficientes

Otimizando suas consultas

1. 
   Usando uma consulta coberta. Uma consulta coberta é aquela que é sempre completamente satisfeita por um índice, portanto, não precisa examinar nenhum documento. A consulta coberta, portanto, deve ter todos os campos como parte do índice e, consequentemente, o resultado deve conter todos esses campos.
   
   Vamos considerar este exemplo:
   

   {_id: 1, product: { price: 50 }

   
   Se criarmos um índice para esta coleção como
   

   {“product.price”: 1} 

   
   Considerando uma operação de busca, então este índice cobrirá esta consulta;
   

   db.collection.find( {“product.price”: 50}, {“product.price”: 1, _id: 0}  )

   
   e retorne apenas o campo product.price e o valor.
   
2. 
   Para documentos incorporados, use a notação de ponto (.). A notação de ponto ajuda no acesso a elementos de uma matriz e campos de documento incorporado.
   
   Acessando uma matriz:
   

   {
      prices: [12, 40, 100, 50, 40]  
   }

   
   Para especificar o quarto elemento, por exemplo, você pode escrever este comando:
   

   “prices.3”

   
   Acessando uma matriz de objetos:
   

   {
   
      vehicles: [{name: toyota, quantity: 50},
                {name: bmw, quantity: 100},
                {name: subaru, quantity: 300}                    
   } 

   
   Para especificar o campo de nome na matriz de veículos você pode usar este comando
   

   “vehicles.name”

3. 
   Verifique se uma consulta está coberta. Para fazer isso, use o db.collection.explain(). Esta função fornecerá informações sobre a execução de outras operações - por exemplo. db.collection.explain().aggregate(). Para saber mais sobre a função de explicação, você pode conferir o explain().