O cenário filho do cartaz para big data – você precisa filtrar uma grande quantidade de dados para extrair um pequeno “ pepita” de informação. Além disso, isso precisa ser feito no menor tempo possível, sua empresa depende disso. Historicamente, usando a tecnologia tradicional de sistema de gerenciamento de banco de dados relacional (RDBMS), esse tipo de cenário exigia uma grande equipe e um investimento de tempo e dinheiro. A maioria dos RDBMS tradicionais só escala verticalmente, então você precisa continuar comprando máquinas cada vez maiores para reduzir seu tempo de resposta. O advento de nuvens públicas e bancos de dados NoSQL como o MongoDB interrompeu completamente a forma como as equipes estão pensando nesse cenário.
Um de nossos clientes nos procurou recentemente com um problema interessante. Periodicamente, eles precisavam executar uma consulta realmente complexa que examinava todo o conjunto de dados. Essa consulta foi praticamente uma verificação de coleção que tocou em todos os documentos da coleção e incluiu estes detalhes:
- O total de dados foi de cerca de 100 GB.
- A segurança dos dados não era um problema, pois a cópia principal dos dados residia em outro lugar.
- A velocidade da consulta foi extremamente importante. O objetivo era poder executar toda a consulta em 10 a 15 minutos.
- O sistema precisa estar ativo apenas quando a consulta está em execução (minimizar o custo).
Devido ao último requisito, fazia sentido executar todo o sistema em uma nuvem pública. As máquinas são ligadas apenas algumas horas por semana para que os dados sejam atualizados e a consulta seja executada. O cliente já estava confortável com o Amazon EC2, então foi tomada a decisão de prototipar o sistema na AWS.
A melhor configuração para atingir esse objetivo foi uma implantação do MongoDB "fragmentada". Aqui está a configuração que estabelecemos:
- 3 estilhaços – cada estilhaço tem uma instância autônoma (r3.xlarge) com 30 GB de RAM
- 1 servidor de configuração
- 1 roteador de estilhaço (m3.xlarge) com 15 GB de RAM
Alguns pontos a serem destacados sobre nossas escolhas:
-
Conjunto de réplicas x autônomo
A segurança dos dados não é um requisito importante aqui, pois os dados mestre são armazenados em um sistema separado. Por isso, optamos por servidores autônomos em vez de um conjunto de réplicas para economizar custos. -
3 servidores de configuração vs 1 servidor de configuração
mesmo motivo como acima. A segurança dos dados não é uma questão importante. Em um ambiente de produção típico, teríamos três servidores de configuração.
A verdadeira beleza dessa configuração é que, devido à configuração fragmentada, quase todos os 100 GB de dados são armazenados completamente na memória. Então, essencialmente, o que você está executando é uma varredura “na memória”. Isso reduziu drasticamente o tempo de execução da consulta de algumas horas para menos de 10 minutos. O uso da nuvem pública também reduziu drasticamente o investimento de capital, pois você só paga pelas máquinas quando elas estão funcionando.
Esta é uma mudança bastante dramática na forma como as equipes têm lidado com esse cenário na última década. Então, se você está no negócio de “encontrar uma agulha no palheiro”, pense em Cloud + NoSQL!
Como sempre, se você tiver alguma dúvida, pode nos contatar em [email protected].
