Quais são alguns casos de uso real para ir com um DB da loja de documentos NoSQL?

Question

Eu tenho lido a documentação e assistindo screencasts específicos para Mongo DB nos últimos dias e estou perdido para quando uma solução como essa seria melhor do que um ambiente típico de PG ou MySQL.

Especificamente, minha pergunta está em que circunstância (com caso de uso seria bom) você gostaria de seguir a rota NoSQL?

Obrigado!

Answer 1

1. Muitos escritores díspares. Especialmente quando os escritores podem ser segmentados devido a desconexões na rede e, posteriormente, precisarão redirecionar dados que foram gravados em ambos os lados da bifurcação. Isso quebra o ácido e, embora você possa resolver o problema com a lógica explícita de negócios, agora está no território NoSQL. Isso é muito comum em situações militares, mas qualquer sistema em que todos sejam um escritor prolífico terão alguma trava de contenção de gravação em um sistema ácido.

2. Esquemas de fluido. Alterar um esquema em um banco de dados tradicional é uma operação cara que geralmente requer algum tipo de tempo de inatividade do servidor ou outros processos complicados. Com a maioria dos sistemas NoSQL, é trivial. Portanto, se você tiver dados de muitas fontes díspares para mesclar e/ou ter situações em que você pode começar a rastrear novas informações posteriormente, os sistemas NOSQL serão muito mais fáceis de lidar. A fusão de duas fontes de dados para que elas possam ser mapeadas entre si é um bom exemplo em que posso pensar.

3. Replicação de baixa largura de banda. Depois de quebrar o ácido, você pode ter leitores e escritores nos nós foliares de um gráfico de rede com dados parciais que não precisam de réplicas completas do banco de dados. O produto da minha própria empresa, o posto de comando do exército do futuro, usa isso.

4. Interoperabilidade de dados. A maioria dos bancos de dados NoSQL permite introspectar os dados sem conhecer o esquema com antecedência, permitindo que as conexões entre sistemas díspares ocorram mais facilmente.

5. Escala maciça. Este é o que é mais frequente e mais frequentemente abusado pelos proponentes do NOSQL. Se essa é a única razão pela qual você está escolhendo o NOSQL, comece com o MySQL e escala mais tarde.

Answer 2

Caso de uso
Usamos o MongoDB para uma estrutura de dados extremamente transitória em larga escala. Com efeito, funciona como um rastreador / gerente de emprego, com muitas unidades de trabalho sendo processadas a cada segundo. A unidade de trabalho não possui esquema definido (unidades diferentes são inventadas com um pouco de frequência), mas precisamos ter a capacidade de consultar campos ou propriedades específicas sem iterar em todo o banco de dados. Então, para recapitular: altamente transitório, altamente disponível (não posso se dar ao luxo de bloquear uma consulta) com uma carga de trabalho de aproximadamente 600qps para uma única máquina de "commodity" em execução na nuvem.

O fato é que é extremamente difícil fazer o mesmo em uma máquina SQL, mantendo os mesmos custos.

Outros casos de uso popular para MongoDB (também para nós) são coleta estatística, é extremamente eficiente em incrementar propriedades específicas dentro de documentos, muito mais do que a maioria dos sistemas RDBMS.

Novamente, não é impossível fazê -lo no MySQL, é apenas mais caro e leva mais tempo (mais habilidade) que para uma pequena empresa ou um ambiente de desenvolvimento rápido significa que não pode ser feito.

Answer 3

Algumas APIs REST retornam dados JSON (por exemplo, muitos dos APIs de dados do governo aberto). Se você deseja despejar os dados restantes em um armazenamento de dados local (caso precise executar análises, etc.), a ingestão de um objeto JSON com MongoDB é trivial. Não há necessidade de definir um esquema de tabela. Melhor ainda, se o objeto JSON mudar com o tempo (por exemplo, a API REST retornar campos adicionais), você ainda poderá ingerir os dados em uma etapa. Tente isso com um banco de dados relacional!