Guia de Performance Interbase / Firebird

[b:673d799388][size=24:673d799388]Guia de Performance Interbase[/size:673d799388][/b:673d799388] Por Peter Mc Leod Tradução: Cristiano de Favari Marcello Henrique da Costa Grec Este artigo tenta definir várias direções em como conseguir a melhor performance no Interbase. Antes de chegar aos aspectos que eu recomendaria no projeto de bancos de dados para atender às demandas de seus clientes, eu pediria que você lembrasse que geralmente os aspectos mais caros (na ordem) dos custos de um projeto são: 1. Desenvolvedores 2. Rede 3. Servidor Então, quando estiver priorizando seus recursos, mantenha os itens acima em mente. Também, um atalho tomado no começo (tal como não testar um banco de dados largamente povoado) sempre leva no mínimo três vezes mais tempo para reparar mais tarde, levando a custos no mínimo três vezes maiores. [b:673d799388][size=18:673d799388]Desenvolvimento de Bancos de Dados[/size:673d799388][/b:673d799388] [b:673d799388]Normalize seu Banco[/b:673d799388] Não interessa para qual banco de dados você esteja desenvolvendo, você tem que começar com um bom projeto. Assegure-se que você tenha seu banco de dados normalizado no mínimo na terceira forma normal. Assegure-se que suas chaves primárias são independentes de qualquer objeto de negócio que você esteja armazenando e, por razões de performance, use um Integer sempre que possível (Integers são 32 bits e ordenados mais rapidamente pela maioria dos algoritmos se comparado com campos Char e Varchar), a menos que você não possa fazer isto por uma razão específica (tal quando você precisa de um identificador único para replicação ou quando você está usando um banco de dados relacional para armazenar objetos). [b:673d799388]Chaves Primárias[/b:673d799388] Se você definir uma chave primária composta, mais que um índice é criado (um para cada coluna que compõe a chave). Como o otimizador de consultas usará os múltiplos índices para resolver a consulta, isto pode causar um gargalo para o otimizador, já que os múltiplos índices usados pelo otimizador são iguais aos campos da consulta. [b:673d799388]Chaves Estrangeiras[/b:673d799388] Chaves estrangeiras são essencialmente restrições de integridade referencial. O problema com chaves estrangeiras é que elas criarão um índice na respectiva tabela para facilitar a restrição. Normalmente isto não é um problema; contudo, se você tem uma restrição de chave estrangeira em colunas que tendem a não ter valores únicos, então você tem um índice bastante pobre. Se o otimizador de consultas utilizar um desses índices, isto causará um gargalo devido à pobreza dos índices. Nestes casos, remover os índices pode melhorar a performance das consultas em 100¬. Então tenha cuidado quando você definir suas chaves estrangeiras. [b:673d799388]Utilize Índices em Colunas de Ligadas (por operações de Join)[/b:673d799388] Um índice é uma estrutura de dados de árvore balanceada que fornece uma melhora na velocidade de ordenação para um banco de dados. Índices do Intebase são de direções exatas (ascendente ou descendente) então, se você realiza uma busca de trás para frente nos dados de uma tabela, você deve definir um índice descendente. Índices trabalham melhor com dados que apresentam alguma exclusividade sobre ele. O otimizador de consultas do Interbase usará índices para acelerar as consultas. Índices na verdade podem ser prejudiciais à performance se criados em colunas que têm poucos valores únicos. Índices deixam lentas as inserções de dados em uma tabela, já que eles precisam ser recalculados a cada inclusão. Se você for fazer um grande número de inserções em uma tabela você pode considerar a desativação temporária de índices para minimizar o impacto de performance (ALTER INDEX name INACTIVE) e sua posterior reativação após as inclusões (ALTER INDEX name ACTIVE). Para determinar a eficiência de um índice, rode a seguinte instrução SQL: Select RDB$INDEX_NAME, RDB$STATISTICS from RDB$INDICES O valor RDB$STATISTICS mostra a eficiência do índice. Quanto mais baixo o valor, melhor o índice, com o valor 1 indicando um índice muito pobre. Como regra geral, você deve definir apenas uns poucos índices por tabela (o otimizador de consultas usará múltiplos índices para referenciar os mesmos campos conforme exigido pela consulta, portanto muitos índices podem degradar a performance). [b:673d799388]SQL[/b:673d799388] Certas instruções SQL são mais lentas que outras. Geralmente, evite o uso de funções como ´CONTAINING´, ´LIKE´, ´´, ´COUNT´ e ´UPPER´ pois elas não usarão índices durante sua operação, tornando-as mais lentas que outros comandos. O livro ´SQL Performance Tuning´ de Peter Gulutzan e Trudy Pelzer cobre em detalhes como melhorar a eficiência de suas instruções SQL sem particularizar aspectos proprietários. Eu recomendaria este livro a qualquer um que esteja envolvido com o desenvolvimento em banco dados. [b:673d799388]Subconsultas Correlacionadas[/b:673d799388] Uma subconsulta correlacionada é uma subconsulta onde as condições da subconsulta são diferentes para cada linha na consulta principal. Por isto, as subconsultas precisam ser executadas várias vezes (uma para cada linha da consulta pai). Em alguns casos, uma junção pode substituir uma subconsulta correlacionada e resultará em um tempo de execução total menor para a mesma consulta. [b:673d799388]Joins Externos[/b:673d799388] Outer joins são a realidade da programação em banco de dados. Left outer join tem a tendência de ser mais lento e um índice será apenas utilizado para a resolução do primeiro outer join na consulta. Onde possível, reduza a necessidade de left outer joins. Isto pode ser feito: - Projetando suas tabelas de forma a não serem necessários - Usando subconsultas (isto pode ser mais rápido que a solução left outer joins) - Usando um procedimento armazenado com select para aumentar a velocidade. [b:673d799388]Procedimentos Armazenados (Stored Procedures)[/b:673d799388] Quando criar um procedimento armazenado que contém laços aninhados assegure-se que o laço mais externo retorna o menor número possível de registros. Se possível, estruture seu procedimento armazenado de forma que os laços mais internos sejam sempre os mais rápidos já que são esses blocos os mais repetidos ao longo do processamento da rotina. [b:673d799388]Não Utilize Colunas Char e Varchar Longas[/b:673d799388] Antes do Interbase 7.0, Varchar´s and Char´s eram preenchidos ao tamanho do campo quando retornado ao cliente. Se você apenas preencher parte de um varchar grande ou um campo char e então retornar os resultados ao cliente, uma grande quantidade de tráfego de rede é gerado, degradando a performance de sua aplicação e da rede. Se possível, não use campos Varchar ou Char longos e, se possível, use BLOBs. Um Blob também tem a vantagem de ser armazenado em sua própria página no banco de dados e assim reduz a chance de qualquer bloqueio. Alternativamente, faça o upgrade para a versão 7.0 do Interbase. [b:673d799388]Colunas BLOB[/b:673d799388] Um BLOB (Binary Large OBject) é um tipo e dado que suporta grandes objetos. Um Blob é definido com um tamanho de segmento e, no Interbase, este default é 80 bytes. Se um campo Blob é definido com um tamanho de segmento igual ao tamanho da página do banco de dados, então consultas a campos Blob tornam-se extremamente rápidas, pois apenas uma página precisa ser resgatada para retornar os dados. Sob estas situações, o Interbase não é um gargalo para a transferência de dados. Outros sistemas, como sistema de hardware, rede, etc, normalmente deixam baixa a taxa de transferência de dados. [b:673d799388]Utilize o Modelo Cliente-Servidor[/b:673d799388] Interbase fornece várias características que permitem que os processamentos sejam realizados no servidor (que possui geralmente maior capacidade de processamento que uma máquina cliente e também permite a redução do tráfego na rede). Triggers (gatilhos), UDFs e procedimentos armazenados são adequadamente detalhados no ´Guia do Programador´ e no ´Guia de definição de dados´ sem serem detalhados aqui. [b:673d799388]Plano de Consulta[/b:673d799388] Interbase usa um otimizador baseado em custo para otimizar a execução de instruções SQL. Na maioria dos casos, o otimizador faz um trabalho muito bom. Sob certas circunstâncias, o otimizador não seleciona o melhor plano para performance. Esteja informado que se você especificar seu próprio plano de consulta, o otimizador não analisará seu plano para assegurar que ele está correto. Detalhes de quando e como ajustar um plano de consulta do Interbase podem ser encontrados nos seguintes sites: * Specifying Query Access Plans in the Interbase Optimizer on the documentation page http://www.ibphoenix.com * Managing your Interbase Server by Paul McGee http://www.mers.com [b:673d799388]RDB$DB_KEY[/b:673d799388] A rdb$db_key é um identificador de registro de baixo nível, mais rápido que chaves primárias para resgatar registros. Rdb$db_key´s são apenas válidos para a vida da transação corrente e não podem ser pensados como identificadores de registro imutáveis. É ainda possível utilizar rdb$db_keys para melhorar a performance de rotinas SQL em um banco de dados Interbase. A desvantagem é que este ganho de performance é específico do Interbase. Para mais detalhes em como utilizar rdb$db_key, por favor consulte os documentos localizados no seguinte website: http://www.cvalde.com/ibdocumentation [b:673d799388][size=18:673d799388]Guia para o Servidor[/size:673d799388][/b:673d799388] [b:673d799388]Utilize um Servidor Dedicado[/b:673d799388] Um servidor dedicado fornece a melhor performance para um banco de dados cliente-servidor. O custo de uma performance inadequada é muito maior que o custo da compra de um servidor dedicado. Performances baixas refletirão em você como desenvolvedor e normalmente resultarão em perda de tempo identificando e corrigindo problemas. Não leva muito tempo para você justificar os custos de um servidor dedicado. [b:673d799388]Utilize Linux ou Unix como SO do Servidor[/b:673d799388] Servidores Linux ou Unix têm melhor utilização de memória e de memória virtual, modelos de priorização de multi-processador mais eficientes e, frequentemente, requerem menos recursos de CPU e de memória que outros sistemas operacionais. Servidores Linux demonstram impressionantes tempos de atividade quando comparados a suas contrapartes Windows. Linux também não parece ser atormentado por processos misteriosos que degradam performance e que desaparecem logo que você loga no servidor para examinar o problema. Servidores Linux ou Unix podem ser integrados a redes Windows com SAMBA, fornecendo um ambiente homogêneo na perspectiva das estações cliente. [b:673d799388]Se Tiver que Usar o Windows[/b:673d799388] Verifique a configuração do seu servidor Windows para ver se está configurado para fornecer os recursos máximos de compartilhamento ou para aplicações de segundo plano. Como estas opções estão localizadas em diferentes áreas em diferentes máquinas Windows, verifique sua documentação do Windows. Estes ajustes podem ter um grande impacto na performance do Interbase. [b:673d799388]Utilize Máquinas Mono-Processadas com InterBase[/b:673d799388] Se você está usando uma versão do Interbase sob o Windows NT antes da versão 7.0, então não use um servidor com multi-processador na plataforma Windows. Se você fizer isto, o processo do servidor Interbase saltará de processador para processador causando degradação na performance do seu servidor. Se você quer usar Interbase (antes da versão 7.0) em um sistema com multi-processadores, então use uma ferramenta para amarrar o Intebase a um processador (há algumas delas disponíveis, inclusive uma da Microsoft). Contudo você deve ainda estar ciente que, como alguns dos sistemas operacionais Windows NT mais antigos não têm implementados um modelo adequado de suporte a SMP, o ganho de performance pode não ser tanto quanto o esperado. Sistemas Linux têm suporte a SMP adequado. [b:673d799388]Utilize um Disco Rígido Dedicado[/b:673d799388] Se você tem um banco de dados armazenado no mesmo drive que as pagefiles do servidor, a elevação das operações de I/O das operações de memória virtual do servidor impactará na performance de sua aplicação. Aloque sempre seu banco de dados em um drive separado. Se você tem dinheiro para isto, eu recomendaria que seu sistema operacional fosse para um drive, seu banco de dados para outro e o arquivo de swap para outro drive. [b:673d799388]E/S de Disco Rápida[/b:673d799388] Operações de I/O em disco são frequentemente um gargalo para performance do banco de dados. Drives IDE frequentemente usam algum recurso de CPU. Se você puder, coloque sistemas SCSI mais rápidos. Ser mesquinho nesta área custará muito a você em termos de degradação da performance. Sistemas RAID também oferecem melhor performance que sistemas de disco único. Um apropriado array de drives SCSI é a melhor solução. [b:673d799388]Utilize um IP Estático no Servidor[/b:673d799388] Um IP estático no servidor significa que o endereço IP do servidor pode ser encontrado mais rápido do que se for usado um serviço de tradução de nomes de endereço. Este IP deveria ser armazenado no Host file do servidor e no Host files das máquinas cliente. [b:673d799388]Utilize TCP/IP como Protocolo de Rede[/b:673d799388] TCP/IP é um protocolo baseado em conexão (pacotes são roteados para o receptor pretendido ao invés de ir para todas as máquinas) o qual gera menos tráfico de rede que protocolos sem conexão como NetBEUI and IPX/SPX. TCP/IP é também mais rápido que estes protocolos e tem a vantagem de estar disponível em uma grande variedade de plataformas. Sempre que possível, TCP/IP deveria ser usado para comunicar-se com o Interbase por suas vantagens de velocidade. Para melhorar a performance além disto não é aconselhável instalar múltiplos protocolos na rede pois isto aumenta o ´barulho´ na rede. Se isto for inevitável, assegure-se que o protocolo de rede que você usa terá maior prioridade através da rede. [b:673d799388]Não Utilize Proteção de Tela[/b:673d799388] Protetores de tela, particularmente os tipos 3GL podem estar sobrecarregando o processador e degradarão visivelmente o desempenho do sistema. Na maioria dos casos os protetores de tela não são necessários pois os monitores modernos são projetados de modo que o risco de queimar a tela seja insignificante pois possuem sistema de proteção de energia e se desligarão após certo período de tempo. Se você não tiver um monitor com sistema de proteção de energia somente desligue-o- você estará gastando menos energia e diminuindo o aquecimento da sua sala. Se você tiver que usar um protetor de tela então use uma tela em branco ou marquee (ajuste a velocidade do texto para uma taxa lenta para evitar a utilização excessiva da CPU) pois estes usam menos quantidade de recursos do sistema. [b:673d799388]Logins de Console[/b:673d799388] Muitas pessoas tendem a usar Windows NT/2000 pois estão mais familiarizadas com o sistema operacional Windows. Se você realmente usa Windows NT, então não faça login desnecessariamente ou fique logado. Além de ser uma questão de segurança, deixar o servidor logado permite que processos rodem em segundo plano, o que pode degradar a performance do servidor. Até mesmo processos em segundo plano podem usar de 20-30¬ dos recursos do servidor. Há várias ferramentas que permitem a você manter seu servidor Interbase sem a necessidade de ter o servidor continuamente logado. [b:673d799388]Utilize a Mesma Versão do Servidor no Cliente[/b:673d799388] Se você tem uma versão do Cliente do Interbase ultrapassada na sua máquina cliente, compare com a versão instalada no servidor. Você pode estar sofrendo com um problema de performance. Testes com Interbase 5.1 e 5.6 podem demonstrar uma performance diferente em pouco mais que 50¬ por usar uma instalação de cliente ultrapassada. Também, características mais novas podem não estarem disponíveis se você não está usando a mesma versão de cliente e servidor e erros de programa podem resultar (em alguns casos isto pode causar um crash no seu servidor Interbase e possivelmente corromper seu banco de dados). [b:673d799388]Vencendo Restrições de E/S de Disco[/b:673d799388] É possível reduzir o problema de operações de E/S em discos no Interbase. Depois de ter realizado o backup e o restore, crie uma tabela temporária no banco de dados (usando campos Blob ou colunas Varchar grandes). Preencha esta tabela com uma grande quantidade de dados. Então apague (drop) a tabela temporária e faça o sweep do banco de dados. Isto significa que o Interbase irá aproveitar o espaço dentro do banco de dados durante operações e não pedirá para ao SO espaço em disco até que o espaço vazio dentro do banco de dados tenha sido aproveitado. Isto aumenta a velocidade de operações de gravação para o banco de dados na medida que E/S de disco não é essencialmente um fator de limitação. [b:673d799388]Proteção de Arquivos no Windows[/b:673d799388] Algumas versões do Windows (Windows XP) têm implementado mecanismos de proteção a arquivos com extensão.GDB (Banco de dados Interbase). Se você está usando Sistema Operacional Windows mais recente que Windows 2000, você pode experimentar de-activating Windows File Protection ou renomear seu banco de dados para uma extensão diferente (Para Banco de dados Interbase superior a 7.0 ou FireBird 1.5). Os cínicos entre nós podem querer saber se a Microsoft fez isto para reduzir a performance do Interbase em comparação ao seu próprio banco de dados, o SQL Server...