[firebase-br] RES: RES: Core 2 Duo SuperServer ou Classic Server

[Rodrigo A. de Freitas]

Olá Eduardo,

Só complementando sua resposta: certa vez indaguei o Cantu sobre a questão
de se commitar SELECTS. Ele me respondeu que SE estivermos utilizando uma
transação configurada como somente leitura o commit não é necessário, já que
esta transação é pré-commitada.

[]'s

Rodrigo A. de Freitas
Análise & Desenvolvimento

Soluções & Informática

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Eduardo Jedliczka
Enviada em: segunda-feira, 20 de abril de 2009 10:44
Para: FireBase
Assunto: Re: [firebase-br] RES: Core 2 Duo SuperServer ou Classic Server

Como recebi algumas mensagens na minha caixa particular pedindo maiores
informações, eu resolvi complementar minha resposta:

De um modo geral, trabalhar com firebird é muito simples... dá
pouquíssima manutenção e problemas (exceto em caso de panes de hardware
ou copiar um banco "aberto")

mas há algumas considerações para que ele funcione corretamente:

- ter um bom controle transacional (que dure o menor tempo possível) 
- trazer somente os dados necessários (não montar um GRID com todos os
campos e "aqueles" milhões de registros de uma tabela)
- lembra-se de COMMITAR os selects (pois diferentemente de outros
bancos, select gera transação)

Dentro deste cenário, o Firebird SuperServer é fantástico!!!

Só que além do SuperServer existe o Classic. Não há um que seja melhor
ou pior pois eles tem arquitetura, objetivos e desempenhos diferentes.

o Classic quase sempre exige um DBA, pois é utilizado em circunstâncias
de alta demanda, ou alta concorrência - ou seja, há muito dinheiro
envolvido e as empresas estão dispostas a pagar (com equipamentos e
pessoal qualificado, pois o BANCO é GRATUITO) para não ter riscos... uma
hora sem sistema pode custar muito caro.

Neste último cenário, exitem muitas soluções e conceitos que seriam
inviáveis (do ponto de vista econômico) para uma empresa de menor
porte. 

Agora temos uma nova linha de desktops da intel chamada de Core i7 (tem
4 núcleos com o HT - ou seja o Sistema Operacional pode executar 8
tarefas simultâneas) e embora seja robusto e performático continua sendo
um desktop. não é um chip projetado para trabalhar 24 meses
consecultivos sem ser desligado com média de consumo na casa dos 30% a
60% com muitos momentos na faixa dos 100%

Uma empresa pequena, pode optar por este equipamento pagando R$ 3 mil ou
menos, e estará muito bem servido, desde que tenha um no-break que
aguente tempo suficiente para os terminais serem desconectados e
desligar corretamente o servidor.

Numa empresa grande, opta-se por um equipamento SERVIDOR que tem toda
arquitetura projetada para funcionar durante anos sem ser desligado.
Nestes casos, existem equipamentos com duas (ou mais) fontes de
alimentação, e que  se uma delas queimar ou ficar sem eletricidade o
computador continua funcionando sendo alimentado pela outra fonte (por
isto são chamadas de redundante) - há servidores mais caros que até a
fonte pode ser trocada "a quente" ou seja com a máquina ligada.

Mesma regra para os DISCOS, que nos servidores estão SEMPRE espelhados.
Se um disco queimar, pode-se removê-lo "a quente" e inserir outro disco
do mesmo tipo e capacidade que o sistema irá reconstruir automaticamente
o "RAID" (mesmo que isto demore dias)

Ou seja, há empresas que pagam mais de 20 mil reais num servidor que é
15% mais rápido que um Core i7 (que custa R$ 3mil) apenas pela
tranquilidade de saber que o servidor não vai "dar pane" do dia para a
noite.

Mesma regra vale para o banco de dados. Já trabalhei com Oracle em
ambientes críticos (tinhamos um servidor SUN com 32 processadores e 32
GB de ram que custou mais de 150 mil dólares - Nunca precisamos, mas
dava até para trocar um dos processadores "a quente") e sempre adota-se
o RAC (é uma sigla da oracle para dizer que vários computadores
trabalham juntos como um único super-computador e que se um deles
travar, os outros assumem a carga de trabalho) ou o Servidor Stand-By
(há dois equipamentos idênticos gravando todas as operações do banco,
mas só um responde as consultas dos clientes, e em caso do primário
travar, o secundário assume até o nome e IP do primário).

Veja bem, são soluções que podem piorar o desempenho (embora algumas
melhorem bem) e custam muito caro mas praticamente eliminam a
possibilidade do ambiente ficar parado. Ou seja é um ambiente de alta
disponibilidade, mas nem sempre tem alta performance, pois com 20% deste
dinheiro seria possível compram um único computador sem nenhuma
redundância que apresentaria melhor desempenho que toda esta
parafernália.

POOL de conexões (termo usado em ambientes em 3 ou 4 camadas) é quando
as requisições de vários terminais são aglutinadas em poucas conexões
reais com o banco (e sempre tem um servidor de aplicação responsável por
este POOL). Aplicações desktop em rede local (chamadas de duas camadas)
não usam POOL de conexões. O POOL  permite que mesmo após um commit ou
desconexão de um cliente, não seja encerrada a conexão com o banco
visando economizar tempo alocando e desalocando recursos.

o Java dispõe de funcões construir nativamente um POOL de conexões, e
alguns componentes e bibliotecas permitem que várias linguagens ofereçam
esta possibilidade (como o DBX para o Delphi).

Ambiente Multi-thread é quando um programa é fracionado em várias
tarefas (que podem ser executados por núcleos/processadores diferentes
permitindo uma maior velocidade, ou evitando que um
relatório/processamento congele o resto do sistema) ainda não é muito
comum, mas com o aparecimento de desktops dual-core e quad-core, cada
vez mais aplicações estão usando esta técnica.

Servidores WEB geralmente são multi-thread, pois cada cliente geram uma
nova thread (tarefa) no servidor, com seu próprio espaço de memória...
se um travar, os outros continuam funcionando.

Quanto ao banco ORACLE de 2GB do meu amigo, era um banco de integração
onde várias aplicações escreviam e excluíam informações para
"sincronizar" suas bases, por isto ele não crescia... mas é algo
extremamente complexo e pesado.

Abraço

Eduardo.
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use:
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa

Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br 
Versão: 8.5.287 / Banco de dados de vírus: 270.12.0/2068 - Data de
Lançamento: 04/19/09 20:04:00