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

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.

In NoSQL database you have only one criterion you can search for effectively - the key.

Isso claramente não é verdade.

Por exemplo, o MongoDB suporta índices. (de link )

Indexes support the efficient execution of queries in MongoDB. Without indexes, MongoDB must perform a collection scan, i.e. scan every document in a collection, to select those documents that match the query statement. If an appropriate index exists for a query, MongoDB can use the index to limit the number of documents it must inspect.

Indexes are special data structures [1] that store a small portion of the collection’s data set in an easy to traverse form. The index stores the value of a specific field or set of fields, ordered by the value of the field. The ordering of the index entries supports efficient equality matches and range-based query operations. In addition, MongoDB can return sorted results by using the ordering in the index.

Como o couchbase (do link )

Couchbase views enable indexing and querying of data.

A view creates an index on the data according to the defined format and structure. The view consists of specific fields and information extracted from the objects in Couchbase.

Na verdade, qualquer coisa que se chame um banco de dados NoSQL em vez de um armazenamento de valor-chave deve 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).

    

De modo geral, se o seu fluxo de trabalho for uma correspondência perfeita para as consultas de banco de dados relacional, você verá 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 importante é o potencial do NoSQL.

Para usar o exemplo, a consulta SQL por país é tão lenta quanto a verificação NoSQL de todos os usuários, a menos que você tenha explicitamente informado ao SQL para indexar a tabela users 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.

    

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 em 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 em sã consciência afirmaria 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 são mantidos 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 esse é 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.