HOME EMPRESA SOLUES NOTCIAS PARCEIROS CONTATO

Home > Notcias > Degradao de Performance com Firebird

NOTCIAS voltar

16.03.15
Degradao de Performance com Firebird

Texto extrado do site da FIREBASE

www.firebase.com.br
Banco de Dados de um Terabyte
por: Carlos H. Cantu

DEGRADAO DE PERFORMANCE COM FIREBIRD

Uma das preocupaes mais importantes em relao a

bancos de dados a degradao de performance. Muitos
usurios alegam que suas aplicaes de bases de dados
comeam a ter problemas de performance quando a base
atinge um determinado limiar: pode ser 3Gb, 5Gb, tamanho
da memria RAM, 20Gb, etc. A queixa mais comum
quando o tamanho da base ultrapassa a quantidade de
RAM disponvel no servidor. Ser verdade?

Vamos realizar uma srie de testes para checar se h

realmente degradao de performance relacionada com o
crescimento da base de dados. Para tanto, simulamos o
crescimento da base de dados com a mesma carga e o mesmo hardware, realizando 11 testes com bases de dados entre 9GB e 30GB.

- HARDWARE UTILIZADO

CPU = AMD FX8350

RAM = 16GB
HD (database) = RAID 2 x 4 TB, SATA, Segate

Como se pode ver, uma mquina com configurao modesta, podendo ser considerado um servidor tpico de baixo custo, talvez exceto pelos drives SATA de alta capacidade, mas de
acordo com o fabricante, drives de 1TB e 4TB tem praticamente a mesma velocidade.

- SOFTWARE UTILIZADO

Sistema Operacional = Windows Server 2008R2 (64 bits).

Firebird = Firebird SuperServer 64bits
Loader = Custom loader from tpc-based test

Como o objetivo do teste medir a variao de performance de um sistema tradicional, ns usamos o Firebird SuperServer 64bits, e no o Classic, para simular o cenrio mais comum em
pequenas empresas, que geralmente usa o que foi instalado h anos. Como voc deve saber, o SuperServer, por padro, usa apenas uma CPU/Core, portanto, provavelmente o
Classic/SuperClassic (que usa todos os processadores) poderia mostrar resultados melhores, mas o objetivo do teste no ajuste de performance.

- CONFIGURAO DO ARQUIVO DE BANCO DE DADOS E DO FIREBIRD (SGBD)

Alteramos dois parmetros do firebird.conf, conforme sempre recomendamos aos nosso usurios: aumentamos o page buffers para 10.000 e o espao temporrio para sort. Todas as
bases de dados utilizadas foram criadas com page size de 16.384 bytes.

- PROCESSO DE CARREGAMENTO DOS DADOS

Cada teste era composto de duas etapas: carga e simulao de 20 terminais que realizavam inserts, updates e deletes. A
carga dos dados foi executada pela aplicao load.exe, que insere dados em diversas tabelas. Como se v na figura abaixo
(linha vermelha), a velocidade de insero dos dados variou entre 35 MB/seg a 1 MB/seg.

A diferena de velocidade devida ao prprio design da aplicao de carga, e no ao Firebird: o loader foi desenhado de
forma que insira rapidamente 70% dos dados desejados, e lentamente insera o restante das informaes. Esse
comportamento foi repetido nos testes com todas as bases de dados, pois importante executar exatamente as mesmas
operaes em todos os testes, para que possamos fazer a mdia de velocidade de carga.

importante mencionar que o loader.exe insere apenas dados, sendo que os ndices so criados aps a carga estar completa.
Abaixo temos a tabela com os valores obtidos com a carga nos 11 bancos de dados com tamanhos variando entre 9GB e 30GB.

# Velocidade de carga
Tamanho da base (GB) Tempo de carga (seg) (MB/seg)

1 9,04 2535 3,65166075

2 10,80 3197 3,45924304

3 13,00 4057 3,281242297

4 15,50 4698 3,378458919

5 17,30 5455 3,24751604

6 19,90 6037 3,375451383

7 21,60 6473 3,417024564

8 24,20 7539 3,287014193

9 26,00 7779 3,422547885

10 28,60 8851 3,308823862

11 30,30 9266 3,348499892

Como podemos ver, os dados so relativamente estveis, e a media de variao da velocidade de carga variou entre 3.3-3.4MB/sec. No h sinais que a performance caia quando a base
de dados passa a quantidade de RAM disponvel (aps a base #5, com 17.3GB).

- PERFORMANCE

O tempo de carga foi bastante promissor, mas e quanto aos resultados de performance? Antes de comentar, vamos rever
rapidamente o processo de simulao.

A simulao roda 20 threads, e cada uma delas realiza diversas operaes de negcio: cria pedidos, processa pagamentos,
faz contagem de estoque, processa o envio dos pedidos, etc. Como voc pode perceber, simulamos um ambiente normal de
uma aplicao de vendas.

A aplicao de teste mede o nmero de operaes de negcio por segundo, e reporta a mdia. Obviamente, esse nmero um parmetro artificial, mas bom o suficiente para
comparao.

# Tamanho do BD (GB) Performance (SATA RAID1)

1 9,04 494,73

2 10,80 491,94

3 13,00 480,36

4 15,50 469,11

5 17,30 446,42

6 19,90 431,61

7 21,60 426,85

8 24,20 424,5

9 26,00 414,04

10 28,60 409,14

11 30,30 407,97

Como se pode observar, existe uma lenta degradao de performance conforme o tamanho da base aumenta quanto maior a base de dados, mais lenta ser (no mesmo hardware). No
h grande degradao de performance quando a base de dados ultrapassa a quantidade de RAM. O crescimento da base de dados de 9GB para 30GB leva praticamente a 20% de perda
de performance.

Bases de dados Firebird com 30GB atualmente so facilmente encontradas pelo mundo afora, e continuam crescendo com o passar do tempo.

E o que acontecer com a performance do banco, quando a base se tornar maior? Ou melhor, MUITO MAIOR!

- BANCO DE DADOS 1.77 TERABYTES

Para responder a pergunta anterior, decidimos realizar um teste com uma base de 1.77 Terabytes, no mesmo hardware, com
a mesma configurao.

- PROCESSO DE CARREGAMENTO DOS DADOS

A carga durou 566.448 segundos 157 horas, 6.55 dias. muito tempo, mas a media de velocidade de carga foi de
3.28MB/seg

Tamanho da base, Gb Tempo de carga, seg Velocidade de carga, MB/seg

1813,969025 566448 3,279214122

- PERFORMANCE DO BANCO DE 1,77 TERABYTE

Aps a carga, realizamos novamente o teste de performance, dessa vez com a base de 1.77TB.

O resultado confirma que h uma lenta e estvel queda de performance no Firebird enquanto a base de dados cresceu 60
vezes (de 30GB para 1.7713GB), a queda de performance foi de 2.4 vezes (de 407 para 169 pontos).

No comum que uma base de dados cresa tanto sem que se melhore o hardware do servidor, mas mesmo nessa
situao, o Firebird continua funcionando.

# Tamanho do BD (GB) Performance (SATA RAID1)

1 9,04 494,73

2 10,80 491,94

3 13,00 480,36

4 15,50 469,11

5 17,30 446,42

6 19,90 431,61

7 21,60 426,85

8 24,20 424,5

9 26,00 414,04

10 28,60 409,14

11 30,30 407,97

12 1813,969025 169,33

Aps completar a srie de testes com um hardware de baixo custo, decidimos checar como seria o resultado usando outro tipo de tecnologia de armazenamento, e instalamos um drive
SSD no mesmo servidor.

- TESTANDO O BANCO DE DADOS DE 1,77 TERABYTES COM DRIVES SSD

Foi instalado um drive Plextor PX-256M M5 Pro, e executados a mesma srie de testes (com exceo da base de 1.77TB),
com as mesmas configuraes.

Os resultados foram adicionados no grfico comparativo com os dispositivos SATA, conforme figura ao lado.

O tempo de carga no drive SSD praticamente o mesmo do SATA. Isso esperado, pois a velocidade de escrita sequencial
praticamente a mesma entre drives SATA e SSD.

- PERFORMANCE

Como podemos observar, a performance com operaes de I/O randmicas mostra uma performance 8x melhor para o drive
SSD. Nossa experincia com clientes mostra que drives SSD so de 30 a 50% mais rpidos no uso de aplicaes reais, mas
um ganho de 8x tremendamente alto.

No entanto, esse teste artificial e especialmente desenhado para simular uma alta carga de operaes de OLTP, com
muitos updates e deletes, mas sem grandes recuperaes de informao. As aplicaes de bases de dados mais comuns
no trabalham dessa forma todo o tempo. Isso explica porque o SSD mostra um resultado to bom nesse caso especfico.

- CONCLUSO DOS TESTES

Primeiro a performance do Firebird no apresenta queda acentuada relacionada a alguma restrio de tamanho. No mesmo hardware, a performance ter uma degradao lenta com o
crescimento da base de dados. Essa degradao pode ser compensada com o tuning da configurao do Firebird ou com um upgrade inteligente de hardware.

Segundo comprovamos que mesmo bases de dados gigantes (1.7TB) funcionaro em um hardware de baixo custo, com uma queda de performance significativa mas ainda aceitvel.

Terceiro SSD muito bom para uso com aplicaes OLTP. Provavelmente, a opo de menor custo para aumentar a performance no momento. Obviamente, usar um SSD no
resolver os problemas relativos queries com planos de acesso ruins e ndices ineficientes, mas pode aumentar a performance de forma geral.

- DETALHAMENTO DOS TESTES

- TABELAS

Na tabela abaixo listamos as tabelas da base de dados com suas principais caractersticas. Os dados foram obtidos com o gstat -a -r e interpretados pelo IBAnalyst.

Tabela Records RecLength, Data Pages Table size, Indices size, Total %
bytes Mb Mb
ORDER_LINE 6300024797 60.09 38880344 607505.3 50582.3 34
STOCK 2100000000 298.88 43783806 684121.9 15809.61 39
ORDERS 630004141 29.00 2692324 42067.56 4250.38 2
HISTORY 630000434 48.77 3446455 53850.86 0.00 3
CUSTOMER 630000000 577.52 24226054 378532.0 8675.78 21
NEW_ORDER 188999981 13.00 623764 9746.31 1260.84 1
DISTRICT 210000 103.92 1860 29.06 1.27 ~0
ITEM 100000 82.73 756 11.81 0.52 ~0
WAREHOUSE 21000 97.90 179 2.80 0.11 ~0

Como podemos observar, a maior tabela a ORDER_LINE contendo mais de 6 bilhes de registros. Seu tamanho de cerca de 600Gb sendo que 50GB so ocupados por ndices. Ela
ocupa 34% do tamanho total da base de dados.

A tabela STOCK tambm imensa cerca de 2 bilhes de registros. Apesar do nmero de registros ser menor do que a tabela ORDER_LINE, a STOCK ocupa ~680Gb na base de dados
(39%), pelo fato do comprimento dos registros na tabela STOCK ser 298.88 bytes contra apenas 60.09 bytes na ORDER_LINE. Da mesma forma, o tamanho dos ndices associados a
tabela STOCK de apenas 15Gb.

A terceira maior tabela, CUSTOMER, tem um comprimento de registro ainda maior 577.52 bytes, e ocupa 378Gb (21%) com apenas 630 milhes de registros.

- NDICES

Existem poucos ndices nessa base de dados, pois foi modelada apenas para testes a maioria das tabelas tem apenas um ndice a chave primria. No mundo real, os desenvolvedores
criam diversos ndices para servir a necessidades especiais, mas aqui, limitamos os ndices para nos concentrar na velocidade das inseres e atualizaes dos dados como resultado,
o tamanho do ndice representa apenas 5-10% do tamanho da tabela, quando geralmente o cenrio mais comum de 30-50% (se mais de 50% do tamanho de uma base de dados
ocupada por ndices, considere remodelar a base de dados, ou remover ndices desnecessrios).

Na tabela abaixo listamos todos os ndices da base de dados e suas caractersticas:

Index Table Depth Keys # Key Len, # of unique keys Size, Mb

bytes
ORDER_LINE_PK ORDER_LINE 4 6300024797 1.41 6300024797 50582.34
STOCK_PK STOCK 4 2100000000 1.00 2100000000 15809.61
ORDERS_PK ORDERS 3 630004141 1.01 630004141 4250.38
CUSTOMER_LAST CUSTOMER 3 630000000 0.00 1000 4029.64
CUSTOMER_PK CUSTOMER 3 630000000 1.01 630000000 4646.14
NEW_ORDER_PK NEW_ORDER 3 188999981 1.01 188999981 1260.84
DISTRICT_PK DISTRICT 2 210000 1.37 210000 1.27
ITEM_PK ITEM 2 100000 1.00 100000 0.52
WAREHOUSE_PK WAREHOUSE 2 21000 1.00 21000 0.11

Todos os ndices possuem um tamanho de chave reduzido a maior 1.41, significando que o ndice tem um ndice de compresso bastante efetivo por exemplo, a o ndice primrio da
tabela ORDER_LINE contm 6 bilhes de chaves em 50Gb de espao. Um resultado muito bom.

Existem 2 ndices com profundidade igual a 4. Isso significa que o Firebird precisa fazer 4 leituras em pginas de ndices para encontrar o valor desejado. recomendado que a
profundidade dos ndices no seja maior que 3. Se for maior, o tamanho da pgina da base de dados deve ser aumentado. No entanto, essa base de dados j est com o tamanho de
pgina no limite (16kb), portanto, teremos que viver com isso.

- AQUECIMENTO

Antes de continuarmos e falarmos de grandes consultas, vamos aquecer a base de dados. Quando a base de dados
grande, os dados das tabelas de sistema associadas aos objetos do banco de dados tambm so grandes, e leva algum
tempo para que o Firebird coloque as pginas de sistema no cache. Por exemplo, a tabela ORDER_LINE tem 10.110 pginas
de ponteiro. Aquecimento necessrio para qualquer base de dados grande.

Com a base fria, a execuo das queries levar muito mais tempo do que com a base aquecida.

Para aquecer o cache do banco de dados, vamos executar uma srie de consultas simples, para ler os dados de sistema
para o cache:

select first 1 * from ORDER_LINE;

select first 1 * from STOCK;
select first 1 * from customer;
select first 1 * from ORDERS;
select first 1 * from NEW_ORDER;

Isso suficiente para uma base com modelagem to simples. Para bases de dados mais complexas, com centenas de tabelas, o aquecimento pode ser mais complexo, e precisa ser
bem pensado. (Veja na figura ao lado, o consumo de memria do processo do Firebird (Firebird SuperServer 2.5.2 64 bit)).

- QUERIES

Aps o aquecimento, vamos executar diversas consultas tpicas para simular o uso normal de um sistema. Vejamos o tempo de resposta para essas consultas, e o nmero de operaes
de leitura.

Query Plan and stats Description

select first 10 w_id, w_name, c_id, PLAN JOIN (WAREHOUSE Juno da tabela WAREHOUSE
c_last from WAREHOUSE, NATURAL, CUSTOMER INDEX (21000 records) com a
customer (CUSTOMER_PK))STATISTICS CUSTOMER (630 million records),
where c_w_id = w_id and c_w_id = Current memory = 166919744 com a condio de pegar um
10000 Delta memory = 5616 armazm especfico
Max memory = 166977488
Elapsed time= 0.08 sec
Buffers = 10000
Reads = 1
Writes 0
Fetches = 51
select count(*) PLAN JOIN (WAREHOUSE INDEX Contagem de registros para a
from WAREHOUSE, customer (WAREHOUSE_PK), CUSTOMER query anterior.
where c_w_id = w_id and c_w_id = INDEX (CUSTOMER_PK))COUNT
10000 ============
30000STATISTICS
Current memory = 166918560
Delta memory = -1184
Max memory = 166977488
Elapsed time= 0.16 sec
Buffers = 10000
Reads = 1175
Writes 0
Fetches = 60040
SELECT first 10 * FROM PLAN (ORDER_LINE INDEX Query na maior tabela da base
ORDER_LINE (ORDER_LINE_PK))STATISTICS ORDER_LINE (~6billion records)
WHERE OL_W_ID = 10050 Current memory = 167013640 com a condio de selecionar os
Delta memory = 95080 registros de um armazm
Max memory = 167055968 especfico. Como a chave primria
Elapsed time= 0.80 sec ORDER_LINE_PK composta, e
Buffers = 10000 contm a ID do armazm
Reads = 10285 (CONSTRAINT ORDER_LINE_PK:
Writes 0 Primary key (OL_W_ID, OL_D_ID,
Fetches = 10424 OL_O_ID, OL_NUMBER), o ndice
efetivamente usado nessa
consulta.
SELECT count(*) FROM PLAN (ORDER_LINE INDEX Contagem da consulta anterior. A
ORDER_LINE WHERE OL_W_ID = (ORDER_LINE_PK))COUNT segunda consulta com os mesmos
10050; ============ parmetros sera muito mais rpida,
299509STATISTICS mas queries com parmetros
Current memory = 167125464 diferentes apresentam um
Delta memory = -7160 resultado similar.
Max memory = 167267976
Elapsed time= 3.41 sec
Buffers = 10000
Reads = 1994
Writes 0
Fetches = 599170
Select first 10 w_id, w_name, c_id, PLAN JOIN (WAREHOUSE INDEX Query com join e duas condies.
c_last (WAREHOUSE_PK), CUSTOMER
from WAREHOUSE, CUSTOMER INDEX
where c_w_id = w_id and (c_w_id > (CUSTOMER_PK))STATISTICS
8000) and (c_w_id < 10000) Current memory = 167687664
Delta memory = -651888
Max memory = 168931400
Elapsed time= 0.19 sec
Buffers = 10000
Reads = 31
Writes 0
Fetches = 63
select first 10 PLAN JOIN (C1 INDEX Query para mostrar os detalhes de
c1.C_ID, c1.C_FIRST, c1.C_LAST, (CUSTOMER_PK), O1 INDEX um cliente especfico em um
o1.O_ID, o1.O_OL_CNT, (ORDERS_PK), OL1 INDEX armazm e distrito especfico.
i1.I_NAME, i1.I_PRICE, (ORDER_LINE_PK), I1 INDEX Demonstra a performance de
ol1.OL_AMOUNT (ITEM_PK))STATISTICS junes mais complexas.
from customer c1 Current memory = 166807128
join orders o1 on (c1.c_w_id = Delta memory = 6016
o1.O_w_ID and c1.C_D_ID = Max memory = 166879200
o1.O_D_ID and c1.C_ID = Elapsed time= 0.20 sec
o1.O_C_ID) Buffers = 9999
join ORDER_LINE ol1 on Reads = 1
(ol1.ol_w_id = c1.C_W_ID and Writes 0
ol1.OL_D_ID = c1.C_D_ID and Fetches = 4960
ol1.OL_O_ID = o1.O_ID)
join Item i1 on (ol1.OL_I_ID = i1.i_id)
where o1.o_d_id = 1 and o1.o_w_id
= 1 and c1.c_id = 10;

- CONCLUSO DOS TESTES

Como podemos ver, a base de dados de 1.7 Terabytes apresenta uma boa performance com o Firebird, para consultas comuns. Se a query for bem desenhada e fizer uso de bons ndices,
a performance boa at mesmo em bases de dados imensas. claro, h pontos crticos, como o tempo de fetch para datasets muito grandes e longo tempo para operaes de count
(pelo fato do Firebird visitar todas as pginas para obter o nmero exato de registros para aquela query naquela transao especifica), mas esses pontos crticos so bem conhecidos
pelos desenvolvedores mais experientes, e h mtodos de se modelar a base de dados para contorna-los.

VEJA TAMBM
27.07.15
Encontro de alunos e empresas de
tecnologia
Selando uma parceria de
comprometimento com a
sociedade, a Soluvert
apoia o movimento de
encontro entre os alunos e
as empresas de tecnologia
da regio.
+ ler tudo
15.06.15 16.03.15
Conhea a mais nova verso dos Banco de dados de um Terabyte
aplicativos
O S-RES um sistema
que exige mtodos
Conhea a mais nova
robustos de engenharia de
verso dos aplicativos da
software na sua
Soluvert, verso 1.7
construo para garantir
disponvel para
que a informao possa
distribuio. Esta verso
ser capturada,
foi planejada para atender
armazenada, exibida e compartilhada de forma segura,
a dois objetivos:
integra e completa.
Certificao e Inovao.
+ ler tudo + ler tudo

Soluvert (54) 2106 5517

Newsletter Digite seu email OK Av. Tiradentes, 40, Sala 805 escrevapara@soluverti.com.br 2017 - Soluvert
Centro, Erechim RS, 99700-424

Home Empresa Solues Notcias Parceiros Contato astrusweb.com