A implantação de um banco de dados em cluster é uma coisa, mas como você mantém seu DBM enquanto está em cluster pode ser uma grande tarefa para um serviço consistente de seus aplicativos. Deve-se ter uma atualização frequente sobre o status do banco de dados, especialmente as métricas mais importantes, a fim de obter uma pista do que atualizar ou alterar como forma de evitar gargalos que possam surgir.
Há muitas considerações sobre o MongoDB que devem ser levadas em consideração, especialmente o fato de que sua instalação e execução são muito fáceis de negligenciar as práticas básicas de gerenciamento de banco de dados.
Muitas vezes, os desenvolvedores não levam em conta o crescimento futuro e o aumento do uso do banco de dados, o que consequentemente resulta em falhas de aplicativos ou dados com alguns problemas de integridade, além de serem inconsistentes.
Neste artigo vamos discutir algumas das melhores práticas que se deve empregar para o cluster MongoDB para um desempenho eficiente de seus aplicativos. Alguns dos fatores a serem considerados incluem...
- Atualizando para a versão mais recente
- Mecanismo de armazenamento apropriado
- Alocação de recursos de hardware
- Replicação e fragmentação
- Nunca altere o arquivo de configuração do servidor
- Boa estratégia de segurança
Atualizando para a versão mais recente
Trabalhei com o MongoDB a partir de versões anteriores à 3.2 e, para ser honesto, as coisas não eram fáceis naquela época. Com grandes desenvolvimentos, bugs corrigidos e recursos recém-introduzidos, aconselho você a sempre atualizar seu banco de dados para a versão mais recente. Por exemplo, a introdução da estrutura de agregação teve um impacto melhor no desempenho em vez de depender do conceito Map-Reduce que já existia. Com a última versão 4.0, agora é possível utilizar o recurso de transações de vários documentos que geralmente melhora as operações de rendimento. A versão mais recente também possui alguns novos operadores de conversão de tipo adicionais, como $toInt, $toString, $trim e $toBool. Esses operadores ajudarão muito na validação de dados, portanto, criarão algum senso de consistência de dados. Ao atualizar, consulte os documentos para evitar cometer pequenos erros que podem se tornar errôneos.
Escolha um mecanismo de armazenamento apropriado
O MongoDB suporta 3 mecanismos de armazenamento atualmente, ou seja:mecanismos de armazenamento WiredTiger, In-Memory e MMAPv1. Cada um desses mecanismos de armazenamento tem méritos e limitações sobre o outro, mas sua escolha dependerá da especificação do aplicativo e da funcionalidade principal do mecanismo. No entanto, eu pessoalmente prefiro o mecanismo de armazenamento WiredTiger e recomendo isso para quem não tem certeza de qual usar. O mecanismo de armazenamento WiredTiger é adequado para a maioria das cargas de trabalho, fornece um modelo de simultaneidade em nível de documento, pontos de verificação e compactação.
Algumas das considerações sobre as seleções do mecanismo de armazenamento dependem desses aspectos:
- Transações e atomicidade: fornecimento de dados durante uma inserção ou atualização que é confirmada somente quando todas as condições e etapas da aplicação foram executadas com sucesso. As operações são, portanto, agrupadas em uma unidade imutável. Com isso, a transação de vários documentos pode ser suportada, como visto na versão mais recente do MongoDB para o mecanismo de armazenamento WiredTiger.
- Tipo de bloqueio: é uma estratégia de controle de acesso ou atualização de informações. Durante a duração do bloqueio, nenhuma outra operação pode alterar os dados do objeto selecionado até que a operação atual seja executada. Conseqüentemente, as consultas são afetadas neste momento, portanto, é importante monitorá-las e reduzir o volume do mecanismo de bloqueio, garantindo que você selecione o mecanismo de armazenamento mais apropriado para seus dados.
- Indexação: Os mecanismos de armazenamento no MongoDB fornecem diferentes estratégias de indexação dependendo dos tipos de dados que você está armazenando. A eficiência dessa estrutura de dados deve ser bastante amigável com sua carga de trabalho e pode-se determinar isso considerando cada índice extra como tendo alguma sobrecarga de desempenho. As estruturas de dados otimizadas para gravação têm menor sobrecarga para cada índice em um ambiente de aplicativo de alta inserção do que as estruturas de dados otimizadas para não gravação. Este será um grande revés, especialmente quando um grande número de índices estiver envolvido e a seleção de um mecanismo de armazenamento inadequado. Portanto, a escolha de um mecanismo de armazenamento adequado pode ter um impacto dramático.
Alocação de recursos de hardware
À medida que novos usuários entram em seu aplicativo, o banco de dados cresce com o tempo e novos fragmentos serão introduzidos. No entanto, você não pode confiar nos recursos de hardware que estabeleceu durante o estágio de implantação. Haverá um aumento correspondente na carga de trabalho e, portanto, exigirá mais recursos de processamento, como CPU e RAM, para suportar seus grandes clusters de dados. Isso geralmente é referido ao planejamento de capacidade no MongoDB. As melhores práticas em torno do planejamento de capacidade incluem:
- Monitore seu banco de dados constantemente e ajuste de acordo com as expectativas. Como mencionado anteriormente, um aumento no número de usuários acionará mais consultas daqui em diante com um conjunto de carga de trabalho aumentado, especialmente se você empregar índices. Você pode começar a ter esse impacto no final do aplicativo quando ele começar a registrar uma alteração na porcentagem de gravações versus leituras com o tempo. Portanto, você precisará reconfigurar suas configurações de hardware para resolver esse problema. Use a ferramenta mongoperf e MMS para detectar alterações nos parâmetros de desempenho do sistema.
- Documentar antecipadamente todos os requisitos de desempenho. Quando você encontrar o mesmo problema, você terá pelo menos um ponto de referência que economizará algum tempo. Sua gravação deve envolver o tamanho dos dados que você deseja armazenar, análise de consultas em termos de latência e quantos dados você gostaria de acessar em um determinado momento. No ambiente de produção, você precisa determinar quantas solicitações serão tratadas por segundo e, por último, quanta latência você tolerará.
- Faça uma prova de conceito. Execute um projeto de esquema/índice e compreenda os padrões de consulta e, em seguida, refine sua estimativa do tamanho do conjunto de trabalho. Registre essa configuração como ponto de referência para testes com revisões sucessivas do aplicativo.
- Faça seus testes com carga de trabalho real. Depois de realizar o estágio de conceito de prova, implante somente após realizar um teste substancial com dados do mundo real e requisitos de desempenho.
Replicação e fragmentação
Esses são os dois principais conceitos para garantir alta disponibilidade de dados e maior escalabilidade horizontal, respectivamente, no cluster MongoDB.
O sharding basicamente particiona os dados entre os servidores em pequenas porções conhecidas como shards. O balanceamento de dados entre shards é automático, os shards podem ser adicionados ou removidos sem necessariamente colocar o banco de dados offline.
A replicação na outra extremidade mantém várias cópias redundantes dos dados para alta disponibilidade. É um recurso embutido no MongoDB e funciona em redes de longa distância sem a necessidade de redes especializadas. Para uma configuração de cluster, recomendo que você tenha pelo menos 2+ mongos, 3 servidores de configuração, 1 shard e garanta a conectividade entre as máquinas envolvidas no cluster shard. Use um nome DNS em vez de IPs na configuração.
Para ambientes de produção, use um conjunto de réplicas com pelo menos 3 membros e lembre-se de preencher mais variáveis de configuração, como tamanho do oplog.
Ao iniciar suas instâncias do mongod para seus membros, use o mesmo arquivo de chave.
Algumas das considerações do seu shardkey devem incluir:
- Chave e valor são imutáveis
- Sempre considere usar índices em uma coleção fragmentada
- O comando Atualizar driver deve conter uma chave de fragmentação
- Restrições exclusivas a serem mantidas pela chave de fragmentação.
- Uma chave de fragmentação não pode conter tipos de índice especiais e não deve exceder 512 bytes.
Nunca altere o arquivo de configuração do servidor
Depois de fazer sua primeira implantação, é aconselhável não alterar muitos parâmetros no arquivo de configuração, caso contrário você poderá ter problemas, especialmente com fragmentos. O elo mais fraco com o sharding são os servidores de configuração. Isso quer dizer que todas as instâncias do mongod precisam estar em execução para que a fragmentação funcione.
Boa estratégia de segurança
O MongoDB tem sido vulnerável a ataques externos nos últimos anos, portanto, um empreendimento importante para seu banco de dados ter alguns protocolos de segurança. Além de executar os processos em diferentes portas, deve-se empregar pelo menos uma das 5 maneiras diferentes de proteger bancos de dados MongoDB. Você pode considerar plataformas como o MongoDB Atlas que protegem os bancos de dados por padrão por meio da criptografia dos dados em trânsito e em repouso. Você pode usar estratégias como TLS/SSL para todas as conexões de entrada e saída.
Conclusão
O controle de cluster do MongoDB não é uma tarefa fácil e envolve muitas soluções alternativas. Os bancos de dados crescem como resultado de mais usuários, portanto, maior conjunto de carga de trabalho. A On tem, portanto, um mandato para garantir que o desempenho do DBM esteja alinhado com esse número crescente de usuários. As melhores práticas vão além de aumentar os recursos de hardware e aplicar alguns conceitos do MongoDB como sharding, replicação e indexação. No entanto, muitos dos inconvenientes que podem surgir são bem resolvidos com a atualização da sua versão do MongoDB. Mais frequentemente, as versões mais recentes têm bugs corrigidos, solicitações de novos recursos integrados e quase nenhum impacto negativo na atualização, mesmo com grandes números de revisão.
