O uso de bancos de dados NoSQL é impraticável para grandes conjuntos de dados nos quais você precisa pesquisar por conteúdo?


51

Estou aprendendo sobre os bancos de dados NoSQL há uma semana.

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 os bancos de dados relacionais. E há um ponto em que não consigo entender:

Os bancos de dados NoSQL são (geralmente) armazenamentos de valores-chave.

Obviamente, é possível armazenar tudo em um armazenamento de valor-chave (codificando os dados em JSON, XML, qualquer que seja), mas o problema que vejo é que você precisa obter uma quantidade de dados que corresponda a um critério específico, em muitos casos de uso. Em um banco de dados NoSQL, você tem apenas um critério que pode procurar efetivamente - a chave. Os bancos de dados relacionais são otimizados para procurar efetivamente qualquer valor na linha de dados.

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

Um exemplo:

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

Em um banco de dados relacional, você armazena todos os usuários como uma linha na userstabela, 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.

Portanto, se você precisa obter todos os usuários de um país específico (por algum motivo, os profissionais 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ê precisa obtenha todos os usuários, analise todos os dados e filtre.

Não digo que seja impossível , mas fica muito mais complicado e acho que não é tão eficaz se você deseja pesquisar nos dados das entradas do NoSQL.

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

Não tenho muita certeza se entendi mal algo ou negligenciei alguns conceitos ou práticas recomendadas para lidar com esses casos de uso. Talvez você possa corrigir minhas declarações e responder minhas perguntas.


16
Isso parece mais um discurso retórico do que uma pergunta. Você parece ter uma boa noção das vantagens e desvantagens do armazenamento de valor-chave versus relacional. Então, qual é exatamente a pergunta?
precisa saber é o seguinte

16
Não é nada divertido :) Os bancos de dados NoSQL são impressionantes, mas 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 os bancos de dados NoSQL não são a melhor opção se se trata de pesquisar em 'datarows' ... ou se eu não entendi o tópico corretamente.
Leo Lindhorst


5
Mas o MongoDB é de escala da Web ! [aviso: inclui um pouco de linguagem NSFW]
Jerry Coffin

5
@ DevWurm: Você não deve confundir armazenamentos de valores-chave com o NoSQL em geral. Por exemplo, o Google BigTable é considerado um banco de dados NoSQL, mas você ainda pode pesquisar e criar índices em vários campos. Um armazenamento de valores-chave é apropriado quando você sabe que precisa pesquisar apenas em um único campo (a chave).
precisa saber é o seguinte

Respostas:


40

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ê não entendeu um ponto-chave.

No banco de dados NoSQL, você tem apenas um critério que pode procurar efetivamente - a chave.

Isso claramente não é verdade.

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

Os índices suportam a execução eficiente de consultas no MongoDB. Sem índices, o MongoDB deve executar uma verificação de coleção, ou seja, verificar todos os documentos em uma coleção, para selecionar os documentos que correspondem à instrução de consulta. Se existir um índice apropriado para uma consulta, o MongoDB poderá usá-lo para limitar o número de documentos que ele deve inspecionar.

Os índices são estruturas de dados especiais [1] que armazenam uma pequena parte do 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 ordem das entradas do índice suporta correspondências de igualdade eficientes e operações de consulta baseadas em intervalo. Além disso, o MongoDB pode retornar resultados classificados usando a ordem no índice.

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

As visualizaçõ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 e a estrutura definidos. A visualização consiste em campos e informações específicos extraídos dos objetos no Couchbase.

De fato, qualquer coisa que se autodenomina um banco de dados NoSQL, em vez de um armazenamento de valores-chave, deve realmente suportar algum tipo de esquema de indexação.

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


13
"... como eles geralmente vivem fora da mesa, você não precisa alterar os esquemas da mesa para apoiá-los." Essa é a mesma situação entre um índice não agrupado em um banco de dados SQL e um índice para um banco de dados noSQL, certo?
Jirka Hanika

Resposta bastante sólida. Eu acrescentaria que o NoSQL é um pouco baseado na idéia de que, se você quiser ir mais rápido, deve fazer solicitações de 90% ++ por uma chave primária sem associação, e se você quiser fazer qualquer outra coisa, estará no mundo de varreduras de tabela e índices secundários, que sempre têm limites de desempenho e escala. Depois de pesquisar um índice ou criar um monte, você simplesmente não está na área em que a velocidade pode ser alcançada (exceto para pequenos conjuntos de dados de alguns milhões de linhas). Se você codificar no estilo em que pesquisas alternativas são raras, você terminará com um sistema operacional muito sólido.
Brian Bulkowski

40

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

A alegação que muitos defensores do NoSQL fariam é que muitos fluxos de trabalho foram realmente massageados em uma forma relacional e teriam sido mais eficazes antes dessa massagem. A validade desta alegação é complicada de verificar. Claramente, existem trabalhos que são muito bem descritos por consultas SQL. Posso dizer pela minha experiência que minhas tarefas de programação relacional específicas poderiam ter sido realizadas 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 em uma experiência restrita.

Sinto 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 conjuntos de dados maiores. O NoSQL parece ser melhor para apoiar esse esforço de preparação. Assim, quanto maior o banco de dados, os recursos mais importantes do NoSQL podem ser potencialmente.

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

A diferença? Os mecanismos SQL tinham o conceito de indexar a tabela incorporada. Isso significa que você precisa fazer menos trabalho (tudo o 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 SQL fazendo o trabalho por você. No entanto, em conjuntos de dados maciços, convém 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 no 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 corte.


2
No seu exemplo, você afirma "A consulta SQL por país é tão lenta quanto a verificação NoSQL de todos os usuários ". Você tem evidências para apoiar isso? O NoSQL descrito na pergunta é um par de valores-chave; portanto, você deve verificar o valor para obter a localização do país e, em seguida, fazer a comparação. O SQL já sabe onde estão esses dados, para selecioná-los diretamente do disco (ignorando o que não é necessário) e, em seguida, verifique o valor. Se o país for uma chave estrangeira, é uma comparação rápida de números inteiros. No entanto, isso sempre será mais rápido, pois você está puxando menos do disco e a verificação é mais rápida.
Trisped

11
@Trisped É difícil fornecer evidências, porque o NoSQL é uma abordagem, não um produto (o mesmo para SQL). No entanto, vale ressaltar que o BigTable, uma implementação NoSQL, tem um conceito de colunas, assim como as tabelas SQL. É o conceito de colunas que permite ignorar dados sabendo onde procurar, que pode ser aplicado a qualquer implementação.
Cort Ammon

16

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

O que você descreve é ​​um armazenamento de valores-chave , que é um tipo de banco de dados em que um blob de dados é armazenado em uma chave e pode ser pesquisado 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 dos dados, será lento e complicado.

Ninguém em sã consciência alegaria que os armazenamentos de valores-chave podem substituir os bancos de dados relacionais em geral. No entanto, pode haver casos de uso específicos em que o armazenamento de valores-chave é um bom ajuste. Os armazenamentos de valores-chave geralmente são usados ​​para armazenamento em cache, pois você normalmente armazena itens em cache por ID, mas não precisa executar consultas ad-hoc sobre 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 são mantidos em um banco de dados relacional.

Portanto, a resposta é bastante óbvia: use um armazenamento de valores-chave se você só precisar 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, pois esse é o tipo mais versátil de banco de dados, enquanto os bancos de dados NoSQL são frequentemente otimizados para casos de uso muito particulares.


2
"NoSQL é um termo bastante vago, pois basicamente cobre 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 o Rel e o Tutorial D (bancos de dados projetados para seguir o modelo relacional mais de perto, sem o "amolecimento" que o SQL faz). Existem bancos de dados hiper-relacionais. Realmente, NoSQL significa "Não apenas SQL", que significa "não assume automaticamente o SQL, escolha o modelo de banco de dados correto que corresponda à estrutura da sua data ... que pode muito bem ser SQL".
Jörg W Mittag

@ JörgWMittag Por sua definição, se eu escolher o MySQL porque é o melhor banco de dados para corresponder aos meus dados, essa é uma solução NoSQL válida.

11
@ JörgWMittag: Não existe uma definição oficial do termo NoSQL, mas normalmente se refere a sistemas de banco de dados não relacionais. O sobrenome "Not Only Sql" é realmente um retcon mais recente para combater a inevitável reação de hype. Mas, em uso comum, o NoSQL é usado para descrever sistemas como MongoDb, Bigtable etc., sem dizer o tutorial D (que nem sequer é um banco de dados).
precisa saber é o seguinte

2
@ JörgWMittag NoSQL originalmente significava "não SQL" ou "não relacional". O "Não apenas SQL" seria NOSQL, pois é um acrônimo em vez da combinação da palavra "Não" e o acrônimo "SQL". Tornou-se popular como um contraponto à 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.
Trisped

Totalmente de acordo. Parece que os principais padrões do NoSQL são o armazenamento de documentos com 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.
paj28

10

Suas afirmações sobre bancos de dados relacionais são verdadeiras, até o ponto em que você tem tantos dados que não pode mais copiar uma cópia deles em um único servidor. Então você começa a encontrar 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 relativamente próximo dele ou dela geograficamente?

Esses objetivos geralmente conflitam entre si. Muitos usuários do twitter seguem pessoas de todo o mundo. O banco de dados do twitter deve ser geograficamente otimizado para ler 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 se assemelham muito a um banco de dados NoSQL. Se você pode ajustar todos os seus dados em uma única caixa, estará recebendo apenas as restrições e não precisará dos benefícios.


Ler 10 TB na RAM leva um tempo @Daniel ... Algumas horas seriam um bom resultado. Isso tornaria a recuperação de um desastre relativamente desastrosa.
Ben

11
Eu diria que o Big Data é certamente uma área em que os bancos de dados NoSQL entram em jogo, mas é apenas uma. Também existem muitas outras razões pelas quais um banco de dados NoSQL pode ser mais adequado para um problema. Se você possui gráficos de dados, faz sentido usar um banco de dados de gráficos; se você possui dados XML, faz sentido usar um banco de dados XML. Não só Big Data, mas também o modelo de dados é um critério importante na escolha de um banco de dados apropriado (e, claro, muitas vezes SQL-bases de dados são a escolha certa, dependendo do problema)
dirkk

5
Isto está errado. O sharding como abordagem de programação é padrão em bancos de dados de larga escala há anos e alguns bancos de dados oferecem suporte a clusters com compartilhamento transparente de dados (Oracle RAC). Como você acha que todos os bancos funcionam? E com uma configuração adequada, você RARAMENTE restaura backups - isso é deixado como um cenário real de "2 data centers queimados". E sim, trabalhamos em um banco de dados de 30 TB uma vez - não tivemos problemas.
TomTom

Sim, os bancos de dados relacionais realizam fragmentação e agrupamento transparentes de dados, mas é uma abstração muito vazada se você se preocupa em otimizar o desempenho.
Karl Bielefeldt

5

Os bancos de dados NoSQL têm muito pouco a ver com " No SQL".

Trata-se de admitir que você não pode ter um banco de dados em escala sempre consistente e que suporte transações complexas e tenha 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 índices e presume-se que os índices estejam 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 imposto.
  • Portanto, o código que usa o índice deve ser capaz de lidar com o registro incompleto de impostos
  • Outra opção é ter momentos em que uma pessoa registrada para imposto não esteja no índice. (Portanto, seu design deve lidar com a falta de dados consistentes e decidir como os dados não serão consistentes.)

Como um exemplo real, a Amazon prefere me mostrar a descrição desatualizada de um livro do que atrasar a exibição da página da web, aguardando 106 computadores para confirmar que a trava correta foi removida.

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.

Porém, assim que você começar a pensar em usar mais de um banco de dados relacional ou dividir transações para evitar erros de bloqueio, estará enfrentando o problema de lidar com o tipo de problemas que você obtém ao usar os bancos de dados “NoSQL”.

Como os bancos de dados “NoSQL” não ocultam esses problemas, eles podem se tornar a melhor opção quando você amplia o sistema. Mas lembre-se de que o Stackoverflow ainda usa um banco de dados relacional para armazenar todos os seus dados, com uso limitado do NoSQL na camada de cache - portanto, você deve ser MUITO grande antes de ser forçado a usar o NoSQL para armazenar seus dados.


Esse último boato é muito interessante - você tem um link para algum site de meta SO para leitores interessados ​​clicarem no (não) uso do NoSQL por SO? Obrigado!
kcrisman

@kcrisman, consulte highscalability.com/stack-overflow-architecture por exemplo
Ian

2

Os bancos de dados relacionais são otimizados para procurar efetivamente qualquer valor na datarow.

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


Um bom exemplo seria salvar chats. Pode haver uma necessidade de relacioná-los com outros dados e fazer todos os tipos de análise, mas durante a sessão de bate-papo, 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.
Jeffo

-1

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 na exposição por meio de uma linguagem de consulta (algumas são até do tipo SQL!). Na minha opinião, a força vem dessa variedade de sistemas para que você possa escolher a melhor ferramenta para o trabalho. Mas, ainda assim, espero que você possa cobrir uma dúzia de necessidades diferentes com apenas algumas soluções diferentes, não desejando 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 levando em consideração também a experiência da equipe).


-2

Estou usando o couchdb há dois anos. É usado principalmente para gerenciamento e configuração de conteúdo.

Para relacionamentos hierárquicos, é muito mais fácil gerenciar quando você pode visualizá-los. Para dados principalmente de leitura, é mais fácil editar JSON do que escrever uma instrução UPDATE em muitos casos. Na verdade, não é necessário um programador 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 recebe um aumento de desempenho porque não está juntando 10 a 20 tabelas em consultas complexas. As visualizações do Couchdb são muito rápidas porque o javascript em que se baseiam não é executado no momento da consulta.

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

No Couchdb, uma visão pode ser vista como um resumo de um documento JSON. A decisão de como os dados da exibição são estruturados depende de você (você não é 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 trabalhar com o SQL.

Observe, porém, que não há uma 'normalização' clara que possa ser aplicada (embora evitar a duplicação de dados seja uma meta válida), e existe uma estratégia de atualização essencialmente e 'otimista' semelhante ao bloqueio otimista.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.