O uso de Bancos de Dados NoSQL é impraticável para grandes conjuntos de dados em que você precisa pesquisar por conteúdo?

Eu tenho aprendido sobre bancos de dados NoSQL por uma semana agora.

Eu realmente entendo as vantagens dos Bancos de Dados NoSQL e os muitos casos de uso para os quais eles são ótimos.

Mas muitas vezes as pessoas escrevem seus artigos como se o NoSQL pudesse substituir bancos de dados relacionais. E aí está o ponto que eu não consigo entender:

Bancos de dados NoSQL são (muitas vezes) armazenamentos de valores-chave.

É claro que é possível armazenar tudo em um armazenamento de valor-chave (codificando os dados em JSON, XML, qualquer coisa), mas o problema que vejo é que você precisa obter

Portanto, os bancos de dados NoSQL não são realmente uma opção para persistir dados que precisam ser pesquisados ​​por seu conteúdo. Ou eu entendi mal alguma coisa?

Um exemplo:

Você precisa armazenar dados do usuário para uma loja virtual.

Em um banco de dados relacional, você armazena cada usuário como uma linha na tabela users , com um ID, o nome, o país dele, etc.

Em um banco de dados NoSQL, você armazenaria cada usuário com seu ID como chave e todos os seus dados (codificados em JSON, etc.) como valor.

Então, se você precisa obter todos os usuários de um país específico (por alguma razão os caras de marketing precisam saber algo sobre eles), é fácil fazê-lo no banco de dados relacional, mas não muito eficaz no banco de dados NoSQL, porque você tem que obtenha todos os usuários, analise todos os dados e o filtro.

Eu não digo que é impossível , mas fica muito mais complicado e eu acho que não é tão eficaz se você quiser pesquisar os dados das entradas do NoSQL.

Você pode criar uma chave para cada país que armazena as chaves de cada usuário que mora neste país e obter os usuários de um país específico obtendo todas as chaves que são depositadas na chave desse país. Mas eu acho que esta técnica torna um conjunto de dados complexo ainda mais complexo - é mais difícil de implementar e não tão eficaz quanto a consulta de um banco de dados SQL. Então eu acho que não é uma maneira que você usaria na produção. Ou é?

Eu não tenho certeza se eu entendi mal alguma coisa ou ignorei alguns conceitos ou práticas recomendadas para lidar com tais casos de uso. Talvez você possa corrigir minhas declarações e responder minhas perguntas.

48
Tudo é possível dado tempo, dinheiro e recursos de programadores suficientes, a menos que o problema seja NP-difícil. Se é prático ou não, é uma questão diferente.
adicionado o autor sgwill, fonte
Não é um desentendimento em tudo :) Bancos de dados NoSQL são impressionantes, mas eu acho que os Bancos de Dados Relacionais não são tão ruins quanto algumas pessoas afirmam. Eu só quero descobrir, se minha tese, que bancos de dados NoSQL não são a melhor escolha se for pesquisar em 'datarows' ... ou se eu não entendi o tópico corretamente.
adicionado o autor magol, fonte
@CortAmmon oh, você está certo, eu estraguei o título: /
adicionado o autor magol, fonte
Mas o O MongoDB é o Webscale ! [aviso: inclui alguma linguagem NSFW]
adicionado o autor achrn, fonte
NoSQL: é apenas uma "palavra" que significa aproximadamente: uma alternativa para um banco de dados relacional. Essa "categoria" é tão grande que você não pode fazer uma comparação relacional no NoSQL. É como comparar maçãs com NoApples e depois escolher comparar apenas com bananas e esquecer que também há peras e muitas outras frutas NoApple.
adicionado o autor xirt, fonte
Lumping em todos os bancos de dados NoSQL juntos ... não é o ideal. Há uma variação maior nas coisas chamadas NoSQL do que entre o MongoDB e o Postgresql.
adicionado o autor user40980, fonte
adicionado o autor Lightness Races in Orbit, fonte
O NoSQL não não (ou pelo menos não deveria ) significa que seu banco de dados não é relacional, mas não usa SQL. Eu me contentaria com um banco de dados relacional com uma linguagem de consulta realmente estruturada, como a do MongoDB, em vez do string hell que é o SQL.
adicionado o autor Vincent Peres, fonte
Isso parece mais um discurso do que uma pergunta. Você parece ter uma boa compreensão das vantagens e desvantagens do armazenamento de valor-chave versus o relacional. Então, qual é exatamente a questão?
adicionado o autor JacquesB, fonte
@Darkhogg: Na prática, o termo NoSQL é usado para descrever bancos de dados que não são relacionais. Existem alguns bancos de dados experimentais que são relacionais, mas usam uma linguagem de consulta diferente do SQL - mas não é para isso que o termo NoSQL é usado.
adicionado o autor JacquesB, fonte
@DevWurm: Você não deve confundir armazenamentos de valores-chave com o NoSQL em geral. Por exemplo, o googles BigTable é considerado um banco de dados NoSQL, mas você ainda pode pesquisar e criar índices em vários campos. Um armazenamento de valor-chave é apropriado quando você sabe que só precisa pesquisar em um único campo (a chave).
adicionado o autor JacquesB, fonte
@DevWurm: Nenhuma pessoa sensata declararia que os bancos de dados relacionais são ruins, mas há alguns casos de uso específicos em que um armazenamento de valor-chave pode ser mais apropriado.
adicionado o autor JacquesB, fonte
@RobertHarvey editou, mas na minha resposta, notei que você diz "não digo que é impossível", enquanto seu título é "não é impossível o uso de bancos de dados NoSQL ..." Você pode querer corrigir isso
adicionado o autor Cort Ammon, fonte

8 Respostas

De um modo geral, se o seu fluxo de trabalho é uma combinação perfeita para consultas de banco de dados relacional, você encontrará os bancos de dados relacionais como a abordagem mais eficiente. É um tipo de tautológico, mas é verdade.

A alegação de que muitos defensores do NoSQL fariam é que muitos fluxos de trabalho foram realmente massageados em uma forma relacional e teriam sido mais eficazes antes de tal massageamento. A validade desta alegação é complicada de verificar. Claramente existem trabalhos que são muito bem descritos por consultas SQL. Eu posso dizer pela minha experiência que as minhas tarefas de programação relacional em particular poderiam ter sido feitas usando o NoSQL com quase o mesmo nível de eficiência, se não mais. No entanto, essa é uma afirmação muito subjetiva, baseada na experiência limitada.

Tenho a sensação de que grande parte da venda da abordagem NoSQL vem da suposição de grandes bancos de dados. Quanto maior o banco de dados, mais você deve preparar seu fluxo de trabalho para suportar os conjuntos de dados maiores. O NoSQL parece ser melhor em apoiar esse esforço de preparação. Assim, quanto maior o banco de dados, mais importantes podem ser as funcionalidades do NoSQL.

Para usar o exemplo, em SQL, a consulta por país é tão lenta quanto a verificação NoSQL de todos os usuários, a menos que você explicitamente tenha dito ao SQL para indexar a tabela usuários por país. O NoSQL pode fazer o mesmo, onde você cria uma coleção de valores-chave ordenada que é o índice (assim como o SQL faz sob o capô) e a mantém.

A diferença? Mecanismos SQL tinham o conceito de indexar a tabela embutida. Isso significa que você precisa fazer menos trabalho (tudo que você precisa fazer é adicionar um índice à tabela). No entanto, isso também significa que você tinha menos controle. Na maioria dos casos, essa perda de controle é aceitável, em troca do mecanismo de SQL que faz o trabalho para você. No entanto, em conjuntos de dados massivos, você pode querer um modelo de consistência diferente do modelo típico do SQL ACID. Você pode querer usar o modelo BASE que suporta consistência eventual. Isso pode ser muito difícil em SQL, porque o mecanismo SQL está fazendo o trabalho para você, portanto, isso deve ser feito pelas regras do mecanismo SQL. No NoSQL, essas camadas são normalmente expostas, permitindo que você as invada.

40
adicionado
No seu exemplo, você afirma que " consulta SQL por país é tão lento quanto a verificação NoSQL de todos os usuários ". Você tem evidências para apoiar isso? O NoSQL descrito na questão é par de valores-chave, portanto, você teria que verificar o valor para obter a localização do país e fazer a comparação. O SQL já sabe onde esses dados estão, portanto, pode selecioná-los diretamente do disco (ignorando o que não é necessário) e, em seguida, verificar o valor. Se o país é uma chave estrangeira, é uma comparação rápida de números inteiros. Não será sempre mais rápido, já que você está puxando menos do disco e a checagem é mais rápida.
adicionado o autor Peter Theill, fonte
@Trisped É difícil fornecer evidências, porque o NoSQL é uma abordagem, não um produto (mesmo para SQL). No entanto, vale a pena notar que o BigTable, uma implementação NoSQL, tem um conceito de colunas, assim como as tabelas SQL. É o conceito de colunas que permite saltar dados, sabendo onde procurar, o que pode ser aplicado a qualquer implementação.
adicionado o autor Cort Ammon, fonte

Embora eu concorde com sua premissa de que o NoSQL não é uma panacéia para todos os problemas do banco de dados, acho que você entendeu mal um ponto importante.

No banco de dados NoSQL você tem apenas um critério que você pode pesquisar com eficiência - a chave.

Isso claramente não é verdade.

Por exemplo, o MongoDB suporta índices. (de https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Índices suportam a execução eficiente de consultas no MongoDB. Sem   índices, o MongoDB deve executar uma varredura de coleta, ou seja,   documento em uma coleção, para selecionar os documentos que correspondem   declaração de consulta. Se existir um índice apropriado para uma consulta, o MongoDB   pode usar o índice para limitar o número de documentos que deve inspecionar.

     

Índices são estruturas de dados especiais [1] que armazenam uma pequena porção de   o conjunto de dados da coleção em um formato fácil de percorrer. O índice   armazena o valor de um campo específico ou conjunto de campos, ordenados pelo   valor do campo. A ordenação das entradas de índice suporta   correspondências de igualdade eficientes e operações de consulta baseadas em intervalos. Em   Além disso, o MongoDB pode retornar resultados classificados usando a ordem em   o índice.

Como o couchbase (de http://docs.couchbase.com/admin/admin/Views/views -intro.html

As exibições do Couchbase permitem a indexação e a consulta de dados.

     

Uma visão cria um índice nos dados de acordo com o formato definido   e estrutura. A visão consiste em campos e informações específicas   extraído dos objetos no Couchbase.

Na verdade, qualquer coisa que se chame um banco de dados NoSQL, em vez de um armazenamento de valor-chave, deveria realmente suportar algum tipo de esquema de indexação.

Na verdade, muitas vezes é a flexibilidade desses esquemas de índice que faz o NoSQL brilhar. Na minha opinião, a linguagem usada para definir os índices do NoSQL geralmente é mais expressiva ou natural que o SQL, e como eles geralmente vivem fora da tabela, você não precisa alterar os esquemas de tabela para suportá-los. (Para não dizer que você não pode fazer coisas parecidas no SQL, mas para mim parece que há muito mais saltos de aros envolvidos).

38
adicionado
"... uma vez que eles geralmente vivem fora da tabela, você não precisa alterar os esquemas da tabela para suportá-los." Essa é a mesma situação entre um índice não clusterizado em um banco de dados SQL e um índice para um banco de dados noSQL, certo?
adicionado o autor Jirka Hanika, fonte
Resposta bastante sólida. Eu adicionaria que o NoSQL é um pouco baseado na idéia de que, se você quer ir mais rápido, você deve fazer 90% de requisições ++ por uma chave primária sem uma junção, e se você quiser fazer qualquer outra coisa, você está no mundo de varreduras de tabelas e índices secundários, que sempre têm limites de desempenho e escala. Uma vez que você está pesquisando um índice, ou você criou um monte, você simplesmente não está na área onde a velocidade pode ser alcançada (exceto para pequenos conjuntos de dados de alguns milhões de linhas). Se você codificar no estilo onde as pesquisas alternativas são raras, você vai acabar com um sistema operacional muito sólido.
adicionado o autor Mr Stux, fonte

NoSQL é um termo bastante vago, uma vez que abrange basicamente todos os sistemas de banco de dados que não são relacionais.

O que você descreve é ​​um armazenamento de valor-chave , que é um tipo de banco de dados em que um blob de dados é armazenado sob uma chave e pode ser consultado rapidamente se você souber a chave. Esses bancos de dados são incrivelmente rápidos se você souber a chave exata, mas, como você mesmo diz, se precisar pesquisar ou filtrar várias propriedades nos dados, isso será lento e incômodo.

Ninguém no seu perfeito juízo alegaria que os armazenamentos de valores-chave podem substituir bancos de dados relacionais em geral. No entanto, pode haver casos de uso específicos em que o armazenamento de valor-chave é um bom ajuste. Os armazenamentos de valores-chave são geralmente usados ​​para armazenamento em cache, pois você normalmente armazena em cache os itens por id, mas não precisa realizar consultas ad-hoc nos caches. Por exemplo, o próprio site Stackoverflow usa Redis (um db de valor-chave) extensivamente , mas apenas para o cache de saída. Os dados canônicos subjacentes ainda persistem em um banco de dados relacional.

Portanto, a resposta é bastante óbvia: use um armazenamento de valor-chave se você precisar apenas armazenar e pesquisar usando uma única chave. Caso contrário, use um tipo diferente de banco de dados. E se você estiver em dúvida, use um banco de dados relacional, já que este é o tipo de banco de dados mais versátil, enquanto os bancos de dados NoSQL são geralmente otimizados para casos de uso muito particulares.

15
adicionado
@ JörgWMittag NoSQL originalmente significava "não-SQL" ou "não-relacional". O "Não apenas SQL" seria o NOSQL, pois é um acrônimo em vez da combinação da palavra "Não" e o acrônimo "SQL". Tornou-se popular como um contador para a prática geral de colocar tudo em um banco de dados (como indicado no artigo da Wikipedia). Como você comentou, o campo é um pouco mais complexo agora.
adicionado o autor Peter Theill, fonte
"NoSQL é um termo bastante vago, uma vez que abrange basicamente todos os sistemas de banco de dados que não são relacionais." - Isso não é verdade. Abrange todos os sistemas de banco de dados que não são bancos de dados SQL. Existem bancos de dados relacionais que não usam SQL, como Rel e Tutorial D (bancos de dados projetados para seguir mais de perto o modelo relacional sem a "suavização" que o SQL faz). Existem bancos de dados hiper-relacionais. Realmente, NoSQL significa "Não apenas SQL", o que significa "não assuma automaticamente SQL, escolha o modelo de banco de dados correto que corresponde à estrutura de sua data ... o que pode muito bem ser SQL."
adicionado o autor Lawrence B. Crowell, fonte
@ JörgWMittag: Thee não é uma definição oficial do termo NoSQL, mas normalmente se refere a sistemas de banco de dados não relacionais. O "Não apenas Sql" -backronym é realmente um retcon mais recente para contrariar o backlash hype inevitável. Mas no uso comum, o NoSQL é usado para descrever sistemas como o MongoDb, Bigtable etc., e não o tutorial D (que nem é um banco de dados).
adicionado o autor JacquesB, fonte
@ JörgWMittag Por sua definição, se eu escolher o MySQL porque é o melhor DB para combinar com os meus dados, isso é uma solução NoSQL válida.
adicionado o autor Arrow, fonte
Totalmente de acordo. Parece que os principais padrões do NoSQL são armazenamento de documentos de valor-chave (por exemplo, Redis) (por exemplo, Mongo) e gráfico (por exemplo, Neo4J). Eu gostaria que as pessoas abandonassem o NoSQL e usassem um desses termos.
adicionado o autor Benjamin Fuentes, fonte

Suas afirmações sobre bancos de dados relacionais são verdadeiras, até o ponto em que você tem tantos dados que você não pode mais colocar uma cópia em um único servidor. Então você começa a se deparar com todos os tipos de problemas interessantes. Como você divide suas tabelas para que a maioria das suas consultas possa ser executada em um único servidor? Quantas cópias dos dados você faz? Como você lida com inconsistências entre essas cópias? Como você mantém os dados de um usuário em um data center que é relativamente próximo a ele ou geograficamente?

Essas metas geralmente entram em conflito umas com as outras. Muitos usuários do Twitter seguem pessoas de todo o mundo. O banco de dados do Twitter deve ser geograficamente otimizado para ler tweets ou escrever tweets?

Acontece que quando você lida com esse tipo de escala, você começa a inventar soluções, adicionando redundâncias e impondo restrições que muito se assemelham a um banco de dados NoSQL. Se você puder ajustar todos os seus dados em uma caixa, você só receberá as restrições e não precisará dos benefícios.

10
adicionado
Isto está errado. A fragmentação como abordagem de programação tem sido padrão em bancos de dados de grande escala há anos e alguns bancos de dados suportam clusters com compartilhamento de dados de forma transparente (Oracle RAC). Como você acha que todos os bancos funcionam? E com uma configuração adequada, você RARAMENTE restaura os backups - que é deixado como um cenário real de "dois data centers incendiados". E sim, trabalhei em um banco de dados de 30 TB uma vez - não tivemos problemas.
adicionado o autor Fable, fonte
Sim, os bancos de dados relacionais fazem sharding e clustering de dados transparentes, mas é uma abstração muito fraca se você se preocupa com a otimização do desempenho.
adicionado o autor Mr Rogers, fonte
Ler 10 TB no RAM leva um tempo @Daniel ... Um par de horas seria um bom resultado. Isso tornaria a recuperação de um desastre relativamente desastroso.
adicionado o autor user35424, fonte
Eu diria que o Big Data é certamente uma área em que os bancos de dados NoSQL entram em ação, mas é apenas um deles. Há também muitas outras razões pelas quais um banco de dados NoSQL pode ser um melhor ajuste para um problema. Se você tiver gráficos de dados, faz sentido usar um banco de dados gráfico, se você tiver dados XML, faz sentido usar um banco de dados XML. Não apenas Big Data, mas também o modelo de dados é um critério importante ao selecionar um banco de dados apropriado (e, claro, muitas vezes, bancos de dados SQL são a escolha certa, dependendo do problema)
adicionado o autor Brian, fonte

Bancos de dados NoSQL têm muito pouco a ver com “ Não SQL”.

Eles estão prestes a admitir que você não pode ter um banco de dados em escala que seja sempre consistente e dê suporte a transações complexas e tenham durabilidade.

Em um banco de dados relacional normal, todos os índices são mantidos atualizados automaticamente dentro do escopo de uma transação, portanto, podem ser usados ​​para qualquer consulta.

Em um banco de dados NoSQL, o programador é responsável por manter muitos dos índices e assume-se que os índices estarão sempre desatualizados.

Por exemplo:

  • Um índice de pessoas por número de imposto pode conter algumas pessoas que nunca concluem o processo de registro para impostos.
  • Portanto, o código que usa o índice tem que ser capaz de lidar com o registro incompleto para o imposto
  • Outra opção é ter momentos em que uma pessoa registrada para imposto não está no índice. (Portanto, seu design precisa lidar com a falta de dados consistentes e decidir como os dados não serão consistentes.)

Como um exemplo real, a Amazon preferiria me mostrar a descrição desatualizada de um livro do que atrasar a exibição da página da Web esperando que 106 computadores confirmassem que a trava correta foi retirada.

Portanto .....

Se um único banco de dados relacional normal puder armazenar todos os seus dados e processar cada transação com rapidez suficiente para que o bloqueio não impeça o sistema de realizar um trabalho útil, um banco de dados relacional é a melhor opção.

Mas, assim que você começar a pensar em usar mais de um banco de dados relacional ou em dividir as transações para evitar erros de bloqueio, você terá que lidar com o tipo de problema que você recebe ao usar bancos de dados “NoSQL”.

As “NoSQL” databases do not hide these issues, they may become the best option when you scale up a system. But remember that Stackoverflow still uses an relational database for storing all its data, with limited use of NoSQL in the caching layer – so you have to be VERY big before you are forced to use NoSQL to store your data.

5
adicionado
adicionado o autor user1114, fonte
Esse último detalhe é muito interessante - você tem um link para algum site meta SO para os leitores interessados ​​clicarem sobre o (não) uso de SO do NoSQL? Obrigado!
adicionado o autor philomory, fonte

Bancos de dados relacionais são otimizados para procurar por qualquer valor no   datarow efetivamente.

Não confunda a capacidade de pesquisar em "qualquer" valor em uma linha com o valor "every" em uma linha. A maneira mais eficaz de fazer isso requer um ou mais índices. Você poderia ter índices que incluam todos os campos, mas você apenas impediu a capacidade de fazer alterações que exijam a alteração do índice (inserções, atualizações, exclusões). Você (ou seu DBA) tem que entender os dados, o uso, os gargalos, etc.

2
adicionado
Um bom exemplo seria salvar conversas. Pode haver a necessidade de relacioná-los com outros dados e fazer todo tipo de análise, mas durante a própria sessão de chat, os usuários apreciarão algo mais rápido que não possui toda a sobrecarga de um RDBMS, como uma transação ou restrição.
adicionado o autor bstpierre, fonte

Eu tenho usado o couchdb por dois anos agora. É usado principalmente para gerenciamento e configuração de conteúdo.

Para relacionamentos hierárquicos são muito mais fáceis de gerenciar quando você pode visualizá-los. Para dados de leitura geral, é mais fácil editar o JSON do que gravar uma instrução UPDATE em muitos casos. Não leva um programador, na verdade, para editar o JSON. E o SQL fornece linhas e colunas, que você precisa mapear em algum tipo de estrutura de objeto.

Você também obtém um aumento de desempenho porque não está participando de 10 a 20 tabelas em consultas complexas. As exibições do Couchdb são muito rápidas porque o JavaScript no qual elas são baseadas não é executado no momento da consulta.

A maioria dos programadores entende o Javascript, e a maioria dos programadores luta ocasionalmente com o SQL.

No Couchdb, uma visão pode ser considerada como um resumo de um documento JSON. A forma como os dados da visão são estruturados depende de você (você não está limitado pela hierarquia original).

Eu não usaria o Couchdb para dados altamente transacionais, mas para dados semi-estáticos com uma estrutura do tipo explosão de peças, é MUITO mais fácil de trabalhar do que o SQL.

Note, no entanto, que não há uma 'normalização' clara que possa ser aplicada (embora evitar a duplicação de dados seja um objetivo digno), e há uma estratégia de atualização essencialmente e 'otimista' semelhante ao bloqueio otimista.

2
adicionado

Já existem muitas respostas, mas eu só queria adicionar meu resumo.

Claramente, o conceito NoSQL abrange uma variedade de abordagens diferentes na organização de dados em disco, na memória e a exposição por meio de uma linguagem de consulta (alguns são até parecidos com SQL!). A meu ver, a força vem dessa variedade de sistemas para que você possa escolher a melhor ferramenta para o trabalho. Mas ainda assim esperamos que você possa cobrir uma dúzia de necessidades diferentes com apenas algumas soluções diferentes, você não iria querer gerenciar uma dúzia de sistemas diferentes.

Os bancos de dados relacionais podem levá-lo muito longe e são uma tecnologia comprovada, mas, assim como o banco de dados, você pode escolher a linguagem de programação com base nas necessidades de cada projeto (mas também levando em conta a experiência da equipe).

1
adicionado