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).
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 Para os testes, eu uso o Firebird 5.0.3 na arquitetura SuperServer. O valor do parâmetro |
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 UTF8Primeiro, 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 ONLYTempo 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 ONLYTempo 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 ONLYTempo 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?
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 ONLYTempo 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 ONLYTempo 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 ONLYTempo 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.
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?
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:
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):
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
WireCompression=False):Elapsed time: 19288ms Max id: 1000 Record count: 1000 Content size: 12607388 bytes
WireCompression=True):Elapsed time: 15752ms Max id: 1000 Record count: 1000 Content size: 12607388 bytes
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 ONLYWireCompression=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
