Persistência nas Nuvens com NoSQL
•
3 gefällt mir•1,314 views
Computação em Nuvem Persistência de Dados Bancos de Dados Relacionais Movimento NoSQL Modelo de dados do Bigtable da Google Arquitetura do Dynamo da Amazon Detalhes técnicos do Apache Cassandra
![Persistência nas Nuvens com NoSQL Rodrigo Hjort [email_address]](https://image.slidesharecdn.com/persistncianasnuvenscomnosql-hjort-110606114409-phpapp01/85/Persistencia-nas-Nuvens-com-NoSQL-1-320.jpg)
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Persistência nas Nuvens com NoSQL
Ähnlich wie Persistência nas Nuvens com NoSQL (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (6)
Persistência nas Nuvens com NoSQL
- 1. Persistência nas Nuvens com NoSQL Rodrigo Hjort [email_address]
- 2. Quem aqui usa banco de dados?
- 3. Por que precisamos de SQL?
- 4. Onde usamos SQL (i.e. ACID)?
- 6. Universo digital em expansão Fonte: IDC White Paper, "The Diverse and Exploding Digital Universe", 2008.
- 10. BASE otimista, aceitando que a consistência esteja em um “estado de fluxo” http://queue.acm.org/detail.cfm?id=1394128 Possibilita a escalabilidade horizontal...
- 11. NoSQL = Not Only SQL http://nosql-database.org/ distribuídos não relacionais horizontalmente escaláveis esquemas flexíveis replicáveis APIs simples
- 12. NoSQL nas Nuvens escalabilidade flexibilidade performance disponibilidade
- 13. Zoologia dos bancos NoSQL Wide Column Store / Column Families Key-Value Store Document Store Azure Storage Services
- 16. Disponibilidade : toda operação tem uma resposta
- 17. Partição : sistema continua operante mesmo enfrentando partições na rede Consistência Consistency Disponibilidade Availability Partição Partition Tolerance
- 18. Breve explicação do CAP um dia ensolarado... partições de rede!
- 22. “ A high performance, scalable, distributed storage and processing system for structured and unstructured data.”
- 23. Cassandra: um breve histórico Bigtable Dynamo
- 25. Valor (Value)
- 26. Timestamp Keyspace Column Family (Row) Key Column
- 27. As famílias de colunas
- 28. Exemplo: modelagem do Twitter Users Following Followers @paul segue @brigitte desde 22/08/2010 john fullname: John Doe password: swordfish joindate: 20091115 paul fullname: Paul Lane password: thepass joindate: 20091129 john paul: 20091204 brigitte: 20100815 paul john: 20091205 debora: 20100729 brigitte: 20100822 john tom: 20091128 paul: 20091205 brigitte john: 20100815 paul: 20100822
- 29. Exemplo: modelagem do Twitter Statuses (Tweets) Timeline Userline Tweets do @john Tweets dos usuários que o @paul segue data/hora tweet 12345 user: john body: Nuvem privada do @serpro! retweets: 123 12346 user: brigitte john 20100116083155: 12346 paul 20100116083002: 12345 20100116083155: 12346 john 20100116083002: 12345 20100118235914: 23457 brigitte 20100116083155: 12346 tweet body: Acabei de #acordar. tags acordar: 1
- 30. “It took two weeks to perform ALTER TABLE on the statuses [tweets] table.” – Twitter
- 34. One
- 35. Quorum: N / 2 + 1
- 37. R + W > N
- 38. Read repair ack cliente réplica réplica réplica coordenador
- 39. Filiação cluster / detecção falha Gossip-Based Protocol
- 42. escrita: ~0,12 ms Leitura 23x mais rápida! Escrita 2500x mais rápida!
- 43. Escrita é mais rápida que leitura?!
- 44. “ NoSQL adoption is inevitable because, just as in every other walk of life, there are different tools for different jobs” – Stephen O'Graddy (RedMonk) Rodrigo Hjort [email_address] http://agajorte.blogspot.com
Hinweis der Redaktion
- ...
- A grande maioria das aplicações necessita de algum tipo de persistência de dados.
- Por que precisamos de SQL? Modelo relacional está bem consolidado Linguagem com décadas de evolução Integridade referencial e transações (ACID) Conjunto rico de ferramentas É o que aprendemos É o que o mercado usa
- Onde usamos SQL (i.e. ACID)? Aplicações empresariais Agências de viagem Internet banking Compras online Cartões de crédito Transações em geral
- ...
- Informação digital criada, capturada e replicada pelo mundo Fonte: IDC White Paper, "The Diverse and Exploding Digital Universe", 2008.
- Aplicações web modernas Grandes volumes de dados (escala da Internet) Altas taxas de leitura e escrita Necessidade de alta disponibilidade Frequentes mudanças nos esquemas Aplicações “sociais” não exigem os mesmos níveis de consistência que aplicações “bancárias”
- • Scaling existing Relational Databases is hard • Sharding is one solution, but makes your RDBMS unusable • Operational Nightmare
- Os modelos transacionais ACID Atomicity, Consistency, Isolation, Durability: a set of properties that guarantee database transactions are processed reliably BASE Basically Available, Soft state, Eventual consistency : as opposed to the database concept of ACID http://queue.acm.org/detail.cfm?id=1394128 Eventually Consistent http://queue.acm.org/detail.cfm?id=1466448
- O Movimento NoSQL NoSQL = Not Only SQL http://nosql-database.org/ bancos que diferem do modelo clássico relacional não relacionais distribuídos horizontalmente escaláveis com esquemas flexíveis replicáveis APIs simples BASE (e não ACID)
- Por que precisamos de NoSQL nas Nuvens? escalabilidade [horizontal] : mais CPUs comuns ao invés de upgrades performance : alcançado através de design simplificado e denormalização dos dados flexibilidade : natureza dos bancos sem esquema permite metodologias de desenvolvimento ágil [alta] disponibilidade : não existe ponto único de falha (SPOF – single point of failure)
- Wide Column Store: Bigtable (Google) SimpleDB (AWS) Cassandra (Apache) HBase (Apache) Hypertable Document Store: CouchDB (Apache) MongoDB Key-Value Store: Riak Redis Table Storage (Microsoft Azure)
- ...
- Eric Brewer (UCB) in 2000 presented the CAP theorem , which states that of 3 properties of shared-data systems: C: data consistency A: system availability P: tolerance to network partition Only 2 can be achieved at any given time! A more formal confirmation can be found in a 2002 paper by Seth Gilbert and Nancy Lynch.
- ...
- CA – Corruption possible if live nodes can’t communicate (network partition)
- CP – Completely inaccessible if any nodes are dead
- AP – Always available, but may not always read most recent NoSQL chooses AP, but makes consistency configurable
- Cassandra highlights ● High availability ● Incremental scalability ● Eventually consistent ● Super fast writes ● Tunable tradeoffs between consistency and latency ● Minimal administration ● No SPF
- Developed at Facebook Follows the BigTable Data Model - column oriented ( Google ) Follows the Dynamo Eventual Consistency model ( Amazon ) Opensourced at Apache Implemented in Java
- ...
- ...
- ...
- ...
- ...
- Every node is equal Always at least one copy in each datacenter Alternate datacenters on the ring DHT (Distributed Hash Table) Ring
- Eventual consistency ● Synch to Washington, asynch to Hong Kong Client API Tunables ● Confirm R replicas match at read time ● Synchronously write to W replicas of N total replicas Allows for almost-strong consistency ● When W + R > N
- Gossip protocol is used for cluster membership Enables seamless nodes addition Rebalancing of keys Fast detection of nodes that goes down Every node knows about all others - no master State disseminated in O(log N) rounds
- ...
- ...
- Conclusão NoSQL can’t do everything Adhoc queries are not possible Right tool for the right job