Redis

Transcript

1. Redis NoSQL key-value storage
2. Banco de Dados NoSQL O que é NoSQL? • Não-relacional • Não-ACID Características: • Alta performance • Escalabilidade • Replicação • Suporte a dados estruturados
3. Banco de Dados NoSQL Escalabilidade • Distribuição Horizontal ◦ Aumentar o número de máquinas/servidores Exemplos: • Yahoo - Hadoop • Facebook e Digg - Cassandra • LinkedIn - Voldemort Junto com SGBD Relacional
4. O que é Redis? REmote DIctionary Server Banco de Dados NoSQL do tipo Key-Value Key-Value • Tipo de Banco de Dados mais simples, seu conceito é uma chave e um valor para esta chave. • É também o que mais aguenta carga de dados, sendo o que proporciona maior escalabilidade.
5. Redis Estruturas: • Conjuntos • Listas • Ranks • Números Operações: • União • Intersecção • Diferença entre Conjuntos Filas: • Adiciona e remove elementos de maneira organizada
6. Redis Memory / Persistence • Para manter a velocidade dos dados com garantia de persistência, de tempos em tempos (ou a cada n mudanças) as alterações são replicadas, de maneira assíncrona, da memória RAM para o disco. Redis vs MemCacheDB • Similares, a principal diferença refere-se a persistência dos dados.
7. Autor • Salvatore Sanfilippo @antirez
8. Repositório • Opensource ◦ Disponível no github ◦ 643 forks • Escrito em C • Versão atual 2.4.13
10. Exemplo de um Key-Value { "id": 1 "nome": "Batman" "idade": 36 "superpoderes": ["voar", "bater", "pular", "correr"] "inimigos": ["Coringa", "Pinguim", "Charada", "Batgirl"] }
11. "Do jeito redis" { "superheroi:1:nome": "Batman" "superheroi:1:idade": 36 "superheroi:1:superpoderes": ["voar", "bater", "pular", "correr"] "superheroi:1:inimigos": ["Coringa", "Pinguim", "Charada", "Batgirl"] }
12. Estruturas de dados ◦ Diferencial quanto a outros BD's ◦ Mantém tudo em memoria ▪ Persistencia é feita por tempo ou número de atualizações ◦ Redis não se preocupa com o que esta sendo armazenado ▪ Tudo é tratado como array de bytes.
13. Estruturas de dados: Strings • Estrutura mais simples de todas. • Não se trata de Strings como alfanuméricos. • Serve de base para outras mais complexas: ◦ List: lista de Strings ◦ Set: Set de String • Ideal para: ◦ Random access ◦ Bitmap ◦ Array de bytes
14. Estruturas de dados: Lists • Feita para trabalhar com os extremos: ◦ Push / Pop • Acesso randomico: O(N) • Ideal para: ◦ Filas ◦ Pilhas
15. • Estrutura não-ordenada • Permite acesso randomico a elementos ◦ Peek, Pop • Ideal para representar relações: ◦ Quais alunos estudam com aluno 1 • Suporta operações complexas: ◦ União ◦ Intersecção, etc Estruturas de dados: Sets
16. Estruturas de dados: Hashes • Formado por tabelas Hash • Composto por campo e valor • Ideal para armazenamento de objetos • Permite auto incremento • String mais sofisticada ◦ Mais campos ◦ Get, Set campos individualmente sem ter que reescrever todo o registro
17. Estruturas de dados: Sorted Sets • Junto com a lista, unico que mantém items em ordem • Armazenamento de dados de sites: ◦ Mais visitados ◦ Usuário com mais acessos • Mais poderosos que lista ◦ Operações de inclusão, exclusão sempre rapidas mesmo do meio da estrutura. • Ocupa mais memória • Complexidade O(log(N)).
18. Estruturas de dados • Caso especial: ◦ Número pequeno de items e de tamanho ◦ Utiliza-se variações de compactação para armazenamento: O(N). ◦ Automaticamente retornável.
19. Transações • Todos os comandos no Redis são atômicos ◦ Garantia: Single-threaded ◦ comando "incr" = Get seguido de Set • Redis possibilita atomizar múltiplos comandos. • Propriedade de transação: Tudo ou nada • Comandos: ◦ multi ◦ exec / discard ◦ watch
20. Exemplo Transação redis.watch('powerlevel') current = redis.get('powerlevel') redis.multi() redis.set('powerlevel', current + 1) redis.exec()
21. Pipeline • O que é? ◦ Executar uma operação sem precisar esperar pelo callback (sucesso ou erro) • Para que? ◦ grande número de operações ◦ sequencial ◦ rápida execução
22. Pipeline Exemplo (Ruby): redis.pipelined do 9001.times do redis.incr('powerlevel') end end
23. Expiração • Tempo de expiração na chave (unix timestamps) -RPUSH pagewviews.user:<userid> http://..... -EXPIRE pagewviews.user:<userid> 60" • Expiração Passiva: -Testa 100 chaves 10 vezes por segundo • Expiração Ativa: -Quando o usuario tenta acessar
24. Persistência • RDB (point-in-time snapshots) -Perfeito para backups, unico arquivo de representação de estado, restauração mais rapida, etc. -Perigoso em instabilidades do sistema, pode ocupar demais o servidor, etc. • AOF (registro de todas operações "write") -Sem problemas de ocupar CPU ou com instabilidades mesmo quando está sendo reescrito. -Arquivos maiores e possivel maior latencia em comparação ao RDB.
25. Replicação e Scaling/Clustering • Slaves -Enviar leituras para os slaves. • Multiplas Instancias -Horizontalização dos dados. -Redis é single-threaded. • No futuro -horizontal scaling, rebalancing, automated failover.
26. Virtual Memory (Deprecado) • Atual ◦ Requer que todos os dados se encaixem na RAM ◦ Não há problema se forem valores simples ▪ Alternativa: colocar o id de um registro no Redis, o resto fica no BD relacional • VM ◦ Disponível desde a versão 2.0 ◦ Apenas as chaves ficam na RAM ◦ Valores ficam no disco ◦ Possui vários problemas e desvantagens
27. Virtual Memory (Deprecado) "In the future of Redis, we want to simply provide the best in-memory database (but persistent on disk as usually) ever, without considering at least for now the support for databases bigger than RAM" "Our future efforts are focused into providing scripting, cluster and better persistence" http://redis.io/topics/virtual-memory
28. Quando utilizar o Redis? "I think that another big difference is that in order to take advantage of Redis in your production environment you don't need to switch to Redis. You can just use it in order to do new things that were not possible before, or in order to fix old problems."
29. CACHE • Páginas com muito processamento ◦ SQL muito complexa e demorada ◦ muitos acessos na mesma requisição ◦ usar EXPIRE após um intervalo de tempo • Memcached ◦ somente cache ◦ sem persistência ◦ simples e rápido
30. Web Analytics • Análises em tempo real • Muito write • Exemplo ◦ Contadores (Hit counter) ▪ INCR = Atômico!! ▪ INCR "urls:google.com/+" ▪ INCR "banners:12" ◦ Anti-spam
31. Registro aleatório • SQL: ◦ ORDER BY RAND() LIMIT 1 ◦ Ineficiente para grandes tabelas Solução? • Redis ◦ Guardar os IDS em um SET(Lista única) ◦ Usar SRANDMEMBER ◦ Complexidade: O(1)
32. Pegar últimos registros • SQL ◦ SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10 ◦ Problema de escalabilidade Antirez: "É muito contra-intuitivo você precisar ordenar registros quando você apenas quer listar na mesma ordem em que foram criados"
33. Pegar últimos registros • Redis ◦ Inserir o novo registro ▪ LPUSH latest.comments <id> ◦ Permitir apenas os últimos 20 ▪ LTRIM latest.comments 0 20 ▪ Usar SQL para encontrar mais ◦ E se deletar? ▪ Usar LREM ▪ Não fazer nada • quando for tentar encontrar o registro no BD relacional não achará
34. User sessions (web) • Frequentemente criados • BD Relacionais ◦ Passam semanas ocupando espaço no BD ◦ Quase nunca consultados por outra coluna, a não ser seu id primário • Redis store session data ◦ session:5ab5a9b054a8 = ... ◦ EXPIRE session:5ab5a9b054a8 604800 (1 semana) • Frameworks web: ◦ Boa parte usa memcached (sem persistência) ◦ Restart = login novamente
35. Publish/Subscribe • Mapear eventos ◦ SUBSCRIBE chat ◦ PUBLISH chat "Testando" ▪ usar websockets para enviar mensagem! ◦ UNSUBSCRIBE • Exemplos: ◦ Notificação ◦ Cliente de chat
36. Publish/Subscribe http://pusher.com/
37. Publish/Subscribe • Utilizam redis por baixo • Preços: ◦ $19 (100 connections, 200,000 mpd) ◦ $49 (500 connections, 1 million mpd) ◦ $199 (5000 connections, 10 million mpd) • Opção free: ◦ https://github.com/maccman/juggernaut ◦ Também utiliza redis
38. Job Queue • Processamento em background ◦ Image resizing ◦ Send mail ◦ API requests • Queue ◦ LPUSH com RPOP ◦ RPUSH com LPOP • Exemplo: Resque ◦ Processa um worker dado intervalo de tempo ◦ Usa persistência ▪ tranca caso ocorra erro ▪ remove se processado com sucesso
39. Activity Stream • Complicado para desenvolver em BD relacionais • Dificil de escalar • Opções ◦ Criar views com vários JOINS para montar as ações feitas pelas pessoas que você segue em tempo de leitura. ◦ Conceito de inbox, onde cada ação é um registro separado para todos os seguidores. (Melhor)
40. Activity Stream (Inbox) • Usar redis para guardar o inbox (list) de cada usuário, com o id das "activities" • Toda vez que é criada uma activity, é colocado na inbox dos seguidores.
41. Highscores/Leaderboards • Mantido sempre ordenado (sorted set) ◦ ZADD formula1:colocacao -1 rubinho ◦ ZADD formula1:colocacao 5 massa ◦ ZADD formula1:colocacao 10 senna ◦ ZREVRANGEBYSCORE formula1:colocacao 10 0 • Fácil de criar a partir de outras através do ZUNION/SUM • Grande uso para aplicações de jogos
42. Quem está usando?
43. Try redis http://try.redis-db.com/
44. Exemplo prático • Twitter + Rails + Redis + Postgres ◦ Hit count ◦ Leaderboard dos que mais "tuitaram" ◦ Cache
45. Referências http://antirez.com/post/take-advantage-of-redis-adding-it-to- your-stack.html http://openmymind.net/2012/1/23/The-Little-Redis-Book/ http://www.cs.helsinki.fi/u/paksula/misc/redis.pdf