[firebase-br] Curiosidade. Firebird 2.5 x 3.0

[Carlos H. Cantu]

Marcelo, sua resposta está cheia de erros, que vou tentar detalhar a
seguir...

MF> Estranho, isso é o que a versão 3.0 "deveria" fazer!

Não, a versão 3 terá suporte a SMP, mas isso não implica em dizer que
uma única query poderá ser distribuída entre vários processadores.
Isso também não significa que esse recurso não será implementado em
alguma versão futura.

MF> uma coisa que o InterBase, desde a versão 7.0 faz muito bem diga-se de passagem.
MF> REAL SMP!!!!

Sugiro que vc leia os testes de TPC realizados pela IBSurgeon onde
foram testados Yafill, InterBase e Firebird, não estaria falando isso.

MF> Não por suas qualidades ou seus pecados técnicos, nas por que não é
MF> software livre "detalhe Firebird é Open Source mas não é Livre" mas
MF> todo mundo faz questão de Esquecer esse detalhe.

Agora estou surpreso, porque o Firebird não é livre?

MF> Bem Super server se dá melhor com multi processamento porquê, cada
MF> instância de conexão com o banco é criado um novo cache e uma nova
MF> instância para manipular a nmemória e os registros de base de dados,

Isso quem faz é o Classic, não o SuperServer.

MF> obviamente se a máquina tiver mais de um processador ou Core "núucleo
MF> de processamento", ela vai tentar via sistema operacional distribuir
MF> cada um dessses processo + ou - independentemente tirando proveito
MF> destes "X" processadores ou núcleos, porém é um alternativa não
MF> escalável pois cada conexão vai comer "X" de memória para cada
MF> conexão.

Não sei exatamente qual o seu parâmetro para considerar algo escalável
ou não, mas na grande maioria dos grandes casos de uso do Firebird,
incluindo aí bases muito grandes e centenas de conexões simultâneas,
usam o Classic.

MF> A idéia do pessoal do Firebird é comparar as performances das
MF> distintas arquiteturas para ver quem se sobressai melhor. Coisa que na
MF> minha humilde opinião é uma perda de tempo, deveria-se sepultar de vez
MF> a arquitetura ClassicServer e apagar todo este trambolho dos fontes e
MF> fazer todas as rotinas pertinentes SMP usando um layer posix para as
MF> arquiteturas Unix.

A idéia é que as diferentes arquiteturas deixem de existir no futuro,
unificando tudo em uma só. Se você reparar bem, é isso que vem
acontecendo. O SuperClassic é um híbrido entre a Classic e a
SuperServer, enquanto no FB 3, teremos um modelo onde todas as
vantages da SuperClassic serão fundidas com o cache compartilhado
(que atualmente só existe no SuperServer).

Firebird não roda só em Unix, vc sabe disso.

MF> Mas não as mentes iluminadas do leste europeu preferem remover a
MF> compatibilidade com arquiteturas já comprovadas como UnixWare,
MF> (provavelmente só, por que, é da SCO) mas manter HP-UX somente das
MF> última versão por que somente esta última é Posix SMP compatível.

O projeto não tem intenção alguma de suportar uma arquitetura em
detrimento de outras. Acontece que, como você deve saber, ele depende
de voluntários. Se houver algum voluntário que precise de suporte a
UnixWare e quiser ser responsável por gerar as builds e fazer as
adaptações necessárias no código, será bem vindo.

Se existe versões para Solaris, MacOS, etc. é porque alguém precisa
delas, e se dispôs a fazer as builds e adaptações necessárias.

Dizer que o FB deveria suportar isso ou aquilo é fácil, agora colocar
a mão no código e fazer com que isso aconteça, já é uma outra
história, não? Afinal, uma das premissas do Open Source é que
"qualquer um pode baixar os fontes e altera-lo da forma que quiser".

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br