Se NoSQL significa "Not only SQL", SQL é um subconjunto de NoSQL?

TL;DR

A principal distinção entre sistemas de banco de dados não é a linguagem usada para consultar o banco de dados, mas sim o modelo de consistência do sistema. O diagrama de Venn deve ser dois conjuntos de interseção - SQL não é um subconjunto adequado de NoSQL, mas sim sua própria linguagem de acesso a dados que pode ou não ser complementada por outras técnicas. SQL seria um subconjunto adequado de linguagens de consulta de banco de dados.

Há NoSQL, OldSQL e NewSQL.

NoSQL costumava significar "Não SQL", mas agora é (mais) provável que signifique "Não apenas SQL" - já que muitos dos provedores de sistemas NoSQL estão (tentando) aparafusar/enxertar interfaces SQL sobre seu valor-chave (KV ), armazenamentos de documentos ou gráficos.

Os sistemas OldSQL são essencialmente as principais ofertas dos provedores de RDBMS (Oracle, SQL Server, Sybase, PostgreSQL, MySQL...). Na página 13 desta apresentação (.pdf), Michael Stonebraker pretende mostrar que o OldSQL gasta apenas 4% do tempo fazendo trabalho "útil" - também pode ser encontrado aqui :

Sua alegação é que deve-se dividir o trabalho OLTP e OLAP entre diferentes sistemas - OLTP deve ser feito por arquiteturas compartilhadas nada compartilhadas como, surpresa, surpresa, seu próprio sistema, VoltDB e que OLAP deve ser feito por armazenamento colunar (também, veja aqui ) arquiteturas de tipo (como Vertica , na qual ele também teve um papel). Vale ressaltar que a Stonebraker, além de fazer muito sucesso no meio comercial também é grande no meio acadêmico e ganhou um prêmio Turing - o "Prêmio Nobel" da Ciência da Computação!

NewSQL é (IMHO) o mais interessante dos sistemas a surgir (figurativamente falando) como o Phoenix renascido das cinzas do OldSQL. Sua USP é que eles são sistemas HTAP (Hybid Transactional and Analytical Processing).

São sistemas distribuídos que podem suportar consultas OLAP e OLTP simultaneamente devido aos dados estarem espalhados por vários nós - que podem estar no mesmo rack, data center ou continente e/ou serem distribuídos globalmente entre e entre provedores de nuvem para aumentar resiliência e redundância - espere adicionar ~ um '0' ao custo para cada '9' fracionário que você adicionar à sua provisão de tempo de atividade .

Eles usam um algoritmo de consenso (geralmente Raft ou Paxos ) para coordenar os dados dos nós e o sharding é transparente - até mesmo para os DBAs dos sistemas. Os três exemplos de tais sistemas seriam CockroachDB , TiDB e YugaByte .

É interessante notar que, embora tenham um certo nível de sucesso, esses sistemas não são (ainda?) nomes conhecidos. Os "meninos grandes" estão revidando com lojas colunares e ofertas de KV aparafusadas/enxertadas em seus próprios sistemas. De particular interesse neste debate é que esses próprios sistemas ficam "em cima" de uma loja KV (geralmente RocksDB - embora o CockroachDB esteja desenvolvendo seu próprio em Go chamado Pebble ). O PostgreSQL também possui documentos (JSONB) e um repositório KV .

Para responder à pergunta, a verdadeira característica distintiva entre os sistemas não é a interface que se usa para consultar os dados (que pode e varia de programação direta em linguagem C (imperativa) a SQL (declarativa) - e seus sabores/adaptações), mas sim o modelo de consistência da transação.

Esses modelos são ACID (consistente) versus BASE (disponível) e a chave é onde esses sistemas se encaixam em relação ao teorema CAP. Além disso, os armazenamentos KV podem suportar algumas ou todas as características de transação ACID.

OldSQL e NewSQL valorizam a consistência acima de tudo ('CP' sob o sistema CAP) - o argumento deles é que, por exemplo, um sistema bancário com resultados inconsistentes é uma receita para o desastre (verdade!).

No entanto, os aficionados do NoSQL sugerem que nem todos os sistemas exigem consistência de ferro fundido. Por exemplo, encomendar um livro da Amazon (digamos) usando um banco de dados BASE ('AP' em termos CAP) - pode (nível de estoque incorreto mostrado) atrasar alguns dias ou até mesmo ser cancelado - mas a vantagem são consultas mais rápidas e operação mais fácil (sem consenso para manter).

Este é o cerne da distinção entre sistemas de banco de dados - 'CP' ou 'AP'! O CP sempre lhe dará a resposta correta (a maioria dos nós ainda está disponível) ou nenhuma resposta, enquanto os sistemas AP normalmente responderão (mesmo que apenas um nó esteja ativo), mas sua resposta pode não ter levado em consideração as atualizações de dados de outros nós quando respondendo (ou seja, links de rede entre eles para baixo...).

Espero que este seja um "primeiro passo" satisfatório em uma resposta - é um tópico grande e, para nerds de banco de dados, absolutamente fascinante. Eu recomendo que você leia sobre isso (Wiki é um bom começo, mas não substitui as fontes primárias). Em particular, eu o aconselharia a examinar detalhadamente as arquiteturas subjacentes do CockroachDB e do TiDB e ver como eles fragmentam e movem dados de um nó para outro, mantendo a consistência.

Existem listas abrangentes de vários sistemas NoSQL aqui e aqui (melhor IMHO). Há também um site de classificação de popularidade aqui (mas evite as comparações - eles apenas repetem a sinopse dos sites dos sistemas - geralmente desatualizados).

Palavra final, existem bancos de dados de "modelo misto" (ou multimodelo) ( ArangoDB e OrientDB - ambos têm versões F/LOSS e Enterprise - OrientDB agora faz parte do SAP), mas há uma razão pela qual eles não são nomes familiares. O ArangoDB não suporta ANSI SQL, mas sim seu próprio sabor - AQL e nem o OrientDB suporta ISO SQL.

O melhor banco de dados multimodelo com o qual trabalhei é o PostgreSQL, que possui KV e armazenamento de documentos, conforme mencionado acima. Você pode usar o SQL para consultá-los e juntar-se a tabelas "comuns". O trabalho está em andamento para adicionar o OpenCypher - um padrão de linguagem de consulta gráfica aberta - a ele (veja aqui e aqui ).

Palavra final: o PostgreSQL também tem uma extensão Columnar Store e uma extensão Time Series - ambas são (sub)-classes muito importantes do sistema de banco de dados. Ambas as extensões são apenas isso, extensões e não bifurcações - você pode usar SQL "normal" (ou seja, toda a gama de SQL compatível com os padrões do PostgreSQL) com essas extensões.

Assim, podemos ver que, embora o NoSQL seja, em alguns casos, mas não todos (muitos designers de sistemas ficam felizes em permanecer como simples armazenamentos de KV, por exemplo), adicionando recursos de SQL, o SQL está reagindo, adotando e se adaptando a novos e/ou requisitos de armazenamento e recuperação de dados mais sofisticados - alguns dos quais eu nem toquei ( sistemas GIS ...). Então, dizer que o NoSQL abrange totalmente o SQL seria uma imagem incompleta ...

Como apontado nos comentários da própria pergunta, o padrão SQL agora aborda paradigmas não relacionais e isso só aumentará no futuro! Também abordado por outras respostas - vale a pena ler ( 1 e 2 )!

NoSQL foi, é e sempre será uma palavra da moda vaga, não um termo bem definido.

Sua origem está relacionada a uma tendência histórica: no início deste século, se você dissesse "banco de dados", a suposição seria que você estivesse falando de um banco de dados relacional baseado em SQL, e "escolher um banco de dados" significava apenas escolher qual implementação dessa tecnologia que você estava usando. Como parte dos movimentos de tecnologia "Web 2.0" e "nuvem", as pessoas começaram a desafiar essa suposição e trabalhar com sistemas de banco de dados completamente diferentes - sistemas que, incomum para a época, apresentavam "sem SQL". A Wikipedia sugere que o primeiro uso de "NoSQL" para se referir a eles foi em 2009.

O termo inicialmente se referia principalmente a bancos de dados baseados em documentos e valores-chave, porque era nisso que muitas pessoas estavam trabalhando na época; era uma ferramenta útil em um campo em rápida evolução. À medida que mais ideias foram exploradas, o termo se tornou mais confuso do que útil - alguns dos bancos de dados que ele abrange não têm nada em comum além de não serem relacionais ao SQL. Pior ainda, alguns bancos de dados não relacionais começaram a adicionar linguagens de consulta SQL ou semelhantes a SQL; e alguns bancos de dados relacionais começaram a adicionar recursos que permitem usá-los de maneiras não relacionais híbridas.

Retro-ajustar o "não" para significar "não apenas" é uma maneira fofa de fazer o termo fazer sentido novamente, mas a melhor ideia é provavelmente não usá-lo. Seu único valor é um lembrete de que "banco de dados" não precisa significar "banco de dados relacional baseado em SQL"; usar outros termos como "armazenamento de dados" pode servir ao mesmo propósito sem centrar tudo na questão mais irrelevante de como as coisas se relacionam com o SQL.

SQL é uma linguagem. NoSQL é uma abordagem para escolher sistemas de banco de dados. Não faz sentido compará-los.

A origem de "Not Only SQL" está no fato de que não muito tempo atrás, quando você tinha alguns dados para armazenar, a única pergunta era "Oracle ou Microsoft?" Ninguém nunca pensou se um SQL RDBMS seria ou não a melhor solução para armazenar esses dados. Usar algo diferente do Oracle ou SQL Server era simplesmente impensável .

A ideia por trás de "Not Only SQL" é exatamente o que diz: ao escolher como armazenar seus dados, você considera não apenas o SQL, mas também outras possibilidades. A ideia é que você analise seus dados e escolha a solução de armazenamento que melhor se adapta aos dados. Se seus dados são em forma de objeto, você usa um armazenamento de objetos, se seus dados são em forma de documento, você usa um armazenamento de documentos, se seus dados são em forma de XML, você usa um armazenamento XML, se seus dados são um gráfico, você use um banco de dados gráfico, se seus dados são em forma de árvore, você usa um banco de dados de árvore, se seus dados se parecem com uma estrutura plana de valor-chave, você usa um armazenamento de valor-chave, se você deseja armazenar dados de série temporal, você usa um banco de dados de série temporal, … e se seus dados são dados relacionais em forma de tabela retangular, então use um RDBMS.

Mesmo que seus dados sejam relacionais, o SQL ainda não é a única opção. Existem bancos de dados relacionais não SQL, bancos de dados hiper-relacionais, bancos de dados relacionais pós-SQL (por exemplo, Rel), existem coisas como NF² e assim por diante. Todos esses são relacionais, mas nenhum deles é SQL.

Existe um mito de que bancos de dados NoSQL não suportam consistência ou não suportam transações. Isso esta errado. Em primeiro lugar, não existe um "banco de dados NoSQL". NoSQL não é uma tecnologia de banco de dados, é uma abordagem para escolher um banco de dados. Mas mesmo se olharmos para os bancos de dados que são normalmente chamados de "bancos de dados NoSQL", vemos que na verdade existem diferentes com muitas abordagens diferentes para consistência e transações. Por exemplo, Datomic oferece garantias e transações ACID do tipo SQL. Há alguns que oferecem garantias ainda maiores do que o SQL. E há aqueles que oferecem garantias relaxadas em comparação com o SQL.

Alguns oferecem garantias flexíveis e configuráveis, que permitem escolher entre desempenho e garantias em várias dimensões. Às vezes, até mesmo escolhas diferentes para dados diferentes.

Então, na verdade , a ideia por trás do NoSQL é simplesmente que você analise seus requisitos e escolha a solução que melhor se adapta aos seus requisitos. Isso é tudo o que há para isso.

E realmente, isso até agora está falando apenas sobre como os dados são armazenados . Como os dados são consultados é realmente outra questão. É perfeitamente possível consultar muitos bancos de dados "não-SQL" com SQL. As características de desempenho podem ser diferentes, mas a funcionalidade não será. Da mesma forma, você pode consultar bancos de dados "SQL tradicional" com idiomas diferentes do SQL. Na verdade, em muitos sistemas modernos, não há muito SQL. Eles podem estar usando LINQ, por exemplo, ou um ORM. Ruby, Python, Perl, ECMAScript, muitas outras linguagens de programação têm DSLs internas e externas para consultas de banco de dados, por exemplo ARel em Ruby.

ESQUEMA AGORA OU ESQUEMA DEPOIS

NoSQL, imho, é um nome impróprio.

NoSQL é um repositório de dados schema-on-read. O oposto é RDBMS, que é o esquema primeiro. O RDBMS coloca o ônus no designer de criar uma estrutura de dados eficiente e reduz a carga do analista, que tem um esquema definido e restrições para garantir a integridade dos dados. O NoSQL, por outro lado, requer um design mínimo inicial. Isso sobrecarrega o analista de dados, que deve lidar com a flexibilidade da estrutura de dados impondo sua própria estrutura e verificações nos dados.

O próprio SQL é uma linguagem. SQL pode ser usado para consultar repositórios NoSQL assim como é usado para consultar RDBMS.