Persistência
Poliglota e
NoSQL
Christiano Anderson
anderson@propus.com.br
Twitter: @dump
Agenda
● Quem sou eu
● A era de ouro dos bancos relacionais
● Bancos Não Relacionais
● Por que usar persistência poliglota...
Quem sou eu
● Trabalha com internet/devel desde 1996;
● Colabora com diversos projetos livres;
● Fundador do MUG-SP;
● Esp...
A era de ouro dos
Bancos relacionais
Bancos Relacionais
● Opções populares,
como MySQL,
PostgreSQL e Oracle
● Sempre foram a
primeira opção ao
desenvolver qual...
O modelo relacional
● Dados armazenados em tabelas;
● Relacionamentos;
● Normalização de dados;
● Necessidade de schema;
Vantagens do modelo relacional
● SQL → Quase todo mundo conhece;
– Linguagem bem flexível;
– Muitos operadores, stored pro...
Vantagens do modelo relacional
● ACID
– Atomicidade (tudo ou nada);
– Consistência (validação, respeita integridade);
– Is...
Desvantagens do modelo relacional
● Dependência da modelagem, qualquer
alteração, precisa passar por uma migração;
● Dific...
E quando o banco começa ficar lento?
Contrata um cara para criar índices
E de fato fica um pouco melhor, mas não resolve
100%
Contrata um cara para criar views e
queries complexas
Melhora mais um pouco, só que vira um pesadelo
para manter...
Contrata um cara para criar cache
na aplicação
Fica ainda melhor, mas a informação começa ser
duplicada
Not Only SQL
Novo paradigma
● Na verdade, nem tão novo assim;
● Liberdade de schema e modelagem;
● Escalabilidade horizontal (fica lent...
Não é bala de prata
● Fazemos três tipos de serviços:
– Bom, Barato, Rápido
● Se for BOM e BARATO não vai ser RÁPIDO
● Se ...
Escolha bem os recursos que precisa
Abra mão de outros
Teorema de CAP
Teorema de CAP
Consistency (Todos os nós possuem o mesmo dado ao mesmo tempo);
Availability (Garantia que todas as requisi...
De acordo com o teorema, sistemas distribuídos
não podem atender aos três requisitos ao mesmo
tempo, atendem um ou dois.
Desnormalizar
● NoSQL não trabalha de forma normalizada
– Duplicidade?
– Falta de Consistência?
● Isso pode ser bom ou rui...
Aprender novo modelo de fazer
consultas ao banco
● Muitos NoSQL não trabalham com conceito de
queries, mas utilizam filtro...
Esqueça SQL e modelagem
● Aprenda como o NoSQL funciona, nunca, mas
nunca pense da mesma forma que no
relacional;
– O segr...
Deixe de lado ORMs tradicionais
● ORM tradicionais (como SQLAlchemy) não
funcionam com NoSQL e nem vão funcionar;
● Estude...
SQL vs NoSQL
SQL NoSQL
Uma única máquina Um Cluster
Escala verticalmente Escala horizontalmente
Full Index Baseado em chav...
Identifique qual NoSQL mais
apropriado para sua aplicação
● Orientação a Documento;
● Chave/Valor;
● Grafos;
● Colunar;
Qual a melhor ferramenta?
Orientação a documentos
Exemplo de documento
{
“_id”: ObjectId("53582acf31f36c9a248e4c15"),
“nome”: “Christiano Anderson”,
“contato”: {
“email”: “...
Chave/Valor
Grafos
Colunar
Persistência Poliglota
● Uma aplicação eficiente é aquela que atende
bem seu objetivo e está sempre disponível
quando é re...
Persistência Poliglota
● É uma boa ideia usar mais de uma solução de
persistência:
– SQL onde for mais apropriado (ACID, t...
Exemplo: E-commerce
● Catálogo de produtos é a parte mais acessada de uma
loja virtual, o volume de acessos é alto (blackf...
Aproveitando melhor cada
tecnologia
● O exemplo do e-commerce mostra:
– Usa-se MongoDB para escalar bem uma parte
complica...
Ainda tem mais...
● Pode usar Neo4J (Grafos) para recomendar
produtos aos usuários, com base em suas
preferências de naveg...
O arquiteto de soluções dos dias de
hoje...
● Não pode ficar amarrado a uma única solução
– Precisa escolher a que funcion...
É necessário diversas ferramentas
para construir uma casa
● Assim como você precisa de chave de fenda,
alicate, pá, martel...
Fica mais caro manter tudo isso?
● Claro que fica!
– Você vai precisar de mais máquina, pessoas
qualificadas, mais infra.....
Por onde começar
● Primeiro passo é entender bem a arquitetura da
informação;
● Conhecer um pouco de cada alternativa de p...
E o tempo acabou...
Se não deu tempo de responder sua dúvida,
Me chame no corredor ou entre em contato:
Twitter: @dump
Ema...
Upcoming SlideShare
Loading in...5
×

Persistência Poliglota, Big Data e NoSQL FISL 15

2,154

Published on

Com a necessidade de analisar muita informação em tempo real em conjunto com a grande complexidade das aplicações, é muito comum utilizar mais de um tipo de persistência para obter o resultado esperado. Existe uma grande variedade de tipos de persistência, seja relacional (SQL) ou Não Relacional (NoSQL). Compreender os principais recursos de cada um e implementar uma arquitetura com múltiplos tipos diferentes de persistência pode trazer inúmeros benefícios e escala para aplicações. Essa palestra foi apresentada no dia 10 de Maio de 2014 no 15 Fórum Inernacional de Software Livre em Porto Alegre

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,154
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
48
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Persistência Poliglota, Big Data e NoSQL FISL 15

  1. 1. Persistência Poliglota e NoSQL Christiano Anderson anderson@propus.com.br Twitter: @dump
  2. 2. Agenda ● Quem sou eu ● A era de ouro dos bancos relacionais ● Bancos Não Relacionais ● Por que usar persistência poliglota ● Exemplos
  3. 3. Quem sou eu ● Trabalha com internet/devel desde 1996; ● Colabora com diversos projetos livres; ● Fundador do MUG-SP; ● Especialista em NoSQL / Big Data; ● Blog: http://christiano.me ● Twitter: @dump ● Email: anderson@propus.com.br
  4. 4. A era de ouro dos Bancos relacionais
  5. 5. Bancos Relacionais ● Opções populares, como MySQL, PostgreSQL e Oracle ● Sempre foram a primeira opção ao desenvolver qualquer aplicação ● Muitas ferramentas ● Muita gente qualificada no mercado ● Suporte amplo e fácil de encontrar, inclusive do fabricante ● Acabou se tornando um “padrão”
  6. 6. O modelo relacional ● Dados armazenados em tabelas; ● Relacionamentos; ● Normalização de dados; ● Necessidade de schema;
  7. 7. Vantagens do modelo relacional ● SQL → Quase todo mundo conhece; – Linguagem bem flexível; – Muitos operadores, stored procedures, boas ferramentas; ● Dados bem padronizados, normalizados; – Relacionamento; – Join, group by, integridade relacional, etc
  8. 8. Vantagens do modelo relacional ● ACID – Atomicidade (tudo ou nada); – Consistência (validação, respeita integridade); – Isolamento (concorrência retorna resultado válido); – Durabilidade (uma vez gravado, é definitivo)
  9. 9. Desvantagens do modelo relacional ● Dependência da modelagem, qualquer alteração, precisa passar por uma migração; ● Dificuldade para manter aplicações que crescem muito rápido; ● Dificuldade na Escalabilidade – Vertical (o banco está lento, mete mais memória na máquina); – Compra uma máquina melhor;
  10. 10. E quando o banco começa ficar lento?
  11. 11. Contrata um cara para criar índices E de fato fica um pouco melhor, mas não resolve 100%
  12. 12. Contrata um cara para criar views e queries complexas Melhora mais um pouco, só que vira um pesadelo para manter...
  13. 13. Contrata um cara para criar cache na aplicação Fica ainda melhor, mas a informação começa ser duplicada
  14. 14. Not Only SQL
  15. 15. Novo paradigma ● Na verdade, nem tão novo assim; ● Liberdade de schema e modelagem; ● Escalabilidade horizontal (fica lento, coloca mais máquina); – Pode ser máquinas comuns; ● Muito fácil e simples colocar em cluster – Muitos seguem o teorema de CAP
  16. 16. Não é bala de prata ● Fazemos três tipos de serviços: – Bom, Barato, Rápido ● Se for BOM e BARATO não vai ser RÁPIDO ● Se for BARATO e RÁPIDO não vai ser BOM ● Se for BOM e RÁPIDO não vai ser BARATO
  17. 17. Escolha bem os recursos que precisa Abra mão de outros
  18. 18. Teorema de CAP
  19. 19. Teorema de CAP Consistency (Todos os nós possuem o mesmo dado ao mesmo tempo); Availability (Garantia que todas as requisições recebam um retorno true ou false) Partition tolerance (o sistema continua operando mesmo se parte do nó estive inacessível)
  20. 20. De acordo com o teorema, sistemas distribuídos não podem atender aos três requisitos ao mesmo tempo, atendem um ou dois.
  21. 21. Desnormalizar ● NoSQL não trabalha de forma normalizada – Duplicidade? – Falta de Consistência? ● Isso pode ser bom ou ruim dependendo da sua aplicação
  22. 22. Aprender novo modelo de fazer consultas ao banco ● Muitos NoSQL não trabalham com conceito de queries, mas utilizam filtros; – Você precisa estar preparado para integrar novas formas de acesso a dados na sua aplicação – Possui curva de aprendizado (tênue, mas possui)
  23. 23. Esqueça SQL e modelagem ● Aprenda como o NoSQL funciona, nunca, mas nunca pense da mesma forma que no relacional; – O segredo do sucesso chama-se Schema Design
  24. 24. Deixe de lado ORMs tradicionais ● ORM tradicionais (como SQLAlchemy) não funcionam com NoSQL e nem vão funcionar; ● Estude bem o driver apropriado da sua linguagem de programação favorita, provavelmente terá suporte ao NoSQL que você escolher.
  25. 25. SQL vs NoSQL SQL NoSQL Uma única máquina Um Cluster Escala verticalmente Escala horizontalmente Full Index Baseado em chaves SQL Possui API e filtros de pesquisa
  26. 26. Identifique qual NoSQL mais apropriado para sua aplicação ● Orientação a Documento; ● Chave/Valor; ● Grafos; ● Colunar;
  27. 27. Qual a melhor ferramenta?
  28. 28. Orientação a documentos
  29. 29. Exemplo de documento { “_id”: ObjectId("53582acf31f36c9a248e4c15"), “nome”: “Christiano Anderson”, “contato”: { “email”: “chris@christiano.me”, “celular”: “11999998888”, }, “sites”: { “blog”: “http://christiano.me”, “mongodb”: “http://www.mongodb.org” }, “tecnologias”: [“mongodb”,”python”,”big data”,”nosql”] }
  30. 30. Chave/Valor
  31. 31. Grafos
  32. 32. Colunar
  33. 33. Persistência Poliglota ● Uma aplicação eficiente é aquela que atende bem seu objetivo e está sempre disponível quando é requisitada; – Escalável – Segura – Nunca é o gargalo para inovações
  34. 34. Persistência Poliglota ● É uma boa ideia usar mais de uma solução de persistência: – SQL onde for mais apropriado (ACID, transações, normalização); – NoSQL onde você não precisa das features acima;
  35. 35. Exemplo: E-commerce ● Catálogo de produtos é a parte mais acessada de uma loja virtual, o volume de acessos é alto (blackfriday, natal, dia das mães). Nem todo mundo que acessa vai comprar naquele momento. Colocar o catálogo de produtos no MongoDB pode destravar o e-commerce; ● Os dados dos usuários, informações financeiras e tudo aquilo que exige transação, fica no banco relacional (PostgreSQL por exemplo). Assim o SQL só será acessado quando o usuário for concluir a compra.
  36. 36. Aproveitando melhor cada tecnologia ● O exemplo do e-commerce mostra: – Usa-se MongoDB para escalar bem uma parte complicada do site, onde os usuários passam maior parte de seu tempo navegando. Ganha-se agilidade, flexibilidade e escalabilidade; – Usa-se PostgreSQL somente para concluir transações, guardar informações pessoais dos usuários (quando está logado) e tudo que precisa de normalização;
  37. 37. Ainda tem mais... ● Pode usar Neo4J (Grafos) para recomendar produtos aos usuários, com base em suas preferências de navegação e outros critérios utilizados para determinar perfil de compra de cada um.
  38. 38. O arquiteto de soluções dos dias de hoje... ● Não pode ficar amarrado a uma única solução – Precisa escolher a que funciona para cada cenário; ● Não é feio usar SQL e NoSQL ao mesmo tempo, é feio deixar sua aplicação morrer por não ser escalável; ● Precisa ser flexível, adicionar novas features rapidamente (afinal, seu concorrente está em um click de distância);
  39. 39. É necessário diversas ferramentas para construir uma casa ● Assim como você precisa de chave de fenda, alicate, pá, martelo e outras ferramentas para construir uma casa, pode ser necessário mais de uma solução de persistência para sua aplicação, extraindo o melhor que cada uma tem a oferecer.
  40. 40. Fica mais caro manter tudo isso? ● Claro que fica! – Você vai precisar de mais máquina, pessoas qualificadas, mais infra... ● Mas se você faz sua aplicação mais rápida, estável, segura e escalável, vai vender mais... ● Lembra do quadro Bom, Rápido e Barato? Então, faça sua escolha.
  41. 41. Por onde começar ● Primeiro passo é entender bem a arquitetura da informação; ● Conhecer um pouco de cada alternativa de persistência; ● Analisar qual melhor modelo de dados para cada caso (Documento, Chave/Valor, Colunar, Grafos); ● Implementar a(s) persistência(s) certa(s) à sua aplicação; ● Ter mais de uma é aceitável e recomendado
  42. 42. E o tempo acabou... Se não deu tempo de responder sua dúvida, Me chame no corredor ou entre em contato: Twitter: @dump Email: anderson@propus.com.br OBRIGADO!!!
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×