Lazaro Fernandes Lima - Blog

Cache em aplicações web já se tornou uma necessidade extrema para aplicações que crescem muito com o passar do tempo, sendo quase indispensável para que a aplicação seja escalável e performática.

Contudo, a maioria das aplicações não trabalha com cache.

Neste post iremos trabalhar com scripts de cacheamento em queries do banco de dados, cache de arquivos (proximos artigos).

Podemos trabalhar com cacheamento nativo utilizando DEPENCÊNCIAS desde o ASP.NET 2.0.

Irei utilizar um banco de dados próprio, com 10000 registros em uma determinada tabela, SQL Server 2005, Visual Studio 2008 com framework 3.5.

Cache de queries do banco de dados

Primeiramente, baixe o banco de dados, no SQL SERVER 2005, attache o mesmo à uma instância ativa do SQL SERVER 2005 para que possamos utilizar a tabela com os 10000 registros.

Após configurado o banco de dados vamos a etapa de desenvolvimento da aplicação.

Crie um WebSite, com framework 3.5.
Adicione os seguintes controles à pagina:

1. Button (btnObterDados)
2. Label (lblTempo)
3. GridView (grvDados)

Adicione um evento de click ao btnObterDados, o mesmo deve ficar da seguinte maneira:

protected void btnObterDados_Click(object sender, EventArgs e)
{
    //O objeto StopWatch será o nosso MEDIDOR, irá contabilizar o 
tempo gasto para efetuar todo o processo
    System.Diagnostics.Stopwatch timer = new System.Diagnostics.
Stopwatch();
    timer.Start();

    //Verifico se cacheDados é nulo
    if (Cache["cacheDados"] == null)
    {
        //Crio os tradicionais SqlConnection, SqlCommand, 
adapter e dataset
        SqlConnection conn;
        SqlCommand command;
        SqlDataAdapter da;
        DataSet ds = new DataSet();

        //Aqui esta a criança!
        SqlCacheDependency cache;

        //Neste ponto, nenhuma novidade
        conn = new SqlConnection(ConfigurationManager.
ConnectionStrings["auxiliarConnectionString"].ConnectionString);

        //Para que o SqlCacheDependency funcione, ele precisa ser 
inicializado pela classe estatica SqlDependency
        SqlDependency.Start(conn.ConnectionString);

        conn.Open();

        //Aqui temos um novidade, para que o
 SqlCacheDependency funcione algumas regras devem ser respeitadas
        //O select * from [tabela] não é permitido!, defina EXATAMENTE
 quais colunas deseja obter
        //O nome da tabela deve ser informado de forma completa, 
utilizando o (dbo.tabela) por exemplo.
        command = new SqlCommand("Select auxiliarid,auxiliarname,
auxiliarfullname from dbo.Auxiliar", conn);

        //Neste post não irei entrar em detalhes de como as dependências
 funcionam, porém, fica clara a necessidade de HABILITAR as notificações
        SqlCacheDependencyAdmin.EnableNotifications(conn.
ConnectionString);
        SqlCacheDependencyAdmin.EnableTableForNotifications(conn.
ConnectionString, "dbo.Auxiliar");

        //Instancio o objeto cache utilizando o SqlCommand
        cache = new SqlCacheDependency(command);

        da = new SqlDataAdapter(command);
        da.Fill(ds);

        //Adiciono o SqlCacheDependency inserindo no terceiro parâmetro
        Cache.Insert("cacheDados", ds.Tables[0], cache);

        conn.Close();
        conn = null;
    }

    grvDados.DataSource = (DataTable)Cache["cacheDados"];
    grvDados.DataBind();

    //Executo o Stop para que a contagem sera visualizada em lblTempo
    timer.Stop();

    lblTempo.Text = timer.Elapsed.ToString();
    timer = null;
}

O código esta auto-explicativo, baixe o projeto em meu skydrive para verificar uma implementação mais detalhada onde utilizei paginação no gridview.

Os resultados obtidos com esta implementação ficam claramente positivos quanto a performance da aplicação.

Vale lembra que, é necessário ter o Service Broker habilitado e que quaisquer alterações nos dados da tabela que incluem as colunas exibidas, como alteração de um campo, automaticamente, remove o cache da aplicação. É aqui que mora a vantagem da implementação tradicional.

Testem updates no banco.

Ate mais

Baixe o banco de dados e a aplicação.

Olá pessoal,

Lendo um white paper sobre arquitetura de bancos de dados SQL Server da Microsoft obtive diversas respostas para dúvidas quanto as melhores práticas em uma arquitetura utilizando ambientes em RAID (Redundant Array of Independent Disks). Sendo altamente recomendado a sua utilização quando problemas relacionados a disponibilidade de informações e alta taxa de I/O de dados afetam nossos ambientes.

Segue abaixo descrição dos níveis 0, 1, 5 e 10 de ambientes RAID aplicados a estratégias de arquitetura de banco de dados.

RAID0 (simple striping): Baixo custo, sendo o tipo mais simples de se configurar dentre os apresentados, excelente performance para armazenamento e leitura, uma vez que, vários discos estarão responsáveis pelo I/O, acelerando no minimo 100% sua performance. Seu ponto fraco esta na falta de tolerância à possíveis falhas.

RAID1 (simple mirroring): Cria uma cópia exata, espelhada, de todos os dados entre dois ou mais discos. Este nível provê boa redundância, porém, baixa eficiencia em armazenamento, não sendo indicado para performance em I/O e sim, segurança e maior disponibilidade dos dados, uma vez que, todos os dados estarão sendo espelhados em outras unidades de disco automaticamente.

RAID5 (striping with parity):  Nível mais popular utilizado na indústria (segundo documentos da Microsoft). Indicado para menor Input e maior Output de dados, provê uma distribuição de paridade em discos de forma alternada ao qual estas informações sao utilizadas para montar os dados em caso de perda de algum disco, (numero total de drives – 1) / (numero total de drives), claro, baseado em discos idênticos 

RAID10 (0+1) (stripe of mirrors): Este aqui é o mais indicado para a maioria dos casos, porém, 4 discos são necessários para a menor implementação deste nível de RAID, seu custo é o mais alto. Combina o melhor do RAID0 e RAID1, boa performance e excelente tolerância à falhas.

A eficiência na utilização dos níveis de RAID variam de casos para casos conforme podemos analisar acima.

A utilização deste ambiente RAID controlado via hardware é altamente recomendado, uma vez que, o S.O. estará totalmente responsável pelo controle deste ambiente, e sabemos que isto não cheira muito bem ;)

Referências:
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx (white paper ;] )
http://pt.wikipedia.org/wiki/RAID
http://www.clubedohardware.com.br/artigos/651

Até mais ;)

Eu me lembro quando programava com ASP 3 e sempre dava uma olhada em scripts SQL montados diretamente no código fonte. Como abaixo:

dim sql
sql = "Insert MinhaTabela (codigo, nome) "
sql = sql & "values('" & request.form("codigo") & "', '" & request.form("nome") & "')"

objConn.execute(sql)

É um perigo esse tipo de codificaçao!
Porém, muito flexivel.

Já no SQL SERVER 2005, este tipo de construção de script também está disponível, ele se chamada Dynamic SQL.

Ele permite que scripts sejam 'montados' em uma variável, por exemplo, e executados como instruções tradicionais.
Sua flexibidade está em quando se necessita poupar caminhos condicionais, como IFs e CASEs dentro de uma procedure, por exemplo.

Ou em casos em que limpe, altere ou exiba uma determinada tabela com determinadas colunas, onde, no SQL SERVER 2000 esta funcionalidade de 'concatenar' um script com tabelas, colunas, instruções e executar a partir de uma variável não esta disponível.
Com esta flexibilidade podemos desenvolver scripts bem dinâmicos, como o próprio nome diz. Vejam abaixo:

DECLARE@COLUMNS AS VARCHAR(200)

Fora isso, ele pode ser utilizado para melhorar o desempenho em SPs com muitas condicionais com certeza

Uma das novidades mais interessantes do SQL SERVER 2005 são as CTE ( Common Table Expressions ) e novas funções de ranking.

Uma CTE funciona como uma tabela temporaria e uma subquerie ao mesmo tempo, ao qual podemos trabalhar somente no momento da execução do script, ela tem uma construção rápida e extremamente flexível.

No SQL SERVER 2000 quando precisávamos de uma tabela temporária local, por exemplo, era necessário construir a tabela com uma estrutura para comportar a inserção e logo após o seu uso era necessário efetuar o comando drop table ou deixar que o SQL SERVER fizesse o servico sozinho. Já com as CTE as coisas são mais rápidas e eficientes, com elas agora e possível inserir, editar e remover registros direto da tabela original por meio da CTE. Vejam abaixo:

CREATE TABLE minha_tabela1
(
col1  varchar(100),
col2  varchar(100),
col3  varchar(100)
)
go

insert minha_tabela1 values(1,'abc','1')
insert minha_tabela1 values(2,'def','1')
insert minha_tabela1 values(3,'ghi','1')
insert minha_tabela1 values(4,'jkl','1')
insert minha_tabela1 values(1,'abc','1')
insert minha_tabela1 values(2,'def','1')
insert minha_tabela1 values(3,'ghi','1')
insert minha_tabela1 values(4,'jkl','2')

go
WITH MinhaSelecao
AS
(
SELECT *,row_number() over (partition by col1,col2,col3 order by col1,col2,col3) as [Number] FROM minha_tabela1
)
DELETE MinhaSelecao
WHERE number > 1

GO
SELECT * FROM minha_tabela1 -- veja que neste ponto os registros duplicados foram removidos sem maiores segredos.

Vejam a simplicidade do script acima para limpeza de registros duplicados.

ROW_NUMBER() retorna um número sequencial (iniciado por 1) representando o número de um determinado registro agrupado pela clausula PARTITION BY, esta clausula faz a divisão dos registros duplicados e retorna a identificação do mesmo no resultado.

Esta nao e sua única utilidade, sendo possível tambem, construir queries recursivas.
Segue abaixo a estrutura retirada da documentacao no MSDN referente as CTE e a funcao ROW_NUMBER():

WITH expression_name [ ( column_name [,...n] ) ]
AS
( CTE_query_definition )
The list of column names is optional only if distinct names for all resulting columns are supplied in the query definition.
The statement to run the CTE is:
SELECT <column_list>
FROM expression_name

ROW_NUMBER ( )     OVER ( [ <partition_by_clause> ] <order_by_clause> )

até mais ;)