persistência poliglota na prática
DESCRIPTION
Ficou difícil escalar o seu banco de dados atual? Já percebeu alguma vez que um dos problemas que você está tentando resolver parece não combinar muito com um modelo relacional? Já voltou atrás e se arrependeu com uma escolha de NoSQL? Nós enfrentamos esses e outros problemas escalando nossa app Rails da 8tracks.com pra 13 milhões de usuários mais de 100 mil requests por minuto. Vou falar sobre as motivações e desafios que passamos implementando soluções com MySQL, Redis, SOLR, Postgres, Redshift, MongoDB, ElasticSearch e CouchDB. E o que nos incentivou a permanecer ou voltar atrás com cada uma dessas soluções.TRANSCRIPT
http://hdwallpapersx.com/wp-content/uploads/2013/09/Green-Parakeet-Wallpaper.jpg
persistência poliglota na prática
@nettofarah
- - Essas crianças de hoje são verdadeiros poliglotas. !
- - Verdadeiros o que? !
- - Poliglotas. Esses das cavernas.
8tracks
stats
• users: 13.3mi!
• public playlists: 1.8mi (4,2 mi total)!
• uploaded tracks: 31mi!
• requests/minute: ~100k
a melhor ferramenta para o problema
http://peopletakingpictureswithipads.tumblr.com/
melhor ferramenta
http://peopletakingpictureswithipads.tumblr.com/
para o problema!
http://peopletakingpictureswithipads.tumblr.com/
esforço humano esforço da máquina
F.C.P.P. = dev <3 + machine <3
modelo relacional• funciona bem! (até certo ponto)
• confiável
• no mercado há muito tempo
• já foi bem testado
• bem documentado
o modelo relacional
NoSQL
• relativamente novo
• resolve problemas específicos
• developer friendly
NoSQL
O que a gente já testou
Porque você deveria experimentar NoSQL
Porque NoSQL
• pode escalar muito bem
• pode resolver de forma mais elegante
• é empolgante para os devs
• data-first*
Por que desistir de NoSQL?
Complexidade
pode custar caro
muitas mudanças
falta de ferramentas adequadas
reinventar a roda
como decidir?
• documentação
• comunidades (stack overflow, github, forums, irc, listas de email)
• suporte
• quão adequado pra sua infra?
O que funcionou bem pra nós
primário
réplica slave
- escrita - leituras leves
- leitura - queries pesadas
auxiliar players
primário
réplica slave
cache
é um balde onde a gente joga as coisas
aquela aula chata de estrutura de dados…
só que funciona
redis
redis
next next next next
head
tail
• super fácil de deployar
• não usamos para o tráfego comum
• joga qualquer coisa lá dentro
• 16k rpm
• full text search
• autocomplete
• busca personalizada
• cluster de 4 máquinas
• tsv
• optimizado para IO
• queries pesadas/bigdata com SQL
• paralelo/distribuído
e como é que a gente fez?
testes em produção!
rode os sistemas lado a lado
em-proxy
1 $> em-proxy -l 8080 \!2 -r localhost:8081 \!3 -d mysql.8tracks.com:8082, \!4 postgres.8tracks.com:8082 -v!
1 Proxy.start(host: "0.0.0.0", p: 80) do |conn|! 2 conn.server :srv, host: "127.0.0.1", p: 81! 3 ! 4 # modificar pra outro protocolo! 5 conn.on_data do |data|! 6 transform(data)! 7 end! 8 ! 9 conn.on_finish do |backend, name|!10 # ignora a resposta!11 unbind if backend == :srv!12 end!13 end!
transformar para outro protocolo
ignorar a resposta
servir aos poucos
1 elasticsearch_rate = 0.2!2 if rand() =< elasticsearch_rate!3 ElasticSearch.query('justin bieber')!4 else!5 SolrSearch.query('justin bieber')!6 end!
feature toggles
1 tags = []!2 if FEATURES.explore_beta(current_user)!3 tags = RedisExplore.get_tags!4 else!5 tags = DatabaseExplore.global_tags!6 end!
monitoring
new relic
banco de dados
custom
lições
• testar coisa nova é divertido!
• dá pra testar em produção seguramente
• entenda os tradeoffs
• documentação e suporte são essenciais!
Perguntas?
