3. Limitações
• Evolução de Sistemas -> Volume de Dados
• Google – Petabytes – 10 bytes
• Upgrade
• Servidores
15
4. NoSQL - Not Only SQL
• Propósito
• Solução – Gerenciamento de Arquivos em grande massa.
• Performance
• Surgimento 1998
• Sem Interface SQL
• Livre – Flexível
• MRNN – Modelo Relacional não Normalizado
• Histórico de Implementações
• 2004 – Google – BigTable
• 2007 – Amazon – sistema Dynamo
• 2008 – Facebook – Cassandra
• 2009 CouchDB / Mongo DB
• 2010 - Twitter - MySQL to Cassandra
5. Tipos
• Chave-valor
Vantagem - o modelo chave-valor “favorece alta escalabilidade ao invés da
consistência
Desvantagem - omite recursos ricos para consultas (especialmente operações de
joins e agregação são postas de lado)
6. Tipos
• Orientado a documento
• Vantagem - permite que novos campos sejam adicionados a um
documento sem que isso cause algum problema na base de dados.
• Consulta direta
• Desvantagem - não possuem esquema, ou seja, os documentos
armazenados não precisam possuir estrutura em comum”.
• Duplicidade dos dados.
• Exemplo: tendo como contexto uma estrutura que mantenha a
relação de Pessoa com Cargo e fosse criada uma consulta para
recuperar o cargo da pessoa “A”, no modelo orientado a documentos
bastaria recuperar o documento da “A”. Por que? Conteria o
documento de seu cargo, já no modelo relacional seria necessário
realizar um join entre a tabela Pessoa e Cargo, o que tem um custo
de desempenho para execução, melhor percebido em consultas
mais complexas.
7. Tipos
• Orientado a grafo
• Vantagem – O fato de “não existir tanta replicação de dados
como nos outros modelos, fato que acontece por se
aproveitar do relacionamento entre os registros”
• Exemplo: Se houver dois documentos, um representando a
pessoa “A” e outra representando a pessoa “B” e ambos
conhecem a pessoa “C”, tanto o documento “A” quanto “B”
teriam que guardar uma instância da pessoa “C”. No caso dos
grafos, isso é resolvido apenas utilizando ligações com arestas
que armazenam um valor que indica que a pessoa
• conhece “C”;
8. Tipos
• Orientado a colunas
• O exemplo da Figura abaixo que modela o conceito de
amigos, onde primeiroNome e sobrenome são colunas
pertencentes à família de colunas denominada nome. De
maneira semelhante, as colunas endereço, cidade e estado
pertencem à família local. Observe que para a linha 001, o
amigo Hélio tem diferentes endereços, onde para cada um
deles tem um timestamp correspondente. Como já foi dito, o
acesso à linha é atômico, ou seja, mesmo 7 coluna sobrenome
da linha 001, todas as colunas são retornadas quando esta
linha for consultada.
9. SGBDs X NoSQL
• Escalonamento
• Vertical – Upgrade
• Horizontal - Servidores (Máquinas ou Nuvem)
• Sharing – Utilização e Armazenamento em conjunto
• Desnormalização
10. SGBDs X NoSQL
• Vantagens NoSQL
• Disponibilidade
• Otimizado
• Em 2008, enquanto ainda utilizava o PostgreSQL, o site que funciona
como rede social ficou 84 horas for do ar. Em 2009, após a utilização
do Cassandra, esse tempo foi sensivelmente reduzido para 23 horas
e 45 minutos.
http://www.computerworld.com/s/article/9161078/Twitter_growth
_prompts_switch_from_MySQL_to_NoSQL_database
• Menor tempo de resposta para consultas, paralelismo de
atualização de dados e maior grau de concorrência.
• Locks - Controle de Concorrência de Multi-versões (MVCC)
12. SGBDs X NoSQL
• Modelo NoSQL
• Tal idéia se baseia no Teorema de Eric Brewer conhecido como
Teorema CAP (Consistency, Availability e Partition Tolerance), o
qual afirma que é impossível para um sistema computacional
distribuído garantir, de forma
simultânea, consistência, disponibilidade e tolerância ao
particionamento. Segundo esse teorema, um sistema distribuído
pode garantir apenas duas dessas três características
simultaneamente.
E. Brewer. “Towards Robust Distributed Systems”. (Invited Talk). Principles of Distributed
Computing (PODC), Portland, Oregon, Julho 200
13. SGBDs X NoSQL
• Modelo NoSQL
• Esse conceito é estendido para o paradigma chamado BASE
(Basically Available, Soft state, Eventual consistency) que se
caracteriza por ser basicamente disponível, ou seja, o sistema
parece estar funcionando o tempo todo; em estado leve, o
sistema não precisa ser consistente o tempo todo; e
eventualmente consistente, o sistema torna-se consistente no
momento devido.
D. Pritchett, “BASE: An Acid Alternative”, ACM Queue vol. 6, no. 3, Julho 2008.
14. SGBD X NoSQL
• Modelo Relacional
• Esse modelo entra em contraste com o paradigma ACID
(Atomicity, Consistency, Isolation, Durability) comumente
associado aos SGBDs relacionais. Enquanto o modelo ACID força a
consistência ao final de cada operação, o modelo BASE permite
que o banco de dados esteja eventualmente em um estado
consistente. A disponibilidade do modelo BASE está relacionada
ao fato de que a queda de uma máquina do sistema não leva o
sistema como um todo a ser interrompido, representando apenas
uma máquina a menos disponível
D. Pritchett, “BASE: An Acid Alternative”, ACM Queue vol. 6, no. 3, Julho 2008
15. Exemplos
SQL MongoDB
CREATE TABLE USERS (a Number, b
Number)
db.createCollection("mycoll")
INSERT INTO USERS VALUES(3,5) db.users.insert({a:3,b:5})
SELECT a,b FROM users db.users.find({}, {a:1,b:1})
SELECT a,b FROM users WHERE age=33 db.users.find({age:33}, {a:1,b:1})
SELECT * FROM users WHERE age=33
ORDER BY name
db.users.find({age:33}).sort({name:1})
SELECT * FROM users WHERE age>33 db.users.find({age:{$gt:33}})
SELECT * FROM users WHERE age!=33 db.users.find({age:{$ne:33}})
SELECT * FROM users WHERE name LIKE
"%Joe%"
db.users.find({name:/Joe/})
SELECT * FROM users WHERE a=1 and
b='q'
db.users.find({a:1,b:'q'})
16. Exemplos
• $lt – menor que
• $gt – maior que
• $lte – menor ou igual a
• $gte – maior ou igual a
• $ne – diferente de
• $in – está em (recebe uma lista)
• $nin – não está em
• $mod – resto igual a (recebe uma lista onde o primeiro valor é o
divisor e o segundo o resto)
• $exists – contém ou não o atributo
• $not – negação de uma condição
