Persistência Poliglota, Big Data e NoSQL FISL 15

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
● Exemplos

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

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 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”

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 procedures, boas
ferramentas;
● Dados bem padronizados, normalizados;
– Relacionamento;
– Join, group by, integridade relacional, etc

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)

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;

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

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

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

Escolha bem os recursos que precisa
Abra mão de outros

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)

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 ruim dependendo da sua
aplicação

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)

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

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.

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

Identifique qual NoSQL mais
apropriado para sua aplicação
● Orientação a Documento;
● Chave/Valor;
● Grafos;
● Colunar;

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”]
}

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

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;

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.

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;

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.

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);

É 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.

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.

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

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!!!

Persistência Poliglota, Big Data e NoSQL FISL 15

Mais conteúdo relacionado

Mais procurados

Semelhante a Persistência Poliglota, Big Data e NoSQL FISL 15

Mais de Christiano Anderson

Persistência Poliglota, Big Data e NoSQL FISL 15