Olá, pessoal. Neste artigo vou abordar um tópico muito importante para quem trabalha com banco de dados: a melhoria de desempenho também conhecido como performance em banco de dados. Veremos que, de acordo com a documentação oficial dos bancos de dados atuais, ainda estamos muito longe de caracterizar o que realmente gera ou não melhor desempenho no banco.

Antes de começar, vamos imaginar uma situação hipotética que pode acontecer no dia a dia de qualquer profissional que esteja envolvido com banco de dados. Durante o desenvolvimento de algum sistema ou aplicação web, alguém cita que utilizar tal funcionalidade X ou parâmetro Y ou mesmo arquitetura Z gera um desempenho melhor em banco de dados. Até aqui tudo bem, porém são raros os momentos em que alguém se dispõe a quantificar o quanto de desempenho espera-se obter. Esta é uma questão muito séria e que poucas pessoas dão atenção.

Os profissionais da área de TI, e em especial programadores e DBAs, devem ser capazes de justificar certas mudanças atitudes ou mesmo recursos tecnológicos baseados em mais do que intuição e ideias sem quantificação. Imaginem, por exemplo, que um gerente de projeto pode perguntar: “Muito bem, faz sentido utilizar a funcionalidade X ou parâmetro Y ou mesmo arquitetura Z, mas o quanto de melhoria percentual pode-se esperar?”. Qual seria a resposta a ser fornecida para esta pergunta evitando recorrer ao ‘achismo’?

Infelizmente, tenho visto que poucos profissionais respondem adequadamente a este tipo de pergunta. Isso contribui para a falta de preparo de profissionais na área e faz aumentar o ‘achismo’ cada vez mais presente e que, até certo ponto, é incentivado pelos fabricantes de banco de dados, como veremos.

Para saber justificar quantitativamente as melhorias de desempenho em um banco de dados é preciso realizar testes. E testes que sejam de acordo com o ambiente, pois é preciso levar em consideração uma série de fatores. Infelizmente, seguir receitas prontas e recomendações gerais não quantificadas ou baseadas em pouca teoria pode até indicar um caminho certo, mas tal prática torna imprevisível a medição de resultados sem testes. O que quero dizer aqui é que sem testes de desempenho, sejam eles genéricos ou específicos, é muito difícil quantificar efetivamente qual seria a melhoria da implementação de tal funcionalidade X ou Y ou Z. E isso tem um impacto muito grande em certos profissionais a ponto de informações jogadas serem propagadas sem nenhum questionamento. Vejam bem, é inadequado para um profissional dizer que tomou tal atitude ou desenvolveu de certa maneira por que disseram-lhe, sem comprovação com dados ou fundamentação teórica, que era melhor assim. E isso é uma realidade muito próxima quando se fala em melhoria de desempenho de banco de dados – especialmente entre programadores.

Pensando neste cenário resolvi apontar o dedo para os fabricantes de bancos de dados e pesquisar até que ponto eles ajudam o profissional a indicar quantitativamente o quanto funcionalidades, recursos, parâmetros, etc pode auxiliar no desempenho de banco de dados. Obviamente, não estamos falando de valores exatos devido aos fatores do contexto em que os testes são executados. Contudo, procurei por alguma indicação, fonte ou mesmo algum tipo de teste que possa justificar as afirmações de melhora ou piora de desempenho. Caso contrário, é válido dizer que se temos uma informação do tipo “para ter uma performance melhor faça X” sem nenhum tipo de embasamento quantitativo ou mesmo testes que comprovem ou refutem o desempenho, podemos classificar esta afirmação como um mito.

O teste que decidi realizar foi simples: pesquisei na documentação oficial dos principais bancos de dados do mercado: o SQL Server 2012, o Oracle 12g, o IBM DB2 10.1, o PostgreSQL 9.2, o MySQL 5.6 e o MongoDB 2.2.3. A pesquisa foi feita pelos seguintes termos exatos que indicam algo para melhoria de desempenho: “better performance”, “increase performance”, “maximize performance”. Também pesquisei pelos termos “worse peformance”, “decrease performance” e “minimize performance” para identificar pontos onde são explicados motivos pelos quais o desempenho pode ser prejudicado.

Além de anotar a quantidade de ocorrência de cada um destes termos fiz uma análise de cada local onde eles aparecem procurando por alguma indicação numérica do tipo “tal funcionalidade, parâmetro, recurso, etc pode oferecer ganhos de aproximadamente X%”, ou seja, algo quantitativo. Também procurei por algum tipo de informação apontado para testes do fabricante que possam justificar as afirmações de melhora ou piora de desempenho contidas na documentação. Não fui exigente e qualquer tipo de teste ou mesmo aproximação de resultado já me indicava que não estava perante afirmações sem comprovação. Abaixo mostro os resultados das pesquisas e as fontes utilizadas.

Oracle

A pesquisa na documentação do Oracle foi realizada online através do site Oracle Database Documentation Library. Os resultados:

• Better performance: 218 ocorrências;
• Increase performance: 31 ocorrências;
• Maximize performance:  25 ocorrências;
• Worse performance: 2 ocorrências;
• Decrease performance: 3 ocorrências;
• Minimize performance: 3 ocorrências.

Alguns exemplos:

• “Generally, larger redo log files provide better performance.”
• “An inline view that selects data from multiple tables from a single database only. It reduces the amount of times the the remote database is accessed, improving the performance of a distributed query.”
• “During application development, you want to tune a new schema and its associated SQL workload for optimal performance.”

SQL Server

A pesquisa no SQL Server 2012 foi realizada utilizando a documentação oficial chamada Books Online que pode ser obtida gratuitamente. Realizei a pesquisa com a documentação instalada ao invés da versão online. Os resultados:

• Better performance: 50 ocorrências;
• Increase performance: 26 ocorrências;
• Maximize performance: 7 ocorrências;
• Worse performance: 0 ocorrências;
• Decrease performance: 13 ocorrências;
• Minimize performance: 6 ocorrências.

Alguns exemplos:

• “SQL Server optimizes the load automatically, according to the batch size value, which may result in better performance.”
• “To increase performance, each polling query should typically have a corresponding processing query.”
• “We do not recommend that you use fiber mode scheduling for routine operation. This is because it can decrease performance by inhibiting the regular benefits of context switching, and because some components of SQL Server cannot function correctly in fiber mode.”

IBM DB2

Para pesquisar na documentação oficial do IBM DB2 utilizei a página IBM DB2 Version 10.1 Information Center. Os resultados:

• Better performance: 75 ocorrências;
• Increase performance: 8 ocorrências;
• Maximize performance: 13 ocorrências;
• Worse performance: 1 ocorrência;
• Decrease performance: 3 ocorrências;
• Minimize performance: 1 ocorrência.

Alguns exemplos:

• “With table partitioning, you can divide large table objects between multiple data partitions for better performance.”
• “You should only use the NOT FENCED clause when you need to maximize performance benefits, and if you deem the routine to be secure.”

MySQL

A pesquisa na documentação do MySQL foi realizada no MySQL 5.6 Reference Material que pode ser obtido aqui. Assim como no SQL Server, fiz a pesquisa com a documentação em HTML localmente ao invés de Online. Os resultados:

• Better performance: 9 ocorrências;
• Increase performance: 3 ocorrências;
• Maximize performance: 2 ocorrências;
• Worse performance: 0 ocorrências;
• Decrease performance: 1 ocorrência;
• Minimize performance: 0 ocorrências.

Alguns exemplos:

• “The size of the cache to hold changes to the binary log during a transaction. A binary log cache is allocated for each client if the server supports any transactional storage engines and if the server has the binary log enabled (–log-bin option). If you often use large transactions, you can increase this cache size to get better performance.”
• “Data are transferred unbuffered without calling mysqli_stmt_store_result which can decrease performance (but reduces memory cost).”

PostgreSQL

A comunidade que mantém o PostgreSQL, o PostgreSQL Global Development Group, disponibiliza a documentação oficial do PostgreSQL 9.2 aqui. Fiz uma pesquisa pelos termos no arquivo PDF para evitar resultados redundantes e de outras versões. O resultado foi o seguinte:

• Better performance: 5 ocorrências;
• Increase performance: 0 ocorrências;
• Maximize performance: 0 ocorrências;
• Worse performance: 0 ocorrências;
• Decrease performance: 0 ocorrências;
• Minimize performance: 0 ocorrências.

Alguns exemplos:

• “Table- and row-level locking facilities are also available in PostgreSQL for applications which don’t generally need full transaction isolation and prefer to explicitly manage particular points of con?ict. However, proper use of MVCC will generally provide better performance than locks.”
• “Note: the built-in aggregate array_agg provides similar functionality, with better performance than this de?nition would have.”

MongoDB

O MongoDB foi o banco de dados NoSQL que possui a melhor documentação em relação a aspectos de desempenho. A pesquisa pelos termos foi realizada no documento PDF cujo título é MongDB Documentation Release 2.2.3 e que pode ser obtida aqui. Os resultados:

• Better performance: 6 ocorrências;
• Increase performance: 2 ocorrências;
• Maximize performance: 1 ocorrência;
• Worse performance: 0 ocorrências;
• Decrease performance: 0 ocorrências;
• Minimize performance: 0 ocorrências.

Alguns exemplos:

• “If your query includes the ?rst component of a compound shard key, the mongos can route the query directly to a single shard, or a small number of shards, which provides better performance. Even if you query values”
• “(…)Bulk insert can signi?cantly increase performance by amortizing write concern costs.”
• O gráfico mostrado abaixo foi montado para facilitar a visualização dos dados de ocorrências em termos específicos na documentação dos bancos de dados.

Para minha surpresa, apesar de encontrar diversas ocorrências dos termos pesquisados nas documentações oficiais, em nenhum texto encontrei indicações quantitativas de melhora ou piora de desempenho e nenhum teste que comprove ou indique que as afirmações encontradas são verdadeiras. Vejam bem, em todos os casos a própria documentação oficial não fornece dados numéricos que corroboram o que é dito! Isso me leva a pensar que os fabricantes querem que engulamos goela abaixo o que eles escrevem na documentação sem ao menos ter algum tipo de teste, por mais simples que seja, que possa comprovar o que está escrito.

Este tipo de situação bate de frente com o que um bom professor deve ensinar a um aluno: questione. Não aceite informações jogadas sem que elas sejam compreendidas, comprovadas e analisadas quantitativamente com o mínimo de confiança estatística.

Compreendo que testar cada funcionalidade pode ser uma tarefa impraticável e que fica a cargo de quem utiliza o banco de dados verificar que afirmações de piora ou melhora de desempenho deve ser avaliada no contexto específico de cada um. Contudo, ao menos alguma indicação de como proceder para realizar um teste deveria ser colocada na documentação ou em anexos. A propósito, tudo indica que os fabricantes não incentivam o teste de desempenho de certas funcionalidades através da colocação de cláusulas de confidencialidade no EULA ou mesmo dificuldade a criação de baterias de testes para certas funcionalidades específicas.

Há também o teste padrão da indústria, o famigerado TPC. Tenho sérias restrições quanto à utilidade deste teste, sua metodologia, seus resultados e como ele pode ser aplicado no dia a dia de quem trabalha com banco de dados para avaliar e tomar decisões relacionadas ao desempenho.

Para concluir, gostaria de indicar que antes de sugerir alguma abordagem que vai “magicamente” melhorar o desempenho devemos sempre levar que se não temos nenhum tipo de teste ou mesmo resultado empírico esta afirmação pode ser tratada como um mito. Infelizmente, na maioria das vezes muitas pessoas estão mais preocupadas em ganhar desempenho do que em compreender até que ponto certa abordagem pode ser útil, vale a pena ser utilizada e qual é, quantitativamente falando, a vantagem de utilizá-la.