Regras de desenvolvimento
Conexões de banco de dados
Se o número máximo de conexões de mongod ou dds mongos for atingido, seu cliente não poderá se conectar às instâncias do DDS. Cada conexão recebida por mongod ou dds mongos é processada por um único thread de 1 MB de espaço de pilha. À medida que as conexões aumentam, muitos threads aumentam a sobrecarga de troca de contexto e o uso de memória.
- Se você se conectar a bancos de dados de clientes, calcule o número de clientes e o tamanho do pool de conexões configurado para cada cliente. O número total de conexões não pode exceder 80% do número máximo de conexões permitidas pela instância atual.
- A conexão entre o cliente e o banco de dados deve ser estável. Recomenda-se que o número de novas conexões por segundo seja inferior a 10.
- É aconselhável definir o intervalo de tempo limite de conexão do cliente para pelo menos três vezes a duração máxima de execução do serviço.
- Para uma instância de conjunto de réplicas, os endereços IP dos nós primário e em espera devem ser configurados no cliente. Para uma instância de cluster, pelo menos dois endereços IP de dds mongos devem ser configurados.
- O DDS usa o usuário rwuser por padrão. Quando você faz logon como usuário rwuser, o banco de dados de autenticação deve ser admin.
Confiabilidade
- w:1 significa que uma mensagem de confirmação foi retornada depois que os dados foram gravados no nó primário.
- w:1,journal:true significa que o resultado foi retornado depois que os dados foram gravados no nó primário e nos logs.
- w:majority significa que o resultado foi retornado depois que os dados foram gravados em mais da metade do total de nós em espera.
Se os dados não forem gravados usando w:majority, os dados que não estão sincronizados com o nó de espera poderão ser perdidos quando ocorrer uma alternância primária/em espera.
Se for necessária uma alta confiabilidade, implante um cluster em três AZs.
Desempenho
- O programa de serviço não tem permissão para executar a varredura completa da tabela.
- Durante a consulta, selecione apenas os campos que precisam ser retornados. Desta forma, as cargas de processamento de rede e thread são reduzidas. Se você precisar modificar dados, modifique apenas os campos que precisam ser modificados. Não modifique diretamente todo o objeto.
- Não use $not. O DDS não indexa dados ausentes. A consulta $not requer que todos os registros sejam verificados em uma única coleção de resultados. Se $not for a única condição de consulta, uma varredura completa da tabela será executada na coleção.
- Se você usar $and, coloque as condições com o menor número de correspondências antes de outras condições. Se você usar $or, coloque as condições com mais correspondências primeiro.
- Em uma instância de BD, o número total de bancos de dados não pode exceder 200 e o número total de coleções não pode exceder 500. Se o número de coleções for muito grande, a memória poderá estar sobrecarregada. Além disso, o desempenho para restaurar uma instância de BD e realizar uma alternância primário/em espera pode se deteriorar devido a muitas coletas, o que afeta o desempenho de alta disponibilidade em emergências.
- Antes de colocar um serviço on-line, execute um teste de carga para medir o desempenho do banco de dados em horários de pico.
- Não execute um grande número de transações simultâneas ao mesmo tempo ou deixe uma transação sem confirmação por um longo tempo.
- Antes de implementar os serviços, execute planos de consulta para verificar o desempenho da consulta para todos os tipos de consulta.
- Cada conexão é processada por um thread independente em segundo plano. Cada thread é alocado com 1 MB de memória de pilha. O número de conexões não deve ser muito grande. Caso contrário, muita memória é ocupada.
- Use o pool de conexões para evitar conexões e desconexão frequentes. Caso contrário, o uso da CPU é muito alto.
- Reduza as operações de leitura e gravação de disco: reduza as operações de upsert desnecessárias.
- Otimize a distribuição de dados: os dados são fragmentados e os dados quentes são distribuídos uniformemente entre os fragmentos.
- Reduza os conflitos de bloqueio: não execute operações na mesma chave com muita frequência.
- Reduza o tempo de espera de bloqueio: não crie índices no front-end.
Aviso
Durante o processo de desenvolvimento, cada execução em uma coleção deve ser verificada usando explain() para visualizar seu plano de execução. Exemplo:
db.T_DeviceData.find({"deviceId":"ae4b5769-896f"}).explain();
db.T_DeviceData.find({"deviceId":"77557c2-31b4"}).explain("executionStats");
Uma consulta coberta não precisa ler um documento e retorna um resultado de um índice, portanto, usar uma consulta coberta pode melhorar muito a eficiência da consulta. Se a saída de explain() mostra que indexOnly é true, a consulta é coberta por um índice.
- Verifique o tempo de execução. Quanto menores os valores dos seguintes parâmetros, melhor o desempenho: executionStats.executionStages.executionTimeMillisEstimate e executionStats.executionStages.inputStage. executionTimeMillisEstimate
- executionStats.executionTimeMillis especifica quanto tempo o banco de dados levou para selecionar e executar o plano vencedor.
- executionStats.executionStages.executionTimeMillisEstimate especifica o tempo de conclusão da execução do plano de execução.
- executionStats.executionStages.inputStage. executionTimeMillisEstimate especifica o tempo de conclusão da execução da subfase do plano de execução.
- Verifique o número de registros digitalizados. Se os três itens são os mesmos, o índice é melhor usado.
- executionStats. nReturned é o número de documentos que correspondem à condição de consulta.
- executionStats .totalKeysExamined indica o número de entradas de índice digitalizadas.
- executionStats .totalDocsExamined indica o número de entradas de documentos digitalizados.
- Verifique o status do estágio. As seguintes combinações de estágios podem proporcionar um bom desempenho.
- Fetch+IDHACK
- Fetch+ixscan
- Limit+ (Fetch+ixscan)
- PROJECTION+ixscan
Tabela 1 Descrição do status Nome do status
Descrição
COLLSCAN
Varredura completa da tabela
SORT
Classificação na memória
IDHACK
Consulta baseada em _id
TEXT
Índice de texto completo
COUNTSCAN
Número de índices não utilizados
FETCH
Varredura de índice
LIMIT
Usar Limit para limitar o número de registros retornados
SUBPLA
Estágio de consulta $or sem usar um índice
PROJECTION
Restringir o retorno do estágio quando um campo é retornado.
COUNT_SCAN
Número de índices utilizados
Regras de utilização do cursor
Se um cursor estiver inativo por 10 minutos, ele será automaticamente encerrado. Você também pode encerrá-lo manualmente para economizar recursos.
Regras para usar transações distribuídas na versão 4.2
- Spring Data MongoDB não suporta o mecanismo de repetição depois que um erro de transação é relatado. Se o cliente usar Spring Data MongoDB como o cliente para se conectar ao MongoDB, será necessário usar Spring Retry para repetir a transação com base nas referências do Spring Data MongoDB.
- O tamanho dos dados da operação de transação distribuída não pode exceder 16 MB.
Precauções para backups
Não execute operações DDL durante o backup para evitar falhas de backup.
