Rethinking Main Memory OLTP RecoveryAutores: 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

Roteiro

● Introdução

● Panorama VoltDB

● Logging por comandos

● Logging fisiológico

● Avaliação de desempenho

● Conclusões

2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Em um banco de dados baseado em disco, operações de inserção, atualizações e exclusão de dados nas tabelas dão refletidas no disco como uma atualização para a página do disco apropriada. Para cada página modificada, ARIES escreve um registro de log separado, com o número de sequência lógico e esclusivo da página considerada (LSN) - sendo a gravação de uma página uma operaçao atômica. Estes registros de log contém campos específicos do disco, como id da página modificada, juntamente com seu comprimendo e deslocamente de mudança. Esta é armazenado como um ID RID, ou registro, da forma (página#, Slot #)

Em um banco de dados de memória principal como VoltDB, uma tupla de dados pode ser acessados diretamente por sondagem sua localização memória principal sem qualquer indireção através de um orientada a página de buffer. Assim, as estruturas de registo Áries pode ser simplificada quando adaptadas a memória principal de registro fisiológico;

17

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

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

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

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 associ\a um bit sujo (indicando que determinada informação ainda não soufreu commit).

21

Logging Fisiológico - Checkpoint

● Apenas atualizações de transações efetuadas (committed) são deixadas persistentes.

22

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

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

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

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

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

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

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

Avaliação de Desempenho - Voter

30

Avaliação de Desempenho - TCP-C

31

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

Referências

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

33