Usuários: 73432
Artigos: 219
Dicas: 138
Downloads: 315
24.07.16

Banco de dados de 1 Terabyte

Banco de dados de 1 Terabyte

Data da última atualização: 24/08/2009

Porque criar um banco de dados de um terabyte com o Firebird?

Muitas companhias trabalham com grandes bases de dados no Firebird e confiam nelas para realizar importantes operações de negócio. Algumas dessas bases de dados já têm centenas de gigabytes de tamanho, e continuam a crescer (leia mais na seção “quem é grande?”), e não é difícil de prever o dia em que serão 2, 3 ou 5 vezes maiores.  Sendo assim, é interessante para os administradores saberem qual o comportamento do Firebird com bases de dados grandes, e obter algumas recomendações de como administrá-las.

Uma outra razão importante que tínhamos em mente ao criar uma base de 1Tb é acabar de uma vez por todas com a idéia de que o Firebird é um SGBD para pequenas bases de dados. Esse mito parecia estar morto, mas alguns analistas e jornalistas desenterram-no de tempos em tempos, sendo que agora, pretendemos acabar de uma vez por todas com essa percepção ridícula.

Hardware

O Firebird é bem conhecido por sua incrível escalabilidade, e nossos testes confirmam isso mais uma vez. O propósito inicial deste teste era apenas criar um banco de dados de 1Tb, portanto, usamos um computador desktop normal:

Tabela 1: Hardware usado

Componente

Parâmetros

CPU

AMD Athlon 64 x2 5200

RAM

4GB

Motherboard

MSI K9N Platinum

HDD1 (operation system and temp)

ST3160815AS, 160GB, SATA II

HDD2 (auxilary)

HDT721064SLA360, 640GB, SATA II

HDD2 (auxilary)

HDS728080PLA380, 80GB, SATA I

HDD3 (database)

ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

Resumindo, colocamos um HD de 1.5Tb em um dos nossos computadores, sem qualquer modificação. Esse HD foi formatado com clusters de 16Kb (o mesmo tamanho de uma página do banco de dados).

Quem é grande?

Existem diversas empresas que gerenciam bases de dados Firebird significativamente grandes. A seguir, listamos três delas como exemplos de uso real de grandes bases de dados Firebird em empresas de três áreas distintas: varejo, finanças e medicina.

Bas-X

Bas-X (http://www.basx.com.au/, Australia) é líder no fornecimento de tecnologia de informação para varejistas, particularmente operadores “multi-site” e grupos de gerência. Bas-X é um grande exemplo na tecnologia do Firebird: dois dos seus clientes tem bases de dados Firebird com mais de 450GB, e diversos outros possuem bases de mais de 200Gb.
Um fator interessante sobre a Bas-X é o fato de oferecem soluções SAS (Software-as-a-Service), usando o Firebird como banco de dados para milhares de seus clientes. Sem dúvida, é um dos melhores exemplos de uso real de computação em nuvem, mostrando que o Firebird é bom o suficiente para esse tipo de trabalho duro.

Watermark Technologies

Watermark Technologies (http://www.watermarktech.co.uk/, UK) é um ótimo exemplo de uso do Firebird para servir empresas nas áreas de Finanças e setores Governamentais.
A Watermark Technologies produz software que usa o Firebird para gerenciamento de documentos, incluindo busca textual indexada e OCR. É utilizada por conselhos financeiros, seguradoras, etc. No momento, possuem diversas bases de dados com mais de 300 Gb distribuídas.
O licenciamento gratuito do Firebird Free foi uma das coisas que permitiu a Watermark Technologies oferecer modelos de assinatura flexíveis para consumidores finais, permitindo evitar gastos antecipados, e pagar conforme o negócio anda.

Profitmed

Profitmed (http://www.profitmed.net/, Rússia), um dos maiores distribuidores farmacêuticos da Rússia. Eles possuem bancos de dados relativamente pequenos (somente 40Gb), mas decidimos citá-los pelo fato de terem uma alta carga de conexões simultâneas, servindo milhares de pequenas revendas e farmácias em toda a Rússia. Apesar dos tamanhos dos bancos de dados serem menores do que os já apresentamos, eles contém dados de alta densidade: SKUs de medicamentos, movimentação de armazenagem representados em números, e graças ao mecanismo de compressão de dados do Firebird, essas informações ocupam pouco espaço em disco.

Software

Como o computador usado era uma micro normal de trabalho, o sistema operacional foi o Windows XP Professional SP3, 32bit. Para realizar o teste, foi usado o loader baseado no toolkit do TPC (baixe-o em  http://ibdeveloper.com/tests/tpc-c/, tanto o fonte como os binários estão disponíveis).

Gostaríamos de enfatizar que o loader insere dados simulando uma situação de uso real: os registros são inseridos e armazenados dentro do BD (e das áreas físicas do disco) em diversas tabelas seguindo o relacionamento mestre-detalhe, e não inseridos de forma seqüencial, tabela por tabela (pump).

Tabela 2: Software

Software

Versão

Sistema Operacional

Windows XP Professional SP3, 32bit

Firebird

2.1.3 SuperServer (snapshot)

Loader

Custom loader from tpc-based test

Plan

Nosso plano de testes era muito simples:

  1. Criar um BD e carregar ele com 1Tb de dados, sem índices
  2. Criar diversas chaves primárias e índices (portanto, o tamanho do banco é um pouco maior que 1Tb)
  3. Colher estatística do BD
  4. Rodar diversas queries de SQL e estimar a performance do BD

Configuração do banco de dados e do Firebird

O BD usa páginas de 16384 bytes, o mesmo tamanho do cluster do HD, a fim de maximizar a performance das operações de leitura/escrita em uma página por ciclo de I/O.
Na configuração do Firebird, configuramos espaço adicional para os dados temporários, apontando o espaço do temp para um HD de 640GB (com aproximadamente 300Gb livres).

Processo de carregamento

Os dados foram carregados no BD em várias etapas. O computador continuou sendo utilizado para outras tarefas durante o processo (MS Office, Firefox, IBAnalyst, etc – entre 8 e 12 programas rodando ao mesmo tempo). Usando um hardware dedicado para esta tarefa, provavelmente ela seria mais rápida, portanto, considere os valores como um exemplo de “pior caso”; definitivamente, poderíamos obter valores muito melhores.

 

Tabela 3: Operações de carregamento

Descrição

Valor

Tempo total de carregamento

~70 horas

Total de registros inseridos

6.2 bilhões

Velocidade media de inserção

24.500 registros/segundo

Tamanho médio de um registro

146 bytes (min 13 bytes, max – 600 bytes)

Transações

646.489

Foi gasto quase 4 dias para carregar o banco, chegando a um BD com exatamente 1Tb de tamanho (1.099.900.125.184 bytes). Abaixo você pode verificar o gráfico gerado pelo FB DataGuard que demonstra o crescimento do BD e o número de transações dinâmicas:

Grafico

Índices

Criamos os índices um por um, e contamos o tempo de criação e tamanho do arquivo temporário utilizado para ordenação.
O maior índice foi criado na tabela ORDER_LINE. Sua chave primária é composta por 4 campos (Smallint, Smallint, Integer and Smallint). O arquivo temporário para a indexação ocupou 182Gb, e o tamanho final do índice ficou em 29.3Gb.
Foi interessante observar que mesmo em um índice para uma tabela com 3.8 blhões de registros, a profundidade foi igual a 3, devido ao tamanho da página ser de 16Kb, portanto, não há sobrecarga ao realizar pesquisas na chave primária para esta tabela.

Estatísticas

Depois do processo de criação dos índices, era hora de colher as estatísticas do BD. Esta etapa demorou 7 horas, 32 mins e 45 seg. A tabela 4 mostra as estatísticas mais interessantes, incluindo algumas queries e tempos.

Tabela 4: Estatísticas consolidadas para o BD de 1Tb


Tabela

Total de registros

Tamanho (Gb)

Tempo de execução de um select count(*)

Tempo de criação de índice

Tamanho do arquivo temporário (Gb)

Tamanho do índice (Gb)

WAREHOUSE

1240

0.002

0s

0

0

0.0

ITEM

100000

0.012

0.7s

-

-

0.0

DISTRICT

124000

0.017

0.7s

6

-

0.0

NEW_ORDER

111600000

32

20m 00s

23m 00s

4.56

0.8

CUSTOMER

372000000

224

-

41m 00s

-

2.6

  customer_last

 

 

 

1h 52m 32s

12.4

2.3

  fk_cust_ware

 

 

 

2h 10m 51s

-

2.3

HISTORY

372000000

32

-

-

-

-

ORDERS

372000000

25

32m 00s

45m 41s

15.2

2.5

STOCK

1240000000

404

-

3h 34m 44s

41.5

9.2

ORDER_LINE

3720051796

359

-

12h 6m 18s

182.0

29.3

As estatísticas podem ser baixadas em http://www.ib-aid.com/demo/1tb.zip
Você pode usar o FB DataGuard Community Edition (gratuito) para interpretar os dados não só da performance do BD, mas também do uso de memória e CPU.

Queries

Antes de qualquer coisa, foi executado um select count(*) em diversas tabelas (conforme a tabela 4). Como você deve saber, devido à natureza  de múltiplas versões utilizada no Firebird, executar um  select count(*) para um tabela completa é uma operação bastante custosa para o servidor, pois faz com que ele acesse todas as páginas, portanto, usuários experientes do FB não costumam fazer isso, mas resolvemos fazer isso para mostrar a performance geral do BD e do hardware.
Em seguida, executamos queries usadas em situações da vida real, e ficamos maravilhados com o resultado. Veja você mesmo:

Query

Statistics

Description

select w_id, w_name, c_id, c_last
from WAREHOUSE,  customer
where c_w_id = w_id

PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE))

------ Performance info ------
Prepare time = 15ms
Execute time = 79ms
Avg fetch time = 6.08 ms
Current memory = 272 264 476
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 82
Writes from cache to disk = 0
Fetches from cache = 3 648

Junção de tabelas com 12.400 e  372.000.000 registros, sem cláusula WHERE. O tempo mostrado é para recuperar a primeira linha.

select w_id, w_name, c_id, c_last
from WAREHOUSE,  customer
where c_w_id = w_id and c_w_id = 10000

PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))

------ Performance info ------
Prepare time = 16ms
Execute time = 78ms
Avg fetch time = 6.00 ms
Current memory = 272 266 148
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 88
Writes from cache to disk = 0
Fetches from cache = 3 656

Join das mesmas tabelas acima, mas usando uma condição para restringir os registros mais atuais. O tempo mostrado é para recuperar a primeira linha.

select count(*)
from WAREHOUSE,  customer
where c_w_id = w_id and c_w_id = 10000

Result = 30000

PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))

------ Performance info ------
Prepare time = 0ms
Execute time = 453ms
Avg fetch time = 453.00 ms
Current memory = 272 263 844
Max memory = 272 514 048
Memory buffers = 16 384
Reads from disk to cache = 1 048
Writes from cache to disk = 0
Fetches from cache = 60 024

Contagem dos registros do select anterior.

 

 

 

SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500

 

Plan
PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))

------ Performance info ------
Prepare time = 0ms
Execute time = 94ms
Avg fetch time = 7.23 ms
Current memory = 136 445 536
Max memory = 136 592 176
Memory buffers = 8 192
Reads from disk to cache = 150
Writes from cache to disk = 0
Fetches from cache = 2 402

Query na maior tabela do BD (3.8 bilhões de registros). O tempo mostrado é para recuperar a primeira linha.

 

 

 

 

PlanPLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Performance info ------Prepare time = 0msExecute time = 3s 438msAvg fetch time = 0.01 msCurrent memory = 136 445 496Max memory = 136 592 176Memory buffers = 8 192Reads from disk to cache = 1 840Writes from cache to disk = 0Fetches from cache = 598 636

 

 

SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500

 

Query na maior tabela (3.8 bilhões de registros), recuperando todos os registros resultantes (299.245 registros foram recuperados).

 

 

Sumário

Neste experimento, o Firebird mostra os seguintes resultados:

  1. Capacidade indiscutível de gerenciar bases de dados realmente grandes. Estamos certos de que é possível criar e usar bases de 32Tb com o hardware apropriado, mantendo a performance obtida em BDs menores.
  2. Boa escalabilidade e pequeno footprint. O BD de 1Tb foi criado em uma máquina de uso geral (desktop) e, mais importante, pode ser usado para executar queries normais: se você não selecionar milhões de registros com a query, a performance será a mesma obtida em BDs menores (10-15Gb).

Este não é o fim deste experimento. Ainda pretendemos rodar outras queries, colher mais estatísticas e publicar reports mais detalhados em breve.

Contatos

Envie todas as suas dúvidas para terabyte@ib-aid.com

Tradução/adaptação: Carlos H. Cantu (www.firebase.com.br)



Copyright (C) Carlos H. Cantu - É proibida a reprodução de qualquer material desse site sem autorização prévia

Avalie esse artigo:  
       

Comentários

Laszlo Peter Andras Urmenyi [31.08.09]

Definitivamente magnífico. Na atualidade os Bancos de Dados SQL tornaram-se muito mais importantes que os aplicativos propriamente ditos - que passaram a ser meros coadjuvantes front-end. É muito gratificante e tranquilizador receber a confirmação de estarmos trabalhando com o Banco de Dados CERTO. Acertamos com o Firebird!
 

Leandro Laia [04.11.09]

muito bom o teste!
 

Ronaldo Cezar G. Fernandes [05.11.09]

poderia ser disponibilizado o download do banco (via TORRENT por exemplo), feito um .rar do gbak deve dar uns 50 GB...
 

Joaquim Pais [10.11.09]

Gostava de saber em que ambiente foram efectuados estes testes, pois eu tenho base de dados com um 1GB e para fazer um simples select com um left a uma tabela demora uma eternidade.
 

Carlos H. Cantu [12.11.09]

Joaquim, o ambiente foi descrito no artigo. Se quer alguma informação adicional, é só entrar em contato com a IBSurgeon e perguntar. Problemas de lentidão geralmente estão ligados a falta de otimização selects, índices, etc. ou controle transacional incorreto. Sugiro que você se informe melhor sobre como o Firebird funciona, para saber onde está o seu problema.
 

Emerosn dos Santos [19.04.10]

Parabéns pelos testes, é bom saber do potencial de um banco de dados que muitos não accreditam. Estamos muitos satisfeitos com um banco de dados tão robusto como o Firebird.
 

HELIO DA SILVA RODRIGUES [09.04.11]

Parabens !! Realmente é confortável saber que o volume dos dados não será problemas para nossos projetos com o Firebird !
 

Robson de Lacerda Zambroti [16.05.11]

Seria interessante um artigo mostrando os resultados de backup e restore nesta mesma base!
 

Volnei D. Alexandre [29.05.11]

Casualmente estava atrás de informações pois estou com problemas com o meu banco passando dos 4GB e estava preocupado se o problema era hardware ou banco de dados. Sendo assim vendo que que o banco suporta bem mais que 4GB, me deixa mais calmo, pois achava que teria que mudar de banco e ao mesmo tempo sou fã do FIREBIRD e acredito nele e assim continuo acreditando. Obrigado!!!
 

Carlos Daniel A. de Mendonça [20.03.12]

Desenvolvemos um sistema para gestão de balança rodoviaria onde o sistema foi escrito em Delphi 2007, conexão via IBO e base de dados Firebird 2.1.4 . O sistema roda 24 horas, com cerca de uma inserção de dado a cada 2 segundos, já existe no sistema 130 mil registros de pesagens, todos com captura de imagem via camera tcpip(FOSCAM), a base de dados está com 3 GBytes e nenhuma falha foi observada. A estabilidade do sistema está muito clara, a propósito, o servidor é um mero computador com Windows XP devidamente atualizado. Abraços aos colegas.
 

Michael dos Santos da Silva [30.05.12]

Show de Performance! Um cálculo simples sobre os dados fornecidos indica que uma operação de \"fetch-all\" na query \"SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500\" levaria cerca de 300 DIAS! Talvez isso explique porque não foi postado o tempo do count(*) dessa tabela. Além do mais, em que mundo essas são querys reais? O que uma diretoria de verdade quer saber é, por exemplo: Qual o Desvio Padrão das vendas por consumidor em toda a história ou, no mínimo, nos últimos 36 meses.
 

Carlos H. Cantu [01.06.12]

Michael, segue resposta do Dmitry Kuzmenko (IBSurgeon) aos seus comentários (fiz a tradução): Não vejo razão para recuperar milhões de registros do servidor para o cliente e reclamar que \"demoraria 300 dias\", ou mesmo algumas horas, ainda comendo memória no cliente. De qualquer forma, rodei um \"SELECT count(*) FROM ORDER_LINE WHERE OL_W_ID = 500\" e demorou 0.6 segundos retornando o valor 299245. Um fetchall nessa query demorou 3.3 segundos. Como vc queria dizer SELECT COUNT(*) FROM ORDER_LINE, não vejo razão para rodar isso. O pior count, como vc deve ter visto no artigo, é na tabela ORDERS, e demorou 32 minutos em uma tabela de 25GB. Como o count é feito correndo as páginas em ordem natural, é fácild e calcular aproximadamente o quanto iria demorar na tabela ORDER_LINE: 359/25 = ~16, e 32min * 16 = 8.5 horas (no meu HDD!).
 

Atenção! Não poste dúvidas técnicas nos comentários. Para obter suporte, use a lista de discussão da FireBase.

Para enviar comentários é preciso estar logado.

About Notícias Página Principal Login FAQ Consultoria Downloads Lista de discussão Contato Pesquisar Links Produtos a venda

Copyright (c) Carlos H. Cantu - É proibida a reprodução de qualquer material desse site sem autorização prévia