# NoSQL

NoSQL (originalmente se referindo a "no SQL": "não SQL" ou "não relacional", posteriormente estendido para Not Only SQL - Não Somente SQL) é um termo genérico que representa os bancos de dados não relacionais. Uma classe definida de banco de dados que fornecem um mecanismo para armazenamento e recuperação de dados que são modelados de formas diferentes das relações tabulares usadas nos bancos de dados relacionais.
Tais bancos de dados existem desde o final da década de 1960, mas não obtiveram o apelido de "NoSQL" até atingirem sua onda de popularidade no início do século XXI, desencadeada pelas necessidades das empresas de Web 2.0 como Facebook, Google e Amazon.com. Bancos de dados NoSQL são cada vez mais usados em big data e aplicações web de tempo real. Sistemas NoSQL, às vezes, também são chamados de "Not only SQL" ("Não apenas SQL") para enfatizar que eles podem suportar linguagens de consulta semelhantes à SQL. Também são classificados como sendo Banco de dados orientado a documentos.

## Motivações

Motivações para esta abordagem incluem: simplicidade de projeto, escalonamento "horizontal" mais simples para clusters de máquinas (o que é um problema para bancos de dados relacionais) e controle mais refinado sobre a disponibilidade. As estruturas de dados usadas pelos bancos de dados NoSQL (e.g., chave-valor, coluna larga, grafo ou documento) são diferentes daquelas usadas por padrão em bancos de dados relacionais, tornando algumas operações mais rápidas em NoSQL. A adequação particular de um determinado banco de dados NoSQL depende do problema que ele deve resolver. Algumas vezes as estruturas de dados usadas por bancos de dados NoSQL também são vistas como "mais flexíveis" que tabelas de bancos de dados relacionais.
Muitos armazenamentos NoSQL comprometem a consistência (no sentido do teorema CAP) em favor da disponibilidade, tolerância a partição e velocidade. Barreiras para a grande adoção de armazenamentos NoSQL incluem o uso de linguagens de consulta de baixo nível (em vez de SQL, por exemplo, a falta de capacidade de realizar junções ad-hoc entre tabelas), falta de interfaces padronizadas e grandes investimentos anteriores em bancos de dados relacionais existentes. A maioria dos armazenamentos NoSQL carece de transações ACID verdadeiras, embora alguns bancos de dados, como MarkLogic, Aerospike, FairCom c-treeACE, Google Spanner (embora tecnicamente um banco de dados NewSQL), Symas LMDB e OrientDB tornaram-as centrais em seus projetos.
Em vez disso, a maioria dos bancos de dados NoSQL oferece um conceito de consistência posterior (do inglês eventual consistency) em que as alterações do banco de dados são propagadas para todos os nós "posteriormente" (geralmente em milissegundos), de forma que as consultas de dados podem não retornar dados atualizados imediatamente ou podem resultar na leitura de dados não precisa, um problema conhecido como leitura obsoleta. Além disso, alguns sistemas NoSQL podem exibir gravações perdidas e outras formas de perda de dados. Alguns sistemas NoSQL fornecem conceitos como o write-ahead logging para evitar a perda de dados. Para o processamento de transações distribuídas em vários bancos de dados, a consistência de dados é um desafio ainda maior que é difícil tanto para bancos de dados relacionais quanto NoSQL. Até mesmo os bancos de dados relacionais atuais "não permitem restrições de integridade referencial para abranger os bancos de dados." Há poucos sistemas que mantêm transações ACID e padrões X/Open XA para processamento de transações distribuídas.

## História

O termo NoSQL foi primeiramente utilizado em 1998 como o nome de um banco de dados relacional de código aberto que não possuía uma interface SQL. Seu autor, Carlo Strozzi, alega que o movimento NoSQL "é completamente distinto do modelo relacional e portanto deveria ser mais apropriadamente chamado "NoREL" ou algo que produzisse o mesmo efeito".
O termo NoSQL foi reintroduzido no início de 2009 por um funcionário do Rackspace, Eric Evans, quando Johan Oskarsson da Last.fm queria organizar um evento para discutir bancos de dados open source distribuídos. O nome — uma tentativa de descrever o surgimento de um número crescente de banco de dados não relacionais, que não tinham a preocupação de fornecer garantias ACID — faz referência ao esquema de atribuição de nomes dos bancos de dados relacionais mais populares do mercado: MySQL, MS SQL, PostgreSQL etc.
Outros termos equivalentes para esta categoria de bancos é NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-form, schemaless e document database.
Os bancos de dados que estão sob estes rótulos não podem exigir esquemas de tabela fixa e, geralmente, não suportam instruções e operações de junção SQL.
Tendências em arquiteturas de computadores, como a computação na nuvem e a necessidade crescente de prover serviços escaláveis, estão pressionando bancos de dados numa direção onde eles necessitam oferecer escalabilidade horizontal. Bancos de dados NoSQL armazenam os dados com técnicas que visam atender a esse requisito. Há alguns exemplos proeminentes de softwares de código fechado que atendem estes requisitos, sendo alguns deles o BigTable, do Google, IBM Cloudant e o DynamoDB, da Amazon. E alguns exemplos de software open-source como Apache Cassandra (originalmente desenvolvido para o Facebook), Apache HBase, LinkedIn's e vários outros.
É importante entender que o intuito não é eliminar bancos de dados relacionais, mas oferecer uma alternativa. Pois, durante muito tempo o modelo relacional foi usado como "bala de prata" para todos os problemas de persistência.

## Arquitetura

Modernas bases de dados relacionais parecem ter uma limitação a transações com grandes volumes de dados e cargas de trabalhos típicas de operações modernas de grande carga, incluindo o dimensionamento de conjuntos de dados. Sistemas NoSQL frequentemente fornecem garantias de consistência fraca, como consistência posterior e operações restritas a itens individuais de dados, apesar de que uma faixa possa impor garantias ACID, adicionando uma camada de middleware complementares.
Alguns defensores do NoSQL promovem interfaces muito simples, como arrays associativos ou pares chave-valor (Key-Value pairs). Outros sistemas como bancos de dados XML nativos provem o apoio ao padrão XQuery.

## Bancos de dados NoSQL

Atualmente há várias abordagens para se classificar bancos de dados NoSQL, cada uma com categorias e subcategorias diferentes, sendo que algumas delas se sobrepõem. A seguir há uma classificação básica por modelo de dados, com exemplos:
* Coluna: Accumulo, Cassandra, Druid, HBase, Vertica
* Documento: Apache CouchDB, Elasticsearch, ArangoDB, BaseX, Clusterpoint, Couchbase, Cosmos DB, IBM Dominio, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB
* Chave-valor: Aerospike, Apache Ignite, ArangoDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, InfinityDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB, SDBM/Flat File dbm, ZooKeeper
* Grafo: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso
* Multi-modelo: Apache Ignite, ArangoDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDB
Uma classificação mais detalhada é a seguinte, baseada em uma de Stephen Yen:
| Tipo | Exemplos notáveis deste tipo |
| Cache de Chave-Valor | Apache Ignite, Coherence, eXtreme Scale, Hazelcast, Infinispan, Memcached, Velocity |
| Armazenamento Chave-Valor | ArangoDB, Aerospike |
| Armazenamento Chave-Valor (Posteriormente-Consistente) | Oracle NoSQL Database, Dynamo, Riak, Voldemort |
| Armazenamento Chave-Valor (Ordenado) | FoundationDB, InfinityDB, LMDB, MemcacheDB |
| Servidor de Estruturas de Dados | Redis |
| Armazenamento de Tuplas | Apache River, GigaSpaces |
| Banco de dados de Objeto | Objectivity/DB, Perst, ZopeDB |
| Armazenamento de Documentos | ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB, Cloud Firestore |
| Armazenamento de coluna ampla | Amazon DynamoDB, Bigtable, Cassandra, Druid, HBase, Hypertable |
Bancos de dados correlacionais são independentes de modelo e, em vez de armazenamento baseado em linha ou coluna, usam armazenamento baseado em valor.

### Armazenamento de documento

O conceito central de um armazenamento de documento está na noção de um "documento". Apesar de cada implementação de banco de dados orientado a documentos diferir-se nos detalhes desta definição, em geral, todas elas admitem que os documentos encapsulam e codificam dados (ou informação) em alguns formatos ou codificações padrões. Codificações em uso incluem XML, YAML e JSON bem como formas binárias como BSON. Documentos são endereçados no banco de dados por meio de uma chave única que representa aquele documento. Uma das outras características de definição de um banco de dados orientado a documentos é que além da consulta de chave realizada por uma armazenamento chave-valor, o banco de dados também oferece uma API ou linguagem de consulta que recupera os documentos baseado em seus conteúdos.
Implementações diferentes oferecem modos diferentes de organizar e/ou agrupar documentos:
* Coleções
* Etiquetas (tags)
* Metadados não-visíveis
* Hierarquias de diretório
Comparados com bancos de dados relacionais, por exemplo, coleções podem ser consideradas análogas a tabelas e documentos análogos a registros. Porem eles são diferentes: cada registro em uma tabela possui a mesma sequência de campos, enquanto que documentos em uma coleção podem ter campos que são completamente diferentes.