FireBase - o maior portal sobre banco de dados Firebird em português

Prefácio

Desenvolvedores de aplicativos e administradores que usam o SGBD Firebird frequentemente se perguntam: e se implantassem o Firebird na nuvem e o acessassem por uma conexão de internet? No entanto, após testar essa configuração, muitos ficam desapontados, pois a velocidade de transferência de dados em redes de alta latência (como a internet) deixa muito a desejar. Na maioria dos casos, a velocidade de busca de dados de cursores gerados por consultas SQL é aceitável, mas assim que campos BLOB (dados binários ou de texto) aparecem em tais consultas, a velocidade de transferência de dados cai catastroficamente.

Neste artigo, discutiremos como os BLOBs são transmitidos pela rede, os desafios que os usuários enfrentam ao usar o Firebird em redes de alta latência (trabalhando pela internet) e exploraremos soluções para esses problemas. Também abordaremos as melhorias na transmissão de BLOBs nas versões mais recentes do Firebird (5.0.2 e 5.0.3).

1. Aplicação e Banco de Dados para Testes

Para demonstrar várias maneiras de trabalhar com campos BLOB, bem como medições de desempenho, uma pequena aplicação de teste foi escrita, cujos códigos-fonte estão disponíveis em https://github.com/IBSurgeon/fb-blob-test. Na mesma página, você pode baixar uma compilação pronta para Windows x64 e um banco de dados de teste.

Esta aplicação testa o desempenho da transferência apenas de campos BLOB de texto, mas os mesmos mecanismos podem ser aplicados a BLOBs binários.

Para demonstrar a transferência de BLOBs pela rede, precisaremos de um banco de dados contendo tabelas com campos BLOB, e é desejável que o tamanho desses campos BLOB varie de muito pequeno a médio. Para este propósito, você pode usar os códigos-fonte de algum projeto Open Source, por exemplo, a biblioteca UDR lucene_udr.

O conteúdo dos arquivos será armazenado em uma tabela com a seguinte estrutura:


CREATE TABLE BLOB_SAMPLE (
    ID         BIGINT GENERATED BY DEFAULT AS IDENTITY,
    FILE_NAME  VARCHAR(255) CHARACTER SET UTF8 NOT NULL,
    CONTENT    BLOB SUB_TYPE TEXT CHARACTER SET UTF8
);

ALTER TABLE BLOB_SAMPLE ADD PRIMARY KEY (ID);
ALTER TABLE BLOB_SAMPLE ADD UNIQUE (FILE_NAME);

Como o projeto não é grande, o número de arquivos de código-fonte nele não é tão grande quanto gostaríamos. Para tornar os resultados dos testes mais visuais em números, aumentaremos o número de registros BLOB para 10.000. Para fazer isso, criaremos uma tabela separada BLOB_TEST com a seguinte estrutura:


RECREATE TABLE BLOB_TEST (
    ID             BIGINT GENERATED BY DEFAULT AS IDENTITY,
    SHORT_CONTENT  VARCHAR(8191) CHARACTER SET UTF8,
    CONTENT        BLOB SUB_TYPE TEXT CHARACTER SET UTF8,
	SHORT_BLOB     BOOLEAN DEFAULT FALSE NOT NULL,
    CONSTRAINT PK_BLOB_TEST PRIMARY KEY (ID)
);

Aqui removemos o campo de armazenamento de nome de arquivo FILE_NAME, mas adicionamos o campo SHORT_CONTENT. Preencheremos este campo se o conteúdo do campo BLOB CONTENT puder ser armazenado inteiramente em um campo do tipo VARCHAR(8191) CHARACTER SET UTF8. Também adicionaremos o campo SHORT_BLOB, que é uma indicação de que o BLOB é "curto" (cabe em VARCHAR). Precisaremos desses campos ao realizar vários testes comparativos.

Então, precisamos preencher a tabela BLOB_TEST a partir da tabela BLOB_SAMPLE, para que a tabela de destino tenha 10.000 registros. Para isso, usaremos o seguinte script:


SET TERM ^;

EXECUTE BLOCK
AS
DECLARE I INTEGER = 0;
DECLARE IS_SHORT BOOLEAN;
BEGIN
  WHILE (TRUE) DO
  BEGIN
    FOR
      SELECT
        ID,
        CONTENT,
        CHAR_LENGTH(CONTENT) AS CH_L
      FROM BLOB_SAMPLE
      ORDER BY FILE_NAME
      AS CURSOR C
    DO
    BEGIN
      I = I + 1;
      -- The contents of the BLOB are placed into a string variable
      -- with a length of 8191 characters
      IS_SHORT = (C.CH_L < 8191);

      INSERT INTO BLOB_TEST (
        SHORT_CONTENT,
        CONTENT,
        SHORT_BLOB
      )
      VALUES (
        IIF(:IS_SHORT, :C.CONTENT, NULL), -- if BLOB is short we write it in VARCHAR field
        :C.CONTENT,
        :IS_SHORT
      );
      -- exit when 10000 records are inserted
      IF (I = 10000) THEN EXIT;
    END
  END
END^

SET TERM ;^

COMMIT;

O banco de dados com campos BLOB de diferentes comprimentos está pronto para o teste.

Para comparar de forma justa as diferentes opções de transferência de campos BLOB, é necessário "aquecer" o cache de páginas, ou seja, garantir que todas as páginas de dados da tabela BLOB_TEST, bem como as páginas de BLOB, estejam incluídas nele. Se isso não for feito, a primeira consulta pode ser executada significativamente mais lentamente que as outras. A aplicação para testar o desempenho da transferência de BLOB pela rede executa automaticamente uma consulta SQL para "aquecer" o cache de páginas.

Para os testes, eu uso o Firebird 5.0.3 na arquitetura SuperServer. O valor do parâmetro DefaultDbCachePages é 32K, o que é suficiente para garantir que todas as nossas consultas não realizem leituras físicas após o preenchimento do cache de páginas.

2. BLOB vs VARCHAR

Vamos tentar descobrir por que trabalhar em uma rede de alta latência (canal de Internet) se torna desconfortável se as consultas selecionam dados contendo colunas BLOB. Para fazer isso, realizaremos um teste comparativo de transferência dos mesmos dados quando esses dados estão localizados em campos VARCHAR e BLOB. O teste será realizado usando o fbclient versão 5.0.1 (versões anteriores se comportam de maneira semelhante).

Lembro que no Firebird uma coluna VARCHAR pode conter 32.765 bytes. Se contiver texto em codificação UTF8, o VARCHAR pode conter até 8.191 caracteres (UTF-8 usa codificação de comprimento variável de 1 a 4 bytes por caractere). É por isso que na tabela BLOB_TEST a coluna SHORT_CONTENT é definida como

SHORT_CONTENT  VARCHAR(8191) CHARACTER SET UTF8

Primeiro, vamos olhar as estatísticas de execução de uma consulta que transfere dados usando uma coluna BLOB cujo comprimento não excede 8.191 caracteres:

SELECT  ID,  CONTENTFROM BLOB_TESTWHERE SHORT_BLOB IS TRUEFETCH FIRST 1000 ROWS ONLY

Estatísticas

Tempo decorrido: 36544msID máximo: 1700Contagem de registros: 1000Tamanho do conteúdo: 3366000 bytes

Agora vamos comparar com as estatísticas da execução da consulta usando uma coluna VARCHAR:

SELECT  ID,  SHORT_CONTENTFROM BLOB_TESTWHERE SHORT_BLOB IS TRUEFETCH FIRST 1000 ROWS ONLY

Estatísticas

Tempo decorrido: 574msID máximo: 1700Contagem de registros: 1000Tamanho do conteúdo: 3366000 bytes

Uau, a transferência de dados usando uma coluna VARCHAR é 64 vezes mais rápida!

Agora vamos tentar medir a transferência não apenas de campos BLOB curtos, mas também de campos médios:

SELECT  ID,  CONTENTFROM BLOB_TESTFETCH FIRST 1000 ROWS ONLY

Estatísticas

Tempo decorrido: 38256msID máximo: 1000Contagem de registros: 1000Tamanho do conteúdo: 12607388 bytes

Isso é terrivelmente lento. Mas a partir do Firebird 3.0, podemos usar a compressão de rede (wire compression) e, talvez, neste caso, os resultados sejam melhores?

3. BLOB vs VARCHAR + compressão de rede (wire compression)

Bem, vamos tentar habilitar a compressão de rede. Isso pode ser feito especificando o parâmetro WireCompression=True ao se conectar ao banco de dados.

Teste de transferência de BLOBs curtos:

SELECT  ID,  CONTENTFROM BLOB_TESTWHERE SHORT_BLOB IS TRUEFETCH FIRST 1000 ROWS ONLY

Tempo decorrido: 36396msID máximo: 1700Contagem de registros: 1000Tamanho do conteúdo: 3366000 bytes

Teste de transferência de dados no tipo VARCHAR(8191):

SELECT  ID,  SHORT_CONTENTFROM BLOB_TESTWHERE SHORT_BLOB IS TRUEFETCH FIRST 1000 ROWS ONLY

Tempo decorrido: 489msID máximo: 1700Contagem de registros: 1000Tamanho do conteúdo: 3366000 bytes

Teste de transferência de BLOBs curtos e de tamanho médio:

SELECT  ID,  CONTENTFROM BLOB_TESTFETCH FIRST 1000 ROWS ONLY

Tempo decorrido: 38107msID máximo: 1000Contagem de registros: 1000Tamanho do conteúdo: 12607388 bytes

A situação quase não mudou. Vamos tentar entender os motivos.

4. Como os dados BLOB são transmitidos pela rede

Para entender por que isso acontece, precisamos nos aprofundar no funcionamento interno do protocolo de rede do servidor Firebird. Antes de mais nada, é importante entender dois aspectos fundamentais. O protocolo de rede e a API são projetados para lidar com objetos binários grandes ou strings longas (BLOBs):

em pequenos pedaços (chunks) (não maiores que 64 KB);
em um modo adiado (lazy).

Se o primeiro ponto é implementado de forma semelhante em quase todos os servidores SQL, o segundo pode ser uma surpresa para aqueles que não trabalharam com BLOBs no nível da API (apenas através de componentes de acesso de alto nível).

Vamos dar uma olhada em um trecho de código típico para buscar e processar registros de um cursor:


Firebird::IResultSet* rs = stmt->openCursor(status, tra, inMetadata, nullptr, outMetadata, 0);
while (rs->fetchNext(status, outBuffer) == Firebird::IStatus::RESULT_OK) {
    recordProcess(outBuffer);
}
rs->close(status);

Aqui está uma explicação simplificada do que acontece. Quando o cursor é aberto, um pacote de rede correspondente op_execute2 é enviado ao servidor. A chamada fetchNext envia um pacote de rede op_fetch para o servidor, após o qual o servidor retorna tantos registros quantos couberem no buffer de rede. Chamadas subsequentes de fetchNext não enviarão pacotes de rede para o servidor, mas lerão o próximo registro do buffer até que o buffer se esgote. Quando o buffer está vazio, a chamada fetchNext enviará novamente um pacote de rede op_fetch ao servidor. Essa abordagem reduz significativamente o número de roundtrips. Um roundtrip refere-se ao envio de um pacote de rede para o servidor e o recebimento de um pacote de resposta do servidor de volta para o cliente. Quanto menos roundtrips, maior a eficiência do protocolo de rede.

O buffer no qual um registro é colocado após a execução de fetchNext é chamado de mensagem de saída. A mensagem de saída é descrita usando metadados da mensagem de saída, que são retornados ao preparar a consulta SQL ou preparados dentro da aplicação. Vamos dar uma olhada em como as mensagens de saída podem ser mapeadas para estruturas com base nas colunas da consulta.

Para a consulta SQL:


SELECT
  ID,
  SHORT_CONTENT
FROM BLOB_TEST
WHERE SHORT_BLOB IS TRUE
FETCH FIRST 1000 ROWS ONLY

a mensagem de saída pode ser mapeada para a seguinte estrutura:


struct message {
    int64_t id;                  // value of the ID field
    short idNull;                // NULL indicator for the ID field
    struct {
        unsigned short length;   // actual length of the VARCHAR field in bytes
        char[8191 * 4] str;      // buffer for VARCHAR string data
    } short_content;             // value of the SHORT_CONTENT field
    short contentNull;           // NULL indicator for the SHORT_CONTENT field
}

Assim, quando fetchNext é executado, o valor do campo VARCHAR está imediatamente disponível. O servidor usa o chamado prefetch de registros para uma transmissão mais eficiente pela rede.

Agora vamos olhar para a estrutura da mensagem de saída para a consulta SQL:


SELECT
  ID,
  CONTENT
FROM BLOB_TEST
FETCH FIRST 1000 ROWS ONLY

a mensagem de saída pode ser mapeada para a seguinte estrutura:


struct message {
    int64_t id;                  // value of the ID field
    short idNull;                // NULL indicator for the ID field
    ISC_QUAD content;            // identifier for the BLOB field CONTENT
    contentNull;                 // NULL indicator for the CONTENT field
}

Aqui, ISC_QUAD é uma estrutura definida da seguinte forma:


struct GDS_QUAD_t {
	  ISC_LONG gds_quad_high;
	  ISC_ULONG gds_quad_low;
};

typedef struct GDS_QUAD_t ISC_QUAD;

Essa estrutura descreve apenas o identificador do BLOB, que não inclui o conteúdo real. O conteúdo do campo BLOB deve ser recuperado usando funções de API separadas.

De fato, se fôssemos buscar apenas os identificadores de BLOB sem seu conteúdo, nosso teste mostraria excelentes resultados, mas não é isso que precisamos.

Elapsed time: 38ms
Max id: 1000
Record count: 1000

Assim, a última consulta recupera apenas o identificador do BLOB, e agora precisamos buscar seu conteúdo. Para BLOBs de string, isso pode ser feito usando as seguintes funções:


std::string readBlob(Firebird::ThrowStatusWrapper* status, Firebird::IAttachment* att,
    Firebird::Transaction* tra, ISC_QUAD* blobId)
{
    // Open the BLOB using the specified identifier
    Firebird::IBlob* blob = att->openBlob(status, tra, blobId, 0, nullptr);

    // Retrieve BLOB information (size)
    FbBlobInfo blobInfo;
    std::memset(&blobInfo, 0, sizeof(blobInfo));
    getBlobStat(status, blob, blobInfo);

    std::string s;
    s.reserve(blobInfo.blob_total_length);
    bool eof = false;
    std::vector vBuffer(MAX_SEGMENT_SIZE);
    auto buffer = vBuffer.data();
    while (!eof) {
        unsigned int l = 0;
        // Read the next portion of the BLOB or its segment
        switch (blob->getSegment(status, MAX_SEGMENT_SIZE, buffer, &l))
        {
        case Firebird::IStatus::RESULT_OK:
        case Firebird::IStatus::RESULT_SEGMENT:
            s.append(buffer, l);
            break;
        default:
            eof = true;
            break;
        }
    }
    blob->close(status);
    return s;
}


void getBlobStat(Firebird::ThrowStatusWrapper* status, Firebird::IBlob* blob, FbBlobInfo& stat)
{
    ISC_UCHAR buffer[1024];
    const unsigned char info_options[] = {
        isc_info_blob_num_segments, isc_info_blob_max_segment,
        isc_info_blob_total_length, isc_info_blob_type,
        isc_info_end };
    // Retrieve BLOB information
    blob->getInfo(status, sizeof(info_options), info_options, sizeof(buffer), buffer);
    for (ISC_UCHAR* p = buffer; *p != isc_info_end; ) {
        const unsigned char item = *p++;
        const ISC_SHORT length = static_cast(portable_integer(p, 2));
        p += 2;
        switch (item) {
        case isc_info_blob_num_segments:
            stat.blob_num_segments = portable_integer(p, length);
            break;
        case isc_info_blob_max_segment:
            stat.blob_max_segment = portable_integer(p, length);
            break;
        case isc_info_blob_total_length:
            stat.blob_total_length = portable_integer(p, length);
            break;
        case isc_info_blob_type:
            stat.blob_type = static_cast(portable_integer(p, length));
            break;
        default:
            break;
        }
        p += length;
    };
}

Isso é aproximadamente o que acontece nos bastidores no nível da API quando você chama BlobField.AsString em componentes de acesso de alto nível para recuperar o conteúdo de um campo BLOB como uma string.

Agora vamos olhar para as chamadas de rede adicionais feitas neste código. A função IAttachment::openBlob abre um BLOB pelo identificador fornecido enviando o pacote de rede op_open_blob2. Em seguida, solicitamos informações sobre o BLOB usando IBlob::getInfo, que envia outro pacote de rede op_info_blob e aguarda o retorno das informações do BLOB. Depois disso, começamos a ler o BLOB em chunks usando a função IBlob::getSegment, que envia outro pacote de rede op_get_segment. Note que IBlob::getSegment é otimizado para ler o BLOB no maior número possível de chunks em uma única chamada de rede, ou seja, se você chamar getSegment com um tamanho de 10 bytes, um chunk muito maior será lido para o buffer interno, de forma semelhante a como IResultSet::fetchNext faz. Quando todo o BLOB for lido, o método IBlob::close será chamado, que enviará outro pacote de rede op_close_blob.

Pelo exposto, fica claro que mesmo o BLOB mais curto requer 4 pacotes de rede adicionais: op_open_blob2, op_info_blob, op_get_segment, op_close_blob. Você pode evitar o uso de op_info_blob para reservar um buffer para a string de saída com antecedência, o que economizará um roundtrip. No entanto, a maioria dos componentes de acesso de alto nível faz exatamente o que descrevi ao trabalhar com BLOBs.

Agora fica claro por que suas aplicações ficam lentas em redes de alta latência (canal de Internet) ao usar seleções contendo colunas BLOB. Existe alguma maneira de melhorar a situação?

5. Usando BLOB e VARCHAR juntos para otimizar a transferência de rede

Como mostrado acima, a principal sobrecarga ocorre ao transferir BLOBs curtos. BLOBs maiores requerem pacotes op_get_segment adicionais, enquanto outros pacotes de rede associados ao BLOB são enviados no máximo uma vez. Este é um mal inevitável, já que BLOBs grandes não podem ser transferidos em um único pacote de rede.

Mas e se transferirmos o conteúdo do BLOB como VARCHAR se ele couber neste tipo de dados, e transferirmos o restante dos BLOBs da maneira padrão? Vamos tentar isso.

Vamos reescrever nossa consulta da seguinte forma:


SELECT
  BLOB_TEST.ID,
  CASE
    WHEN CHAR_LENGTH(BLOB_TEST.CONTENT) <= 8191
    THEN CAST(BLOB_TEST.CONTENT AS VARCHAR(8191))
  END AS SHORT_CONTENT,
  CASE
    WHEN CHAR_LENGTH(BLOB_TEST.CONTENT) > 8191
    THEN CONTENT
  END AS CONTENT
FROM BLOB_TEST
FETCH FIRST 1000 ROWS ONLY

Agora precisamos reescrever o código da nossa aplicação para que ele possa escolher de onde ler os dados:


Firebird::IResultSet* rs = stmt->openCursor(status, tra, inMetadata, nullptr, outMetadata, 0);

// Description of the output message structure
FB_MESSAGE(OutMessage, Firebird::ThrowStatusWrapper,
    (FB_BIGINT, id)
    (FB_VARCHAR(8191 * 4), short_content)
    (FB_BLOB, content)
) out(status, master);


size_t blb_size = 0;
while (rs->fetchNext(status, out.getData()) == Firebird::IStatus::RESULT_OK) {
    std::string s;
    if (out->short_contentNull && !out->contentNull) {
        // If the field SHORT_CONTENT IS NULL and CONTENT IS NOT NULL read from BLOB
        Firebird::IBlob* blob = att->openBlob(status, tra, &out->content, 0, nullptr);
        s = readBlob(status, blob);
        blob->close(status);
    }
    else {
        // otherwise read from VARCHAR
        s = std::string(out->short_content.str, out->short_content.length);
    }
    blb_size += s.size();
}
rs->close(status);

Vamos ver o desempenho desta solução:

Estatísticas (WireCompression=False):

Elapsed time: 20212ms
Max id: 1000
Record count: 1000
Content size: 12607388 bytes

Agora vamos medir o desempenho com a compressão de tráfego de rede habilitada (WireCompression=True):

Estatísticas (WireCompression=True):

Elapsed time: 15927ms
Max id: 1000
Record count: 1000
Content size: 12607388 bytes

Muito melhor. Deixe-me lembrá-lo que os resultados da leitura apenas de campos BLOB foram 38256ms e 38107ms.

Podemos melhorar nosso resultado ainda mais? Sim, porque se nossa tabela já armazena BLOBs curtos como VARCHAR. Neste caso, a consulta SQL fica assim:


SELECT
  BLOB_TEST.ID,
  CASE
    WHEN BLOB_TEST.SHORT_BLOB IS TRUE
    THEN BLOB_TEST.SHORT_CONTENT
  END AS SHORT_CONTENT,
  CASE
    WHEN BLOB_TEST.SHORT_BLOB IS FALSE
    THEN BLOB_TEST.CONTENT
  END AS CONTENT
FROM BLOB_TEST
FETCH FIRST 1000 ROWS ONLY

Estatísticas (WireCompression=False):

Elapsed time: 19288ms
Max id: 1000
Record count: 1000
Content size: 12607388 bytes

Estatísticas (WireCompression=True):

Elapsed time: 15752ms
Max id: 1000
Record count: 1000
Content size: 12607388 bytes

6. Melhorias na transferência de BLOB com o fbclient versão 5.0.2

No Firebird 5.0.2, foi feita uma pequena otimização na transferência de BLOBs pela rede. Na verdade, as mudanças afetaram apenas a parte cliente do Firebird, ou seja, o fbclient. Você pode sentir isso ao transferir BLOB com qualquer Firebird mais antigo que 2.1 ao usar o fbclient versão 5.0.2 e superior. Antes de explicar o que exatamente foi melhorado, apresentaremos os resultados dos testes.

Teste de transmissão VARCHAR(8191) (WireCompression=False):

SELECT
  ID,
  SHORT_CONTENT
FROM BLOB_TEST
WHERE SHORT_BLOB IS TRUE
FETCH FIRST 1000 ROWS ONLY

Estatísticas (WireCompression=False):

Elapsed time: 569ms
Max id: 1700
Record count: 1000
Content size: 3366000 bytes
Wire logical statistics:
  send packets = 34
  recv packets = 1034
  send bytes = 712
  recv bytes = 3396028
Wire physical statistics:
  send packets = 33
  recv packets = 2179
  send