Ferramentas ORM e os Bancos de Dados Estruturados

Elaborado e escrito por Hemerson Ravaneda e Marlos Santos.

Em tempos de desenvolvimento rpido de aplicaes, metodologias, tcnicas e frmulas

mgicas para a produo de aplicaes, notvel o crescimento da criao e uso de

ferramentas de ORM (object relational mapping), isto , ferramentas para mapeamento

objeto-relacional. Estas ferramentas ORM tem por objetivo traduzir dados estruturados em

tabelas de bancos de dados em objetos de programao e, tambm, o caminho contrrio.

Quando utilizado de forma mais completa, as ferramentas de ORM podem ser utilizadas para a

criao das estruturas dos bancos de dados a partir dos objetos escritos pelos desenvolvedores

em projetos de software. Desta forma, tudo nasce a partir dos objetos e os desenvolvedores

de sistema no precisam ter conhecimento de como as informaes so persistidas ou

recuperadas nos bancos de dados.

Outra abordagem, que pode ser vista como hbrida, quando uma equipe desenha a soluo

atravs da anlise do negcio, documenta e gera um diagrama de entidades e seus

relacionamentos. Este diagrama costuma ser uma representao exata das tabelas criadas nos

bancos de dados. Os desenvolvedores precisam, a partir disto, configurar a ferramenta de

ORM para fazer uma comunicao com esta estrutura j pronta. Este texto trata desta

abordagem.

Muitas vezes (muitas mesmo), reclamaes so feitas aos responsveis do banco de dados na

seguinte tnica: Nossa, est muito lento. O banco de dados no est dando conta, ou

precisamos trocar o banco de dados j que esse no est entregando o resultado no tempo

esperado, ou pior ainda o banco est lento. Reclamaes estas partem de todos os

envolvidos no projeto como os prprios desenvolvedores, lideranas e at os usurios finais do

sistema; so descritos na sequncia alguns cenrios obtidos com esta abordagem.

Em um dos casos presenciados, uma empresa contava com um servidor biprocessado, sendo

cada processador com seis ncleos, e 96 GB de memria. Um determinado processo

gigantesco (processava aproximadamente 200 milhes de registros de uma tabela principal)

levava at 10 horas com consumo de 100% dos recursos da mquina. Ora, a concluso que

costuma parecer bvia neste caso aumentar a capacidade de processamento e a quantidade

de memria do servidor. Com mais espao para cach e mais capacidade de processamento, o

resultado pode ser obtido mais rapidamente. Neste enfoque, a empresa adquiriu um novo

servidor com quatro processadores, 10 ncleos por processador e 512 GB de memria. Era

esperado que esse novo servidor seria capaz de entregar a resposta num tempo considerado

hbil (menos de uma hora). Entretanto, o processo que levava at 10 horas, passou a levar, em

mdia, 12 horas. Acompanhando o processo minuciosamente, o processamento no era mais

problema, pois apresentava picos de apenas 12% de consumo. A memria reservada estava

suficiente e o banco de dados no apresentava waits, locks, limitaes de recursos, nada.

Consequentemente, as reclamaes citadas acima surgiram e tambm concluses empricas

como o SQLServer (banco de dados utilizando nesse caso) no aguenta uma base desse

tamanho. Testes foram feitos com o Oracle e os resultados foram similares. Onde estaria o

problema? Se o processo era o mesmo, porque no conseguia utilizar todo o potencial do

processador? Foi iniciada uma anlise mais profunda do processo e cogitado que o problema

poderia estar na forma como a aplicao solicitava essas informaes ao banco de dados.

Poderia ser interessante implementar o processo no prprio banco de dados. A proposta soou

praticamente ofensiva equipe desenvolvimento, j que todas as best practices haviam sido

implementadas. A ttulo de informao, o banco de dados ficava armazenado em um storage

com 48 discos em RAID 5, com discos de 15k RPM. Ou seja, no era gargalo de IO.

Em uma outra empresa ocorria um problema infinitamente menor, mas tambm preocupante.

Quando um determinado produto entrou em operao foi feita a converso de dados de um

sistema antigo, aumentando bruscamente o nmero de registros armazenados nas tabelas do

banco de dados e a emisso de um relatrio especfico (que deveria ocorrer em at 15

segundos) passou a gastar absurdos 27 minutos. Mas neste caso o processamento e memria

no eram problema para o banco de dados, j que o processo consumia 6% de processamento

e a memria de 4 GB era mais que suficiente para a operao. Para uma anlise mais

detalhada, foi utilizado um profiler, buscando todas as consultas que consumiam mais de 3

segundos na execuo. Nada foi retornado para esta condio. Analisando a aplicao,

tambm no foi detectado problemas com recursos. Aps muita procura e monitorando as

requisies da aplicao ao banco de dados foi detectado o problema: o nmero de

requisies por segundo. Ambos os casos citados utilizavam uma ferramenta ORM.

O problema detectado, na realidade, muito conhecido. Entretanto, em tempo de

desenvolvimento muito difcil averiguar problemas em relao ao desempenho devido essa

ocorrncia. O nome tcnico do mesmo N+1 Queries. As classes escritas na aplicao

mapeiam suas propriedades para suas respectivas estruturas no banco de dados utilizando a

ferramenta de ORM. Entretanto, um objeto pode conter uma coleo de objetos de outro tipo

dentro dele. Esta a forma de relacionar dados em objetos que equivalente uma tabela

ligada outra em um banco de dados. Este outro tipo, por sua vez, pode conter outras

colees de outros tipos dentro dele e assim sucessivamente. A ttulo de exemplo, uma classe

nota fiscal, possui um campo chamado itens que uma coleo de objetos da classe item

de nota fiscal que, por sua vez, contm um produto. No banco de dados a representao

destas classes sero trs tabelas: nota fiscal, item e produto. Uma consulta utilizando joins

consegue trazer os dados j relacionados para cada nota fiscal. Entretanto, uma ferramenta

ORM pode ser configurada para utilizar um conceito chamado carregamento tardio. Este

carregamento far uma consulta para cada dado de uma classe aninhada apenas quando for

necessrio. Isto faz com que j sejam disparados contra o banco de dados uma quantidade

expressiva de consultas. O problema N+1 est relacionado especificamente no caso em que

uma consulta utiliza uma clusula de filtragem que envolve trazer uma entidade pai com

alguma restrio na coleo dos filhos, por exemplo: localizar pessoas que tenham um

endereo em uma cidade especfica. Em SQL, seria:

select p.* from pessoa p inner join endereco e

on p.Id = e.IdPessoa where e.cidade = londrina;

J utilizando ORM com carregamento tardio, sero enviados separadamente os seguintes

comandos ao banco de dados:

select * from pessoa;

Aps isso o sistema percorre pelas pessoas encontradas e envia um comando para cada pessoa

na base de dados como este:

select * from endereco where idpessoa = @idPessoa and cidade = londrina;

Da o nome do problema, uma query para buscar a entidade pai e N queries, ou seja, quantos

pais houverem, na entidade filho. Caso no seja utilizado o carregamento tardio, a ferramenta

de ORM pode gerar consultas utilizando joins, no entanto, caso haja as tabelas sejam

interligadas em teias ou em uma sequncia de relacionamentos muito longa, a consulta para

materializar os objetos pode vir a carregar uma quantidade inconcebvel de dados em uma

nica consulta. claro que erros de design do modelo podem agravar este cenrio.

Vale salientar que um agravante em relao a este problema tem justamente a ver com as

boas prticas de desenvolvimento, como por exemplo o baixo acoplamento de classes. Em um

projeto de maior proporo, no se pode (por questes de boas prticas) acoplar um

framework ORM regra de negcio, pois, se o framework for descontinuado, ele ter que ser

facilmente substituvel. Com alto acoplamento isto se torna uma tarefa complexa. Em geral,

por isso, as ferramentas de ORM so posicionadas em um projeto para serem o mais

transparente possvel. Em consequncia, os desenvolvedores no se preocupam com nenhum

aspecto do comportamento do framework e, mesmo tendo a preocupao, no possuem

meios de configurar a ferramenta em tempo de execuo por estarem desacoplados do

framework. O que ocorre nestes casos uma configurao de alto nvel (global) que, no caso

do carregamento tardio configurado uma nica vez para todo o ciclo de execuo. Esta

configurao pode funcionar para projetos de pequeno porte, mas quando o nmero de

registros comea a crescer, algum contorno deve ser feito para otimizar os casos mais

complexos. Em geral, esse contorno se torna o uso de procedimentos armazenados no prprio

banco de dados, que causa gera um acoplamento altssimo com o sistema gerenciador de

banco de dados.

Voltando aos casos estudados, porque, no primeiro caso, um servidor menor era capaz de

entregar o resultado mais rapidamente que o servidor maior? Com o mecanismo de

carregamento tardio da ferramenta de ORM ativo, um gigantesco nmero de requisies era

disparado contra o servidor. O servidor antigo possua processadores com clock de 3 GHz, e o

servidor novo, apesar de possuir muito mais ncleos de processamento, trabalhava em um

clock de 1,9 GHz. Como cada requisio continha, em si, uma consulta extremamente simples,

o banco de dados no conseguia dividir a tarefa recebida em tarefas menores e utilizar, assim,

outros ncleos do processador. Enfim, o processo se tornava um enfileiramento indivisvel e,

neste caso, processadores com clock mais alto conseguem responder em menor tempo um

mesmo nmero de requisies.

Os dois casos estudados continham o mesmo problema: a forma da utilizao da ferramenta

ORM. Com a alterao da aplicao para utilizar o carregamento imediato em alguns casos e a

migrao de processos mais onerosos para procedimentos armazenados no banco de dados,

os gargalos foram suprimidos. Em alguns casos foram feitas alteraes no design do modelo do

banco de dados afim de facilitar a gerao de consultas pela ferramenta de ORM e

consequentemente aumentar o desempenho global da aplicao. Torna-se possvel concluir

que, a separao completamente desacoplada de regras de negcio, camada de persistncia

(utilizando ORM) e banco de dados deve ser minuciosamente mensurada. H sempre um custo

envolvido que dever ser pago em alguma camada do sistema. Boas prticas de

desenvolvimento em geral so inversamente proporcionais ao desempenho da aplicao

resultante (em relao ao armazenamento de dados, obviamente). Ao utilizar ferramentas

ORM em modelos relacionais construdos previamente, os desenvolvedores devem analisar o

volume de requisies enviado ao banco de dados e se precaver de possveis problemas de

desempenho com o crescimento da base de dados de uma aplicao.