NOTÍCIAS

voltar
16.03.15

Banco de dados de um Terabyte

evolution-of-the-data-center

Texto extraído do site da FIREBASE
www.firebase.com.br
Banco de Dados de um Terabyte
por: Carlos H. Cantu

BANCO DE DADOS DE UM TERABYTE

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, que continuam a crescer e não é difícil de prever o dia em que serão 2, 3 ou 5 vezes maiores.

A seguir, listamos três organizações como exemplos de uso real de grandes bases de dados Firebird, 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.

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.

Abaixo faremos testes com a criação de um banco de dados de um terabyte para entender o comportamento do Firebird com um banco de dados de grande porte.

- PLANEJAMENTO DOS TESTES

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

- HARDWARE UTILIZADO

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).

- SOFTWARE UTILIZADO

Como o computador usado era um 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).

Sistema Operacional = Windows XP Professional SP3, 32bit
Firebird = 2.1.3 SuperServer (snapshot)
Loader = Custom loader from tpc-based test

- CONFIGURAÇÃO DO ARQUIVO DE BANCO DE DADOS E DO FIREBIRD (SGBD)

O banco de dados 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 DOS DADOS

Crescimento_bd_um_teraOs dados foram carregados no arquivo de banco de dados 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.

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 banco com exatamente 1Tb de tamanho (1.099.900.125.184 bytes). Ao lado 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.

 

- Í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 bilhõ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 BANCO. Esta etapa demorou 7 horas, 32 mins e 45 seg. A tabela abaixo mostra as estatísticas mais interessantes, incluindo algumas queries e tempos.

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 das estatisticas). 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:

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 = 10000Result = 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.
SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500
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 Query na maior tabela (3.8 bilhões de registros), recuperando todos os registros resultantes (299.245 registros foram recuperados).

 

- CONCLUSÃO DOS TESTES

O Firebird apresenta 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.

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).

VEJA TAMBÉM

  • 17.01.18

    Parceria Soluvert e JB Software

    Convencao

    Consolidando a parceria técnica e comercial com a JB Software, a Soluvert esteve presente na 12º convenção anual de franquias.

    + ler tudo
  • 27.12.17

    Manutenção de Equipamentos Hospitalares

    2017-12-27 (7)

    A Manutenção preventiva é a ação de controle e monitoramento dos equipamentos, com o objetivo de reduzir ou impedir falhas em seu desempenho.

    + ler tudo
  • 08.12.17

    Preceptoria na residência médica

    2017-12-08 (2)

    Você sabe qual é o papel do Preceptor na residência médica ?

    + ler tudo