Esta página foi traduzida por máquina. Leia o original em inglês. English

← Recursos do servidor HQbird

O HQbird pode armazenar em cache os BLOBs no espaço temporário, a fim de acelerar as operações BLOB (15%–200% mais rápido do que no Firebird padrão) e de evitar o crescimento do arquivo do banco de dados em caso de operações BLOB equivocadas.

O HQbird usa um parâmetro extra do firebird.conf, BlobTempSpace, para controlar esse recurso. A opção de cache pode ser:

  • 0 — desabilitada,
  • 1 — habilitada para PSQL (padrão),
  • 2 — habilitada para todas as operações BLOB.

Resultado em resumo

No teste abaixo, a mesma carga de trabalho foi executada cerca de 12 vezes mais rápido com BlobTempSpace habilitado:

Armazenamento temporário BlobTempSpace desligado BlobTempSpace ligado Aceleração
RAM drive (48 GB) 108,2 s 9,0 s 12,0×
SSD (Samsung 870 QVO, 1 TB) 106,0 s 9,1 s 11,7×

Tempo total = EXECUTE BLOCK + COMMIT, média de duas execuções.

Comparação do tempo total com BlobTempSpace

Onde o tempo é gasto

O ganho vem de dois pontos:

  • O EXECUTE BLOCK é 2,3–2,4× mais rápido. A concatenação de BLOBs é executada no espaço temporário, não em páginas do banco de dados.
  • O COMMIT é quase instantâneo. Sem o cache, o commit grava cerca de 1,1 milhão de páginas no banco de dados (81–88 s). Com o cache, ele grava 3 021 páginas (15–16 ms).
Tempos de EXECUTE BLOCK e COMMIT com BlobTempSpace
Armazenamento temporário BlobTempSpace EXECUTE BLOCK COMMIT Gravações de páginas (block + commit)
RAM drive desligado 20,9 s 87,4 s 1 117 485
RAM drive ligado 9,0 s 0,015 s 3 057
SSD desligado 21,8 s 84,2 s 1 117 485
SSD ligado 9,1 s 0,016 s 3 057

Com BlobTempSpace habilitado, o banco de dados recebe cerca de 365 vezes menos gravações de páginas. As buscas (fetches) e marcações (marks) permanecem quase iguais (5,15 milhões de fetches, 3,45 milhões de marks), portanto o banco de dados realiza o mesmo trabalho lógico; apenas as gravações físicas desaparecem.

Configuração do teste

  • Carga de trabalho: um EXECUTE BLOCK que constrói BLOBs por concatenação (750 linhas), seguido de COMMIT. Cada caso foi executado duas vezes (run-1, run-2).
  • Armazenamento temporário (FIREBIRD_TMP):
    • RAM drive: WinRamTech x64 (ex. Qsoft), 48 GB.
    • SSD: Samsung 870 QVO, 1 TB, com TempCacheLimit = 48G (RAM drive desabilitado).
  • Medição: estatísticas de trace do Firebird (tempo decorrido, leituras, gravações, fetches, marks).
  • Com BlobTempSpace desligado, o tamanho final do banco de dados foi de 8 839 MB.

Resultados brutos

Armazenamento temporário BlobTempSpace Execução Ação Tempo decorrido, ms Gravações Fetches Marks
RAM drive desligado 1 EXECUTE BLOCK 20 104 1 127 5 154 541 3 450 817
RAM drive desligado 1 COMMIT 87 531 1 116 358 1 1
RAM drive desligado 2 EXECUTE BLOCK 21 621 1 127 5 154 541 3 450 817
RAM drive desligado 2 COMMIT 87 229 1 116 358 1 1
RAM drive ligado 1 EXECUTE BLOCK 9 039 36 5 153 997 3 450 273
RAM drive ligado 1 COMMIT 15 3 021 1 1
RAM drive ligado 2 EXECUTE BLOCK 8 976 36 5 153 997 3 450 273
RAM drive ligado 2 COMMIT 15 3 021 1 1
SSD desligado 1 EXECUTE BLOCK 21 831 1 127 5 154 541 3 450 817
SSD desligado 1 COMMIT 86 726 1 116 358 1 1
SSD desligado 2 EXECUTE BLOCK 21 834 1 127 5 154 541 3 450 817
SSD desligado 2 COMMIT 81 614 1 116 358 1 1
SSD ligado 1 EXECUTE BLOCK 9 084 36 5 153 997 3 450 273
SSD ligado 1 COMMIT 16 3 021 1 1
SSD ligado 2 EXECUTE BLOCK 9 074 36 5 153 997 3 450 273
SSD ligado 2 COMMIT 16 3 021 1 1

As leituras foram 0 em todas as execuções.

Observações

  • O RAM drive e o SSD apresentam praticamente o mesmo resultado. O tipo de armazenamento temporário não é o gargalo para esta carga de trabalho: o próprio cache proporciona o ganho.
  • A aceleração depende da carga de trabalho. Concatenação pesada de BLOBs em PSQL, como neste teste, é o que mais ganha. Operações BLOB típicas ganham 15%–200%.