O documento discute NoSQL, comparando propriedades ACID e BASE e o teorema CAP. Apresenta vários modelos NoSQL como chave-valor, orientado a colunas, documentos e grafos. Explica como sistemas NoSQL priorizam disponibilidade sobre consistência de acordo com o teorema CAP.

1. NoSQL
BASE vs ACID
Teorema CAP
Nome: Aricelio de Souza Fernandes
Curso: TADS
Turma: 3º Periodo

2. O que é ?
Quando surgiu?
Qual seu objetivo?

3. É uma denominação para bancos de dados
não-relacionais.
Isso não quer dizer que seus modelos não
possuem relacionamentos.
E sim, que não são orientados a tabelas.
Not Only SQL. (Não Apenas SQL)

4. O termo foi usado pela primeira vez em 1998
para um banco de dados relacional que omitiu
o uso de SQL.
O termo foi usado novamente em 2009 e usado
para conferências de defensores de bancos de
dados não-relacionais

5. Atender as necessidades das aplicações, que
necessitam de alta disponibilidade dos seus
dados e rápido desempenho do
processamento dos mesmos.
Exemplo: A google consegue processar até 20
petabytes de dados por dia armazenadas em
BigTable.

6. Escalabilidade Horizontal.
Ausência de Esquema ou Esquema Flexível.
Suporte a Replicação.
API Simples.
Nem Sempre é Consistente.

7.  A escalabilidade Horizontal consiste em aumentar o
número de máquinas disponíveis.
 A escalabilidade Horizontal em modelos relacionais
seria inviável devido a concorrência.
 Como nos modelos NoSQL não existe bloqueios, esse
tipo de escalabilidade é a mais viável.

8. Apresentam ausência de Esquema ou esquema
flexível, isso permite uma fácil aplicação da
escalabilidade e também um aumento na
disponibilidade dos dados.
Mas também devido a essa ausência, não há
garantia da integridade dos dados.

9. Permitem a replicação de uma forma nativa o
que provém uma escalabilidade maior e
também uma diminuição do tempo gasto para
a recuperação de informações.

10. Para que o acesso ás informações seja feito da
forma mais rápida possível, APIs são
desenvolvidos para que qualquer aplicação
possa ter acesso aos dados do banco de
dados.

11. Os bancos de dados NoSQL nem sempre
conseguem se manter consistentes

12. Map/Reduce.
Consistent Hashing.
Multiversion Concurrency Control.
Vector Clocks.

13. Map: O nó principal recebe os dados, divide
em partes menores e as envia aos outros nós
para serem processados. Ao final do
processamento estes nós devolvem o resultado
ao nó principal.
Reduce: O nó principal combina as respostas
obtidas pelos outros nós gerando o resultado
final do processamento.

14. Essa funcionalidade tem a função de suportar o
mecanismos de armazenamento e
recuperação em bancos de dados distribuídos.

15. O MVCC dá suporte a transações paralelas em
um banco de dados. Por não utilizar bloqueios
ele permite que operações de leitura e escrita
sejam efetuadas simultaneamente, diferente do
esquema clássico de gerenciamento de
transações.

16. Determina qual versão de um dado distribuído
é a mais atual. Devido há muitas operações
que possam ocorrer com esse dado.

17. Banco de dados chave-valor (key-value).
Banco de dados Orientado a Colunas.
Banco de dados Orientado a Documentos.
Banco de dados Orientado a Grafos.

18. Modelo mais simples.
Permite a visualização do banco
como uma grande tabela.
Todo o banco é composto por
um conjunto de chaves que estão
associadas a um único valor.

20. Um pouco mais complexos.
Os dados são indexados por uma tripla (linha,
coluna e timestramp).
As linhas e as colunas são identificadas por
chaves e o timestramp é o que permite
identificar as diferentes versões de um mesmo
dado.

21. Características:
• Permiti Particionamento.
• Forte Consistência.
• Não garante alta disponibilidade.

22. Armazena uma coleção de documentos.
Um documento no geral, é um objeto com um
código único e um conjunto de campos, que
podem ser strings, listas ou documentos
aninhados.
Sua estrutura se assemelha com de chave-valor.

23. Não depende de um esquema rígido, ou seja,
não há exigência de uma estrutura fixa.
Dentre os bancos de dados que utilizam esse
modelo podemos citar o CouchDB e o MongoDB.

24. Neste modelo, o banco pode ser comparado
com um multigrafo rotulado e direcionado, onde
cada nó pode ser conectado por mais de uma
aresta.
Possui três componentes básicos: os nós (são os
vértices do grafo), os relacionamentos (são as
arestas) e as propriedades (ou atributos) dos nós e
relacionamentos.

26. Propriedades ACID:
Atomicidade: A transação será executada totalmente
ou não será executada.
Consistência: Garante que o banco de dados passará
de uma forma consistente para outra forma consistente.
Isolamento: Garante que a transação não será
interferida por nenhuma outra transação concorrente.
Durabilidade: Garante que o que foi salvo, não será mais
perdido.

27. Propriedades BASE:
Basically Available – Basicamente Disponível.
Soft-State – Estado Leve
Eventually Consistent – Eventualmente Consistente.
Uma aplicação funciona basicamente todo o tempo
(Basicamente Disponível), não tem de ser consistente
todo o tempo (Estado Leve) e o sistema torna-se
consistente no momento devido (Eventualmente
Consistente).

28. ACID BASE
Consistência forte Fraca consistência
Isolamento Foco em Disponibilidade
Concentra-se em "commit" Melhor esforço
Transações aninhadas Respostas aproximadas
Disponibilidade Mais simples e mais rápido
Conservador (pessimista) Agressivo (otimista)
Evolução difícil (por exemplo, esquema) Evolução mais fácil

29. Definição
• Consistência – Consistency.
• Disponibilidade – Availability.
• Tolerância ao Particionamento - Partition tolerance.

30. Significa se um sistema esta consistente, após a
execução de uma operação. Por exemplo um
sistema é considerado consistente se depois da
atualização de um dado, todos os usuários que
tem acesso a esse dado, possam acessá-lo em
tempo real.

31. Refere-se á concepção e implementação de
um sistema de modo que seja assegurado que
esse permanece ativo durante um determinado
período de tempo.

32. Refere-se a capacidade de um sistema
continuar operando mesmo depois uma falha
na rede.

33. Consistência
Tolerância ao
Particionamento
Disponibilidade

35. • Os sistemas com consistência
forte e alta disponibilidade não
sabem lidar com a possível falha
de uma partição.
• Caso ocorra, sistema inteiro
pode ficar indisponível até o
membro do cluster voltar.

36. Consistência
Tolerância ao
Particionamento
Disponibilidade

37. • Para sistemas que precisam da
consistência forte e tolerância a
particionamento é necessário
abrir a mão da disponibilidade
(um pouco).
• Exemplos são BigTable, HBase ou
MongoDB entre vários outros.

38. Consistência
Tolerância ao
Particionamento
Disponibilidade

39. Há sistemas que jamais podem ficar
offline, portanto não desejam
sacrificar a disponibilidade. Para ter
alta disponibilidade mesmo com um
tolerância a particionamento é
preciso prejudicar a consistência.
Exemplos de Bancos são: Cassandra,
MongoB, Voldemort.

40. Consistência
Tolerância ao
Particionamento
Disponibilidade

42. Indicado para aplicações que irão trabalhar
com enormes quantidades de dados, que tem
exigências de velocidade em suas consultas e
escritas em grande volumes de dados.

43. MongoDB
CouchDB
Cassandra
Project Valdemort (by Linkedin)
Redis (by Google)
HBase (by Apache)
Dynamo (by Amazon)
dentre muitos outros…

44.  Google - Bigtable.
 Amazon - Dynamo.
 Yahoo - Hadoop.
 Facebook - Cassandra.
 Digg - Cassandra.
 Twitter - Cassandra.
 IBM - Cassandra.
 Netflix - Cassandra.
 LinkedIn - Voldemort.
 Engine Yard - MongoDB.

45. MySQL Cluster é um gravador-escalável, em
tempo real, projetado para oferecer 99,999% de
disponibilidade. Com uma arquitetura multi-
master distribuída e nenhum ponto de falha, o
MySQL Cluster escala horizontalmente em
hardware com auto-particionamento para
servir a ler e escrever cargas de trabalho
intensivas, acessado via SQL e interface NoSQL.
Prove alta disponibilidade e alto desempenho,
com escalabilidade horizontal.

47.  1. Download
link: http://dev.mysql.com/downloads/cluster/
 2. Instalação.
Localizar o arquivo, extrai-lo e criar um link para o mesmo.
 3. Configuração.
Criar a pasta que irá armazenar os arquivos de configuração.
My.cnf e Config.ini
 4. Execução.
Iniciar o processo do nó de gerenciamento, nó de dados e por último o mysql.
 5. Teste.
Criar uma tabela no nó de gerenciamento e inserir dados no mesmo.

48.  Principais focos do NoSQL:
 Desempenho das aplicações mediante a uma enorme quantidade de
dados.
 Escalabilidade horizontal.
 Fácil implantação e uso dos bancos de dados NoSQL.
 O NoSQL não veio para substituir o modelo relacional, mas sim tentar suprir
as novas necessidades das aplicações tem hoje.
 Fazendo então assim que possa gerenciar os seus dados de uma forma
mais eficiente.