Quando usar MongoDB ao invés de MySQL ou outro RDBMS

NoSQL,  nos últimos anos passou de um simples zum zum zum para uma realidade atual.

Portanto, como, onde e quando devemos utiliza-lo é a grande questão para muitos gestores que ainda não conseguiram assimilar a nova tendência.

Como profundo conhecedor de ambos (NoSQL e RDBMS) irei listar abaixo um resumo de melhores práticas onde cada tipo será melhor utilizado.

Melhores Práticas para MongoDB

Produtos NoSQL (MongoDB e entre eles) devem ser utilizados para enfrentar os desafios. Se você tiver um dos seguintes desafios abaixo, você deve considerar MongoDB:

Altas cargas de escrita

O MongoDB por padrão prefere altas taxas de inserção ao invés da segurança da transação. Se você precisar carregar toneladas de linhas de dados com um valor de negócio baixo para cada um, MongoDB deve servir. Não faça isso com a gravação de transações US $ 1 milhão ou pelo menos nestes casos faça com uma segurança extra.

Você precisa de alta disponibilidade em um ambiente não confiável (Cloud e Vida Real)

Definir replicaSet (conjunto de servidores que atuam como Master-Slaves) é fácil e rápido. Além disso, a recuperação de um nó (ou um centro de dados) de uma falha é instantâneo, seguro e automático.

Seus dados irão crescer muito e você precisará dividi-los 

Bases de dados de grande escala é difícil (uma única apresentação da tabela MySQL irá degradar ao cruzar  5-10GB por tabela). Se você necessitar particionar e dividir os dados de seu banco de dados, o MongoDB possui uma solução fácil para isso.

Seus Dados são Baseados por Localização

MongoDB foi construído em funções espaciais, de modo que para encontrar dados relevantes a partir de locais específicos é rápido e preciso.

Seu Data Set vai ser grande (a partir de 1GB) e o Schema não é estável

Adicionar novas colunas para RDBMS pode bloquear todo o banco de dados em algum outro banco de dados, ou até mesmo criar uma grande degradação de carga e desempenho em um outro. Normalmente, isso acontece quando o tamanho da tabela é maior do que 1 GB (e pode ser uma grande dor de cabeça para um sistema como BillRun que é descrito abaixo e tem vários TB em uma única tabela). Como MongoDB não possui schemas, adicionar um novo campo, não afetará linhas antigas (ou documentos) e será de forma instantânea. Outro vantagem é que você não precisa de um DBA para modificar o esquema quando houver qualquer mudança em ou de aplicações. Todos sabemos que em muitas empresas, uma simples tarefa envolvendo alterações de Schemas, Tabelas envolvem reuniões intermináveis e até mesmo aprovações infinitas que tomam muito tempo.

Você não tem um DBA em seu quadro de funcionários

Se você não tem um DBA e também não quer normalizar seus dados ou fazer joins, você deve considerar o MongoDB. MongoDB é perfeito para classes de persistência, pois como as classes podem ser serializadas para JSON e armazenadas COMO SÃO no MongoDB. Nota: Se você pretende lidar com grandes massas de dados, por favor, note que você terá que seguir algumas das melhores práticas para evitar armadilhas.

 

Caso de estudo no mundo real :  Billing

Na última ILMUG, Ofer Cohen apresentou o BillRun, uma solução Open Source de Billing  da próxima geração que utiliza MongoDB como seu armazenamento de dados. Este sistema de faturamento é executado em produção em no mais rápido ambiente em crescimento, em uma operadora de celular em Israel, onde ele processa mais de 500 milhões de CDRs (registros de dados de chamadas) a cada mês. Em sua apresentação, Ofer apresentou como este sistema utiliza vantagens MongoDB:

1.  O projeto sem a utilização de Shemas permite a rápida introdução de novos tipos de CDR para o sistema. Deixando assim o BillRun manter o armazenamento de dados genérico.
2. Em escala de produção, o BillRun já administra vários TB em uma única tabela, w/o que está sendo limitada pela adição de novos campos ou sendo limitada pelo crescimento
3. ReplicaSet Rápido que permite reuniões de regulação com fácil configuração  multi Data Center DRP  e solução de HA.
4. O Sharding permite alinnhar e escalar o crescimento w/o com o orçamento.
5. Com mais de 2.000 inserções CDR, a arquitetura MongoDB é ótima para um sistema que deve suportar alta carga de inserção. No entanto, você pode garantir transações com findAndModify (que é mais lento) e de duas fases (aplicação wise).
6. Desenvolvimento de Consultas Orientadas, permitem que os desenvolvedores escrevam consultas mais elegantes.
7. Dados baseados na localização está sendo utilizado para analisar o uso de cada usuário e determinar onde investir em infra-estrutura celular.

O MongoDB é uma grande ferramenta, e ser for usada nos cenários certos, irá ganhar uma vantagem desleal em seu mercado. BillRun é um bom exemplo para isso.