Firebird 3 - O que vem por a

Data da ltima atualizao: 01/09/2011 Alguns podem achar que o lanamento do Firebird 3 j virou novela mexicana, mas no bem assim. A demora justificada pela complexidade das alteraes necessrias para atingir o principal objetivo dessa verso: Suporte total a SMP com cache compartilhado, tornando o SuperServer totalmente escalvel (ver tabela 1). Na verdade, para o Firebird, o nmero da verso nunca teve muita importncia. Muita gente considera que o Firebird 2.1 deveria ter sado no mnimo como verso 2.5, devido ao grande nmero de recursos adicionados em relao ao 2.0. A verso 2.5 poderia ser a 3.0... trouxe novos recursos, mas grande parte das mudanas no so to visveis a olho nu, pois consistem basicamente em alteraes internas da engine. O Firebird 2.5, com a nova arquitetura (SuperClassic), aumentou a escalabilidade do FB em mquinas Multi-core/SMP, mas ainda manteve a limitao da verso Classic, onde o cache dos dados no compartilhado entre as conexes. O fato que razes histricas acabaram marcando 3.0 como sendo a verso na qual o Firebird passaria a unir o melhor dos mundos (Classic x SuperServer), garantindo alta escalabilidade e total aproveitamento do hardware. Sendo assim, provavelmente, optou-se por lanar verses intermedirias (2.1, 2.5) at atingir esse objetivo (3.0). Recapitulando: a idia inicial para o Firebird 3 era que ele fosse uma juno do Firebird 2.0 com o Vulcan (projeto criado por Jim Starkey, baseado no Firebird 1.5, especialmente para a SAS). No entanto, o que acabou acontecendo foi o lanamento das verses 2.1 e 2.5, e o descarte da idia inicial de fazer um merge com o cdigo do Vulcan, sendo que esse ltimo acabou servindo basicamente apenas como fonte de idias pouqussimo cdigo foi copiado do Vulcan para o Firebird 3.

Arquitetura

Aproveitamento de Cache de dados Cache SMP compartilhado compartilhado de entre as conexes metadata entre as conexes No (threads gerenciam as conexes) Obs: No FB 2.5, suporte parcial, somente quando h conexes com mais de um BD simultaneamente. Sim (um processo por conexo) Sim (threads gerenciam as conexes) Sim (threads gerenciam as conexes) Sim Sim

SuperServer

Classic SuperClassic

No No

No No

SuperServer no Firebird 3

Sim

No (pelo menos at o momento)

Tabela 1. Diferenas entre as arquiteturas Esse artigo apresentar as novidades que podero e, provavelmente, estaro presentes na verso 3 do Firebird. Como a verso ainda est em desenvolvimento, no possvel afirmar com certeza que todos os recursos descritos nesse artigo estaro presentes na verso final, pois alguns deles ainda esto em fase de planejamento ou implementao. Talvez alguns fiquem para uma futura verso, outros j se encontram implementados e disponveis para testes nas atuais verses snapshot disponveis para download em www.firebirdsql.org/en/snapshot-builds/. Via de regra, o

objetivo principal do Firebird 3 oferecer suporte a SMP com cache compartilhado, tudo que vier alm disso, podemos considerar lucro J. Para entender a tabela 1, necessrio saber que o Firebird trabalha com dois tipos de cache: o de dados (que armazena as pginas do BD recentemente acessadas) e o de metadata (que armazena a estrutura do banco: tabelas, relacionamentos,constraints, etc). Cache uma forma de agilizar o acesso s informaes usadas freqentemente, mantendo-as em memria, dispensando o acesso constante ao disco (lembre-se que acessar o disco rgido sempre mais lento que acessar a RAM). Dica: No decorrer desse artigo, ser mencionada diversas vezes a palavra pgina. Saiba que um arquivo de banco de dados Firebird composto por diversas pginas, de tamanho fixo, e de diferentes tipos (pgina de dados, ndices, blobs, tip, header, etc).

Arquitetura
O Firebird 3 trabalhar com o conceito de providers. No servidor, uma requisio de conexo ser tratada pelo network listener e passar para a vlvula-Y (dispatcher), que decidir qual o provider adequado para atend-la. Diferente do que aconteceu at hoje, onde as novas verses do Firebird acessavam normalmente bancos de dados criados com ODS de verses anteriores, a engine/provider do FB 3 s acessar bancos de dados com a ODS 12. Mas e a? Se voc ainda tem um BD criado no FB 2.x (ODS 11.x) e no quer atualiz-lo, ento ele no poder ser mais acessado se o Firebird instalado for o 3.0? Calma! A idia que o Firebird 3.0 traga tambm um provider compatvel com o Firebird 2.5 e, portanto, capaz de acessar bases de dados com ODS menor que 12. O processo de como a configurao ser feita ainda no est bem definido. No momento, o dispatcher tenta conectar atravs de uma lista de providers, e o primeiro que retornar sucesso o que gerenciar a conexo. A figura 1 mostra, de forma simplificada, como diferentes providers trabalhariam em conjunto.

Figura 1. Esquema simplificado do tratamento de conexes e providers.

Nova ODS
O Firebird 3 criar bancos de dados usando uma nova On Disk Structure, de nmero 12. Nela, as pginas do arquivo de banco de dados tero um novo flag, indicando que a mesma est livre de lixo, portanto, agilizando o processo de sweep (limpeza de lixo) do banco, pois o processo no precisar percorrer o contedo de todas as pginas para saber se h lixo a ser coletado.

Provavelmente, a compactao RLE dos dados dos campos passar a usar blocos de 32K ao invs de 128bytes, diminuindo a mdia de espao necessrio para armazenar informaes longas. Um inventrio de pginas modificadas estar disponvel, fazendo com que o nBackup no precise percorrer todas as pginas do banco de dados para saber quais foram alteradas desde o ltimo backup, a fim de realizar um backup incremental, agilizando o processo. H uma grande chance de ter novas informaes nas tabelas de monitoramento, ou mesmo novas tabelas de monitoramento. O Firebird 3 tambm suportar campos do tipo boolean (lgico). At hoje, costumava-se simular booleans atravs de domnios do tipo integer ou char(1).

Segurana
At a verso 2.5, o Firebird centraliza os usurios do servidor em um arquivo de segurana (security.fdb, security2.fdb). O FB 3 permitir que o usurio defina, se desejar, os usurios localmente no banco de dados. Com isso, se o usurio JOAO for criado localmente no BANCO1.FDB, ele no estar disponvel em outros bancos de dados que estejam no mesmo servidor. O recurso de usurios centralizados continuar existindo, e simplifica bastante o gerenciamento de usurios que precisam acessar diversos bancos de dados de um mesmo servidor. Espera-se que o FB 3 traga tambm o recurso de criptografia, tanto na transmisso dos dados pela rede, como nas pginas do banco de dados. A criptografia dos dados pela rede sempre pde ser obtida atravs de ferramentas de terceiros, como por exemplo, o Zebedee, que permite criar um tnel criptografado para trafegar os dados entre o servidor e o cliente. Um recurso similar disponibilizado nativamente no SGBD facilitar a vida de muitos usurios. A criptografia de pginas far com que os arquivos dos bancos de dados sejam gravados de forma codificada, portanto, se algum roubar o arquivo, s conseguir acessar as informaes caso conhea a chave utilizada durante a criptografia. Nota: Em se tratando de criptografia, o grande problema referente implementao desse recurso descobrir como tratar a chave de forma simples e eficiente. Existem inmeros algoritmos para criptografar informaes, mas de nada adianta voc ter uma informao criptografada, se no tiver uma forma de guardar a chave de acesso de forma segura. Lembre-se, o Firebird OpenSource, o que descarta totalmente a utilizao de chaves hardcoded no cdigo do servidor, pois qualquer um teria acesso. A tendncia que o Firebird 3 possibilite que o usurio escolha a forma que ir trabalhar com a chave. Atravs de APIs e Plugins de autenticao, a chave poderia ser recuperada de tokens, por exemplo. A utilizao de chaves pblicas e privadas quase que uma certeza. importante lembrar que perder a chave significaria perder todas as informaes do banco, pois ele no poderia ser mais acessado. Ser possvel restringir operaes DDL (Data Definition Language) por usurio, impedindo que qualquer usurio do SGBD consiga manipular a estrutura do banco, por exemplo, criando tabelas, etc.

Otimizaes
Apesar do otimizador de queries do Firebird evoluir a cada verso lanada, h sempre margem para melhorias. Planejase que o Firebird 3 oferea histogramas com informaes de distribuio de valores nos ndices. Com isso, o otimizador poder escolher melhor qual ndice mais eficiente para uma determinada pesquisa, no s levando em considerao a seletividade do ndice, mas tambm o valor que est sendo pesquisado. Por exemplo, um ndice no campo ESTADO de uma tabela de clientes, com 100 chaves, onde 99 delas contm SP, e uma delas contenha MG, tem uma pssima seletividade, visto que 99% das chaves so repetidas (SP). Nas verses atuais, provavelmente, o Firebird no utilizaria o ndice em uma pesquisa do tipo select ... where estado = XX. No entanto, se houvesse histogramas, o otimizador no usaria o ndice se a query pesquisasse por SP, mas optaria por us-lo caso a query estivesse procurando por MG (o ndice pouco seletivo para SP, mas muito seletivo para MG). Outro recurso que est planejado um auto-refresh total ou parcial das estatsticas dos ndices. Atualmente, necessrio executar um SET STATISTICS para que o Firebird recalcule a seletividade do ndice, ou ento desativar/ativar o ndice, ou fazer um backup/restore. Faa o teste: Crie um novo ndice em uma tabela vazia, verifique a seletividade do mesmo, insira 1.000 registros com chaves diferentes, verifique novamente a seletividade do ndice e voc ver que ela no mudou, apresentando, portanto, uma informao irreal, que pode fazer com que o otimizador escolha um plano inadequado para determinadas pesquisas. Dica: De tempos em tempos, lembre-se de recalcular as estatsticas dos ndices associados a tabelas que sofrem constantes atualizaes de dados.

A exibio de planos de acesso passar a ser muito mais detalhada e legvel. O plano de acesso mostra como o otimizador do Firebird optou por acessar/recuperar as informaes solicitadas. analisando o plano que se descobre se o otimizador cometeu algum engano. Abaixo segue um exemplo do plano de acesso de um select hipottico no Firebird 3:

SELECT statement -> First [10] -> Sort [SUM desc, O_ORDERDATE asc] -> Aggregate -> Sort [L_ORDERKEY, O_ORDERDATE, O_SHIPPRIORITY] -> Inner Loop Join -> Filter -> Table [ORDERS] Access By ID -> Bitmap -> Index [ORDERS_ORDERDATE] Range Scan -> Filter -> Table [CUSTOMER] Access By ID -> Bitmap -> Index [CUSTOMER_PK] Unique Scan -> Filter -> Table [LINEITEM] Access By ID -> Bitmap -> Index [LINEITEM_PK] Unique Scan

Recursos de SQL
Comentarei a seguir, algumas novidades disponveis no SQL do Firebird 3. Todas elas j foram implementadas, portanto, praticamente 100% de certeza que estejam presentes na verso final.

Window functions (funes de janela)

Recurso j desenvolvido para o Firebird 3 por Adriano dos Santos Fernandes. Confesso que em um primeiro momento, pode ser um pouco difcil de compreender como as funes de janela funcionam, e at mesmo como podem ser aplicadas na vida real. No Oracle, essas funes so conhecidas como Funes Analticas. Basicamente, so um tipo de funo de agregao, mas diferente das agregaes normais (sum, count, etc), pois o resultado das funes de janela so misturados com o resultado da queryprincipal. Utilizando um exemplo que o prprio Adriano postou em seu blog, vejamos a analogia: Imagine que voc tenha uma tabela de empregados e salrios, e queira retornar, em porcentagem, o quanto determinado salrio representa no total da folha de pagamento. Utilizando funes de agregao comuns, seria algo do tipo:

select id, name, salary, salary / (select sum(salary) from employee) percentage from employee;
Convertendo para usar funes de janela, ficaria:

select id, name, salary, salary / sum(salary) over () percentage from employee;
Para mais detalhes, e tambm obter uma lista das funes de janela que estaro disponveis no FB 3, aconselho visitar o blog do Adriano, em http://asfernandes.blogspot.com

Funes SQL
Ser possvel criar funes de uso semelhante s UDFs, mas usando o PSQL do Firebird.

Triggers DDL
So semelhantes aos triggers comuns, mas associados a alteraes de estrutura do banco de dados. Por exemplo, voc pode criar triggers que sejam disparados quando um novo campo for adicionado a uma tabela no BD, ou um novo ndice for criado (ou removido), etc. Mais informaes: http://tracker.firebirdsql.org/browse/CORE-2310 Recurso patrocinado por doaes dos participantes do Firebird Developers Day.

Colunas Identity
Similares aos tipos auto-incremento de outros bancos de dados, a coluna Identity associada a uma sequence/generatorinterna, fazendo com que ela assuma o prximo valor da seqncia, durante um insert em que o valor do campo no tenha sido informado. No Firebird, at hoje era comum simular esse comportamento atravs de triggers e generators. Veja um exemplo:

create table objects ( id integer generated by default as identity primary key, name varchar(15) ); insert into objects (name) values (Table); insert into objects (name) values (Book); insert into objects (id, name) values (10, Computer); select * from objects; ID NAME ============ =============== 1 Table 2 Book 10 Computer
Os tipos da coluna identity devem ser numricos com escala zero, ou seja, smallint, integer, bigint, numeric(x, 0) e decimal(x, 0).

Cursores bi-direcionais
O PSQL sempre permitiu a utilizao de cursores atravs do comando FOR SELECT. Posteriormente, o Firebird introduziu a sintaxe necessria para manipular cursores diretamente no PSQL, mas esses cursores eram unidirecionais, ou seja, era impossvel mover o cursor para trs (ex: voltar para o registro anterior). No Firebird 3, o desenvolvedor poder trabalhar com cursores bi-direcionais no PSQL, movendo-o para frente ou para trs, conforme a necessidade.

Packages
Outro recurso desenvolvido pelo Adriano, e patrocinado ($$$) por doaes realizadas no Firebird Developers Day. Package um grupo de procedures e funes tratado como uma unidade, facilitando o gerenciamento. Mais informaes:http://tracker.firebirdsql.org/browse/CORE-2312

Stored Procedures, Triggers e Funes em Java

O Firebird 3 permitir que o usurio defina stored procedures, triggers e funes externas, escritas em Java! Esse recurso j est presente no (atualmente quase morto) Fyracle - Oracle Mode Firebird - h muitos anos. Inicialmente, o suporte ser nativo ao Java, mas como a arquitetura aberta, nada impede que sejam inseridos plugins que suportem outras linguagens, como C#, Delphi, etc.

Concluso

Mesmo que o foco do Firebird 3 seja disponibilizar uma arquitetura que aproveite totalmente mquinas multi-core/SMP, e ofereacache compartilhado entre as conexes, as mudanas disponibilizadas nessa verso iro muito alm disso, e passaro por diversas reas, desde segurana, performance, at melhorias de SQL.