O Azure oferece basicamente 2 tipos de repositórios: o ATS (Azure Table Service) e o SQL Azure. O ATS é um conjunto de tabelas de estrutura “frouxa”, o que significa que, na mesma tabela, você pode gravar linhas com estrutura de colunas distintas. A restrição téorica de tamanho no ATS é de 100 TB; o ATS é bem mais barato que o SQL Azure em termos de custo de espaço de armazenamento usado, e ainda tem um esquema de particionamento dos dados voltado para aumento da performance de acesso – os dados de uma mesma tabela podem ser divididos em partições, e estas partições podem estar em máquinas diferentes, efetivamente paralelizando o acesso aos dados – e isto tudo é feito automagicamente, quando o Azure “nota” que uma partição está sendo muito acessada e/ou ficou muito grande.
Isto tudo torna o ATS uma opção atrativa para quem está modelando a camada de dados de uma aplicação no Azure, MAS… É, sempre tem o tal do “MAS”. Leia a seguir alguns “MAS” que encontramos no nosso trabalho com o ATS.
1. O ATS é bem mais barato, que o SQL Azure, mas é mais doído de usar.
O custo atual de 1GB de dados no Azure Table Service é de US$ 0,15/mês. Um BD de 1GB no SQL Azure custa US$ 9,99/mês. Mas o ATS tem um monte de restrições que tornam a produtividade baixa e o código complicado. Por exemplo:
- Linq to ATS não tem JOIN, GROUP BY, subqueries e um monte de outras coisas às quais já estamos acostumados. Olha a “listinha” dos operadores não suportados aqui. Você ou vai ter que trazer os dados do ATS pra dentro da sua aplicação e usar Linq To Objects, com o prejuízo óbvio de trafegar um monte de dados que não serão necessários, ou inventar algum meio maluco de fazer isso de dentro do ATS, usando p.e. duplicação de dados.
- O ATS não suporta transações.
- Tem um modo restrito chamado de Entity Group Transactions (EGT), mas as restrições são severas a ponto de torná-lo inaplicável, dependendo da sua aplicação. P.e., este modo é restrito a transações envolvendo no máximo 100 entidades (100 “registros”), o que pode torná-lo inútil em uma aplicação de importação de arquivos, aonde podemos inserir um monte registros de uma vez em uma transação.
2. Se você escolheu o ATS, gaste espaço em disco sem pena, se isso for facilitar sua programação.
Sendo o custo atual de 1GB de dados no ATS de US$ 0,15/mês, é ridículo não criar desnormalizações. Se você *duplicar* seus dados, seu custo passará de 15 para 30 cents/mês por GB. Em 10GB de dados, você irá pagar a mais 3 dólares/mês. Por exemplo:
- Como Linq to ATS não tem suporte a JOIN’s, se você tem um relacionamento 1-N que é muito acessado, grave os dados como uma única entidade, repetindo, para cada entidade do lado N, os valores da entidade do lado 1. Exemplo: você tem uma tabela de Vendas e de DetalheDasVendas; em Vendas tem os dados de cada venda, e em DetalhesDasVendas tem a lista de itens vendidos em cada venda. Considere criar uma única tabela VendasDetalhes, com as colunas das duas tabelas reunidas nela:
Dá dor na alma ver uma modelagem desta, e realmente ela exige um pouco mais na hora de codificar o inclui-altera-exclui. Mas a flexibilidade de pesquisa que ela dá é muito maior do que a modelagem normalizada. Por exemplo:
- O JOIN é ridiculamente fácil de implementar, porque, na verdade, ele já está implementado.
- O tráfego de dados é minizado (minha preocupação é com desempenho e não com gasto, pois tráfego de dados no ATS também é na casa de cents/GB/mês).
Como exercício, tente pensar no algorítmo sem usar JOINs para ler das 2 tabelas as vendas de 2010 que incluíram “BANANA” como item. Ok, dá até pra implementar. Agora lembre que você tem cem mil registros de vendas em 2010, cada um com uma média de 5 itens, e faça um chute alto de quantas idas-e-vindas a aplicação teve que fazer no ATS para recuperar os dados. Em seguida, faça essa conta para a tabela “aglutinada” e veja a diferença. A aplicação fica mais leve nas consultas, e você perde menos tempo desenvolvendo algoritmos de JOIN que deveriam ser feitos pelo repositório de dados, e não por seu código…
E há outras aventuras mais de uso do ATS. Não é que o ATS seja ruim; ele, como toda ferramenta deve ser, é bom para a finalidade para a qual foi projetado: listas massivas de dados que exigem performance no acesso. Ele não foi construído para ser um BD relacional. Talvez a Microsoft inclua funcionalidade para tal em versões futuras; mas meu conselho é, se possível, usar o SQL Azure para suas aplicações transacionais, e deixar o ATS para aquela coleção de dados que você sabe que será gigantesca. “SQL Azure se possível” significa que o limite de tamanho máximo do SQL Azure tem que ser respeitados. As opções atuais são de bancos de no máximo 1, 10 ou 50GB. Mas lembre que as aplicações podem usar os dois mecanismos, então nada impede de uma aplicação de digitalização de documentos guardar seus dados “normais” em uma instância do SQL Azure, e os documentos digitalizados no Azure Blob Service. Vai ser seu trabalho, como arquiteto da aplicação, decidir a “dose certa” a usar de cada um dos mecanismo de armazenamento de dados que o Azure oferece.
Microsoft SQL Azure Home Page: http://www.microsoft.com/en-us/sqlazure
Portal de informações, vídeos, artigos e outros sobre o SQL Azure.
MSDN: Using the Windows Azure Storage Services: http://msdn.microsoft.com/en-us/library/ee924681.aspx
Links para artigos com descrição dos 4 mecanismos de armazenamento nativos do Windows Azure: Table Services (tabelas), Blob Services (dados binários), Queue Services (filas) e os Windows Azure Drives.
