O documento discute técnicas de logging para recuperação em sistemas de banco de dados de alto desempenho (OLTP). Ele propõe o "logging por comandos", que grava apenas os comandos das transações no log, em vez de imagens completas de dados como no estilo ARIES. Os resultados experimentais mostram que o logging por comandos oferece melhor desempenho do que o logging fisiológico para sistemas OLTP, fornecendo até 1,5x mais throughput.

1. Rethinking Main Memory
OLTP Recovery
Autores: Nirmesh Malviya, Ariel Weisberg, Samuel Madden e Michael
Stonebraker. Trabalho multi-institucional pelo MIT CSAIL e VoltDB Inc.
Apresentado por Lucas Vinícius e Rafael Macêdo
Professor: João Batista

2. Roteiro
● Introdução
● Panorama VoltDB
● Logging por comandos
● Logging fisiológico
● Avaliação de desempenho
● Conclusões
2

3. Introdução
● Sistemas de recuperação asseguram a durabilidade das transações
efetuadas (em estado commit), garantindo que após recuperação:
○ Transações commitadas antes da quebra serão refletidas no banco de dados;
○ Transações não commitadas não refletem no banco de dados.
● O padrão de ouro para recuperação é o write-ahead logging,
exemplificado por sistemas ARIES;
○ Escreve tudo em um arquivo de log;
○ Utiliza uma combinação de UNDO lógico e REDO físico.
3

4. Introdução
● Sistemas de logging convencionais (e. g. ARIES) gravam no log uma
imagem do dado antes e depois da modificação, antes que seja
propagada para o disco;
● Existe uma alternativa ao logging no estilo ARIES:
○ Ao invés de gravar as modificações, grava a lógica da transação;
○ Aplicações que executam o mesmo template de consultas várias vezes -> simplificação
do log;
○ Log: identificador da transação (e. g. ID da transação) + parâmetros da consulta.
4

5. Termos Importantes
● Tempo de Execução;
● Tempo de Recuperação;
● Sistemas OLTP: sistemas de alta vazão para processamento de
transações;
● Algoritmos do estilo ARIES: Write Ahead Logging, por exemplo.
5

6. Panorama VoltDB
● VoltDB é um sistema de banco de dados na memória principal de código aberto;
● É distribuído em memória principal, executado em um cluster;
● Cada nó tem um componente iniciador ao qual envia transações para as
partições/réplicas apropriadas;
● Utiliza particionamento horizontal;
● Cada seção do particionamento pode ser replicada em nós para prover alta
disponibilidade. 6

7. Panorama VoltDB
● Transações no VoltDB são tratadas como procedimentos armazenados
(stored procedures);
● Transações são executadas de forma serial;
● Mesmo transações distribuídas são executas em uma ordem global.
7

8. Panorama VoltDB
● O VoltDB possui um componente chamado iniciador;
● O iniciador é responsável por:
○ Receber requisições dos clientes;
○ Despachar as transações para o nó apropriado;
○ Gerar id’s com base no tempo.
8

9. Logging por Comandos
● A ideia é simplificar o log ao qual o comando foi emitido antes que a
transação seja executada;
● Segue a abordagem write-ahead;
● Vantagem: requer apenas que uma entrada de log seja escrita por
transação;
● Entrada de log: nome do procedimento + parâmetros de entrada;
● Entrada de log << consultas SQL inteiras.
9

10. Logging por Comandos - escrevendo no log
● Transação de partição simples -> simples;
● Transações distribuídas: apenas o site (nó) coordenador pode escrever no
log;
● Transações são escritas diretamente ao log de comandos depois delas
terem sido recebidas;
● Em tempo de recuperação, as transações devem ser ordenadas de
maneira que concorde com a ordenação global das transações em tempo
de execução.
10

11. Logging por Comandos - escrevendo no log
● Na implementação do logging por comando em VoltDB, o log gravado para
cada transação tem a estrutura abaixo:
11

12. Logging por Comandos - otimizações
● Gravações em logs por comando podem ser liberadas para o disco de
forma síncrona ou assíncrona;
● Semântica ACID: somente com logging síncrono, porque uma gravação de
log para a transação é forçada para o disco antes que a transação seja
conhecida como comitada (efetuada);
● No artigo, apresentam-se resultados apenas para a forma síncrona.
12

13. Logging por Comandos - otimizações
● Para melhorar a performance:
○ Registra lotes de log para transações múltiplas;
○ Descarrega os lotes juntos para o disco;
○ Envia um commit para as transações do lote;
● Vantagem: reduz a quantidade de escrita no disco.
13

14. Logging por Comandos - recuperação
● É realizada da seguinte forma:
○ O snapshot do banco de dados no disco é carregado para a memória;
■ O snapshot não possui índices;
■ Todos os índices são reconstruídos, podendo ser em paralelo com a restauração
do snapshot;
○ O log de comandos compartilhados (presente na memória) é lido por uma thread
dedicada;
○ Começando pela primeira transação não refletida ao banco, o log é lido e a transação
correspondente é liberada para o local apropriado.
14

15. Logging por Comandos - recuperação
● Esta abordagem funciona mesmo que o número de nós durante a
recuperação seja diferente do número em tempo de execução;
○ Exige que o número de partições do banco permaneça o mesmo;
● Dado que cada registro no log corresponde a uma transação:
○ A ordenação global em tempo de recuperação é idêntica a ordenação antes da
quebra.
15

16. Logging por Comandos - recuperação
● Com esta abordagem, se ocorrer uma quebra logo após a escrita no log
para uma transação (antes de sua execução):
○ A transação é recuperada;
○ O estado do banco é definido como se a transação tivesse sido efetuada;
○ O cliente não é notificado depois da recuperação.
16

17. Algoritmo ARIES
● ARIES do inglês: Algorithm for Recovery and Isolation Exploiting
Semantics;
● Empregados na recuperação de sistemas de banco de dados tradicionais;
● Os sistemas do tipo ARIES basicamente exigem que as seguintes
condições sejam cumpridas:
○ Cada operação (Insert / delete / update) realizada por uma transação são gravadas em
um log antes mesmo que os dados em disco sejam atualizados.
○ Cada uma dessas entrada de log contém o antes e depois de imagens de dados
modificadas.
17

18. Algoritmo ARIES - Visão Geral da
Recuperação
● Recuperação usando ÁRIES acontece em vários passes (parsers):
○ Análise;
○ Passagem de REDO física;
○ Passagem de UNDO lógico.
18

19. Logging Fisiológico
● Algoritmo do estilo ARIES aplicado a bancos de dados em memória
principal;
● Todos os dados no registro do log relacionados aos campos do disco
podem ser omitidos;
● Para cada modificação para uma tupla de banco de dados: grava uma
entrada única para o registo de forma serializada de uma imagem da tupla
antes e depois de ser modificada.
19

20. Logging Fisiológico
● A tupla é referenciado através de um par (id-tabela, chave-primária) que
identifica exclusivamente a tupla dados modificados;
○ Se uma tabela não tem uma chave primária única e a operação de modificação não é uma
inserção, a imagem da tupla anterior inteira deve ser utilizada para referenciar a tupla na
tabela.
20

21. Logging Fisiológico - Páginas Sujas
● Os bancos de dados em memória não têm o conceito de páginas sujas e
(diferente do ARIES) o logging fisiológico não mantem uma tabela de
páginas sujas na memória;
● Para saber se determinado registro é sujo, o sistema associa um bit sujo
(indicando que determinada informação ainda não soufreu commit).
21

22. Logging Fisiológico - Checkpoint
● Apenas atualizações de transações efetuadas (committed) são deixadas
persistentes.
22

23. Logging Fisiológico - Recuperação
● Transações do tipo OLTP são curtas, assim:
○ A quantidade de dados de log produzido por atualização na transação é pequeno e não
necessita de escrita apressadamente no disco;
○ Dados presentes no final da gravação do log de atualizações deve ser descarregado antes
que a transação seja efetuada (commited).
● É melhor bufferizar todas as gravações de uma única transação e escrever
todas elas no log juntas.
23

24. Logging Fisiológico - Recuperação
● O logging fisiológico é síncrono:
○ O que o log escreve de uma transação efetuada (committed) são forçados para o disco
antes que o status de transação commited seja reportada ao usuário.
● O log fisiológico usa commit em grupo:
○ Escritas de diferentes transações são colocadas juntas em um lote para alcançar melhor
throughput em disco e reduzir a sobrecarga de por transação.
24

25. Logging Fisiológico - Escrevendo no Log
● A estrutura da gravação de log para o logging fisiológico na
implementação do VoltDb é mostrado na figura 2.
25

26. Avaliação de Desempenho - Hardware
Utilizado
● Hardware utilizado para executar os experimentos:
○ Um único Intel Xeon, duas socket com clock de 2.4 GHz e 8 núcleo
○ 24 GB de memória RAM
○ 12 TB de disco rígido
○ Cache de gravação com bateria de reserva
○ Sistema operacional: Ubuntu Server
26

27. Avaliação de Desempenho Benchmarks
Utilizados
● Os benchmarks do tipo OLTP usados (geram um ambiente de teste para
bancos de dados em memória) foram:
○ TPC-C
○ Voter
● Foram utilizados dois benchmarks, pois estes diferente signifcantemente
na complexidade das transações utilizadas.
○ O trabalho feito por cada transação no Voter é mínimo se comparado ao TPC-C;
○ As tabelas do banco de dados do TPC-C são muito mais largas e relacionadas se
comparadas com as do Voter. 27

28. Avaliação de Desempenho - Testes
Realizados
● Os resultados experimentais foram obtidos executando os benchmarks no
sistema em três modos diferentes:
○ Modo 1: Logging por comando ligado e logging fisiológico desligado;
○ Modo 2: Logging fisiológico ligado e logging por comando desligado;
○ Modo 3: Ambos os loggings desligados.
28

29. Avaliação de Desempenho - Testes
Realizados
● Os resultados em gráfico (medida de performance X Taxa de clientes) a
seguir demonstram os seguintes modos de comparação de performance:
○ Throughput
○ Latência
○ Taxa de recuperação
● Para todos os experimentos, a frequência em que o sistema relizava um
“snapshot” era de 180 segundos
29

30. Avaliação de Desempenho - Voter
30

31. Avaliação de Desempenho - TCP-C
31

32. Conclusões
● O write-ahead logging tem sido o padrão de ouro para recuperação de BD;
● No artigo, foi mostrado que para sistemas de alta vazão esta abordagem não é o
caminho que apresenta maior desempenho;
● Foi proposta um técnica de logging por comandos que somente grava as transações
executados no BD e que foi comparada com outra técnica, estilo ARIES, de logging
fisiológico, para comprovar seu desempenho;
● Os testes realizados apresentam que o logging por comandos pode oferecer 1.5X mais
vazão de transações em tempo real (run time) que o logging fisiológico do estilo ARIES,
porém exige um maior tempo de recuperação em caso de falhas (recovery time).
32

33. Referências
Rethinking Main Memory OLTP Recovery. Nirmesh Malviya, Ariel Weisberg,
Samuel Madden, Michael Stonebraker. ICDE, 2014.
33