A gravação de Binary Large Objects (BLOBs) no MySQL em ambientes de alta concorrência frequentemente causa gargalos de desempenho, como contenção de locks e geração excessiva de redo log. PolarDB resolve esses desafios com otimizações no nível do kernel que eliminam a contenção de locks, a pressão de I/O e problemas de gerenciamento de espaço durante operações com BLOBs. Isso melhora significativamente o desempenho de DML e DDL, garantindo que seus serviços funcionem de forma estável e eficiente sob cargas de trabalho altamente concorrentes.
Visão geral
Um Binary Large Object (BLOB) é um tipo de campo de banco de dados usado para armazenar objetos de dados grandes, como imagens, documentos e textos longos. No mecanismo nativo MySQL InnoDB, quando um campo BLOB em uma linha de dados excede determinado tamanho, o InnoDB o armazena em páginas de dados separadas fora da página principal (off-page). Embora esse mecanismo lide com grandes volumes de dados, ele também introduz três grandes desafios de desempenho:
Gargalo de gravação concorrente: A atualização de um BLOB off-page adquire um lock pessimista. Isso permite que apenas uma única thread grave BLOBs na tabela por vez, limitando severamente a concorrência.
Aumento da pressão de I/O: Campos grandes geram entradas extensas de redo log. Se o I/O do disco for insuficiente, o flush de logs torna-se um gargalo e bloqueia operações de gravação em primeiro plano.
Reclamação de espaço atrasada: O processo de limpeza de dados antigos de BLOB, conhecido como processo Purge, é ineficiente. Isso pode levar ao inchaço do espaço de armazenamento e à degradação do desempenho.
O recurso de otimização de BLOB no PolarDB soluciona esses problemas. Ele otimiza todo o ciclo de vida dos BLOBs, incluindo gravações, atualizações e reclamação de espaço, diretamente no kernel, sem exigir alterações na aplicação.
Faturamento
O recurso de otimização de desempenho de BLOB está integrado ao kernel do PolarDB e está disponível sem custo adicional.
Otimizar o desempenho de gravação de BLOB
Se você enfrentar gargalos de throughput ou alta latência ao gravar em tabelas BLOB durante horários de pico de negócios, a causa geralmente é a contenção de locks de gravação. O PolarDB resolve esse problema com pré-alocação de páginas e otimização de latch de índice.
Pré-alocação de páginas
Esta otimização divide o processo de gravação de BLOB nas seguintes etapas:
Calcula o número necessário de páginas de dados e as aloca em uma única operação em lote.
Copia os dados em um estado livre de locks e preenche as páginas recém-alocadas com o conteúdo do BLOB.
Anexa a cadeia resultante de páginas de dados ao registro de índice com uma única operação de lock otimista.
Durante todo esse processo, apenas a fase inicial de alocação de espaço é exclusiva. As operações mais demoradas, como a cópia de dados, podem ser executadas simultaneamente com outras gravações de BLOB. Além disso, como a cópia de dados ocorre fora da seção crítica, o sistema evita o risco de uma única gravação gerar grande quantidade de dados de redo log que poderiam preencher o buffer de log e bloquear gravações. Em última análise, esse mecanismo minimiza o tempo de retenção de locks globais e melhora significativamente o desempenho de gravação concorrente.
Otimização de latch de índice
Para tabelas com campos BLOB pequenos (abaixo de 8 KB) ou de tamanhos mistos, o MySQL nativo frequentemente abandona o lock otimista prematuramente durante atualizações devido a operações de modificação da estrutura da página de índice (SMOs). Ele então recorre a um modelo de lock pessimista ineficiente, o que impacta severamente o desempenho concorrente. A otimização de latch de índice resolve esse gargalo ao manter as operações no caminho otimista por mais tempo. Esta otimização funciona nas seguintes etapas:
Manter o caminho otimista: Quando uma possível atualização de campo BLOB é detectada, a lógica de otimização não muda imediatamente para um lock pessimista. Em vez disso, ela continua a manter um latch compartilhado (S-latch), que tem menor probabilidade de conflito, e permanece no caminho de atualização otimista.
Pré-construir e tentar atualização: No caminho otimista, o sistema pré-constrói a estrutura de dados BLOB necessária para a atualização e tenta modificar a página de índice diretamente.
-
Decidir e confirmar ou retroceder:
Sucesso: Se o registro atualizado couber nos requisitos de espaço da página de índice atual, a operação é concluída rapidamente no caminho otimista.
Falha: Se a página não tiver espaço suficiente, a otimização abandona automaticamente a tentativa e retorna perfeitamente ao caminho de lock pessimista nativo do MySQL. O caminho nativo então conclui toda a operação de atualização e garante a consistência dos dados.
A principal vantagem dessa abordagem otimista é o aumento significativo na taxa de sucesso das atualizações otimistas. Ela permite que muitas operações, que de outra forma recorreriam ao lock pessimista, sejam concluídas de maneira mais eficiente. Isso aprimora consideravelmente o throughput para atualização de dados BLOB de tamanhos mistos sob alta concorrência.
Ativar otimizações de gravação
No console do PolarDB, acesse a página para visualize e modifique os seguintes parâmetros e ative essas otimizações:
|
Parâmetro |
Descrição |
Versões suportadas |
|
|
Ativa ou desativa a pré-alocação de páginas para BLOBs. Valores válidos:
|
|
|
|
Define o comprimento máximo de uma única coluna BLOB para a qual a pré-alocação de páginas é usada. |
|
|
|
Ativa ou desativa a otimização de latch de índice para BLOBs. |
Reduzir redo log para gravações de BLOB
Se sua carga de trabalho envolver a gravação de grandes quantidades de dados BLOB e a taxa de geração de redo log se tornar um gargalo de I/O, ative a compressão de redo para aliviar a pressão.
A compressão de redo funciona compactando entradas de redo log relacionadas a BLOBs em paralelo antes de gravá-las no buffer de log. Esse processo reduz significativamente o volume de dados de redo log gravados no disco; testes mostram uma redução média de 40% a 60%. Isso diminui a pressão de I/O de armazenamento e impede que o módulo de redo se torne um gargalo que afeta o desempenho geral de gravação. Durante a recuperação de falhas, o sistema descompacta e aplica esses logs automaticamente.
Ativar compressão de redo
No console do PolarDB, acesse a página para visualize e modifique os seguintes parâmetros e ative esta otimização:
|
Parâmetro |
Descrição |
Versões suportadas |
|
|
Define o algoritmo de compressão para logs de redo de BLOB. Valores válidos:
|
|
|
|
Define o nível de compressão para o algoritmo selecionado. Valores válidos: 0 a 9. Padrão: 6. |
Acelerar a reclamação de espaço de BLOB
Se a reclamação de tablespace estiver lenta e os arquivos continuarem a crescer após exclusões ou atualizações frequentes de dados BLOB, a causa raiz é a ineficiência do processo Purge em segundo plano nativo do MySQL. Ao limpar dados, esse processo primeiro adquire locks principais, como Index SX, antes de ler páginas BLOB. Se uma página não estiver na memória, uma operação de I/O de disco demorada é acionada enquanto o lock é mantido, o que pode bloquear outras operações concorrentes na tabela por um longo período. A otimização de pré-leitura do Purge do PolarDB resolve esse gargalo ao separar as operações de I/O do processo de bloqueio. Esta otimização funciona nas seguintes etapas:
Identificar páginas alvo: Antes de adquirir um lock e iniciar a limpeza, o processo Purge identifica a cadeia completa de BLOBs off-page que precisam ser recuperados.
Pré-leitura assíncrona: O sistema inicia solicitações de I/O assíncronas para carregar as páginas alvo que ainda não estão na memória do disco para o buffer pool.
Limpeza rápida: Após o carregamento de todas as páginas na memória, o processo Purge adquire os locks principais necessários, como
Index SX, e executa rapidamente as operações de liberação de páginas na memória e modificação de metadados.
O mecanismo de pré-leitura do Purge evita a execução de qualquer operação de I/O de disco dentro de uma seção crítica onde um lock é mantido. Ao mover as operações de I/O mais demoradas para um estágio anterior, o tempo de retenção do lock é reduzido à duração de operações rápidas na memória. Isso não apenas melhora a eficiência da reclamação de dados BLOB e evita o inchaço de espaço, mas, principalmente, reduz o bloqueio de cargas de trabalho em primeiro plano, como gravações de alta concorrência, pelo processo de limpeza em segundo plano. Como resultado, aprimora o desempenho geral de concorrência e a estabilidade do banco de dados.
Ativar pré-leitura do Purge
No console do PolarDB, acesse a página para visualize e modifique o seguinte parâmetro e ative esta otimização:
|
Parâmetro |
Descrição |
Versões suportadas |
|
|
Ativa ou desativa a pré-leitura do Purge para BLOBs. Valores válidos:
|
Suportado em todas as versões. |
Melhorar a eficiência de execução de DDL
Se você precisar executar operações DDL, como ALTER TABLE, em tabelas com grande quantidade de dados BLOB e as operações demorarem muito, ative as otimizações de BLOB relacionadas a DDL para reduzir significativamente o tempo de operação.
Pré-alocação de páginas: Como colunas de estouro para campos BLOB existem na chave primária, operações DDL que reconstroem a tabela principal também envolvem a gravação de campos BLOB. A otimização de pré-alocação de páginas usa um método de bloqueio mais direto e simplificado para gravar dados BLOB, evitando a sobrecarga de lidar com conflitos complexos de concorrência e melhorando significativamente a eficiência de reconstrução.
Otimização de latch: O DDL paralelo particiona a árvore de chave primária para que múltiplas threads de trabalho não operem na mesma página de dados. Esta otimização protege a alocação de novas páginas independentemente, permitindo que outras operações sejam executadas simultaneamente e melhorando a eficiência.
-
Otimização de redo:
Agregação de páginas: Durante um bulk load, em vez de gerar uma entrada de redo log para cada registro, o sistema grava as alterações de uma página de dados inteira como uma única entrada grande de redo log após a página estar cheia. Isso melhora a eficiência das operações de redo.
Compressão agregada: As entradas grandes e agregadas de redo log são então compactadas para reduzir ainda mais a quantidade de dados de redo log gerados durante o processo DDL.
Ativar otimizações de DDL
No console do PolarDB, acesse a página para visualize e modifique os seguintes parâmetros e ative essas otimizações:
Alguns parâmetros na tabela a seguir não podem ser modificados manualmente. Se precisar alterá-los, envie um ticket para obter assistência.
|
Parâmetro |
Descrição |
Versões suportadas |
|
|
Especifica se as otimizações de BLOB devem ser ativadas durante operações DDL. Valores válidos:
|
|
|
|
Especifica se a otimização de lock de índice deve ser ativada durante operações DDL. Valores válidos:
|
|
|
|
Especifica se a agregação de páginas de redo deve ser ativada durante o bulk load de DDL. Valores válidos:
|
|
|
|
Define o algoritmo de compressão de redo para bulk load de DDL. Valores válidos:
|
|
|
|
Define o alvo para compressão de redo durante operações DDL. Valores válidos:
|
|
Otimizações de módulos relacionados
Em cenários de BLOB de alto throughput, gargalos também podem ocorrer em outros módulos. Para alcançar desempenho ainda melhor, o PolarDB fornece as seguintes otimizações relacionadas:
Gravações paralelas e assíncronas de redo log: Múltiplas threads fragmentam os dados no buffer de redo log e os enviam simultaneamente como tarefas de I/O assíncronas. Isso aumenta significativamente o throughput de gravação de redo log, atingindo até 4 GB/s em testes.
Otimização de extensão de arquivo: Construída sobre o sistema de arquivos distribuído desenvolvido internamente pelo PolarDB, as operações de extensão de tablespace exigem apenas a modificação de pequena quantidade de metadados. A operação nativa de preenchimento de arquivo com zeros é eliminada, de modo que o tempo e a sobrecarga de locks da extensão de arquivo deixam de ser um gargalo.
Flush de páginas sujas sem locks: Esta otimização utiliza tecnologia de shadow page. Ao realizar o flush de uma página suja, o sistema primeiro constrói uma cópia na memória, libera o lock da página e, em seguida, usa a cópia para a operação de I/O. Isso impede que a operação de I/O bloqueie solicitações de gravação, pois nenhum lock de página é mantido durante o flush.
Benchmarks de desempenho
Os dados a seguir mostram as melhorias de desempenho em cenários DML e DDL após a ativação das otimizações de BLOB.
-
Desempenho DML: Em cenários de alta concorrência com comprimentos de linha de 100 KB e 200 KB, as otimizações do PolarDB melhoram o desempenho de inserção e atualização em quase 3 vezes. Quando combinadas com compressão de redo, o desempenho melhora de 4 a 5 vezes.
Desempenho DDL: Para uma tabela de 40 GB contendo campos BLOB, ativar essas otimizações aumenta a taxa de gravação DDL em 5 a 6 vezes e reduz o tempo total de execução em 84%.
