SQL and Architecture Experience

Competindo com a Oracle

marped — Tue, 24 Mar 2009 22:19:04 GMT

Blogar ou não Blogar, eis a questão. Parece brincadeira, mas o não sempre vence visto que ele é padrão. Acontece que as histórias vão se avolumando e sempre as pessoas me cobram: “e aí, você não vai escrever sobre isto ?”. Fico lisonjeado, mas ao mesmo tempo começa minha briga com a preguiça de escrever J ... Para quem não me conhece, comecei a trabalhar com o SQLServer ainda em 1991 quando a versão era o MS Sybase SqlServer 1.1 rodando sobre OS2 1.2 e Lan Manager. De lá para cá passei por todas as versões do produto: 4.2; 4.21; 4.21a; 6.0; 6.5; 7.0; 2000; 2005 e agora 2008.

Em 1991, fizemos o sistema de contabilidade do antigo Banco Garantia. Lembrando daquele tempo posso dizer que foi insanidade (ou visão de longo termo, o que eu prefiro) fazê-lo. Nos anos seguintes, pude participar com minha própria empresa de sistema integrado de apoio a negócios para tesourarias bancárias. Mais de 500 tabelas, 1000 Stored Procedures e 3000 telas em VB (que alias também comecei programar em 1991 na versão beta). Lembrando dele, posso novamente dizer que foi insanidade, ou novamente visão de longo prazo.

Em 1999 cheguei finalmente à Microsoft após o terceiro namoro onde estou até hoje. De lá para cá migrei vários bancos de dados e pude participar do SPB nos bancos Itaú e HSBC. Lembrando aquela época, o SQLServer não foi em nenhum momento fonte de dor de cabeça, os problemas ocorreram com a maturidade da época do Biztalk. Esta foi a primeira versão do SQL, a 2000, em que todos os clientes consideravam confiável, mas ainda éramos vistos como uma empresa para bancos de dados departamentais. O SPB ajudou a quebrar este paradigma, mas ainda não podíamos ir além de algumas centenas de GBs.

Desde 2005, o que tenho vivenciado é uma mudança neste último paradigma. Começamos a romper a barreira dos TBs e passamos a poder participar de aplicações de Missão Crítica. Neste momento ficamos maduros para competir com a Oracle em quase igualdade de forças. Quase porque a diferença agora é que eles tempo e tradição de um produto confiável, coisa que passamos a ter apenas na versão 2000 para cá. No entanto, quando começamos a usar as novidades do SQL que vieram na versão 2005 como o CLR (Common Language Runtime) integrado, passamos é ter vantagem sobre a Oracle.

Nos últimos anos pudemos tirar duas grandes aplicações de missão crítica no banco Itaú da concorrência: o sistema de risco de mercado da tesouraria, em fase final de carga de dados, hoje em Oracle e que deverá usar mais de 100 CPU cores e chegar a dezenas de TBs e a provisão de devedores duvidosos do DB2 que tem 8 máquinas de 32 cores apenas para simulações simultâneas e um total de uma dezena de TBs.

Os casos por si só já seriam surpreendentes, mas o que mais chama a atenção é o uso das tais novidades das versões 2005 e 2008 do SQL que fizeram a diferença: CLR integrado sem Marshalling , particionamento de tabelas, Service Broker para dar assincronismo, publicação de Stored Procedures como WebServices, ferramenta de ETL eficiente, dimensões geradas dinamicamente por expressões MDX invocando CLR SPs, backup comprimido, mínimo logging e colunas XML, entre outros.

Vejam um exemplo do potencial da plataforma. Defino as mensagens de comunicação como XML. Pego os esquemas XSD e jogo no SDK (Software Developer Toolkit) do CLR usando a ferramenta XSD.exe para gerar todas as classes serializáveis em C# ou VB. Pego este código e coloco dentro do SQL como CLR SPs. O que tenho? Ou melhor, o que não tenho? Deixo de ter uso de XPath e DOM e ganho muita performance no tratamento de XML. Usando o padrão Factory, posso acelerar e muito o desenvolvimento com poucos erros de codificação. Coloco as rotinas para serem assincronamente chamadas e controladas pelo Service Broker e modelo fisicamente minhas tabelas para ter o mesmo comportamento ao longo do tempo (Sliding Window Partitioning). Carrego o resultado em cubos multidimensionais e deixo o usuário pedir o VAR (Value At Risk) de qualquer combinação de dados da carteira.

O resultado de tudo isto está na figura abaixo:

Sei de algumas pessoas que tentaram fazer seus bancos de dados conseguirem eficientemente processar grandes volumes de dados intensivamente sem muito sucesso. A foto anterior mostra que o SQLServer da Microsoft consegue.

Telas genéricas de consultas X Stored Procedures genéricas

marped — Fri, 04 Jan 2008 02:26:00 GMT

Como meu primeiro post técnico, resolvi escrever para um problema que me persegue desde a versão 1.1 . Normalmente as pessoas que fazer as interfaces de usuário não tem a mínima noção de como o otimizador do SQLServer trabalha para escolher um índice. Isto pode ser um problema potencial. Quando o desenvolvedor da Stored Procedure resolve “brilhantemente” escrever um código genérico, a m... está feita. Temos então um SP onde todas as colunas da cláusula where podem ser informadas ou não. No DB Nortwind execute a query abaixo:

declare @o int

set @o = 10521

select * from [order details] od

inner join orders o

on o.orderid = od.orderid

and o.orderid = CASE WHEN @o is null THEN o.orderid ELSE @o END

Com uma construção desta forma, o otimizador irá realizar sempre um Scan, seja da ou do índice que nesta coluna possa existir.

O plano de execução deverá mostrar um Clustered Index Scan

Assim, quando uma construção desta natureza for percebida, o ideal é que para todas as colunas indexadas e seletivas sejam codificadas consultas específicas, conforme exemplo a seguir:

select * from [order details] od

inner join orders o

on o.orderid = od.orderid

and o.orderid = @o

O plano de execução agora realizará um clustered índex seek

Em termos de custos, a primeira consulta consumiu 87.5% do tempo de execução e a segunda apenas 12.%, ou seja, sete vezes mais rápida, pois fez uso correto da indexação.

Uma variação do exemplo acima pode ser:

and (o.orderid = @o OR o.orderid is null)

Não testei, mas certamente o resultado será o mesmo.

Meu Blog

marped — Fri, 04 Jan 2008 02:00:00 GMT

Há algum tempo venho pensando em escrever algumas experiências e alguns truques de SQL e Arquitetura que aprendi com o tempo. Comecei a trabalhar com o SQLServer em 1991 na sua versão 1.1 para OS2. Já faz bastante tempo. Passei por todas as versões do SQL e me vejo agora começando a estudar a versão 2008 ...

Sempre pensei que as coisas que fiz fossem coisas "normais". Ora, já que eu estava naquela situação, tinha que resolver o problema da melhor forma. Assim como qualquer outro faria. Mas vejam que são mais de 16 anos e ainda continuo resolvendo problemas. Isto me fez pensar. Acredito que nem todas as pessoas tem a oportunidade de poder trabalhar com um produto tanto tempo e em tanta diversidade de situações. Enquanto vou ficando mais velho. tenho um verdadeiro banco de dados para passar a frente. É isto que pretendo fazer.

Espero contar com a compreensão e ajuda de vocês.

Obrigado por sua atenção.

P.S. Ouvi ontem na rádio Bandeirantes uma pesquisa sobre quem foi o melhor técnico do campeonato brasileiro. Poxa, fiquei indignado em não conseguir ligar para dar minha opinião, que alias seria única. Meu escolhido: Nelsinho Batista. Como bom palmeirense, não vi nenhum outro que me fez mais feliz.