5. SQL Azure Database Overview
Account
Cada conta tem 0 ou mais servidores lógicos
Criada através do portal
Cada servidor lógico tem uma ou mais bases de
dados
Contém informações aceca das base de dados e consumos
Server Unidade de autenticação, geo-localização, billing, e
reporting
Nome gerado automáticamente
Uma base de dados tem objectos SQL
Database Utilizadores, Tabelas, Views, Indices, etc
Unidade de consistência
6. SQL Azure Database Overview
Web Edition Business Edition
1Gb 5Gb 10Gb 20,30,40,50,100 150Gb
7. SQL Azure Database Overview
Três
Uma Base de Dados
Base de Dados Físicas
Lógica
Primary
Secondary 1
DB
Secondary 2
11. SQL Azure Architecture
Platform Layer
Node 14
SQL Server Instance
SQL Server DB
User User User User
DB1 DB2 DB3 DB4
SQL Azure Fabric
Node 15
SQL Server Instance
SQL Server DB
User User User User
DB1 DB2 DB3 DB4
SQL Azure Fabric
12. Multi-tenant
Uma base de dados por tenant
Custo mínimo por tenant 9.99$
Tudo numa base de dados
Limite de capacidade de processamento
Limitado a 150Gb
15. Distribuição dos dados
Centralizados
Disponíveis num único local Centralizados Particionados
Poucas leituras e escritas
Particionados Configs Dados1 Dados2 Dados3
Cada “pedaço” reside apenas CP CP CP
numa base de dados
Replicados
Replicados
Leituras
Escritas são raras
16. Arquitectura
Federation Root
contêm todas as
Federation Root
informações sobre o
particionamento dos Federations
dados Federation Members
AppDB
Federations
objectos que suportam a
funcionalidade de ClientesFed
distribuição dos dados
entre as várias partições
17. Arquitectura
Federation Member
Instância de SQL Azure
Federation Key Federation Key Member : Range [100,300]
campo que identifica univocamente ID=110 ID=210
cada partição Unidades ID=120 ID=220
Atómicas
Unidades Atómicas ID=130 ID=230
conjunto de dados com a mesma
federation key
ficam garantidamente no mesmo
federation member
19. Regras
CREATE FEDERATION nome_federacao (nome_distribuicao <tipo> RANGE)
Nome da federação têm que ser único dentro de uma base de
dados
Tipo de dados terá que ser INT, BIGINT, UNIQUEIDENTIFIER ou
VARBINARY(n) onde o n poderá ir até 900
20. Regras
Dados Centralizados
Criados na root database
Dados Particionados (federados)
Criados no federation member
Com o atributo FEDERATED ON ()
Dados Replicados
Criados no federation member
Sem o atributo FEDERATED ON ()
21. Regras
CREATE TABLE Produto(…) FEDERATED ON (ID=ProdutoID)
O tipo de dados desta coluna tem que ser obrigatoriamente igual ao
tipo de dados da chave da federação.
Não pode ter valor nulo.
Não pode ser actualizada para valores fora do range do membro
actual.
Não pode ser uma computed column.
Tem que fazer parte de todas as unique e clustered indexes.
Tem que fazer parte de todas as chaves estrangeiras para outras
federated tables.
22. Regras
Schema
Todas as chaves estrangeiras entre federated tables têm que
conter a chave da federação
Não podem existir reference tables com chaves estrangeiras para
uma federated table
Uma federated table pode ter chaves estrangeiras para reference
tables sem restrições
Só poderão ser realizadas alteração ao esquema de um membro
através de ligações sem filtro (FILTERING=OFF)
23. Regras
Os membros da federação não suportam:
Index Views
Colunas Identity
Tipo de dados timestamp e rowversion
25. SPLIT – 1ª Fase
Member : Range [100,300)
São instanciadas duas novas bases de ID=110 ID=210
dados ID=120 ID=220
ID=130 ID=230
São criadas as entradas nas tabelas de
metadata que irão suportar o
progresso da operação Member : Member :
Range [100,200) Range [200,300)
(sys.dm_federation_operation*) e
preparadas as operações de cópia dos
dados
26. SPLIT – 2ª Fase Member : Range [100,300)
ID=110 ID=210
Criação do Schema ID=120
ID=130
ID=220
ID=230
Cópia integral dos dados replicados
Cópia filtrada dos dados particionados
Operações acontecem sobre as novas
bases de dados e respectivas réplicas Member :
Range [100,200)
Member :
Range [200,300)
Original passa a offline e novas a online ID=110
ID=120
ID=210
ID=220
Alteração transparente para o utilizador ID=130 ID=230
alteração na metadata
retry logic
28. Use Federation
USE FEDERATION ROOT WITH RESET
USE FEDERATION federation_name (distribution_name =
value) WITH FILTERING={ON|OFF}, RESET [;]
RESET é obrigatório
FILTERING
OFF – Acede a todos os dados do federation member
ON – Acede apenas a dados da unidade atómica definida
29. Root Database a Bottleneck ?
Client Layer
Infrastructure Layer
33. LINQ
using (DataClasses1DataContext db = new DataClasses1DataContext())
{
db.Connection.Open();
db.ExecuteCommand("USE FEDERATION ProdutosFed(ID = 110)
WITH RESET, FILTERING=OFF");
(…)
}
34. Entity Framework
using (DemoEntities db = new DemoEntities())
{
db.Connection.Open();
db.ExecuteStoreCommand(“USE FEDERATION ProdutosFed(ID = 110)
WITH RESET, FILTERING=OFF”);
(…)
}
35. Entity Framework – Code First
using (DemoEntities db = new DemoEntities())
{
((IObjectContextAdapter)db).ObjectContext.Connection.Open();
db.ExecuteStoreCommand(“USE FEDERATION ProdutosFed (ID = 110)
WITH RESET, FILTERING=OFF”);
(…)
}
36. Transacções
using (DemoEntities db = new DemoEntities())
{
db.Connection.Open();
db.ExecuteStoreCommand(“USE FEDERATION ProdutosFed(ID = 110) WITH
RESET, FILTERING=OFF”);
using (TransactionScope scope = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
(...)
}
}
37. Multiple Active Result Sets (MARS)
Ainda não existe suporte para MARS em SQL Azure Federations
Não pudemos usar Lazy Loading, LoadProperty() e Load()
Temos que fazer Eager Loading
Inicializar os objectos no momento da criação
38. Multiple Active Result Sets (MARS)
LINQ
DataLoadOptions dataLoadOptions = new DataLoadOptions();
dataLoadOptions.LoadWith<Produto>(c => c.Categoria);
db.LoadOptions = dataLoadOptions;
Entity Framework
O eager loading é realizado através do método Include:
var produtos = from p in db.Produto.Include("Categoria1") select p;
Slide ObjectiveUse this slide to transition into an explanation of SQL Azure Database (Reporting and Data Sync will be covered later)Explain at a high level how SQL Azure worksSpeaker NotesDesign Principle of SQL Azure: Focus on combining the best features of SQL Server running at scale with low frictionSQL Azure is a high availability databaseAlways three transaction consistent replicas of the databaseOne primary replica; two slave replicasFailure of a replica will result in another replica being spun up immediately by the fabricFailure of the primary replica means a slave replica will become the primary and a new slave will spin upMinimal down timeTypically just a few dropped connectionsEasy to code for the failover scenario- if you are ding god connection management and error handling will be fineClustered index required on all tables to allow replicationNotesUseful article from SQL Azure teamhttp://msdn.microsoft.com/en-us/magazine/ee321567.aspx
What about this? Draw answer on slide, highlight all storage points & internal endpointsALSO talk about other tricks such as putting static content into blob storage.Note we don’t talk about CDN here – we’ll cover that in thinking globally