O cloud computing tem sido um assunto muito debatido no mundo das tecnologias de informação não só pela capacidade de computação de alta disponibilidade, escalabilidade e elasticidade bem como pela redução de custos que o modelo baseado em serviços proporciona. 

A SQL Database da Microsoft fornece um conjunto de serviços que implementa as capacidades de armazenamento e processamento de dados relacionais na cloud. A SQL Database é um serviço de alta disponibilidade e tolerante a falhas onde os programadores não têm que se preocupar com instalação, configuração ou manutenção dos servidores de bases de dados.

SQL Database é baseado numa versão especial do Microsoft SQL Server pelo que permite ainda ao programador ser bastante produtivo dado que usa o mesmo modelo relacional baseado em T-SQL e permite usar as mesmas ferramentas de desenvolvimento e gestão usadas nas bases de dados locais.

Escalabilidade

Scale Up

Actualmente o modelo de escalabilidade mais simples de utilizar em SQL Database é a escalabilidade vertical (scale up), ou seja, aumentar o tamanho máximo de armazenamento na base de dados.

Figura 1.1 – Escalabilidade Vertical (Scale Up)

A escalabilidade em SQL Database está, em termos de capacidade de armazenamento limitada a 150Gb e poderemos chegar a uma altura em que a capacidade de armazenamento disponível não é suficiente.

Scale Out

Outra limitação natural, quem em muitos cenários se revela mais importante ainda, é a capacidade de processamento do servidor. Quantas vezes as necessidades de escalabilidade são provocadas pelo aumento da carga de processamento? Imagine um website de vendas de bilhetes onde devido ao lançamento de um evento o número de pedidos ao servidor aumenta drasticamente durante alguns dias.

Numa aplicação multicamada suportada pela plataforma Windows Azure, a gestão da capacidade de resposta a pedidos na camada de apresentação ou na camada lógica de negócio é simples, podemos por exemplo aumentar ou diminuir o número de servidores (web e worker roles) consoante a carga a que o website está a ser sujeita (scale out).

Figura 1.2 – Escalabilidade Horizontal (Scale Out)

O problema é que este modelo de escalabilidade elástica não estava presente na camada de acesso a dados (base de dados) sem que houvesse a necessidade de o implementar.

As SQL Azure Federations vêm fornecer à camada de acesso a dados essa capacidade, ou seja, será possível aumentar ou diminuir o número de nós que constitui a camada de acesso a dados sem que a mesma fique indisponível durante essas alterações. Vêm ainda permitir um aumento mais granular do espaço de armazenamento e consequente poupança de custos.

Outro “cliente” muito importante das federations serão as aplicações multi-tenant, vamos tentar perceber porquê.

Multi-tenant

Quando se desenha uma aplicação multi-tenant (multi-cliente), uma das primeiras e grandes opções que se tem que tomar tem a ver com a distribuição ou não dos dados dos clientes por várias base de dados.

De uma forma geral podemos optar por meter todos os dados dos clientes numa única base de dados ou ter uma base de dados para cada cliente. Existe ainda uma opção intermédia que é ter vários schema dentro de uma única base de dados onde cada cliente tem um schema. Não iremos considerar esta opção por se enquadrar dentro da opção de guardar todos os dados numa única base de dados relativamente à análise que pretendemos fazer.

Quando o alojamento é on-premisses (local), a opção mais comum é o fornecimento de uma base de dados para cada cliente.

Uma base de dados por cliente

Figura 2.1 – Uma base de dados por cliente (tenant)

Esta opção tem as suas vantagens e desvantagens mas o que importa reter neste caso é que, no alojamento local (on-premisses), não existe o limite mínimo em relação ao custo de uma base de dados. Actualmente o custo mínimo de uma base de dados em SQL Database é cerca de 5$.

Dependendo da aplicação esta pode ser uma opção demasiado cara e, nesse caso, a opção por juntar todos os dados dos clientes numa única base de dados pode ser a opção mais correcta.

 Tudo numa base de dados

Figura 2.2 – Todos os clientes numa única base de dados

Tanto uma opção como a outra têm problemas de escalabilidade. Ter todos os dados numa única base de dados, além do limite de 150Gb para dados pode ter problemas de capacidade de processamento. Ter uma base de dados por cliente pode ser bastante dispendioso ou, no limite, os 150Gb de armazenamento podem não chegar para um cliente que tenha muita informação para armazenar.

Sharding

Para resolver este problema era necessário recorrer à implementação manual de sharding. Sharding é um padrão que permite aumentar a escalabilidade e a performance de grandes bases de dados. Aplicar o padrão a uma base de dados significa “partir” essa base de dados em pedaços mais pequenos e distribui-los por vários servidores de modo a obter escalabilidade. A cada pedaço resultante chamamos de shard.

Neste padrão são as linhas das tabelas que são divididas pelos vários servidores. Uma outra opção seria realizar o particionamento vertical. No particionamento vertical os dados são separados por distribuição de tabelas completas entre os servidores. Meter a tabela de clientes num servidor e a tabela de vendas noutro servidor seria um exemplo de partição vertical. A partição de dados por valor (sharding) permite atingir maior escalabilidade porque, por exemplo, não está limitada ao número de tabelas existentes na aplicação e permite a divisão de tabelas com mais acessos.

Figura 2.3 – Sharding de uma base de dados

Nas aplicações multi-tenant podemos começar com uma única base de dados e, à medida que o volume de carga vai crescendo, usar o padrão de sharding para distribuir os dados dos clientes por várias bases de dados.

Figura 2.4 – Sharding numa aplicação multi-tenant

Com SQL Azure Federations vamos poder usar este padrão com “muito pouco esforço” e sem ter downtimes.

SQL Azure Federations

Distribuição dos dados

Um conceito muito importante antes de entrarmos na arquitectura das SQL Azure Federations é a distribuição dos dados. Conforme pode verificar na figura seguinte existem dados centralizados, particionados e replicados.

Figura 3.1 – Distribuição dos dados

Centralizados

Como exemplo de dados centralizados poderemos ter as tabelas de configurações. São dados sobre os quais não existem muitas operações de leitura e escrita e que estão disponíveis apenas num único local.

Replicados

Neste caso imagine a tabela de códigos postais dos CTT. São dados sobre os quais apenas existem operações de leitura (as escritas são possíveis mas raras) e que por questões de performance estão disponíveis em todas as bases de dados da aplicação. Dados replicados (reference data) são muito importantes relativamente a operações de join.

Particionados

Nesta categoria estarão a grande maioria dos dados onde cada “pedaço” de dados reside numa e apenas numa base de dados.

Arquitectura

Figura 4.1 – Arquitectura das federations

Federation Root

Refere-se à base de dados central que contêm todas as informações sobre o particionamento dos dados.

Federation

Federations são os objectos que suportam a funcionalidade de distribuição dos dados entre as várias partições. Estes objectos representam o schema da federation e contêm a chave da distribuição, o tipo de dados e o estilo da distribuição. Na imagem anterior a base de dados AppDB representa uma base de dados com federations. Uma base de dados pode ter várias federations.

Federation Member (Shard)

A cada partição de dados dentro de uma federation chamamos federation member. Na imagem acima podemos observar uma federation para a tabela Clientes com vários membros. Cada federation member contêm uma parte dos dados e é suportado por uma instância de base de dados SQL Azure que fornece lhe capacidade de armazenamento e computação.

Figura 4.2 – Arquitectura das federations member

Federation Distribution Key

Os dados são distribuídos pelos vários federation members com base na federation key. Esta chave deve ser um campo que identifica univocamente cada partição possível para os dados. Na imagem anterior podemos verificar que o campo ID é a federation key.

Atomic Unit

Uma unidade atómica representa todo o conjunto de dados com a mesma federation key. Na imagem anterior podemos observar que todos os clientes com ID=100 são uma unidade atómica. Como o próprio nome indica, não é possível dividir uma unidade atómica, ou seja, dentro de uma federation, todas as tabelas com a mesma federation key ficam garantidamente no mesmo federation member.

Exemplo

Não é objectivo deste artigo ensinar a criar e a manipular federations mas para não defraudar alguns leitores mais curiosos vamos ver alguma ver um exemplo para que possamos ficar desde já familiarizados com alguma sintaxe.

-- Criar a base de dados root 

CREATE DATABASE AppDB (EDITION='business',MAXSIZE=150GB)

-- Criar uma federation 

CREATE FEDERATION ClientesFed(ID BIGINT RANGE)

A federation foi criada com o tipo de dados BIGINT e um esquema de partição RANGE. Os tipos de dados possíveis na versão actual são INT, BIGINT, UNIQUEIDENTIFIER e VARBINARY(900).

É importante notar que sempre que criamos uma federation estamos a instanciar uma nova base de dados para alojar essa federation, que no início terá todos os federation members.

-- Ligação à ClientesFed  

USE FEDERATION ClientesFed (ID=0) WITH RESET, FILTERING=OFF

Repare que a sintaxe utiliza a palavra reservada USE seguida de FEDERATION na sintaxe de ligação a uma federation. Temos que indicar qual a unidade atómica que nos queremos conectar, o que neste caso é indiferente porque acabámos de criar a federation e portanto todos ID são válidos.

A opção FILTERING indica se queremos ligar apenas à unidade atómica indicada (ON) ou se queremos ligar-nos a todas (OFF). Neste caso, como estamos a realizar operações ao nível da federation teremos que estar ligados sem filtro. 

CREATE TABLE Cliente(

ClienteID bigint,

Nome nvarchar[100],

primary key (ClienteID)

FEDERATED ON (ID = ClienteID)

A sintaxe de criação de uma tabela neste caso não tem nada de novo à excepção da última linha que permite anotar a tabela como fazendo parte da federation e indicar qual a coluna que serve de federation key é a coluna ClienteID. Repare que o tipo de dados dessa coluna tem que ser igual ao tipo de dados definido para a federation key. 

CREATE TABLE Distrito(DistritoID tinyint primary key, Nome nvarchar(128))

Se não for indicado o FEDERATED ON estamos a criar uma tabela com dados de referência que irá ser replicada por todos os federation members.

USE FEDERATION ClientesFed (ID = 110) WITH RESET, FILTERING=ON

 Temos agora um exemplo de uma ligação a uma unidade atómica. Neste exemplo estamos a criar uma ligação à unidade atómica com ID=110 dado que a opção FILTERING está ON.

SPLIT

Neste momento a única operação suportada é a operação de Split (divisão) com um parâmetro.

No futuro termos mais operações disponíveis tais como:

Vamos então ver como é feita a divisão de um federation member de modo a que o sistema não fique indisponível e a operação seja completamente transparente para o utilizador.

A operação de split é executada em duas fases. A primeira fase tem como objectivo preparar a transição e a segunda fase será a realização da transição.

Fase 1

Nesta primeira fase instanciadas duas novas base de dados para alojar, uma para cada parte dos dados. Essas bases de dados terão o estado SPLITTING na tabela sys.databases.

São criadas as entradas nas tabelas de metadata que irão suportar o progresso da operação (sys.dm_federation_operation*) e preparadas as operações de cópia dos dados.

Figura 5.1 – Primeira fase do SPLIT

Enquanto esta fase corre a aplicação continua a funcionar sobre a base de dados original e além das operações de CRUD podem ainda ser realizar alterações ao schema.

Fase 2

É nesta fase que ocorre a transacção do schema e dos dados para as novas base de dados.

O Schema e todas as tabelas com dados replicados (tabela de códigos postais dos CTT por exemplo) são copiados para ambas as bases de dados novas. Os dados a particionar serão filtrados e copiados para a respectiva base de dados. Além das bases de dados novas os dados serão também copiados para as respectivas cópias secundárias.

Após todos os dados terem sido copiados dá-se a troca. A base de dados original passa para o estado offline quebrando assim todas as ligações existentes e imediatamente após isso as novas bases de dados passam para o estado online e começam a aceitar os novos pedidos de ligação.

Figura 5.2 – Segunda fase do SPLIT

Repare que o downtime que existe é muito pequeno porque trata-se apenas de alterações na metadata e é mascarado pela retry logic que devemos ter nas aplicações que usam SQL Azure e portanto o erro não chega a ser visível aos utilizadores da aplicação.

Conclusão

A plataforma Windows Azure já permitia a construção de camadas de apresentação e camadas de lógica de negócio altamente escaláveis mas estava ligeiramente atrás no que respeita a camadas de acesso a dados sobre bases de dados. As camadas de acesso a dados sobre storage já são altamente escaláveis mas agora as SQL Azure Federations vêm trazer ao SQL Azure a mesma possibilidade sem que tenha que existir uma implementação “manual” do padrão de sharding.

Poderá consultar a continuação deste artigo em SQL Azure Federations na prática.

Publicações

Referências

Building Scale-Out Database Solutions on SQL Azure - Lev Novik (http://channel9.msdn.com/Events/PDC/PDC10/CS02)

Building Scalable Database Solutions Using Microsoft SQL Azure Database Federations - Cihan Biyikoglu (http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DBI403)

Your Data in the Cloud - Cihan Biyikoglu (http://blogs.msdn.com/b/cbiyikoglu/)