#NoSQLMistakes @leomrlima @otaviojava
Top 9 mistakes to avoid when
developing with NoSQL
Leonardo Lima
Otávio Santana
#NoSQLMistakes @leomrlima @otaviojava
About the Speakers
Leonardo Lima
• Computer engineer, server & embedded sw developer
• From São Paulo, Brasil, currently in Austin, TX
• CTO at V2COM
• Spec Lead – JSR363 – Units of Measurement
• Representative at JCP Executive Committee & Eclipse IoT
[about.me/leomrlima]
#NoSQLMistakes @leomrlima @otaviojava
Otávio Santana
• Software engineer, Tomitribe
• Java & Oracle Dev Champion, SouJava JUG Leader
• Apache, Eclipse and OpenJDK Committer
• Expert Group member in many JSRs
• Representative at JCP EC for SouJava
About the Speakers
[about.me/otaviojava]
#NoSQLMistakes @leomrlima @otaviojava
Desenvolver NoSQL
é fácil & super fun!
#NoSQLMistakes @leomrlima @otaviojava
Mas a diversão começa MESMO é
quando entra em produção…
#NoSQLMistakes @leomrlima @otaviojava
“Quando NoSQL entra em produção…
... como eu vejo os dados na base?”
… como eu faço backup disso?”
… e como eu recupero esses backups?”
… por que está ocupando tanto espaço?”
… não era pra ser mais rápido?”
… não era super-disponível?”
… por que mesmo escolhemos isso??”
#NoSQLMistakes @leomrlima @otaviojava
#1: Você usou NoSQL!
#NoSQLMistakes @leomrlima @otaviojava
#2: Documentos NoSQL não são PDFs!
“Preciso guardar [INSIRA TIPO DE DADO AQUI], vou utilizar
MongoDB!”
“Já recebemos os dados como JSON, só guardar na base!”
“Qual é o problema de guardar CLOB na base?”
#NoSQLMistakes @leomrlima @otaviojava
!2: Repense seus conceitos!
Entender conceitos e arquitetura dos diferentes tipos de arquitetura
Coerência, Independência & Isolamento
https://www.youtube.com/watch?v=FY0BiZaJwL4
#NoSQLMistakes @leomrlima @otaviojava
#3: Colunas NoSQL <> Colunas SQL!
“Eu adicionei índice em todas as colunas e mesmo assim a query ficou
super lenta!”
“Minha base de dados NoSQL está tão limpa e enxuta – não tem nada
duplicado!”
“Por que meus dados demoram tanto para serem escritos?”
#NoSQLMistakes @leomrlima @otaviojava
!3: Dicas do mundo NoSQL para Colunas!
• Evite adicionar índices a todo custo.
• Dados duplicados não são os inimigos!
• Família de colunas como “view materializada”,
ou seja, escrita <> leitura!
#NoSQLMistakes @leomrlima @otaviojava
#4: Queries NoSQL <> Queries SQL!
“Cadê os left join?”
“Como busco apenas pela chave?”
“Por que buscar com like demora tanto?!”
#NoSQLMistakes @leomrlima @otaviojava
!4: Dicas do mundo NoSQL para Queries!
#NoSQLMistakes @leomrlima @otaviojava
#5: Model Read + Write
“Por que criar dois modelos de dados, quando conseguimos fazer um
só para tudo? Só vai duplicar código e aumentar o que precisamos
testar…”
“Por que uma busca tão simples está trazendo tantos dados,
demorando tanto e jogando quase tudo fora no final?!”
#NoSQLMistakes @leomrlima @otaviojava
!5: Pense CQRS!
Command Query Responsability Segregation não é exclusividade de
microservices
Utilize para modelar suas bases NoSQL com modelos otimizados de
leitura e escrita e, assim, obter melhor performance.
#NoSQLMistakes @leomrlima @otaviojava
#6: Levar benchmarks ao pé da letra!
“Quando eu fiz a pesquisa, ele fazia de tudo E não consumia mais que
dois cores e 2 GB de RAM…”
#NoSQLMistakes @leomrlima @otaviojava
!6: Faça (sempre) seus próprios
Não caia em conversa de vendedor
Utilize seus casos de usos e dados
#NoSQLMistakes @leomrlima @otaviojava
#7: Não considerar os trade-offs
“Mas eu não posso ter transações, atomicidade, escalabilidade E
garantia de consenso?”
“Por que quando minha atualização demora tanto para aparecer?”
“Como eu posso garantir que minhas atualizações são executadas com
sucesso sem ninguém ser afetado?”
#NoSQLMistakes @leomrlima @otaviojava
!7: Aceite a (sua) realidade!
Basically
Available,
Soft State,
Eventual
consistency
Atomicity,
Consistency,
Isolation,
Durability
#NoSQLMistakes @leomrlima @otaviojava
!7: Aceite a (sua) realidade!
#NoSQLMistakes @leomrlima @otaviojava
!7: Aceite a (sua) realidade!
Scalability
Complexity
Key/Value
Document
Column
Family
Grap
h
#NoSQLMistakes @leomrlima @otaviojava
#8: Utilizar ORM cegamente
“Eu só queria persistir minhas entidades de maneira rápida.”
“Já investimos muito em arquitetura, não precisamos mais definir como
persistir os dados”
#NoSQLMistakes @leomrlima @otaviojava
!8: Utilize conceitos e ferramenta
certos!
#NoSQLMistakes @leomrlima @otaviojava
#9: Encantar-se com a tecnologia,
esquecer do negócio
“Mas dá pra fazer X, Y E Z com o banco! Por que não aproveitamos e
adicionamos full text search com grafo de relacionamento entre as
entidades com sugestão de busca com…”
#NoSQLMistakes @leomrlima @otaviojava
!9: Lembre-se que são só ferramentas!
#NoSQLMistakes @leomrlima @otaviojava
Concluindo!
Foca no caso de uso
Faça testes e escolha a ferramenta mais adequada
Não tenha medo de mudar – arquitete sua solução para garantir
mudanças tranquilas!
#NoSQLMistakes @leomrlima @otaviojava
Perguntas?!
#NoSQLMistakes @leomrlima @otaviojava
Thanks!

Top 9 mistakes to avoid when developing with NoSQL

Notas do Editor

  • #7 Falta de ferramentas para exploração Todo mundo tem ferramentas para explorar, consultar e editar bases SQL, porém o mundo NoSQL não é tão estruturado assim!! Vejo os dados na base: Como eu desfaço operações? Crescimento desordenado Não tem as definições, limitações e restrições de um SQL tradicional, como varchar2(50) para nome Algumas bases não apagam os dados “de verdade” até você pedir – e quem te disse isso antes?
  • #8 Eu acredito que esse é o maior erro quando se fala em banco não relacional. Exato, quando não utilizar um banco não relacional. Como toda tecnologia o NoSQL não é uma bala de prata e não serve para tudo! O banco relacional possui uma maturidade de décadas de mercado. Possui um padrão que permite evitar o lock-in. Manutenção fácil. Backup! Auditória Possui uma transação bem madura, é o caso de uma aplicação que precisa de controle de estoque, passagem de avião, etc. Nesses casos o uso de uma transação bem evoluída, que inclui transação alinhada.
  • #14 Pense como um motor de busca. O caso clássico é buscar a informação que aparecerá numa tela de sumarização e quando se clicar no item que se deseja obter todas as informações, uma vez que se tem a informação do ID buscar tudo diretamente do banco. Por exemplo, cadastro de pessoas que retornará o id, nome e a foto, quando o usuário clicar em tal pessoa, uma vez com id ele retornará todas as informações, por exemplo, endereço, cadastro, etc. Duplicação não é malvista – use e abuse para atender as necessidades de performance
  • #16 O conceito novo que vem se discutindo fortemente no mundo de microservices que é o CQRS que é o Command Query Responsability Segregation que como o nome já diz está relacionado a separar a escrita da leitura. Porém, esse conceito não pode e não deve ser considerado como algo novo ou algo a ser implementado, isso não é opcional, mas obrigatório. É importante lembrar que as aplicações no mundo NoSQL são realizadas considerando a volumetria, além de tudo, como as informações serão lidas.
  • #18 O fato é que os benchmarks terão uma tendência em explorar pontos fortes do produto “aliado” e explorar pontos fracos do “inimigo”. Uma boa dica é simplesmente, criar os seus próprios spikes, verificar qual dos bancos é o melhor para o seu cenário.
  • #20 Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
  • #21 Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
  • #22 Partindo do ponto do CAP e do tradicional gráfico de escalabilidade vs complexidade de modelo é importante entender que em nenhum momento você terá 100% garantia. Numa arquitetura de persistência distribuida você sempre ganhará em um ponto para poder perder em outro. Uma boa sugestão seria utilizar banco de dados para cada situação, porém, é difícil para administrar infra, além da consistência em múltiplos bancos de dados.
  • #23 O mundo orientado objeto é algo muito rico, e conceitos como DDD e clean code, fazem seu código cada vez mais próximo do mundo real, fazendo cada vez mais valer a regra da linguagem ubiquá. Porém, apesar do seu código usar esse paradigma seu banco de dados não utiliza.
  • #24 Uma dica é olhar o livro Clean architecture, ele fala de separar o que importa do seu código. Separar seu negócio da tecnologia é uma boa prática e te pode ajudar também a separar seu rich model da entidade que será inserida no banco de dados.
  • #26 A base de dados é só (mais) uma ferramenta para atingir necessidade de negócio