Estou seguro com no sql
•Als PPTX, PDF herunterladen•
3 gefällt mir•406 views
O documento discute as opções de persistência e backup para bancos de dados NoSQL Redis, Cassandra e PostgreSQL. Redis oferece RDB e AOF para persistência, enquanto Cassandra usa commitlog, SSTables e hinted handoff. PostgreSQL usa fsync e synchronous_commit. Todos permitem automatizar backup, embora com estratégias diferentes. Rotacionais são mais lentos que SSDs para escrita.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Estou seguro com no sql
Ähnlich wie Estou seguro com no sql (20)
Estou seguro com no sql
- 1. Estou seguro com NoSQL? Rafael Redondo
- 2. O que falaremos ACID(Atomicity, Consistency, Isolation, Durability) + backup
- 3. O que não falaremos SQL X NoSQL
- 4. O que não falaremos BASE (Basically Available, Soft state, Eventual consistency) CAP (Consistency, Availability, Partition tolerance)
- 5. Programação • Durabilidade • Redis • Cassandra • Comparativo: Redis, Cassandra, PostgreSQL
- 6. Durabilidade “Garantir que os dados estarão disponíveis em definitivo.”
- 7. O SO e o Disco CLIENT MÍDIA FÍSICA CACHES BUFFERS CACHES BUFFERS CONTROLADOR DE DISCO BANCO DE DADOS SOWRITE FSYNC
- 8. Quando o dado está seguro? CLIENT MÍDIA FÍSICA CACHES BUFFERS CACHES BUFFERS CONTROLADOR DE DISCO BANCO DE DADOS SOFALHA DE BD QUEDA DE ENERGIA
- 9. WRITE vs FSYNC Desempenho Usa Cache Garantia Usa Recursos LINUX: 30 Segundos Qual o requisito não-funcional mais importante?
- 10. Redis
- 11. Modos de persistência • RDB (Redis Database), faz um snapshot da base em intervalos pré-determinados. • AOF (Append of file), log com todas as operações. • Nenhum, caso você queira que os dados estejam disponíveis apenas enquanto durar o processo. • Ambos. Nesse caso, o Redis vai utilizar o AOF quando iniciar o processo para garantir que os dados estejam completos.
- 12. Vantagens do RDB • Perfeito para back-up: arquivo único com representação completa da base. • Ótima para recuperação de desastres: pode ser armazenado em datacenters externos. • Maximiza a performance: roda em um processo filho, evitando que o processo principal faça I/O. • Restart mais rápido em comparação com o AOF.
- 13. Desvantagens do RDB • Se o seu snapshot por feito a cada 5 minutos e o Redis parar sem um shutdown normal, haverá perdas. • Ainda que o snapshot rode em um processo filho, pode interferir no processo pai caso a base seja muito grande ou o CPU e o disco não sejam performáticos.
- 14. Vantagens do AOF • Configurações: nunca, a cada segundo ou a cada query. • Thread paralela ajuda a performance. • Log simples: não há problemas com arquivo corrompido nem gravações randômicas. • Mesmo que o logs termine com um comando pela metade por alguma razão (disco cheio, queda de energia), a ferramenta redis-check- aof permite fácil correção.
- 15. Vantagens do AOF • Dados que surgem após o início da reescrita do AOF são gravados no arquivo antigo e também em uma fila na memória, para que esses dados sejam gravados no novo arquivo. • O AOF contém o log de todas as operações, uma depois da outra, em um formato legível e editável. • As reescritas são geradas usando operações de I/O sequenciais, tornando o processo eficiente mesmo em discos tradicionais.
- 16. Desvantagens do AOF • São maiores que o RDB. • Dependendo da configuração da escrita do AOF, pode interferir na performance do Redis. • Os comandos gerados não são imunes a bugs, embora estes sejam raros.
- 17. RDB ou AOF? • Ambos. caso você deseje que a segurança dos dados fique em um nível de um banco tradicional. • Se você pode viver com a perda de alguns minutos de dados, use apenas o RDB. • O Redis não deixa uma execução interferir na outra. • Há planos a longo prazo para que AOF e RDB sejam unificados.
- 18. Backup • Crie um job para criar snapshots RDB de hora em hora • Renomeie os snapshots com data e hora. • Transfira o snapshot para um local fora do seu data center. • Certifique-se que o tamanho do arquivo transferido é igual ao do arquivo copiado. • Crie algum tipo de alerta caso o arquivo não esteja sendo transferido.
- 19. Cassandra
- 20. Modos de persistência • Replicação do mesmo dado em diversos nós. • Nós podem estar em datacenters ou regiões diferentes. • Escolha do tipo de consistência para cada operação. • Commitlog. • SSTable. • HintedHandoff
- 21. Commitlog • A cada operação, primeiramente o commitlog é escrito de forma sequencial • É similar ao AOF do Redis • A escrita sequencial é rápida, já que não perde tempo varrendo o disco • Age como um log de recuperação de crash para os dados • A escrita nunca será considerada se não tiver ao menos gravada no commitlog
- 22. fsync • periodic: joga o cache para o commitlog a cada periodo configurado no commitlog_sync_period_in_ms (default: 10000ms), sem travar novos writes • batch: o Cassandra não aceita outras escritas para o cache até que seja feito o flush, dentro do período limite configurado em commitlog_sync_batch_window_in_ms.
- 23. fsync • coloque o commitlog em outro drive para não disputar recursos de I/O com SSTable • o dado não será perdido uma vez que esteja no arquivo do commitlog • o Cassandra roda o commitlog após o restart do sistema para recuperar dados que possam ter sido perdidos
- 24. memtable • Depois do commitlog, o Cassandra escreve o dado na memtable • Memtable é um cache na memória com os dados no formato chave/coluna • É classificada por chave • Cada ColumnFamily tem sua própria Memtable e recupera os dados da chave
- 25. SSTables • Sorted String Table • Memtables são descarregadas quando esta fica sem espaço, ou quando o número de chaves excede o limite (default de 128), ou quando atinge um determinado tempo • uma SSTable é imutável e não pode ser alterada
- 26. SSTables • Inúmeras SSTables serão criadas no disco para cada CF • Ler uma linha requer ler todos os SSTables de uma CF para obter o valor mais atual • Em algum momento é feito um merge das SStables para reduzir o tempo de leitura
- 27. HintedHandoff • Técnica otimizada de escrever dados em réplicas • Quando uma escrita é feita e um nó está fora: 1. O coordenador envia uma mensagem para outro nó vivo 2. Esse nó vai lembrar o nó caído das mudanças assim que ele voltar a funcionar
- 28. HintedHandoff • HH reduz a latência da escrita quando uma réplica está fora do ar • HH provê alta disponibilidade de escrita • Se não houve outros nós vivos, dependendo do nível de consistência, o coordenador envia a mensagem para si mesmo
- 29. Backup • A maneira mais simples de fazer backup é usando o Opscenter. • Selecione a keyspace, frequência de backup e frequência com que backups antigos são apagados. • Também é possível configurar o percentual mínimo de espaço em disco para que os backups não encham o disco.
- 30. PostgreSql
- 31. Modos de persistência • fsync: desligado, deixa ao SO a tarefa de fazer fsync. Em caso de crash, se desligado pode deixar a base inconsistente. • synchronous_commit: desligado, faz o fsync em até wal_writer_delay (default 200ms) * 3. • Se crashar, dados dos últimos 600ms sofrerão rollback, mantendo a base consistente. • Se ambos estiverem ligados, só retornam ok quando o dado estiver no disco.
- 32. Backup • Use a ferramenta pg_dump • É gerado um arquivo que pode ser enviado para outro datacenter.
- 33. Comparativo
- 34. fsync em config default Até 600ms Até 10000ms Até 1000ms
- 35. Estratégia de backup Automatizável via job Automatizável via OPSC Automático por default
- 36. Outras características Master/Slave Commitlog, HintedHandoff, Replicação em nós Master/Slave, AOF
- 37. Partindo para o HW Ephemeral Rotacional ESB SSD DISCOS
- 38. Ephemeral x ESB
- 39. Rotacional x SSD
- 40. Bibliografia • http://redis.io/topics/persistence • http://oldblog.antirez.com/post/redis- persistence-demystified.html • https://sites.google.com/site/developertips/H ome/java/how-cassandra-writes-and-reads- data • http://www.datastax.com/documentation/ops center/3.2/webhelp/index.html
- 41. Bibliografia • http://stackoverflow.com/questions/1037101 7/fsync-vs-write-system-call • http://www.postgresql.org/docs/9.0/static/ru ntime-config-wal.html • http://dba.stackexchange.com/questions/185 09/difference-between-fsync-and- synchronous-commit-postgresql • http://jasonirwin.ca/2011/08/17/ec2-raid- comparison-ephemeral-vs-ebs-volumes/