O PolarDB-X Standard Edition substitui o sistema de transações do InnoDB pelo Lizard, um mecanismo personalizado desenvolvido com base no modelo de System Commit Number (SCN). Enquanto o InnoDB rastreia a visibilidade usando um array de IDs de transação ativas compartilhado entre todos os leitores, o Lizard atribui um único SCN a cada visão de transação. Essa abordagem elimina a contenção em estruturas globais, reduz o custo de propagação de snapshots e oferece suporte nativo a consultas FlashBack em versões históricas confirmadas.
Limites
O mecanismo de banco de dados deve ser compatível com o MySQL 8.0.
Funcionamento
Bancos de dados relacionais utilizam o Controle de Concorrência Multiversão (MVCC) para determinar a visibilidade dos dados com base nas versões confirmadas. O Lizard implementa o MVCC por meio de dois componentes principais:
SCN (System Commit Number): Número atribuído no momento da confirmação que define a ordem das transações confirmadas.
Slot de transação: Unidade de armazenamento durável que retém o SCN de uma transação confirmada. Cada linha modificada armazena o UBA do seu slot de transação em vez do SCN diretamente.
Transações de escrita
Ao iniciar uma transação, o sistema aloca um slot de transação e registra seu endereço como UBA.
Para cada linha modificada, o sistema grava
(SCN=NULL, UBA)no registro da linha.No momento da confirmação, o sistema atribui um SCN, grava-o no slot de transação, marca a transação como concluída e retorna o resultado da confirmação ao cliente.
Transações de leitura
Ao iniciar uma consulta, o sistema cria uma visão de transação lendo o SCN atual do gerador de SCN.
Para cada linha examinada, o sistema localiza o slot de transação por meio do UBA para recuperar o status de confirmação e o SCN da transação.
O sistema compara o SCN da linha com o SCN da visão para determinar se a versão da linha está visível.
Desempenho de transações baseadas em SCN
Em comparação ao sistema de transações do InnoDB, o modelo SCN do Lizard oferece três vantagens:
|
Vantagem |
Detalhe |
|
Independência de estrutura global |
As verificações de visibilidade não acessam um array compartilhado de IDs de transação ativas, o que reduz significativamente os conflitos de leitura e escrita sob carga concorrente. |
|
Visão de transação compacta |
A visão de transação contém apenas um SCN em vez de um array de IDs de transação ativas, tornando a propagação de snapshots mais eficiente. |
|
Consultas FlashBack |
O modelo SCN oferece suporte nativo a consultas FlashBack personalizadas em versões históricas confirmadas. |
Compromisso: No momento da confirmação, apenas o slot de transação é atualizado. O SCN em cada registro de linha modificado permanece NULL até que ocorra uma limpeza. Portanto, toda verificação de visibilidade precisa seguir o UBA até o slot de transação, resultando em uma busca adicional por linha.
O Lizard resolve essa sobrecarga com dois mecanismos de limpeza.
Limpeza na confirmação
Durante uma transação de escrita, o Lizard rastreia um subconjunto das linhas modificadas. Após a confirmação, ele preenche retroativamente o SCN confirmado nessas linhas. Para manter baixa a latência de confirmação, o número de linhas preenchidas é limitado com base na quantidade atual de registros e na capacidade de carga do sistema.
Limpeza adiada
Quando uma consulta lê uma linha cujo SCN ainda é NULL, o Lizard resolve o SCN consultando o slot de transação via UBA. Se a transação já estiver confirmada, o Lizard grava o SCN de volta no registro da linha como efeito colateral. Leituras subsequentes da mesma linha ignoram completamente a busca pelo UBA.
Reutilização de slots de transação
Os slots de transação não podem crescer indefinidamente. O Lizard os recicla por meio de uma lista livre: os slots retornam à lista livre e as novas transações obtêm recursos primeiramente dessa lista.
Para evitar a sobrecarga de percorrer várias páginas de dados em busca de um slot livre, o Lizard mantém uma tabela de cache de páginas de slots de transação. A alocação de slots lê diretamente desse cache, reduzindo o custo de E/S da reciclagem de slots.
Desempenho
A sobrecarga de limpeza aplica-se apenas durante consultas de leitura, não durante contenção de hotspots. Os resultados de benchmark a seguir comparam o sistema de transações SCN com o InnoDB tradicional:
|
Sistema |
QPS |
TPS |
Latência no percentil 95 (ms) |
|
Lizard |
636.086,81 |
31.804,34 |
16,07 |
|
MySQL 8.0.32 |
487.578,78 |
24.378,94 |
34,33 |
|
MySQL 8.0.18 |
311.399,84 |
15.577,15 |
41,23 |
Ambiente de teste: Intel 8269CY 104C, 16 milhões de linhas, 512 threads simultâneas de leitura e escrita.
Comparado ao MySQL 8.0.32, o Lizard proporciona uma melhoria de 30% no throughput e uma redução de 53% na latência p95.