Os testes neste post apresentados não representam uma amostra exata ou fidedigna que represente uma condição real de acesso a dados de uma aplicação a fim de comparar a performance das duas tecnologias. A idéia é apenas mostrar alguns dados e exemplos com o objetivo de dismistificar a idéia de que ORM é uma ferramenta lenta e estes testes são apenas um exercício.

Sou usuário de NHibernate e defendo o uso de ORM’s portanto as conclusões apresentadas com certeza não são as mais imparciais possíveis.

Motivado por esta thread no DNA hoje decidi fazer alguns testes de perfomance pra comparar acesso a dados utilizando ADO.NET nativo (queries AdHoc e Stored Procedures) versus NHibernate.

Sempre rolam diversas discussões a respeito do assunto e a conclusão que geralmente se chega é de que qualquer ORM vai ser mais lento do que uma chamada nativa. É uma conclusão óbvia já que utilizar um ORM é adicionar uma camada de abstração a mais dentro da nossa aplicação. No entanto, até então eu nunca havia efetuado nenhuma medição pra ver qual a diferença de performance.

Todos os testes foram executados na minha máquina com código compilado em modo Release com banco de dados Sql Server 2008 também local.

Vamos aos testes.

Cenário de testes

Criei uma tabela (Product) e populei com cerca de 500 registros vindos do AdventureWorks (banco de dados exemplo do SqlServer).

Contra essa tabela executei duas categorias de testes:

1. Carregar todos os registros da tabela em um List<>
2. Carregar apenas um registro

Pra ficar mais interessante fiz algumas variações dos testes:

• Query AdHoc/Inline
• Query AdHoc/Inline com hidratação[1] via reflection
• Query utilizando uma procedure
• NHibernate com LINQ
• NHibernate com HQL
• NHibernate com Criteria
• Nhibernate com Projections

Como rodando uma única vez não foi possível obter dados suficientes, executei cada teste dentro de um loop com 1000 (numberOfIterations = 1000) iterações que resultou no código abaixo:

Método principal:

static void Main(string[] args)
{
    for (int i = 1; i <= 3; i++)
    {
        Console.WriteLine("Test " + i.ToString());
        Console.WriteLine("======================");

        SqlAdHocAllProducts();
        SqlAdHocAllProductsWithReflection();
        SProcAllProducts();
        NHibernateAllProductsWithLinq();
        NHibernateAllProductsWithHql();
        NHibernateAllProductsWithCriteria();
        NHibernateAllProductsWithProjections();

        SqlAdHocOneProduct();
        SqlAdHocOneProductWithReflection();
        SProcOneProduct();
        NHibernateOneProduct();

        Console.WriteLine();
    }

    Console.ReadLine();
}

Um dos métodos usando Sql AdHoc e outro usando NHibernate:

private static void SqlAdHocAllProducts()
{
    List<Product> allProducts = null;

    var connectionString = "Data Source=(local);Integrated Security=SSPI;Database=TDC2010;";
    var select = @"SELECT P.Id, P.Description, P.Name, P.Price FROM dbo.Product P";

    var connection = new SqlConnection(connectionString);
    connection.Open();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = new List<Product>();
        var command = new SqlCommand(select, connection);
        var reader = command.ExecuteReader();

        while (reader.Read())
        {
            allProducts.Add(new Product()
                {

                    Id = Convert.ToInt32(reader["Id"]),
                    Name = Convert.ToString(reader["Name"]),
                    Description = Convert.ToString(reader["Description"]),
                    Price = Convert.ToDecimal(reader["price"])
                });
        }

        reader.Close();
    }

    watch.Stop();

    connection.Close();
    connection.Dispose();

    Console.WriteLine(
        "Loading " + allProducts.Count + " Products with Sql AdHoc took " + watch.ElapsedMilliseconds + " ms");
}

private static void NHibernateAllProductsWithLinq()
{
    List<Product> allProducts = null;

    var session = CreateForSqlServer().OpenSession();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = session.Linq<Product>().ToList();
    }

    watch.Stop();

    session.Close();

    Console.WriteLine(
        "Loading " + allProducts.Count + " Products with NHibernate took " + watch.ElapsedMilliseconds + " ms");
}

Vou omitir o restante dos métodos para evitar duplicações já que eles são apenas variações dos dois exemplos acima.

Resultado Geral

Análise dos Resultados

Stored Procedures versus Queries AdHoc/Inline [500 registros]

A diferença entre o uso de stored procedures e queries AdHoc é praticamente inexistente. A diferença média medida foi de menos de 1%.

Isso acontece, pois não existe complexidade suficiente neste tipo de query para que a armazenagem do plano de execução no banco de dados faça diferença.

Portanto, na grande maioria dos cenários Stored Procedures não são necessárias.

NHibernate versus NHibernate [500 registros]

Na média, todas as variações de consulta utilizando NHibernate também tiveram mais ou menos o mesmo resultado (~1500ms) com exceção do uso de Projections, que levou o dobro (~3000ms) do tempo.

Não conheço o NHibernate suficiente pra afirmar com 100% de certeza o motivo, mas acredito que seja pelo fato de esse tipo de query retornar Arrays bidimensionais que são criados e redimensionados em runtime até que todos os itens possam ser acomodados.

NHibernate versus ADO.NET [500 registros]

Este e o comparativo mais importante. Carregando (e hidratando) 500 registros o ADO.NET é cerca de 30% mais rapido do que o NHibernate. A causa dessa discrepância é uma só e se chama reflection.

Apesar de todas as otimizações o NHibernate utiliza-se de reflection para efetuar a hidratação[1] de todos os objetos e é dai que vem a queda de performance que fica clara quando executamos queries AdHoc usando hidratação via reflection conforme o código abaixo.

private static void SqlAdHocAllProductsWithReflection()
{
    List<Product> allProducts = null;

    var connectionString = "Data Source=(local);Integrated Security=SSPI;Database=TDC2010;";
    var select = @"SELECT P.Id, P.Description, P.Name, P.Price FROM dbo.Product P";

    var connection = new SqlConnection(connectionString);
    connection.Open();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = new List<Product>();
        var command = new SqlCommand(select, connection);
        var reader = command.ExecuteReader();

        while (reader.Read())
        {
            var newProduct = Activator.CreateInstance<Product>();
            SetProperty(newProduct, "Id", Convert.ToInt32(reader["Id"]));
            SetProperty(newProduct, "Description", Convert.ToString(reader["Description"]));
            SetProperty(newProduct, "Name", Convert.ToString(reader["Name"]));
            SetProperty(newProduct, "Price", Convert.ToDecimal(reader["Price"]));
            allProducts.Add(newProduct);
        }

        reader.Close();
    }

    watch.Stop();

    connection.Close();
    connection.Dispose();

    Console.WriteLine(
"Loading " + allProducts.Count + " Products with Sql AdHoc and Reflection took " + watch.ElapsedMilliseconds + " ms");
}

private static void SetProperty(object instance, string property, object val)
{
    Type t = instance.GetType();
    var prop = t.GetProperty(property, BindingFlags.Instance | BindingFlags.Public);
    prop.SetValue(instance, val, null);
}

Este código quando executado demora cerca de 6000ms, ou 4 vezes mais, do que o código executado pelo NHibernate.

Mas por que a diferença não é de 30%? Porque o NHibernate possui otimizações quanto ao modo de hidratar um objeto via reflection. No meu código acima podemos ver, por exemplo, que toda vez que chamo o método SetProperty o Type da propriedade a ser refletida ainda não está criado. Provavelmente o NHibernate deve manter cache deste tipo de informação (e de outras) a fim de otimizar o processo de hidratação das entidades.

Stored Procedures versus Queries AdHoc/Inline [1 registro]

Mesmo resultado do cenário onde 500 registros são carregados. Não há diferença.

NHibernate versus ADO.NET [1 registro]

Aqui a diferença é gigantesca sendo de quase 4000% a favor do NHibernate. Isso acontece, pois o NHibernate implementa cache nível 1 nativamente então dentro de uma mesma ISession o objeto é carregado apenas uma vez enquanto com ADO.NET é necessário ir ao banco e carregar o objeto diversas vezes.

Conclusões

Olhando para os números apenas, em casos onde diversos registros precisam ser carregados, ADO.NET nativo oferece uma performance superior e parece ser a escolha óbvia. No entanto:

• Os testes com NHibernate foram executados utilizandos exemplos simples e sem qualquer tipo de otimização.
• NHibernate oferece nativamente cache de resultados de queries e cache nível 2 que se utilizados iriam exibir um resultado bem próximo ao cenário “NHibernate versus ADO.NET [1 registro]” onde o NHibernate é 4 vezes mais rápido.
• ADO.NET oferece um custo de desenvolvimento e manutenção altissimo e este custo torna-se ainda maior se utilizado com Stored Procedures que transformam o cenário em algo totalmente caótico de gerenciar devido a dificuldade de manter a rastreabilidade desses diabinhos malignos.

No caso de sistemas OLTP onde as transações carregam unidades individuais e/ou pequenas coleções de entidades por sessão, NHibernate não só é mais rápido como também oferece muito mais flexibilidade pra lidar com praticamente todos os cenários existentes. Este post do Ayende mostra 25 funcionalidades importantes (cache, gerenciamento de concorrência, etc) que você vai precisar quando estiver lidando com dados e que custariam muito caro (tempo e complexidade) caso você queira escreve-las “na mão”.

Em cenários de aplicações de internet onde o número de leituras é infinitamente superior ao número de escritas no banco de dados deve se utilizar cache no front end (IIS), portanto o tempo que se leva pra montar uma página é irrelevante. Mesmo que você carregasse os dados de um servidor remoto via conexão discada não faria diferença uma vez que os dados estivessem em cache.

Por último, se você se encontrar em uma situação utilizando NHibernate onde o acesso a dados é o gargalo da sua aplicação seu problema não é o NHibernate (a não ser que você tenha usado-o de maneira totalmente absurda, mas a probabilidade de você fazer o mesmo com ADO.NET é grande também). Nestes cenários o problema não é o acesso a dados em si, mas o resto da arquitetura que não escala de maneira adequada seja por meio de cache, processamento assincrono, filas, etc.

Sendo assim, acredito que podemos concluir que não faz sentido algum no meio do ano de 2010 utilizar queries AdHoc ou Stored Procedures em aplicações LoB.

O código completo utilizado está no GitHub e pode ser acessado online ou baixado em formato zip.

[1] – Hidratação é o processo de preenchimento (filling) das propriedades de uma entidade

Apresentando Migrator.NET

Para resolver a maioria (senão todos) os problemas de versionamento de banco temos uma ferramenta maravilhosa chamada Migrator.NET. Essa ferramenta é um port para .NET do original em Rails. A idéia por trás dela é bastante simples: consiste em diversos objetos (classes) versionados (da mesma maneira que código normal) contendo as instruções que devem ser executadas para gerar e/ou voltar o schema do banco de dados. Cada classe corresponde a uma instrução de alteração e contém um método Up (adicionar/avançar) e um método Down (retroceder/fallback) equivalente. Vejamos como é facil no exemplo abaixo:

#region Usings

using System.Data;
using Migrator.Framework;

#endregion

namespace NetScrum.Migrations.Tables
{
    [Migration(20090209211900)]
    public class CreateTableProject : Migration
    {
        public override void Down()
        {
            Database.RemoveTable("netscrum_project");
        }

        public override void Up()
        {
            Database.AddTable("netscrum_project",
                new Column("id", DbType.Int32, ColumnProperty.Identity)
                , new Column("name", DbType.AnsiString, 100, ColumnProperty.NotNull)
                , new Column("description", DbType.AnsiString, 300, ColumnProperty.Null)
                );

            Database.AddPrimaryKey("pk_project", "netscrum_project", "id");
        }
    }
}

Viram? Basta referenciar a DLL Migrator.Framework.dll, adicionar a diretiva using criar sua classe herdando de Migration e dar override nos métodos Up e Down.

Gerenciando as versões

Para gerenciar as versões e garantir que os migrations sejam executados na ordem correta, você deve utilizar o atributo Migration(long version) decorando a classe. Você deve preenche-lo com um long contendo o timestamp no formato AAMMDDhhmmss (ano/mes/dia/hora/minuto/segundo) em que seu migration foi gerado. Ou seja, um alter table da tabela projeto, por exemplo, deve conter um valor mais novo (maior) que o create table correspondente para que o migration de create seja executado antes do alter.

Configurando o build

Criar e gerenciar migrations é muito fácil. No entanto, as configurações dele são um pouquinho chatas para quem não está familizarizado com MSBuild ou NAnt. Neste artigo vamos usar o MSBuild que já é nativo e eu gosto mais simplesmente por estar familiarizado.

Junto com o código fonte compilado do Migrator.NET vem também o assembly Migrator.MSBuild.dll que é onde está a o target especifico que o MSBuild precisa para executar os migrations. Este target será usado no arquivo de build (explicado mais abaixo) e deve ser configurado como o exemplo abaixo apontando para o caminho onde esta o assembly. Arquivos Migrator.Targets:

        $(MigratorTasksPath)\Migrator.MSBuild.dll

A propriedade $(MigratorTasksPath) define onde está o assembly Migrator.MSBuild.dll. O valor desta propriedade pode ser hard-coded ou então preenchida no arquivo de build conforme veremos.

Por padrão, todo projeto (arquivo.csproj no caso de C#) é um arquivo de MSBuild. É possível editá-lo para incluir as configurações necessárias ao Migrations, mas cedo ou tarde é perigoso que Visual Studio o recrie ou o modifique a seu bel prazer e ai perderiamos as customizações. Portanto, prefiro criar um outro arquivo de build exclusivo para os migrations e chama-lo quando eu bem entender. Segue abaixo o arquivo NetScrum.Migrations.build:

    $(MSBuildProjectDirectory)

Este arquivo define uma série de paramêtros:

• MigratorTasksPath – Caminho utilizado para apontar onde esta o target (mencionado acima). Neste caso, é preenchido pela propriedade $(MSBuildProjectDirectory) que aponta para onde o arquivo build que está sendo chamado está localizado.
• DatabaseVersion – Será passado via paramêtro na hora da chamada do Migrator.NET. Caso não seja informado, o valor default é -1 que indica para a última versão.
• Provider = Banco de dados de destino. Neste caso estamos usando SqlServer, mas Migrator.NET funciona para outros bancos também.
• Connectionstring – Óbvio, né?
• To – Recebe o valor do parametro DatabaseVersion indicando a versão de destino do migrations.
• Migrations – Caminho onde se encontra o assembly compilado contendo as migrations.

Existem alguns outros paramêtros que permitem uma configuração um pouco diferenciada, como por exemplo, ao invés de fornecer o assembly compilado apenas informar o caminho onde estão as classes para que o próprio Migrator.NET faça a compilação.

Uma vez que tudo esteja configurado, basta ir até o command prompt, navegar até a pasta onde o arquivo.build e chamar o MSBuild passando os paramêtros conforme o exemplo abaixo:

%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe NetScrum.Migrations.build /t:Migrate /p:DatabaseVersion=-1

Os paramêtros são:

• NetScrum.Migrations.build – Nome do arquivo de build que contém as configurações do Migrator.NET
• /t:Migrate – Target que deve ser executado. Neste caso o target de migrations
• /p:DatabaseVersion=-1 – Versão do banco para qual desejo ir. Caso queira ir para última versão é só informar -1. Caso queira zerar o banco (executar Down de todas as migrations) é só informar 0. No caso de ir para uma versão específica é só informar o timestamp desejado.

É isso! Configurar a primeira vez é um pouco chato. Acertar os caminhos dos arquivo requer algumas tentativas para quem não está familizarizado com o MSBuild, mas nada muito traumático. Nos exemplos, todos os arquivos necessários (menos o assembly contendo as migrations) estavam na mesma pasta (tools) para facilitar.

Exemplo

Quem quiser ver o exemplo funcionando, basta baixar a última versão do .NET Scrum. Ele contém as pastas e arquivos configurados direitinho pra funcionar.

Importante

A versão utilizada para este artigo foi a 0.8 que baixei tem uns 45 dias. Na época, apesar de compilada não estava funcionando então tive que efetuar umas pequenas correções do trunk. Não testei a versão 0.8 disponível hoje, portanto você pode baixar aqui a versão 0.8 compilada e corrigida por mim.

Referências

Até alguns dias atrás eu não tinha encontrado nenhum outro artigo a respeito deste assunto em português. Acredito que ainda não exista e esse seja o primeiro. Além das instruções básicas de banco que foram apresentadas no migration do exemplo ainda é possível criar PKs, FKs, executar Sql’s open text entre outros procedimentos não descritos aqui.

Vocês podem encontrar informações a respeito desses procedimentos no site do projeto ou tirar dúvidas e perguntar aqui mesmo no blog.

Enjoy!

O problema

Controlar o código fonte que é compilado pela nossa ferramenta de trabalho é uma tarefa que já foi bem complicada, mas que se tornou relativamente fácil com a evolução dos próprios editores de código (Visual Studio) e dos repositórios de código (TFS, SVN, CVS, etc). No entanto, não podemos dizer o mesmo dó código fonte que utilizamos para nossa aplicação acessar bancos de dados. Na maioria da vezes esse código não é compilado e por mais que existam checagens de sintaxe os erros tendem a aparecer na hora que estamos desenvolvendo a versão 2.1 do sistema e precisamos recuperar versão 1.5 para corrigir bugs. Isto, quando esse controle é feito de alguma forma e esse processo é possível, pois na maioria das vezes tudo que as pessoas mantém são os dados no próprio SGBD sem nenhum controle de versão.

Gerenciar a versão do banco de dados quer dizer que no momento em que eu recuperar a versão XYZ do meu sistema também vou conseguir recuperar os artefatos de banco (tabelas, procedures, triggers, etc) correspondentes a esta versão, restaurando desta forma o sistema em um ponto estável tanto do ponto de vista de estrutura quanto do ponto de vista de dados.

Além dos pontos falhos óbvios que essa falta de controle apresenta existe mais um problema que considero grave e que, inclusive prejudica a aplicação de práticas ágeis como integração contínua e testes automatizados. Existindo a necessidade de efetuar esse controle de maneira manual fica impraticável a execução dessas práticas, pois para executá-las durante todo o tempo tudo (incluindo os scripts de banco de dados) que compõe o sistema deve permitir automatização.

As opções existentes

É claro que não posso falar por toda a comunidade de desenvolvimento Microsoft, mas a grande maioria dos projetos que já participei ou conversei a respeito com outros colegas de plataforma tinha pouquissimo (não confiável) ou nenhum controle deste tipo. Geralmente as pessoas efetuam este tipo de controle de duas formas:

• Como se fosse código-fonte normal – Scripts de create table, procedures e demais artefatos são mantidos em diversos arquivos SQL (ou em um linguição) no repositório de código e o desenvolvedor utiliza eles na hora em que precisa avançar ou restaurar uma versão. O maior problema desta técnica é que como o desenvolvedor não precisa efetivamente gerar scripts de banco de dados para modificar o banco, pois pode faze-lo pela ferramenta RAD com arrasta-estica-e-puxa dificilmente ele gera esses scripts depois da primeira vez e mais raramente ainda ele gera esses scripts de maneira correta. No final, temos uma salada de scripts: alguns utilizando alter table, outros modificando um script de create já existente, diversas versões da mesma procedure e possívelmente nenhum daqueles scripts de carga feitos pelo joãozinho no começo do projeto. Dessa forma, é impossível ir para a versão de banco de dados desejada de maneira fácil e sem dores de cabeça.
• Mantendo tudo no banco de dados – A maioria dos desenvolvedores, infelizmente, se preocupa pouquissimo com o futuro do projeto e estão preocupados apenas com suas tarefas atuais. Dessa forma, qualquer atalho para terminar uma tela mais rápido é bem vindo, mesmo que este atalho cause um grande problema no futuro. Por este motivo, muitas pessoas mantem a estrutura de banco de dados apenas no SGBD. Alguns projetos inclusive não tem nem um modelo de dados em uma ferramenta como o ErWin ou DBDesigner por exemplo. Agora vamos imaginar que por algum motivo o banco de dados de desenvolvimento foi pro espaço. Se não tiver alguém da equipe que mantem um backup local o projeto está perdido. Possívelmente milhões $$$ perdidos por preguiça e falta de organização.

A Microsoft tentou no Visual Studio Team System Database Edition com o projeto de banco de dados (somente para SqlServer) uma alternativa a essas maneiras, mas infelizmente não obteve sucesso. A idéia é manter um projeto que por meio de um banco de dados local simula a compilação dos scripts diminuindo os erros de deploy. No entanto, todo este processo é lento, obriga o desenvolvedor a ter um SqlServer instalado localmente e tem uma série de limitações como não poder acessar outros bancos diferentes do banco com qual o sistema trabalha e de outros providers (Oracle, MySql, etc.). Ainda não testei o VSTS 2010, mas não acredito que seguindo esta receita seja possível obter muito sucesso.

A solução

Para resolver este problema, o ideal seria que pudéssemos tratar dos objetos de banco da mesma maneira que tratamos os objetos do nosso sistema. Objetos que compilam efetivamente nos oferecem mais segurança, ainda mais se estes forem construidos utilizando uma API simples e padronizada que possibilite o deploy em bancos distintos. Melhor ainda se o desenvolvedor não precisar ter muito trabalho para efetuar este controle, pois se o processo exigir muito trabalho ninguém irá utilizá-lo.

No próximo post, vou falar sobre o Migrator.NET que oferece essas características que apresentei no paragráfo anterior de uma maneira rápida e fácil de usar.

Link para parte 2