Não há dúvida de que a maneira como os aplicativos da web lidam com os dados mudou significativamente na última década. Mais dados estão sendo coletados e mais usuários estão acessando esses dados simultaneamente do que nunca. Isso significa que a escalabilidade e o desempenho são um desafio maior do que nunca para bancos de dados relacionais baseados em esquema e, portanto, podem ser mais difíceis de escalar.

A evolução do NoSQL

O problema de escalabilidade do SQL foi reconhecido por empresas da Web 2.0 com necessidades enormes e crescentes de dados e infraestrutura, como Google, Amazon e Facebook. Eles criaram suas próprias soluções para o problema - tecnologias como Mesa grande , DynamoDB e Cassandra .

Esse interesse crescente resultou em uma série de sistemas de gerenciamento de banco de dados NoSQL (DBMS), com foco em desempenho, confiabilidade e consistência. Diversas estruturas de indexação existentes foram reutilizadas e aprimoradas com o objetivo de aprimorar o desempenho de pesquisa e leitura.

Primeiro, havia tipos proprietários (código fechado) de bancos de dados NoSQL desenvolvidos por grandes empresas para atender às suas necessidades específicas, como o BigTable do Google, que se acredita ser o primeiro sistema NoSQL, e o DynamoDB da Amazon.

O sucesso desses sistemas proprietários iniciou o desenvolvimento de vários sistemas de banco de dados proprietários e de código aberto semelhantes, sendo os mais populares Hypertable, Cassandra, MongoDB, DynamoDB, HBase e Redis.

O que torna o NoSQL diferente?

Uma diferença fundamental entre os bancos de dados NoSQL e os bancos de dados relacionais tradicionais é o fato de que NoSQL é uma forma de armazenamento não estruturado .

Isso significa que os bancos de dados NoSQL fazem não têm uma estrutura de tabela fixa como as encontradas em bancos de dados relacionais.

Vantagens e desvantagens dos bancos de dados NoSQL

Vantagens

Os bancos de dados NoSQL têm muitas vantagens em comparação com os bancos de dados relacionais tradicionais.

Uma grande diferença subjacente é que os bancos de dados NoSQL têm uma estrutura simples e flexível. Eles não têm esquemas.

Ao contrário dos bancos de dados relacionais, os bancos de dados NoSQL são baseados em pares chave-valor.

Alguns tipos de armazenamento de bancos de dados NoSQL incluem armazenamento de coluna, armazenamento de documento, armazenamento de valor de chave, armazenamento de gráfico, armazenamento de objeto, armazenamento XML e outros modos de armazenamento de dados.

Normalmente, cada valor no banco de dados possui uma chave. Alguns armazenamentos de banco de dados NoSQL também permitem que os desenvolvedores armazenem objetos serializados no banco de dados, não apenas valores de string simples.

Os bancos de dados NoSQL de código aberto não exigem taxas de licenciamento caras e podem ser executados em hardware barato, tornando sua implantação econômica.

Além disso, ao trabalhar com bancos de dados NoSQL, sejam eles de código aberto ou proprietários, a expansão é mais fácil e mais barata do que ao trabalhar com bancos de dados relacionais. Isso ocorre porque é feito escalonando horizontalmente e distribuindo a carga em todos os nós, ao invés do tipo de escalonamento vertical que geralmente é feito com sistemas de banco de dados relacionais, que está substituindo o host principal por um mais poderoso.

Desvantagens

Obviamente, os bancos de dados NoSQL não são perfeitos e nem sempre são a escolha certa.

bancos de dados de documentos agrupam documentos em grupos lógicos chamados:

Por um lado, a maioria dos bancos de dados NoSQL não suporta recursos de confiabilidade que são nativamente suportados por sistemas de banco de dados relacionais. Esses recursos de confiabilidade podem ser resumidos como atomicidade, consistência, isolamento e durabilidade. Isso também significa que os bancos de dados NoSQL, que não oferecem suporte a esses recursos, trocam a consistência por desempenho e escalabilidade.

Para oferecer suporte a recursos de confiabilidade e consistência, desenvolvedores deve implementar seu próprio código proprietário, o que adiciona mais complexidade ao sistema.

Isso pode limitar o número de aplicativos que podem contar com bancos de dados NoSQL para transações seguras e confiáveis, como sistemas bancários.

Outras formas de complexidade encontradas na maioria dos bancos de dados NoSQL incluem incompatibilidade com consultas SQL. Isso significa que uma linguagem de consulta manual ou proprietária é necessária, adicionando ainda mais tempo e complexidade.

NoSQL vs. Bancos de dados relacionais

Esta tabela fornece uma breve comparação de recursos entre NoSQL e bancos de dados relacionais:

Característica	Bancos de dados NoSQL	Bancos de dados relacionais
atuação	Alto	Baixo
Confiabilidade	Pobre	Boa
Disponibilidade	Boa	Boa
Consistência	Pobre	Boa
Armazenamento de dados	Otimizado para dados enormes	De médio a grande
Escalabilidade	Alto	Alto (mas mais caro)

Deve-se notar que a tabela mostra uma comparação na nível de banco de dados , não os vários Sistemas de Gerenciamento de Banco de Dados que implementam ambos os modelos. Esses sistemas fornecem suas próprias técnicas proprietárias para superar alguns dos problemas e deficiências em ambos os sistemas e, em alguns casos, melhorar significativamente o desempenho e a confiabilidade.

Tipos de armazenamento de dados NoSQL

Key Value Store

No tipo de armazenamento de valor-chave, uma tabela de hash é usada na qual uma chave exclusiva aponta para um item.

As chaves podem ser organizadas em grupos lógicos de chaves, exigindo apenas que as chaves sejam exclusivas em seu próprio grupo. Isso permite chaves idênticas em grupos lógicos diferentes. A tabela a seguir mostra um exemplo de armazenamento de valor-chave, no qual a chave é o nome da cidade e o valor é o endereço da Ulster University naquela cidade.

s corporação e c corporação

Chave	Valor
'Belfast'	{“University of Ulster, Belfast campus, York Street, Belfast, BT15 1ED”}
“Coleraine '	{“University of Ulster, campus Coleraine, Cromore Road, Co. Londonderry, BT52 1SA”}

Algumas implementações do armazenamento de valor-chave fornecem mecanismos de cache, que melhoram muito seu desempenho.

Tudo o que é necessário para lidar com os itens armazenados no banco de dados é a chave. Os dados são armazenados na forma de string, JSON ou BLOB (Binary Large OBject).

Uma das maiores falhas nessa forma de banco de dados é a falta de consistência no nível do banco de dados. Isso pode ser adicionado pelos desenvolvedores com seu próprio código, mas, como mencionado antes, adiciona mais esforço, complexidade e tempo.

O banco de dados NoSQL mais famoso que é construído em um armazenamento de valor chave é o DynamoDB da Amazon.

Loja de Documentos

Os armazenamentos de documentos são semelhantes aos armazenamentos de valores-chave porque não têm esquema e são baseados em um modelo de valor-chave. Ambos, portanto, compartilham muitas das mesmas vantagens e desvantagens. Ambos carecem de consistência no nível do banco de dados, o que permite que os aplicativos forneçam mais recursos de confiabilidade e consistência.

No entanto, existem diferenças importantes entre os dois.

Em Armazenamentos de documentos, os valores (documentos) fornecem codificação para os dados armazenados. Essas codificações podem ser XML, JSON ou BSON (JSON codificado em binário) .

Além disso, é possível fazer consultas com base nos dados.

O aplicativo de banco de dados mais popular que depende de um armazenamento de documentos é o MongoDB.

Armazenamento de coluna

Em um banco de dados de armazenamento de coluna, os dados são armazenados em colunas, em vez de serem armazenados em linhas como é feito na maioria dos sistemas de gerenciamento de banco de dados relacional.

Um armazenamento de coluna é composto de uma ou mais famílias de colunas que agrupam logicamente certas colunas no banco de dados. Uma chave é usada para identificar e apontar para várias colunas no banco de dados, com um atributo keyspace que define o escopo dessa chave. Cada coluna contém tuplas de nomes e valores, ordenados e separados por vírgulas.

Os armazenamentos de colunas têm acesso rápido de leitura / gravação aos dados armazenados. Em um armazenamento de coluna, as linhas que correspondem a uma única coluna são armazenadas como uma única entrada do disco. Isso torna o acesso mais rápido durante as operações de leitura / gravação.

Os bancos de dados mais populares que usam o armazenamento de coluna incluem BigTable, HBase e Cassandra do Google.

Base do Gráfico

Em um banco de dados NoSQL de base de gráfico, uma estrutura de gráfico direcionada é usada para representar os dados. O gráfico é composto de arestas e nós.

Formalmente, um gráfico é uma representação de um conjunto de objetos, onde alguns pares de objetos são conectados por links. Os objetos interconectados são representados por abstrações matemáticas, chamadas vértices, e os elos que conectam alguns pares de vértices são chamados de arestas. Um conjunto de vértices e as arestas que os conectam é chamado de gráfico.

Isso ilustra a estrutura de um banco de dados de base de gráfico que usa arestas e nós para representar e armazenar dados. Esses nós são organizados por alguns relacionamentos entre si, que são representados por arestas entre os nós. Ambos os nós e os relacionamentos têm algumas propriedades definidas.

Os bancos de dados gráficos são mais usados ​​em aplicativos de rede social. Os bancos de dados gráficos permitem que os desenvolvedores se concentrem mais nas relações entre os objetos do que nos próprios objetos. Nesse contexto, eles realmente permitem um ambiente escalonável e fácil de usar.

Atualmente, InfoGrid e InfiniteGraph são os bancos de dados gráficos mais populares.

Sistemas de gerenciamento de banco de dados NoSQL

Para uma breve comparação dos bancos de dados, a tabela a seguir fornece uma breve comparação entre os diferentes sistemas de gerenciamento de banco de dados NoSQL.

	Tipo de armazenamento	Método de Consulta	Interface	Linguagem de programação	Código aberto	Replicação
Cassandra	Armazenamento de coluna	Thrift API	Thrift	Java	sim	Assíncrono
MongoDB	Loja de Documentos	Consulta Mongo	TCP / IP	C ++	sim	Assíncrono
HyperTable	Armazenamento de coluna	HQL	Thrift	Java	sim	Assíncrono
CouchDB	Loja de Documentos	MapReduce	DESCANSAR	Erlang	sim	Assíncrono
Mesa grande	Armazenamento de coluna	MapReduce	TCP / IP	C ++	Não	Assíncrono
HBase	Armazenamento de coluna	MapReduce	DESCANSAR	Java	sim	Assíncrono

O MongoDB tem um armazenamento de esquema flexível, o que significa que os objetos armazenados não precisam necessariamente ter a mesma estrutura ou campos. O MongoDB também possui alguns recursos de otimização, que distribuem as coletas de dados, resultando na melhoria geral do desempenho e em um sistema mais equilibrado.

Outros sistemas de banco de dados NoSQL, como o Apache CouchDB, também são bancos de dados do tipo de armazenamento de documentos e compartilham muitos recursos com o MongoDB, exceto que o banco de dados pode ser acessado usando APIs RESTful.

REST é um estilo arquitetônico que consiste em um conjunto coordenado de restrições arquitetônicas aplicadas a componentes, conectores e elementos de dados na World Wide Web. Ele se baseia em um protocolo de comunicação sem estado, cliente-servidor, que pode ser armazenado em cache (por exemplo, o protocolo HTTP).

Os aplicativos RESTful usam solicitações HTTP para postar, ler dados e excluir dados.

Quanto aos bancos de dados de coluna, Hypertable é um banco de dados NoSQL escrito em C ++ e é baseado no BigTable do Google.

Hypertable suporta a distribuição de armazenamentos de dados entre nós para maximizar a escalabilidade, assim como MongoDB e CouchDB.

Um dos bancos de dados NoSQL mais usados ​​é o Cassandra, desenvolvido pelo Facebook.

Cassandra é um banco de dados de armazenamento de coluna que inclui muitos recursos voltados para confiabilidade e tolerância a falhas.

quais são os princípios de design

Em vez de fornecer uma análise aprofundada de cada DBMS NoSQL, Cassandra e MongoDB, dois dos sistemas de gerenciamento de banco de dados NoSQL mais amplamente usados, serão explorados nas próximas subseções.

Cassandra

Cassandra é um sistema de gerenciamento de banco de dados desenvolvido pelo Facebook.

O objetivo por trás do Cassandra era criar um DBMS que não tivesse um ponto único de falha e fornecesse o máximo de disponibilidade.

Cassandra é principalmente um banco de dados de armazenamento de coluna. Alguns estudos se referiram ao Cassandra como um sistema híbrido, inspirado no BigTable do Google, que é um banco de dados de armazenamento de colunas, e no DynamoDB da Amazon, que é um banco de dados de valor-chave.

Isso é conseguido fornecendo um sistema de valor-chave, mas as chaves no Cassandra apontam para um conjunto de famílias de colunas, com base no sistema de arquivos distribuídos BigTable do Google e nos recursos de disponibilidade do Dynamo (tabela de hash distribuída).

O Cassandra foi projetado para armazenar grandes quantidades de dados distribuídos em diferentes nós. Cassandra é um DBMS projetado para lidar com grandes quantidades de dados, espalhados por vários servidores, ao mesmo tempo em que fornece um serviço altamente disponível e sem ponto único de falha, o que é essencial para um grande serviço como o Facebook.

Os principais recursos do Cassandra incluem:

• Nenhum ponto único de falha. Para que isso seja alcançado, o Cassandra deve ser executado em um cluster de nós, ao invés de uma única máquina. Isso não significa que os dados em cada cluster sejam os mesmos, mas o software de gerenciamento é. Quando ocorre uma falha em um dos nós, os dados desse nó ficarão inacessíveis. No entanto, outros nós (e dados) ainda estarão acessíveis.
• Hashing distribuído é um esquema que fornece funcionalidade de tabela de hash de forma que a adição ou remoção de um slot não altere significativamente o mapeamento de chaves para slots. Isso fornece a capacidade de distribuir a carga para servidores ou nós de acordo com sua capacidade e, por sua vez, minimizar o tempo de inatividade.
• Interface do cliente relativamente fácil de usar . Cassandra usa Apache Thrift para sua interface de cliente. O Apache Thrift fornece um cliente RPC de linguagem cruzada, mas a maioria dos desenvolvedores prefere alternativas de código aberto construídas sobre o Apple Thrift, como Hector.
• Outros recursos de disponibilidade. Um dos recursos do Cassandra é a replicação de dados. Basicamente, ele espelha os dados para outros nós do cluster. A replicação pode ser aleatória ou específica para maximizar a proteção de dados, colocando em um nó em um data center diferente, por exemplo. Outro recurso encontrado no Cassandra é a política de particionamento. A política de particionamento decide onde em qual nó colocar a chave. Isso também pode ser aleatório ou em ordem. Ao usar os dois tipos de políticas de particionamento, o Cassandra pode encontrar um equilíbrio entre o balanceamento de carga e a otimização do desempenho da consulta.
• Consistência. Recursos como replicação tornam a consistência um desafio. Isso se deve ao fato de que todos os nós devem estar atualizados a qualquer momento com os valores mais recentes ou no momento em que uma operação de leitura é acionada. Eventualmente, porém, Cassandra tenta manter um equilíbrio entre as ações de replicação e as ações de leitura / gravação, fornecendo essa personalização ao desenvolvedor.
• Ações de leitura / gravação. O cliente envia uma solicitação a um único nó Cassandra. O nó, de acordo com a política de replicação, armazena os dados no cluster. Cada nó primeiro executa a mudança de dados no log de confirmação e, em seguida, atualiza a estrutura da tabela com a mudança, ambas feitas de forma síncrona. A operação de leitura também é muito semelhante, uma solicitação de leitura é enviada para um único nó, e esse único nó é aquele que determina qual nó contém os dados, de acordo com a política de particionamento / posicionamento.

MongoDB

MongoDB é um banco de dados orientado a documentos, sem esquemas, escrito em C ++. O banco de dados é baseado no armazenamento de documentos, o que significa que ele armazena valores (chamados de documentos) na forma de dados codificados.

A escolha do formato codificado no MongoDB é JSON. Isso é poderoso, porque mesmo se os dados estiverem aninhados em documentos JSON, ainda serão questionável e indexável .

As subseções a seguir descrevem alguns dos principais recursos disponíveis no MongoDB.

Fragmentos

Sharding é o particionamento e distribuição de dados em várias máquinas (nós). Um shard é uma coleção de nós do MongoDB, em contraste com o Cassandra, onde os nós são distribuídos simetricamente. O uso de shards também significa a capacidade de escalar horizontalmente em vários nós. No caso de haver um aplicativo usando um único servidor de banco de dados, ele pode ser convertido em cluster fragmentado com muito poucas alterações no código do aplicativo original, porque a fragmentação é feita pelo MongoDB. oftware é quase completamente desacoplado das APIs públicas expostas no lado do cliente.

Mongo Query Language

Conforme discutido anteriormente, o MongoDB usa uma API RESTful. Para recuperar certos documentos de uma coleção de banco de dados, um documento de consulta é criado contendo os campos aos quais os documentos desejados devem corresponder.

Ações

No MongoDB, existe um grupo de servidores chamados roteadores. Cada um atua como servidor para um ou mais clientes. Da mesma forma, o cluster contém um grupo de servidores chamados servidores de configuração. Cada um contém uma cópia dos metadados indicando qual fragmento contém quais dados. As ações de leitura ou gravação são enviadas dos clientes para um dos servidores do roteador no cluster e são roteadas automaticamente por esse servidor para os shards apropriados que contêm os dados com a ajuda dos servidores de configuração.

Semelhante ao Cassandra, um fragmento no MongoDB tem um esquema de replicação de dados, que cria um conjunto de réplicas de cada fragmento que contém exatamente os mesmos dados. Existem dois tipos de esquemas de réplica no MongoDB: replicação mestre-escravo e replicação de conjunto de réplicas. O Replica-Set fornece mais automação e melhor tratamento para falhas, enquanto o Master-Slave às vezes requer a intervenção do administrador. Independentemente do esquema de replicação, em qualquer ponto no tempo em um conjunto de réplicas, apenas um shard atua como o shard primário, todos os outros shards de réplica são shards secundários. Todas as operações de gravação e leitura vão para o shard primário e, em seguida, são distribuídas uniformemente (se necessário) para os outros shards secundários no conjunto.

No gráfico abaixo, vemos a arquitetura MongoDB explicada acima, mostrando os servidores do roteador em verde, os servidores de configuração em azul e os fragmentos que contêm os nós do MongoDB.

Deve-se observar que o sharding (ou compartilhamento de dados entre shards) no MongoDB é completamente automático, o que reduz a taxa de falhas e torna o MongoDB um sistema de gerenciamento de banco de dados altamente escalonável.

o que é c corporation vs s corporation

Estruturas de indexação para bancos de dados NoSQL

A indexação é o processo de associar uma chave à localização de um registro de dados correspondente em um DBMS. Existem muitas estruturas de dados de indexação usadas em bancos de dados NoSQL. As seções a seguir discutirão brevemente alguns dos métodos mais comuns; a saber, indexação B-Tree, indexação T-Tree e indexação O2-Tree.

Indexação B-Tree

B-Tree é uma das estruturas de índice mais comuns em DBMSs.

Nas árvores B, os nós internos podem ter um número variável de nós filhos dentro de algum intervalo predefinido.

Uma grande diferença de outras estruturas de árvore, como AVL, é que a árvore B permite que os nós tenham um número variável de nós filhos, o que significa menos equilíbrio da árvore, mas mais espaço desperdiçado.

OB + -Tree é uma das variantes mais populares de B-Trees. A árvore B + é um aprimoramento da árvore B que requer que todas as chaves residam nas folhas.

Indexação T-Tree

A estrutura de dados do T-Trees foi projetada combinando recursos do AVL-Trees e B-Trees.

As AVL-Trees são um tipo de árvore de busca binária de auto-equilíbrio, enquanto as B-Trees são desequilibradas e cada nó pode ter um número diferente de filhos.

Em uma árvore T, a estrutura é muito semelhante à árvore AVL e à árvore B.

Cada nó armazena mais de uma tupla de {valor-chave, ponteiro}. Além disso, a pesquisa binária é utilizada em combinação com os nós de várias tuplas para produzir melhor armazenamento e desempenho.

Uma T-Tree tem três tipos de nós: Um T-Node que tem um filho direito e esquerdo, um nó folha sem filhos e um nó meia folha com apenas um filho.

Acredita-se que as árvores T têm melhor desempenho geral do que as árvores AVL.

Indexação O2-Tree

A O2-Tree é basicamente uma melhoria em relação às árvores Red-Black, uma forma de árvore de busca binária, na qual os nós folha contêm as tuplas de {valor-chave, ponteiro}.

O2-Tree foi proposto para melhorar o desempenho dos métodos de indexação atuais. Uma árvore O2 de ordem m (m ≥ 2), onde m é o grau mínimo da árvore, satisfaz as seguintes propriedades:

• Cada nó é vermelho ou preto. A raiz é preta.
• Cada nó folha é colorido em preto e consiste em um bloco ou página que contém pares de “valor-chave, ponteiro de registro”.
• Se um nó for vermelho, seus dois filhos serão pretos.
• Para cada nó interno, todos os caminhos simples do nó para os nós-folha descendentes contêm o mesmo número de nós pretos. Cada nó interno contém um único valor de chave.
• Os nós-folha são blocos que têm entre ⌈m / 2⌉ e m pares de “valor-chave, ponteiro de registro”.
• Se uma árvore tem um único nó, então deve ser uma folha, que é a raiz da árvore, e pode ter entre 1 e m itens de dados principais.
• Os nós de folha são duplamente vinculados nas direções para frente e para trás.

Aqui, vemos uma comparação direta de desempenho entre O2-Tree, T-Tree, B + -Tree, AVL-Tree e Red-Black Tree:

tamanho da tela de consulta de mídia css

A ordem da Árvore-T, Árvore-B + e Árvore-O2 usada foi m = 512.

O tempo é registrado para operações de pesquisa, inserção e exclusão com taxas de atualização variando entre 0% -100% para um índice de 50 milhões de registros, com as operações resultando na adição de outros 50 milhões de registros ao índice.

É claro que com uma taxa de atualização de 0-10%, B-Tree e T-Tree têm um desempenho melhor do que O2-Tree. No entanto, com o aumento da taxa de atualização, o índice O2-Tree tem um desempenho significativamente melhor do que a maioria das outras estruturas de dados, com as estruturas B-Tree e Red-Black Tree sofrendo mais.

O caso para NoSQL?

Uma introdução rápida aos bancos de dados NoSQL, destacando as principais áreas onde os bancos de dados relacionais tradicionais falham, leva ao primeiro ponto:

Embora os bancos de dados relacionais ofereçam consistência, eles não são otimizados para alto desempenho em aplicativos onde dados massivos são armazenados e processados ​​com frequência.

Os bancos de dados NoSQL ganharam muita popularidade devido ao alto desempenho, alta escalabilidade e facilidade de acesso; no entanto, eles ainda carecem de recursos que fornecem consistência e confiabilidade.

Felizmente, vários SGBDs NoSQL abordam esses desafios, oferecendo novos recursos para aprimorar a escalabilidade e a confiabilidade.

Nem todos os sistemas de banco de dados NoSQL têm melhor desempenho do que os bancos de dados relacionais.

MongoDB e Cassandra têm desempenho semelhante e, na maioria dos casos, melhor do que bancos de dados relacionais em operações de gravação e exclusão.

Não há correlação direta entre o tipo de loja e o desempenho de um DBMS NoSQL. As implementações NoSQL passam por mudanças, então o desempenho pode variar.

Portanto, as medições de desempenho entre os tipos de banco de dados em diferentes estudos devem sempre ser atualizado com as versões mais recentes do software de banco de dados para que esses números sejam precisos.

Embora eu não possa oferecer um veredicto definitivo sobre o desempenho, aqui estão alguns pontos a serem considerados:

• A indexação tradicional B-Tree e T-Tree é comumente usada em bancos de dados tradicionais.
• Um estudo ofereceu melhorias e aprimoramentos ao combinar as características de múltiplas estruturas de indexação para criar o O2-Tree.
• O O2-Tree superou outras estruturas na maioria dos testes, especialmente com grandes conjuntos de dados e altas taxas de atualização.
• A estrutura B-Tree apresentou o pior desempenho de todas as estruturas de indexação abordadas neste artigo.

Um trabalho adicional pode e deve ser feito para aprimorar a consistência dos DBMSs NoSQL. A integração de ambos os sistemas, NoSQL e bancos de dados relacionais, é uma área a ser explorada posteriormente.

Finalmente, é importante observar que NoSQL é uma boa adição aos padrões de banco de dados existentes, mas com algumas ressalvas importantes. O NoSQL troca recursos de confiabilidade e consistência por desempenho e escalabilidade absolutos. Isso o torna uma solução especializada, pois o número de aplicativos que podem contar com bancos de dados NoSQL permanece limitado.

O lado de cima? A especialização pode não oferecer muita flexibilidade, mas quando você deseja realizar um trabalho especializado da maneira mais rápida e eficiente possível, não precisa de um canivete suíço. Você precisa do NoSQL.

Relacionado: Plataforma de Business Intelligence: tutorial usando o MongoDB Aggregation Pipeline