Database Performance Tuning

Aumente a performance de seu servidor de banco dados | Melhore os indicadores e métricas de seus sistemas

Oracle | MySQL | SQL Server | DB2 | PostgreSQL | MariaDB | Amazon EC2 e RDS | Rackspace | Microsoft Azzure | Google Cloud | Cassandra | Hadoop | MongoDB | IaaS | DBaaS


Melhorar a performance de um banco de dados é essencial, pois, aumenta a capacidade de processamento de informações por unidade de tempo, gera economia com menor uso de hardware (menos servidores ou menos tempo de nuvem), cria um diferencial ao entregar informações, relatórios e dashboards mais rapidamente e mais completos, que se traduzem em ferramenta gerencial e estratégica para as unidades de negócios.


O Database Server Tuning é um serviço premium, de ajuste fino de perfomance. Enquanto nossos concorrentes tentam resolver problemas de performance baseando-se, somente, na parametrização (configuração) do servidor de banco de dados. Nós preferimos uma imersão (deep dive) no ambiente de banco de dados, analisando todos os fatores que possam contribuir para melhoria geral de performance, como inversamente, impactar negativamente nesta. 

Quando contratar o serviço de performance tuning:

  • Banco de dados que apresentava performance satisfatória passou a apresentar degradação
  • Após uma atualização (do próprio RDBMS, aplicação, modelagem, metadados, código SQL) foi percebida uma queda de performance
  • Os consumidores de dados demonstram insatisfação com os tempos de entrega de relatórios e consultas
  • Os SLA's de telas, aplicações, relatórios, integrações estão comprometidos
  • Inclusive, quando tudo está, aparentemente, bem, mas, você precisa ter certeza de que está obtendo a melhor performance possível



Cases de Performance Tuning

Portal de Notícias

Diminuição do tempo de apresentação de noticias conteve a debandada de assinantes. Com escalabilidade foi possível aumentar a base de assinantes. Com mais performance e recursos disponíveis, foi possível criar banners mais adequado ao perfil do internauta, melhorando, o índice de monetização com publicidade

Seguros

Em um ambiente SOA (Service-oriented Archicture) é imprescíndivel que os serviços de consumo de dados sejam ágeis. Através de uma consultoria de performance com reescrita de procedures, queries e parametrização, conseguimos diminuir em até 75% os tempos de resposta de serviços cruciais para o negócio de crivo e propostas

Serviços Financeiros

Entregar aos seus clientes informações completas, seguras de forma rápido afim de agilizar decisões de crédito. Com o aumento da base de dados e quantidade de requisições, este sistema quase parou. Com nosso serviço de performance tuning e alto volume, ajudamos nosso cliente atingir seus objetivos e o de seus clientesImagens e Links

Jogos Online

Através de consultoria com parametrização e escalabilidade horizontal, aumentamos em 5x o número de jogadores simultâneo, gerando ganhos em assinaturas e publicidade

eCommerce

Redução do tempo de navegação entre categorias e produtos, e carrinho (checkout), aumentaram o número de visitantes, e, consequente aumento das vendas

WMS e Fiscal

A melhoria de peformance possibilitou ondas de separação de mercadorias mais ágeis, menor tempo de composição da rota e carga, resolvendo os constantes problemas de backlog de pedidos

Como funciona nosso serviço

Consumo e Utilização

Métricas de Consumo e Uso

O primeiro passo é uma análise de toda a carga à de consumo de seu banco de dados. Através de nossa exclusiva ferramenta de monitoramento, coletaremos estatísticas de uso para que possamos entender melhor como e quanto o banco de dados é consumido: transações por segundo, quantidade e tipos de travamento, concorrência, forma e quantidade de consumo, picos de consumo, planos de execução, comportamento do hardware e sistema operacional.

Hardware

Aderência à Demanda

Sempre existiu a máxima de que banco de dados deveria rodar, unicamente, em máquinas físicas. Com as novas tecnologias de virtualização, isso não é, exatamente, uma verdade irretocável. Contudo, é preciso entender se o hardware e/ou máquina virtual está configurado adequadamente, e se, os recursos disponíveis são suficientes para atender às demandas impostas ao banco de dados. Capacidade e configuração incorreta de hardware e máquinas virtuais, podem representar boa parte de uma performance baixa. Mas, jamais acredite que "basta acrescentar mais hardware que tudo se resolve" - nós não acreditamos nisso. Nós preferimos resolver problemas de performance com inteligência e não fluxo de caixa. 

Sistema Operacional

Tuning de S/O

O Sistema Operacional é uma parte pouco cuidada quando da instalação de um novo ambiente de banco de dados. Normalmente, existe um "establishment" (padrão de "deployment" de S/O) e este é seguido sem se ater às necessidades do RDBMS escolhido. Iremos atuar no contingenciamento e na equalização do "establishment" com o RDBMS. Passando por configurações do S/O, formas de "checkpoint", Cache, apresentação das mídias (discos), tipo de "file system" (sua configuração e  "blocagem").

Parametrização

Otimização = HW + SO + Demanda

Dependendo do banco de dados (Oracle, MySQL, SQL Server, DB2, PostgreSQL, etc) a parametrização pode ser a parte mais importante de um trabalho com ênfase no ajuste fino de performance (performance tuning).  Porém, é preciso aceitar que há um limite do que se pode, de fato, ganhar com este "apertar de parafusos". Não tem mais coelho nesta cartola. A parametrização é parte importante sim, mas, não é o Santo Graal da Performance. Não tem uma parâmetro mágico do tipo "ALTER PERFORMANCE = NITRO". Mas, fato é, que a perfeita orquestração de parâmetros podem contribuir para um excelente ganho de performance.

Estratégia de Paralelismo

Escalabilidade e Performance

Quanto e o quê pode ou deve ser paralelizado? Cores, Threads, NUMA... As novas arquiteturas de hardware permitem-nos extrair todo o potencial das pastilhas (processadores) e do uso e mapeamento de grandes quantidades de memória (RAM). Todavia, é preciso um entendimento sistêmico do conjunto: hardware + sistema operacional + parametrização do banco de dados. Pouco paralelizar leva a subutilização do potencial do hardware, restringindo a performance. Inversamente, paralelizar em excesso ou de maneira pouco estratégica pode levar o hardware a exaustação, aumentando muito os conflitos, contenções, travamentos, MUTEX, e, também, diminuindo a performance, em alguns casos, de maneira drástica. Por isso, gostamos de usar o termo "estratégia". Os núcleos, cores e threads estão lá. Acertar a mão no quanto utilizar é tão importante quanto a correta parametrização do RDBMS e Sistema Operacional.

Estratégia de Índices

Seletividade e Cardinalidade

Os índices estão construídos da maneira mais eficiente de forma à atender suas queries? Existem índices pouco ou nunca utilizados que estão pesando nas escritas? Quem nunca ouviu: "É só criar um índice que diminuirá o tempo de consulta". Ou então, mais brilhante ainda: "Precisamos cortar alguns índices para conseguirmos melhores tempos de escrita". E o tempo gasto com a manutenção destes índices? Bancos de dados tem vida própria! Cardinalidade e Seletividade mudam, e, com isso índices bons se tornam ruins, e, talvez alguns ruins possam se tornar bons. Novamente, a palavra "estratégia". Analisaremos os índices, como foram pensados, e, se estão atendendo as principais e mais ofensivas queries. 

Modelagem de Dados

Nível de Normalização e Relacionamento

Um breve estudo da modelagem de dados e como ela pode impactar na performance total do banco de dados. Academicamente, acreditamos que o sucesso ou o fracasso de uma aplicação inicia-se na modelagem da base de dados. Será que o banco de dados escolhido é o ideal para a aplicação pretendida? O formato normalizado seria melhor que o denormalizado? Guardar os dados em modelo bidimensional (colunas x linhas), documentos, familia de colunas, grafos? Tenho certeza de tudo que quero "perguntar" ao meu banco de dados? Mapeei as melhores formas de procurar por estas respostas? O fato é que cuidar, de verdade, da modelagem é uma parte do processo do software (aplicações). Depois que o avião está voando, fazer reparo nas turbinas é complicado. Um "refactoring" da base de dados pode significar horas de reescrita de código fonte das aplicações,  o que envolveria muitos recursos: pessoas e financeiro. Portanto, não nos aprofundamos neste parte tão fundamental (temos uma serviço específico para isso). Mas, iremos nos pontos que podem contribuir negativamente na performance: excesso de normalização, "data types"(tipagem), tabelas de "staging" (auxiliares), tabelas temporárias, tabelas sumarizadas, entre outros fatores que podem ser, perfeitamente, ajustados em sintonia com a aplicação.