Quero um exemplo trivial de onde o MongoDB pode escalar, mas um banco de dados relacional terá problemas [fechado]

Estou apenas aprendendo a usar o MongoDB e, ao discutir com outros programadores, gostaria de um exemplo rápido de por que o NoSQL pode ser uma boa escolha em comparação com um RDBMS tradicional - no entanto, os cenários apresentados e os que posso encontrar online parecem bastante artificial.

Por exemplo, um blog com muito tráfego pode ser representado de forma relacional, mas exigirá algum ajuste de desempenho e junção entre tabelas (assumindo que a desnormalização completa está sendo usada). Enquanto o MongoDB permitiria a recuperação direta de uma coleção para o mesmo efeito.

Mas a resposta que recebo de outros programadores é "por que não mantê-lo relacional e depois adicionar um cache trivial mais tarde?"

Alguém tem um exemplo menos artificial em que o MongoDB realmente brilhará e um banco de dados relacional cairá muito mais rapidamente? Quanto menor o projeto / sistema, melhor, porque deixa menos espaço para desacordo.

Algo parecido com a complexidade do exemplo do blog seria realmente útil.

Obrigado.

Primeiro, ele escala bem.

Quando um banco de dados MongoDB é muito freqüente ou muito grande para um único servidor, você pode adicionar mais servidores facilmente criando um cluster ou conjunto de réplicas de vários shards. Escala quase linearmente. Isso não funciona tão bem com a maioria dos bancos de dados relacionais. Dê uma olhada na lista de limitações do MySQL ao trabalhar como um cluster , por exemplo. A maioria das entradas da lista não é problema para o MongoDB (ou não se aplica).

Segundo, permite dados heterogêneos.

Imagine, por exemplo, o banco de dados do produto de uma loja de hardware de computador. Quais propriedades os produtos possuem? Todos os produtos têm um preço e um fornecedor. Mas as CPUs têm uma taxa de clock, os discos rígidos e os chips de RAM têm capacidade (e essas capacidades não são comparáveis), os monitores têm uma resolução e assim por diante. Como você projetaria isso em um banco de dados relacional? Você criaria uma tabela muito longa de productID-property-value ou criaria uma tabela de produtos muito ampla e esparsa com todas as propriedades que possa imaginar, mas a maioria delas é NULLpara a maioria dos produtos. Ambas as soluções não são realmente elegantes. Mas o MongoDB pode resolver isso muito melhor porque permite que cada documento em uma coleção tenha um conjunto diferente de propriedades.

Algum exemplo do mundo real de um problema que eu não teria idéia de como resolver de uma maneira razoável apenas com SQL e um banco de dados relacional (talvez seja minha culpa).

Portanto, temos um banco de dados (relacional comum) com cerca de 30.000 produtos. Nada grande até agora. Cada um desses produtos possui muitos atributos. Existem os mais comuns, como grupo (cabos, antenas, capas para iphone ... cerca de 80), sortimento (de alguma forma semelhante a grupos: carro, hifi, mp3, apenas 15), marca (30).

Depois vem os dados técnicos. Cada item tem muitos itens como cor, comprimento do cabo, peso, volume. cerca de 200 tipos de valores e milhares de valores.

E o mais complicado: muitos desses produtos pertencem a algum tipo de carro (ou vários deles) ou a algum tipo de dispositivo móvel. Esses vêm em hierarquias na forma como: tipo de marca (maçã) (ipad) (1,2,3,4) e, em alguns casos, geração. (para carros é semelhante, embora em vez de geração tenhamos anos de construção)

Etapa 1 do problema:

Queremos a quantidade de produtos para cada um desses atributos. Quantos são vermelhos? Quantos estão no grupo de cabos? E assim por diante.

Isso pode ser parcialmente resolvido com o SQL. Seria um monte de consultas e bastante feio, mas acho possível. Talvez lento, mas poderíamos fazê-lo ainda mais feio e manter os contadores em cada tabela e atualizar a cada alteração. Especialmente difícil com os atributos em que um produto pode ter vários (como funciona com o iPhone e outros 12 telefones celulares)

Mas aqui vem o problema, etapa dois:

Quando um cliente seleciona um atributo (digamos que ele quer apenas ver produtos vermelhos), queremos atualizar todos esses contadores em tempo real. Isso significa que teríamos consultas extremamente complicadas (provavelmente pouco rápidas de qualquer maneira) ou manteríamos contadores para possíveis combinações de atributos (bilhões).

Quando eu comecei neste projeto, eles deram a opção de contador e tentaram fazer isso para um subconjunto muito pequeno de atributos (grupo, sortimento, marca). O código era feio, com erros e lento. Além disso, agora eles tinham uma mesa com balcões que era muito maior que a mesa de produtos.

Usar as facetas do Apache Solr foi realmente a solução. Nivele as tabelas em uma lista de documentos (um por produto) permitidos para obter todos esses dados em tempo real com consultas muito mais simples.

Você pode pensar a qualquer momento que achar que uma tabela EAV é a melhor maneira de fazer as coisas (notoriamente lenta em bancos de dados reais e difíceis de consultar); talvez seja necessário um banco de dados nosql. Isso é especialmente verdade quando você não tem como saber antecipadamente quais seriam os campos. Um exemplo seria armazenar os detalhes dos exames médicos. Cada novo teste pode ter dados totalmente diferentes que você precisaria armazenar. E embora você possa (em teoria) modelar testes existentes (com muito tempo e esforço, pois existem milhares deles), como você saberia de quais novos testes poderá obter resultados para testes (e talvez equipamentos médicos) que não temos ' ainda nem inventou.

Quanto menor o projeto / sistema, melhor, porque deixa menos espaço para desacordo.

Isso é difícil porque o NoSQL é melhor apenas em grandes ambientes. Entendo que você quer dizer um Exemplo Simples , e eu tenho um perfeito para você.

Suponha que você esteja criando um site de viagens e precise que os usuários viajem de e para os 5.170 aeroportos dos EUA destinados a qualquer um dos outros (mesmos) 5.170 aeroportos dos EUA ...

Mas aqui está o Kicker, nem todos os vôos são diretos, você também precisa informar ao usuário todas as opções de escala, às vezes 2 ou 3 escalas. Você também precisa informar ao usuário todas as opções em uma janela de 5 horas! E você precisa calcular isso em menos de 10 segundos enquanto o usuário estiver aguardando.

Este é o Pesadelo do banco de dados relacional ... No NoSql, as rotas de vôo geralmente são definidas com algumas semanas de antecedência, para que você possa calcular todos os Gazillions de roteadores possíveis com antecedência, do que em um simples cluster NoSql DB ...

NoSql é o vencedor claro é esse cenário.