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