Depois de desenvolver seu aplicativo e modelo de banco de dados (quando é hora de mover o ambiente para produção), há algumas coisas que precisam ser feitas primeiro. Muitas vezes, os desenvolvedores não levam em consideração etapas adicionais importantes do MongoDB antes de implantar o banco de dados em produção. Consequentemente, é no modo de produção que eles acabam se deparando com contratempos subjacentes que não se apresentam no modo de desenvolvimento. Às vezes, pode ser tarde demais ou muitos dados seriam perdidos se ocorrer um desastre. Além disso, algumas das etapas discutidas aqui permitirão avaliar a integridade do banco de dados e, portanto, planejar as medidas necessárias antes que ocorram desastres.
Use a versão atual e os drivers mais recentes
Geralmente, as versões mais recentes de qualquer tecnologia vêm com recursos aprimorados em relação à funcionalidade subjacente do que suas antecessoras. As versões mais recentes do MongoDB são mais robustas e aprimoradas do que seus antecessores em termos de desempenho, escalabilidade e capacidade de memória. O mesmo se aplica aos drivers relacionados, pois eles são desenvolvidos pelos engenheiros de banco de dados principais e são atualizados com mais frequência até do que o próprio banco de dados.
Extensões nativas instaladas para seu idioma podem facilmente estabelecer uma plataforma para procedimentos rápidos e padrão para testar, aprovar e atualizar os novos drivers. Existem também softwares automotivos como Ansible, Puppet, SaltStack e Chef que podem ser usados para fácil atualização do MongoDB em todos os seus nós sem incorrer em despesas e tempo profissionais.
Considere também o uso do mecanismo de armazenamento WiredTiger, pois é o mais desenvolvido com recursos modernos que atendem às expectativas modernas de banco de dados
Inscreva-se em uma lista de discussão do MongoDB para obter as informações mais recentes sobre alterações em novas versões e drivers e correções de bugs, mantendo-se atualizado.
Use um sistema de 64 bits para executar o MongoDB
Em sistemas de 32 bits, os processos do MongoDB são limitados a cerca de 2,5 GB de dados porque o banco de dados usa arquivos mapeados na memória para obter desempenho. Isso se torna uma limitação para processos que podem ultrapassar o limite que leva a uma queda. O impacto principal será:em caso de erro, você não poderá reiniciar o servidor até remover seus dados ou migrar seu banco de dados para um sistema superior, como o de 64 bits, portanto, um tempo de inatividade maior para seu aplicativo.
Se você precisar continuar usando um sistema de 32 bits, sua codificação deve ser muito simples para reduzir o número de bugs e a latência das operações de taxa de transferência.
No entanto, para complexidades de código, como pipeline de agregação e dados geográficos, é aconselhável usar o sistema de 64 bits.
Certifique-se de que os documentos sejam limitados ao tamanho de 16 MB
Os documentos do MongoDB são limitados ao tamanho de 16 MB, mas você não precisa chegar perto desse limite, pois isso implicará em alguma degradação do desempenho. Na prática, os documentos são principalmente KB ou menos em tamanho. O tamanho do documento depende da estratégia de modelagem de dados entre a incorporação e a referência. A incorporação é preferível quando não se espera que o tamanho do documento aumente muito. Por exemplo, se você tem um aplicativo de mídia social onde os usuários postam e tem comentários, a melhor prática será ter duas coleções, uma para armazenar as informações da postagem.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}e o outro para manter comentários para essa postagem.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Por ter tais modelos de dados, os comentários serão armazenados em uma coleção diferente da postagem. Isso evita que o documento na coleção de postagem fique fora do limite, caso haja tantos comentários. Certifique-se de evitar padrões de aplicativos que permitiriam que os documentos crescessem sem limites.
Garantir que o conjunto de trabalho cabe na memória
O banco de dados pode falhar ao ler dados da memória virtual (RAM) levando a falhas de página. As falhas de página forçarão o banco de dados a ler dados de um disco físico, levando ao aumento da latência e, consequentemente, a um atraso no desempenho geral do aplicativo. As falhas de página ocorrem devido ao trabalho com um conjunto grande que não cabe na memória. Isso pode ser resultado de alguns documentos terem um tamanho ilimitado ou uma estratégia de fragmentação ruim. As soluções para falhas de página serão:
- Garantir que os documentos sejam limitados ao tamanho de 16 MB.
- Garantir uma boa estratégia de fragmentação selecionando uma chave de fragmentação ideal que limitará o número de documentos aos quais uma operação de taxa de transferência estará sujeita.
- Aumente o tamanho da instância do MongoDB para acomodar mais conjuntos de trabalho.
Certifique-se de ter conjuntos de réplicas no local
No mundo dos bancos de dados, não é ideal confiar em um único banco de dados porque pode ocorrer uma catástrofe. Além disso, você esperaria um aumento no número de usuários do banco de dados, portanto, precisa garantir alta disponibilidade de dados. A replicação é uma abordagem crucial para garantir alta disponibilidade em caso de failover. O MongoDB tem a capacidade de servir dados geograficamente:o que significa que usuários de diferentes locais serão atendidos pelo host de nuvem mais próximo como uma forma de reduzir a latência de solicitações.
Caso o nó primário falhe, os nós secundários podem eleger um novo para acompanhar as operações de gravação, em vez de o aplicativo ter um tempo de inatividade durante o failover. Na verdade, algumas plataformas de hospedagem em nuvem que são bastante atenciosas com a replicação não suportam MongoDB não replicado para ambientes de produção.
Ativar registro no diário
Por mais que o journaling implique alguma degradação do desempenho, também é importante. O registro no diário aprimora as operações de gravação antecipada, o que significa que, caso o banco de dados falhe no processo de atualização, a atualização teria sido salva em algum lugar e, quando ela voltar a funcionar, o processo poderá ser concluído. O registro no diário pode facilitar facilmente a recuperação de falhas, portanto, deve ser ativado por padrão.
Certifique-se de configurar uma estratégia de backup
Muitas empresas não conseguem continuar após a perda de dados devido a sistemas de backup inexistentes ou deficientes. Antes de implantar seu banco de dados em produção, certifique-se de ter usado uma destas estratégias de backup:
- Mongodump :ideal para pequenas implantações e ao produzir backups filtrados por necessidades específicas.
- Cópia subjacente :ideal para grandes implantações e abordagem eficiente para fazer backups completos e restaurá-los.
- Serviço de gerenciamento MongoDB (MMS) :fornece backup online contínuo para MongoDB como um serviço totalmente gerenciado. Ideal para um cluster fragmentado e conjuntos de réplicas.
Os arquivos de backup também não devem ser armazenados no mesmo provedor de host do banco de dados. Backup Ninja é um serviço que pode ser usado para isso.
Esteja preparado para consultas lentas
Dificilmente se pode realizar consultas lentas no ambiente de desenvolvimento devido ao fato de que poucos dados estão envolvidos. No entanto, isso pode não ser o caso na produção, considerando que você terá muitos usuários ou muitos dados estarão envolvidos. Consultas lentas podem surgir se você não usar índices ou usou uma chave de indexação que não é a ideal. No entanto, devemos encontrar uma maneira que mostre o motivo das consultas lentas.
Resolvemos, portanto, habilitar o MongoDB Query Profiler. Por mais que isso possa levar à degradação do desempenho, o criador de perfil ajudará a expor problemas de desempenho. Antes de implantar seu banco de dados, você precisa ativar o criador de perfil para as coleções que você suspeita que possam ter consultas lentas, especialmente aquelas que envolvem documentos com muita incorporação.
Conectar a uma ferramenta de monitoramento
O planejamento de capacidade é uma tarefa muito essencial no MongoDB. Você também precisará saber a integridade do seu banco de dados a qualquer momento. Por conveniência, conectar seu banco de dados a uma ferramenta de monitoramento economizará algum tempo para você perceber o que precisa melhorar em seu banco de dados com o tempo. Por exemplo, uma representação gráfica que indica o desempenho lento da CPU como resultado do aumento de consultas direcionará você para adicionar mais recursos de hardware ao seu sistema.
As ferramentas de monitoramento também têm um sistema de alerta por meio de e-mail ou mensagens curtas que o atualizam convenientemente sobre alguns problemas antes que eles se transformem em catástrofe. Portanto, na produção, certifique-se de que seu banco de dados esteja conectado a uma ferramenta de monitoramento.
O ClusterControl fornece monitoramento gratuito do MongoDB na Community Edition.
Implementar medidas de segurança
A segurança do banco de dados é outro recurso importante que precisa ser levado em consideração rigorosamente. Você precisa proteger a instalação do MongoDB em produção, garantindo que algumas listas de verificação de segurança de pré-produção sejam cumpridas. Algumas das considerações são:
- Configurando o controle de acesso baseado em função
- Ativação do controle de acesso e aplicação de autenticação
- Criptografia de conexões de entrada e saída (TLS/SSL)
- Limitando a exposição da rede
- Criptografia e proteção de dados
- Tenha um plano de controle sobre acesso e alterações nas configurações do banco de dados
Evite injeções externas executando o MongoDB com opções de configuração seguras. Por exemplo, desabilitar o script do lado do servidor se não estiver usando operações do lado do servidor JavaScript, como mapReduce e $where. Use o validador JSON para seus dados de coleta por meio de alguns módulos, como o mangusto, para garantir que todos os documentos armazenados estejam no formato BSON válido.
Considerações sobre hardware e software
O MongoDB tem poucos pré-requisitos de hardware, uma vez que foi projetado explicitamente com grande consideração sobre o hardware básico necessário. A seguir estão as principais deliberações de hardware para o MongoDB que você precisa considerar antes da implantação em produção.
- Atribua RAM e CPU adequadas
- Use o mecanismo de armazenamento WiredTiger. Projetado para usar o cache do sistema de arquivos e o cache interno do WiredTiger, aumentando o desempenho. Por exemplo, ao operar com um sistema de 4 GB de RAM, o cache do WiredTiger usa 1,5 GB de RAM (0,5 * (4 GB -1 GB) =1,5 GB), enquanto um sistema com 1,2 GB de cache do WiredTiger usa apenas 256 MB.
- NUMA Hardware. Existem vários problemas operacionais que incluem desempenho lento e alto uso de processos do sistema, portanto, deve-se considerar a configuração de uma política de intercalação de memória.
- Sistema de disco e armazenamento:use disco de estado sólido (SSDs):o MongoDB mostra melhor relação preço-desempenho com SSD SATA
Conclusão
Bancos de dados em produção são muito cruciais para garantir o bom funcionamento de um negócio, portanto, devem ser tratados com muitas considerações. Deve-se estabelecer alguns procedimentos que podem ajudar a reduzir os erros, ou melhor, fornecer uma maneira fácil de encontrar esses erros. Além disso, é aconselhável configurar um sistema de alertas que mostre a integridade do banco de dados com tempo para planejar a capacidade e detectar problemas antes que eles se transformem em catástrofe.
