Firebird e seus PLANos de otimização

Se fossemos enumerar as qualidades do Firebird, poderíamos citar : flexibilidade, simplicidade e portabilidade. No entanto, quando falamos de Servidores SQL, existem muitas outras características que marcam sua excelência. Por exemplo, um produto pode ser simples, flexível e portável, mas e se a performance não for boa ?...

por Gladiston Santana

Se fossemos enumerar as qualidades do Firebird, poderíamos citar : flexibilidade, simplicidade e portabilidade.

No entanto, quando falamos de Servidores SQL, existem muitas outras características que marcam sua excelência.

Por exemplo, um produto pode ser simples, flexível e portável, mas e se a performance não for boa?

Você usuaria ele mesmo assim?

Acrescentou-se a minha query um tal PLAN (TABELA_CLIENTES NATURAL), como eu havia dito antes, ou seja, o otimizador escolheu não fazer nenhuma seleção de índice.

Para ver o tempo que essa query levou para ser executada clique na orelha "Estatistics":

Figura 1:

Interessante, não?

Levou nem 1 milisegundo para pesquisar em 7.091 registros, e se tivesse usado qualquer outro indice teria demorado mais.

5- Vamos criar uma nova querie, dessa vez uma que faça o Firebird usar o "otimizador de query".

Crie a seguinte query:

SELECT * FROM TABELA_CLIENTES WHERE razao_social LIKE "INDUSTRIA%MOVEIS%"

Poderá usar qualquer outro campo, contando que também possua um índice associado. Execute a query.

6- Selecione a orelha "Plan", e observe que dessa vez ele usou um PLAN:

Figura 2:

Naturalmente, usou um PLAN que utilizasse um índice associado a razão social.

E observe então as estatísticas:

Figura 3:

Como essa tabela de clientes possui apenas 7.091 registros a performance não aumentou tanto assim, foi apenas de 10%!

Mas a performance num ambiente cliente/servidor é linear, isto quer dizer em outras palavras, que se o Firebird leva menos de 1 segundo para encontrar um registro numa base com 10.000 registros, a probabilidade de que com uma base 10 vezes maior, digamos 100.000 registros, o tempo nunca será de 10segundos, provavelmente continuará a levar o mesmo 1 segundo.

Não é como nos bancos de dados desktop em que a medida que aumentamos dez vezes nossos dados, perdemos uma performance de 15 vezes ou mais.

Um dado interessante no Firebird é que essa estatistica eu retirei num banco de dados em produção e passados mais ou menos 15 minutos, fui até o Firebird e re-executei a mesma querie anterior e note o seguinte:

Figura 4:

A performance aumentou ainda mais, por que?

Note que ele não fez nenhuma leitura, isto é, Reads=0, isto quer dizer que quando o Firebird repete um PLAN já executado anteriormente, ele vai buscar os dados em cache, e provavelmente o tempo que levou para buscar os dados foi o tempo de transferencia da memoria do servidor. Em outras palavras, 00:00:00.0113 foi o tempo mínimo possível para executar o PLAN. Aonde eu quero chegar?

Vamos executar a mesma query, porém mudemos a clausula LIKE (note que retiramos a palavra "MOVEIS"):

SELECT * FROM TABELA_CLIENTES WHERE razao_social LIKE "INDUSTRIA%"

Com a modificação dessa dessa query, um número ainda maior de registros aparecerá e a performance diminuirá em relação a execução anterior, certo ? Então executemos a query acima e vejamos novamente as estatísticas:

Figura 5:

Note que ao invés da performance diminuir, ela aumentou?

Alguém poderia explicar o milagre, como é que eu aumento a quantidade de registros numa seleção de query e a minha performance aumenta ao invés de diminuir ? Isso tem a ver com a tal performance linear?

A resposta a essa pergunta é : Veja a quantidade de leitura física, notou?

"Reads=0", isto quer dizer que não houve leitura física no disco. Provavelmente na execução anterior, o Firebird trouxe muitos registros para a memória além do que nós necessitávamos, em qualquer RDBMS a leitura é por páginas e provavelmente todas as páginas que satisfizeram a nova condição LIKE já estava em cache e disponível para toda a rede. Se outro usuário na rede precisasse de algum registro já pesquisado por mim, usando o mesmo PLAN que eu, é provável que para esse usuário o Reads seria igual a zero novamente.

Numa rede com muitos usuários simultâneos, essa performance aumenta e vai muito além do que os outros banco de dados desktop (dbf, access, paradox,...) poderiam nos dar.

Claro que isso não é linear a vida toda, como toda a estatística matemática haverá um tempo que essa curva linear tenderá a descer, e quando isso ocorrer então já estará na hora de fazer um UPGRADE no servidor.

Considerações Finais

Percebeu como a "otimização de query" e os "PLAN" são importantes ? Agora você iniciante no mundo SQL, poderá perceber o que realmente faz diferença na performance num banco de dados SQL Cliente/Servidor versus aplicações Desktop (Paradox, Access, DBF,...).

É por causa de recursos como este que banco de dados como Oracle, Sybase, MSSQL dentre outros custam tão caro.

No entanto, agora você tem os mesmos recursos usando o Firebird que não lhe custa *nada*.

Links úteis

Infelizmente a maior parte deste artigo foi produzido com mensagens coletadas em newsgroups, sites na internet, etc... e não num artigo anteriormente escrito, embora certamente exista tais artigos falando exatamente sobre o mesmo tema. Para você ter acesso a maior parte de assuntos relacionados ao tema, faça o seguinte, vá até o site de buscas www.google.com e procure pela chave "database interbase optimize plan". Muitos links poderão ser consultados.

Este artigo está sob forma de licença GPL (General Public License) e pode ser reproduzido e distribuído livremente em outros tipos de mídia diferentes donde este artigo foi originalmente publicado, no entanto, atente-se para fato de que qualquer produto associado à este artigo também herdará as características GPL e também deverá ser fornecido livremente. Para maiores esclarecimentos leia sobre a GPL em: http://www.gnu.org/philosophy/philosophy.pt.html