estou seguro com no sql
DESCRIPTION
Demonstra a segurança de durabilidade de dados do NoSQL e faz um comparativo entre Cassandra, Redis e PostgreSQLTRANSCRIPT
Estou seguro com NoSQL?
Rafael Redondo
O que falaremos
ACID(Atomicity, Consistency, Isolation, Durability)
+ backup
O que não falaremos
SQL X
NoSQL
O que não falaremos
BASE(Basically Available, Soft state, Eventual consistency)
CAP(Consistency, Availability, Partition tolerance)
Programação
• Durabilidade• Redis• Cassandra• Comparativo: Redis, Cassandra,
PostgreSQL
Durabilidade
“Garantir que os dados estarão disponíveis em definitivo.”
O SO e o Disco
CLIENT
MÍDIA FÍSICA
CACHES BUFFERS
CACHES BUFFERS
CONTROLADOR DE DISCO
BANCO DE DADOS
SOWRITE
FSYNC
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
WRITE vs FSYNC
xDesempenho
Usa Cache
Garantia
Usa Recursos
LINUX: 30 Segundos
Qual o requisito não-funcional mais importante?
Redis
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.
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.
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.
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.
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.
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.
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.
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.
Cassandra
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
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
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.
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
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
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
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
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ó vivo2. Esse nó vai lembrar o nó caído das mudanças
assim que ele voltar a funcionar
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
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.
PostgreSql
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.
Backup
• Use a ferramenta pg_dump• É gerado um arquivo que pode ser enviado
para outro datacenter.
Comparativo
fsync em config default
Até 600ms
Até 10000ms
Até 1000ms
Estratégia de backup
Automatizável via job
Automatizável via OPSC
Automático por default
Outras características
Master/Slave
Commitlog, HintedHandoff, Replicação em nós
Master/Slave, AOF
Partindo para o HW
xEphemeral
Rotacional
ESB
SSDDISCOS
Ephemeral x ESB
Rotacional x SSD
Bibliografia
• http://redis.io/topics/persistence• http://oldblog.antirez.com/post/redis-persiste
nce-demystified.html• https://sites.google.com/site/developertips/H
ome/java/how-cassandra-writes-and-reads-data
• http://www.datastax.com/documentation/opscenter/3.2/webhelp/index.html
Bibliografia
• http://stackoverflow.com/questions/10371017/fsync-vs-write-system-call
• http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html
• http://dba.stackexchange.com/questions/18509/difference-between-fsync-and-synchronous-commit-postgresql
• http://jasonirwin.ca/2011/08/17/ec2-raid-comparison-ephemeral-vs-ebs-volumes/
Bibliografia
• http://www.samsung.com/global/business/semiconductor/minisite/SSD/de/html/about/whitepaper01.html