[firebase-br] RES: [firebird - br] Dividir banco de dados, realmente ajuda?

[Eduardo Jedliczka]

Sandro Souza, você tocou num ponto importante!!! Mas, permita-me
complementar algumas informações:

Já trabalhei com alguns bancos na faixa entre 15gb e 20gb (todos com
arquivo único assim não corre-se o risco de esquecer algum arquivo).
Sendo que uma das tabelas com quase 25 milhões de registros possuia um
desempenho muito proximo  (com uma diferença de menos de 10% de
desempenho) em relação à outros bancos com tamanho inferior a 3gb (com
pouco mais de 1 milhão de registros na mesma tabela) hospedados num
servidor de configuração semelhante (2x xeon quad-core, raid em mirror
de 2x discos SAS de 300gb de 15k rpm, com memória entre 8 e 16 gb de
ram). 

A explicação: o Firebird usa índices HASH, e mesmo uma tabela de 25
milhões de registros tinha uma profundidade de índice 4 (para se ter uma
performance excelente, deve-se ter profundidade 2, no máximo 3), e a
tabela de 1 milhão de registros tinha profundidade 3 (durante o processo
de migração de dados e adequação do sistema ela ficou com profundidade 4
até um backup e restore).

Neste caso, se a tabela fosse fracionada, o ganho seria inferior a 10%
para as operações de leitura. Mas poderia ter um ganho um pouto maior
nas operações de escrita.

Quando se trabalha com bases grandes, precisamos nos preocupar com
coisas um pouco diferentes. Se há muito I/O é preciso ter muita memória
para tentar minimizar o máximo, e discos muito rápidos para que isto não
se torne um gargalo no desempenho (disco trabalhando a 100% =
processador ocioso). É preciso quebrar algumas regras (principalmente em
relação à  FKs muito pobres que são custosos de se manter e geram planos
horríveis - trocando por checks constraints que usam a PK da tabela
menor) e estar ciente das suas consequências, sejam elas positivas ou
negativas. 

E como podemos simular uma única tabela grande usando uma view de vários
UNION ALL com algumas triggers para insert/delete/update, podemos
contornar a necessidade de fracionar uma tabela nos moldes do ORACLE. E
isto pode ser interessante para reduzir o excesso de locks em
determinadas páginas do banco). Mas deve-se tomar cuidado pois se isto
for mal implementado o desempenho pode desabar. 

Ao contrário do que se imagina inicialmente, o fracionamento ideal é
realizado por grupo de fornecedores/clientes/filiais e não por ano/data,
pois a maioria das operações de escrita acontecem no mesmo período.

Mas, lembrem-se que uma view de várias tabelas é muito custoso para se
manter (e será um select muito mais lento do que uma tabelona com vários
milhões de registros), portanto, nem pensem em implementar isto num
banco pequeno que não tenha esta necessidade.

Sucesso

Eduardo Jedliczka

Em Dom, 2009-05-03 às 06:06 -0300, Sandro Souza escreveu:
> Bom dia/tarde amigos.
> 
> Posso estar enganado, e se eu estiver, por favor corrijam-me, mas acredito
> que o Firebird ainda não tenha o recurso de dividir uma mesma tabela em mais
> de uma base de dados, ou seja, todos os registros/linhas de uma tabela
> necessariamente estão em uma mesma base de dados, ou seja, estarão em um
> mesmo "cesto" (usando as palavras de nosso amigo Magnos).
> 
> Nesse cenário, realmente não fará diferença alguma dividir a base de dados
> em dois ou mais arquivos.
> 
> O exemplo, de nosso amigo Magno System é interessante, e podemos utilizá-lo
> para exemplificar a idéia.
> 
> Se você tem uma tabela com 120000 registros/linhas, necessariamente todos
> esses registros/linhas estarão na mesma base de dados, a não ser que eu
> esteja enganado e o Firebird já consiga distribuir os registros de uma mesma
> tabela em mais de uma base de dados, caso contrário, tudo estará em uma base
> de dados, seja ela a primária ou não.
> 
> Sendo assim, não haverá qualquer diferença de performance no sentido de ter
> dividido ou não a sua base de dados original, a final, todos os dados dessa
> mesma tabela estarão no mesmo "cesto".
> 
> Lembrem-se também que o Firebird não necessita percorrer sequencialmente
> todas as páginas da(s) base(s) de dados para localizar uma determinada
> página, pois sua organização interna foi construida pensando em todas essas
> situações.
> 
> Podemos até comparar a estrutura das bases de dados com a estrutura de um
> sistema de arquivos (como a FAT16/32, NTFS, ReiserFS, etc...), em que as
> páginas equivaleriam aos clusters (agrupamentos), já que também representam
> o menor bloco de dados onde as informações são armazenadas.
> 
> Já pensou se o sistema operacional tivesse que percorrer todos os clusters
> (agrupamentos) de sua partição só para encontrar um cluster específico?
> Seria o pior sistema de arquivos já existente, merecendo o título de "lesma
> paralítica do milênio".
> 
> Da mesma forma, a estrutura interna de cada base de dados também possui
> áreas que mapeiam as páginas e suas respectivas localizações, para agilizar,
> ao máximo, a pesquisa das mesmas.
> 
> Portanto, o que fará realmente alguma diferença, é a forma que são feitas as
> pesquisas, ou seja, se você tomou o cuidado de consultar por campos/colunas
> que já possuam algum índice, para que dessa forma, a consulta seja otimizada
> ao máximo.
> 
> Uma situação é fazer uma pesquisa por campos/colunas que não possuam índice,
> em uma tabela que está ocupando cerca de 1Gb de dados, obrigando o SGBD a
> fazer uma pesquisa sequencial em todos os registros (FULL SCAN). Outra
> situação é efetuar uma pesquisa por campos/colunas que já possuam um índice,
> fazendo com que o SGBD utilize sua "mira telescópica" para encontrar os
> registros que deseja.
> 
> Nesse exemplo citado acima, não importa se a base de dados contém apenas
> essa tabela de 1Gb ou outras tabelas que deixem essa base de dados com mais
> de 120Gb. A performance será a mesma pois os outros 119Gb não serão
> utilizados utilizados, mesmo no caso da pesquisa sequencial.
> 
> Se eu estiver enganado, por favor me corrijam. mas acredito que essa seja a
> lógica correta. Procure sempre estruturar suas tabelas da maneira mais
> otimizada possível, pensando sempre nas consultas (criando índices, etc...)
> e tudo ficará rápido.
> 
> Espero ter ajudado mais que atrapalhado. :D