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

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.

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).

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.

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.

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.

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.

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.

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).

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.