Por que o NoSQL é melhor para esse cenário?

5

Cenário hipotético: Digamos que estamos baixando JSON do Facebook com detalhes de checkins, posts, etc. de um amigo do usuário. Eles vêm como um documento por amigo por atividade, então com 8 atividades um usuário com 300 amigos causará nosso sistema para fazer 2400 pedidos para o Facebook, baixando 2400 documentos JSON.

Digamos que queremos mesclar esses 2400 documentos juntos, classificar as atividades por date_created descendente e, em seguida, paginá-las em uma espécie de pseudo newsfeed. Por favor, não comente sobre a sabedoria de recriar um feed de notícias do Facebook dessa maneira.

Vamos supor também que queremos baixar novamente todos esses dados sempre que somos notificados de que foi alterado pelo Facebook. (FB tem um serviço de atualização que você pode se inscrever para os usuários do seu aplicativo). Por causa do argumento, vamos supor que todos os dados precisam ser atualizados a cada 5 minutos e, além disso, suponha que queremos poder suportar 1000 usuários simultâneos e que o tamanho médio do documento JSON seja 25kb.

Estou curioso para saber como as técnicas do NoSQL seriam melhores do que analisar o JSON no processamento em um banco de dados relacional? Para mim, parece que map / reduce são apenas sinônimos para parse / aggregate e que ambas as abordagens exigirão que a mesma coisa ocorra. Quais vantagens eu obteria usando o NoSQL?

    
por Infin8Loop 05.02.2013 / 18:40
fonte

2 respostas

6

What advantages would I get from using NoSQL?

O NoSQL será escalado melhor à medida que o número de usuários aumentar.

O RDBMS tradicional não se adapta bem. Tudo o que você pode fazer é jogar máquinas maiores no problema. Eles não são realmente adequados para sistemas distribuídos (nuvem, por exemplo).

O NoSQL é melhor (sob determinadas circunstâncias) para lidar com estruturas hierárquicas como documentos / JSON.

O ponto chave a ser entendido é que esses mecanismos de armazenamento são baseados em valores-chave e, portanto, podem recuperar dados que são armazenados juntos muito rapidamente, ao contrário dos dados que são "meramente relacionados" (que RDBMS foram construídos para).

No seu caso, isso significa que você pode recuperar facilmente todos os registros de um determinado usuário com muita rapidez, por exemplo. Nos bancos de dados relacionais tradicionais, você teria que desnormalizar seu esquema para desempenho ou manter o esquema limpo, mas potencialmente sofrer penalidades de desempenho causadas por junções ou agregações pesadas.

Veja desta forma: Por que um mapa hash (key value store) é rápido? Você pode recuperar itens de um hashmap em quase O (1), pois o hash traduz diretamente para um endereço de memória (simplificado). Procurar um índice binário em contraste com isso produziria O (log (n));

Para o seu caso, o MongoDB ou o CouchDB podem ser boas soluções, já que ele é baseado em JSON.

Na minha opinião, usar uma solução NoSQL aqui é uma boa escolha. Você deseja recuperar todas as atividades de um usuário como um feed. Se eles são escritos corretamente em seu armazenamento de dados, o NoSQL deveria, em teoria, se sobressair nisto, sem a necessidade de juntar nada ou se preocupar com os índices apropriados. @Earlz também mencionou que você não tem garantia de ACID para bancos de dados NoSQL. Isso torna o NoSQL rápido e você provavelmente não precisa de propriedades ACID para seu aplicativo. Experimente!

Além disso, há um artigo sobre Martin Fowler sobre o assunto. Ele fez um diagrama legal que eu gosto muito:

Acesseas suas páginas para ler alguns pensamentos profundos sobre o NoSQL.

    
por 05.02.2013 / 19:05
fonte
1

Primeiro, um banco de dados NoSQL é um banco de dados que não usa uma interface SQL. O que todos os bancos de dados NoSQL têm em comum é que eles não usam uma interface SQL. Acabei de me repetir? Sim, mas não há mais nada que eu possa dizer sobre bancos de dados NoSQL como um grupo. Qualquer outra coisa que esteja sendo falada sobre bancos de dados NoSQL na Internet está errada para alguns membros do grupo, ou provavelmente se tornará assim em algum momento no futuro, com o lançamento de um novo banco de dados ou uma atualização de recursos de um já existente. >

Tudo isso para dizer que perguntar se um banco de dados NoSQL é uma boa escolha para um trabalho em particular não é realmente uma pergunta que possa ser respondida, já que diferentes bancos de dados NoSQL têm características extremamente diferentes.

No cenário em que você descreve o maior problema, é definitivamente que você está batendo no Facebook com 8000 solicitações HTTP por segundo, mas vamos ignorar isso e focar na questão bastante comum de ter uma grande quantidade de dados minúsculos.

Tratamento de dados

Todas as outras coisas são iguais, qual é a diferença de desempenho entre buscar uma string de 8 bytes e uma string de 16 bytes de um banco de dados? É insignificante e, salvo algum contra-exemplo obscuro que seja verdadeiro para qualquer banco de dados, SQL ou não, a sobrecarga de tudo o que acontece em uma solicitação supera o tempo que leva para copiar mais 8 bytes. Se você quiser deslocar os dados rapidamente por meio de um banco de dados, classificá-los em grandes blocos que se encaixam em seu caso de uso é uma das coisas mais significativas que você pode fazer, geralmente muito mais importante do que o software de banco de dados usado.

É claro que há casos em que seu uso não se encaixa em grandes blocos de dados; em alguns casos, uma estratégia de cache em que os dados são mantidos na forma original e em partes pode funcionar bem; em outros casos, não há muito a fazer, mas mantendo os pequenos pedaços separados.

Manipulação de dados

Bancos de dados são lentos, ou seja, se você implementar uma função de manipulação de dados em um programa comum, por exemplo, usando várias strings pequenas e juntando-as em uma, e implementando uma funcionalidade semelhante por meio de uma solicitação de banco de dados, A versão do banco de dados normalmente leva de 100 a 1000 vezes mais tempo para realizar a operação. A figura exata do curso depende do banco de dados, alguns bancos de dados não serão capazes de fazê-lo, então você teria que escrever um programa que busca todos os dados, executar a operação e gravar o resultado no banco de dados, que é também um método bem lento.

Em geral, não faça no banco de dados o que você poderia razoavelmente fazer com os dados antes de gravá-los no banco de dados.

Qual banco de dados escolher

Depois de ter tomado todas essas considerações, que requisitos você tem para um banco de dados? Você conseguiu criar uma estrutura que não precisa de nenhum dos recursos sofisticados / lentos oferecidos por alguns bancos de dados? Se você fez, então um banco de dados SQL pode ser como um canivete suíço com uma lâmina cega, muitos recursos interessantes, mas não particularmente bons para o que você precisa. Alguns dos bancos de dados NoSQL são simplesmente mais rápidos e melhores quando você precisa apenas dos recursos simples, outros se encaixam no trabalho tão ruim quanto um banco de dados SQL.

A grande questão

Apesar de ter sido escrito por último neste post, é a pergunta que você deve fazer antes de todas as outras perguntas que mencionei. Você realmente precisa de um banco de dados?

É uma suposição bastante comum que, quando você lida com uma quantidade significativa de dados, você deve usar um banco de dados. Mas com um computador moderno, você pode armazenar vários gigabytes de dados na memória do aplicativo. Isso lhe dá acesso rápido e fácil, e as boas ferramentas para manipulação estão bem à mão. A única coisa que não lhe dá é a persistência, se a queda do programa de há uma perda de energia, os dados são perdidos. Em muitos casos que são perfeitamente aceitáveis, seu exemplo tem dados com um tempo de vida de ~ 5 minutos, não precisa de persistência, não precisa de um banco de dados.

    
por 05.02.2013 / 21:50
fonte