Padrões para Cloud Computing no Azure – Particionamento com o SQL Azure (Sharding)
O interessante da computação em sistemas elásticos, como o Azure, é que eles tornam factíveis padrões computacionais que costumam ser caros para as empresas.
É claro que podemos utilizar o Azure para migrar sistemas convencionais de nossas empresas (como sistemas departamentais ou algum outro sistema LOB), tentando minimizar o custo total da nossa TI. Mas tudo fica mais divertido – e potencialmente lucrativo - quando pensamos nas oportunidades para modelos computacionais que lidam com uma massa grande de dados ou de computação. E, para compreender isto, vale descrever alguns padrões recorrentes nestes tipos de problemas.
Imagine milhões de usuários visitando o seu site. Que padrões você pode utilizar para viabilizar tamanho número de acessos?
Imagine um cálculo que pode levar milhões de MIPS. Tenho padrões similares?
A resposta a estas perguntas costuma ser um grupo de padrões recorrentes. São eles:
1) Replicação: que se caracteriza pelo uso de uma estrutura repetitiva de computação e/ou armazenamento – o que proporciona a elasticidade pelo simples aumento ou diminuição desta “célula de computação”.
Neste caso temos dois sub-padrões comuns:
a. Sites convencionais compostos de WebFarms + storage: onde repetimos o mesmo código para cada servidor Web (web role, em bom azurês) e colocamos os mesmos dados de leitura copiados (em memória cachê ou cópia em storages (Azure Tables, em bom azurês));
b. Sites SaaS: onde repetimos a estrutura de cada célula (servidores+storage) onde, porém, tanto a estrutura de storage quanto a de código podem ser ligeiramente diferentes para cada usuário/inquilino, devido a customizações e/ou dados exclusivos;
2) Particionamento: que se caracteriza pela subdivisão da computação ou armazenamento com fins de distribuir as demandas para subsistemas diferentes, aliviando subsistemas e evitando potenciais gargalos.
Os sub-padrões seriam:
a. Grid: sites que trabalham com algoritmos de alto paralelismo, com a distribuição de subconjuntos (normalmente distintos) de dados para cada servidor, como acontece no MapReduce (ver post) ou processamentos em pipeline ;
b. Sites que possam ser particionados em subsistemas distintos, como Vendas, Cobrança e Logística numa loja virtual, onde cada subsistema tem código e dados distintos, referentes à cada passo do processo de compra e entrega de um pedido, e cada sub-sistema se comunica com o outro por redirecionamento, compartilhamento de dados e/ou envio de mensagens (filas, em azurês);
c. Sharding: O particionamento de dados em storages diferentes, visando distribuir estatisticamente o acesso aos dados e, assim, diminuir o tempo de espera médio para uma escrita ou leitura. Tables do Azure, por exemplo, têm este comportamento por natureza/construção;
3) Misto: o mais comum, onde padrões de replicação e particionamento são utilizados em conjunto formando arquiteturas complexas.
O SQL Azure, em particular, nasce um pouco limitado devido à sua condição ACID (ver post). Porém isto não impede de você utilizar algumas destas estratégias visando arquiteturas para milhões de usuários. As estratégias possíveis são:
a) SaaS: um banco de dados para cada inquilino ou pequeno grupo de inquilino (ver 1.b acima);
b) Subsistemas distintos: um banco de dados para cada subsistema (ver 2.b acima);
c) Particionamento: um banco de dados para cada subconjunto de dados (ver 2.c acima);
Como o SQL Azure, ao contrário do MS SQL não tem infra-estrutura interna para particionamento, caberá a você construir uma :(
A boa nova é que o Windows Azure Platform Training Kit de outubro traz um lab com um código exemplo que implementa o particionamento com o SQL Azure usando o sharding .
Aos estudiosos, vale a pena baixar o Kit e ir direto para a Demo “Scaling Out SQL Azure with Database Sharding” e dar uma olhada.
Abraços