Seminário apresentado no IME-USP, 16/09/2010 ---------------------------------------------------------------------- Qualquer decisão arquitetural em sistemas de software envolve compromissos entre atributos de qualidade como latência, tempo de resposta, escalabilidade, segurança, manutenibilidade, etc. Um compromisso feito ao se adotar alguns tipos de SGBDs NoSQL é abrir mão da consistência forte para se ganhar em escalabilidade, por exemplo. Nessa apresentação falaremos sobre esse e outros compromissos envolvidos no uso de NoSQL como solução de armazenamento e recuperação de dados.

1. NoSQL: Vantagens,
Desvantagens e Compromissos
Mauricio De Diana (mestrando)
Marco Aurélio Gerosa (orientador)

2. Agenda
Definição de NoSQL
Atributos de qualidade e trocas
Modelo de dados
Escalabilidade
Transações
Consistência e disponibilidade
Desempenho
01/45

3. Dados em larga escala na web - Publicações
Bigtable (Google)
Dynamo (Amazon)
PNUTS (Yahoo!)
Além de:
GFS, MapReduce, Chubby...
Chang, F. et al (2006). Bigtable: A Distributed Storage System for Structured Data.
DeCandia, G. et al (2007). Dynamo: Amazon's Highly Available Key-value Store.
Cooper, B. et al (2008). PNUTS: Yahoo!'s Hosted Data Serving Platform.
02/45

4. Dados em larga escala na web - FLOSS
Cassandra
MongoDB
Neo4J
Redis
Riak
...
03/45

5. SGBDs NoSQL
Não-relacionais
Não-ACID
Distribuídos
04/45

6. SGBDs NoSQL
Não-relacionais
Não-ACID
Distribuídos
Para modelos de dados:
24/09, 14:00, CEC (lab 06): Aula de MAC5855
05/45

7. Atributos de qualidade
Tempo de projeto Tempo de execução
Modificabilidade Desempenho
Testabilidade Disponibilidade
... Escalabilidade
Segurança
...
Barbacci, M. (1995). Quality Attributes.
Bass, L. et al. (2003). Software Architecture in Practice. 2a ed.
06/45

8. Atributos de qualidade - Trocas
07/45
Fonte: Quality Attributes.

9. Modelo de dados

10. Modelos não-relacionais
Grafos: interconectividade dos dados é tão ou mais importante
quanto os dados em si
Chave-valor: modelo simples
Orientado a documentos: dados semiestruturados
Angles, R. e Gutierrez, C. (2008) Survey of Graph Database Models.
Buneman, P. (1997). Semistructured Data.
09/45

11. SGBDs relacionais
Esquema
Restrições de integridade
(entidade, referencial, domínio)
Normalização
10/45

12. Esquema
Banco de dados compartilhado
Hohpe, G e Woolf, B. (2003). Enterprise Integration Patterns.
11/45

13. Diferença de impedância
OO Relacional
Herança Relacionamentos
Encapsulamento Junções
Polimorfismo Normalização
... ...
Ambler, S. The Object-Relational Impedance Mismatch. http://www.agiledata.
org/essays/impedanceMismatch.html
12/45

14. Escalabilidade

15. Escalando relacional

16. N servidores web
1 db

17. Mestre / Escravo

18. Mestre / Escravo

19. Particionamento funcional

20. Particionamento horizontal
Pritchett, D. (2008). BASE: An Acid Alternative.

21. Perde-se
Junções
Normalização
Integridade de entidade e referencial
Transparência de localização
20/45

22. Transações

23. ACID
Atomicidade
Consistência
Isolamento
Durabilidade
22/45

24. ACID e escalabilidade
Atomicidade: protocolo distribuído (2PC)
Consistência: problemas com réplicas
Isolamento: locks distribuídos
Abadi, D. (2010). The problems with ACID, and how to fix them without going NoSQL.
http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html
23/45

25. Exemplos de trocas com ACID em NoSQL
Atomicidade e isolamento: em único banco de dados (Bigtable)
Consistência: em momento indeterminado (Dynamo)
Durabilidade: memória + snapshotting (Redis)
Pritchett, D. (2008). BASE: An Acid Alternative.
Vogels, W. (2009). Eventually Consistent. 24/45

26. Consistência e Disponibilidade

27. Teorema CAP
Consistência
Disponibilidade
Tolerância à partição
Fonte: http://blog.mattwoodward.com/
Brewer, E. (2000). Towards Robust Distributed Systems.
Gilbert, S. e Lynch, N. (2002). Brewer's Conjecture and the Feasibility of Consistent,
Available, Partition-tolerant Web Services
26/45

28. ACID x BASE
Basicamente disponível (Basically available)
Soft state
Consistente em momento indeterminado (Eventually
consistent)
Pritchett, D. (2008). BASE: An Acid Alternative. 27/45

29. Consistência em momento indeterminado

38. Consertando inconsistências
Fazer nada
Tentar novamente
Ação de compensação
Hohpe, G. (2004). Starbucks Does Not Use Two-Phase Commit. http://www.
eaipatterns.com/ramblings/18_starbucks.html
37/45

39. Desempenho

40. Cenários
Cargas de trabalho diferentes precisam de tratamento
diferente
OLTP OLAP
Operação Informação (BI)
CRUD pequeno e rápido Batches demorados
Consultas simples Consultas complexas
Stonebraker, M. e Cetintemel, U. (2005)."One Size Fits All": An Idea Whose Time Has
Come and Gone.
39/45

41. Experimentos
OLTP OLAP
H-Store (VoltDB) C-Store (Vertica)
82x mais rápido que um 124x mais rápido que um
SGBD comercial SGBD comercial orientado a
linha
21x mais rápido que um
SGBD comercial orientado a
coluna
Stonebraker, M. et al. (2007).The End of an Architectural Era (It's Time for a Complete
Rewrite).
Stonebraker, M. et al. (2005). C-store: a Column-oriented DBMS. 40/45

42. Tempos em um SGBDR
Logging, locking, latching e gerenciamento de buffer
1/60 das instruções em uma transação são trabalho útil
20x mais rápido sem esses sub-subsistemas
Harizopoulos, S. et al. (2008). OLTP Through the Looking Glass, and What We Found
There.
41/45

43. Especializações
Problema não está no modelo relacional, nem na SQL
Ordens de grandeza de diferença
Persistência poliglota
42/45

44. Conclusões
Contexto importa
Balancear vantagens e desvantagens é fundamental
43/45

45. Próximos passos
Foco em chave-valor (DHT)
Desenvolvimento de taxonomia
Arquitetura de referência
Experimentos de escalabilidade e desempenho
riak_core
Benchmark para cloud do Yahoo!
44/45

46. Obrigado.
Comentários, dúvidas, sugestões?
mdediana@ime.usp.br
mdediana@gmail.com
@mdediana