Comparativo entre o SQL Server e o SQL Azure Database

Presenciando uma porção de dúvidas em meu e-mail, MSN, skype e twitter sobre o SQL Azure Database, me dei conta que não havia uma publicação acessível à todos que fizesse um comparativo entre os bancos de dados SQL Server (que localmente pode ser chamado de on-premise) e SQL Azure Database (ou só suas iniciais, SAD).

por Diego Nogare

Presenciando uma porção de dúvidas em meu e-mail, MSN, skype e twitter sobre o SQL Azure Database, me dei conta que não havia uma publicação acessível à todos que fizesse um comparativo entre os bancos de dados SQL Server (que localmente pode ser chamado de on-premise)  e SQL Azure Database (ou só suas iniciais, SAD). A algum tempo venho respondendo perguntas sobre diferenças entre eles, então decidi montar esse texto para ajudar a tirar essas duvidas mais comuns.

Os dois “produtos” são bem parecidos na questão da funcionalidade. Analisando com uma visão macro, os dois tem a função de armazenar dados pra aplicações consumirem. Esse é o objetivo de ambos! É claro que existem mais coisas envolvidas, mas a grosso modo, pode-se resumir a isso.

O SQL Azure Database é similar a uma instância do SQL Server local, expondo uma interface baseada em T-SQL para se trabalhar com o database, permitindo que se utilize o SAD para quase todas as coisas que é possível fazer no SQL Server. É claro, que o SAD é fornecido como um serviço então algumas pequenas diferenças com relação ao SQL Server on-premise existirá, principalmente com relação à hardware.

Algumas diferenças para os DBAs que trabalharão com o SAD, é que não precisarão mais se preocupar com questões de hardware como Servidores, aplicação de Services Pack ou Hotfix, memória, espaço em disco. Tudo isso agora é responsabilidade da Microsoft e eles fornecerão pra você. Você como DBA ainda terá seu trabalho de administrar Databases, Logins, Users, roles e todas as outras milhões de coisas que ocupam nosso tempo e fritam nosso cérebro.

Administração Lógica e Administração Física: Apesar do SAD ter um papel de gerenciador do banco de dados, nós DBAs temos uma função muito importante na administração das aplicações baseadas na plataforma Azure. Nós temos que nos preocupar com criação de schemas, gerenciar as estatísticas, tunar índices, fazer otimização de querys (pra isso chamamos o Fabiano Neves Amorim). A administração física do SAD difere bastante do SQL Server que trabalhamos até hoje, com o SAD já temos replicação automática de todos os dados provendo Alta Disponibilidade (praticamente 24X7), também tem Load Balance automático e caso um servidor seu fique off-line, entra em ação Fail-Over transparente para seu usuário. Isso tudo, sem você controlar nada, tudo automático no SAD.

Uma restrição no SAD é que você não poderá especificar em qual disco ou file group um database ou índice fica armazenado, isso porque não temos acesso aos arquivos dos servidores que estão na nuvem, só acessamos os recursos que estão disponíveis pra gente através dos serviços da Plataforma Azure.

Hah, um detalhe. Replicação, Backup e Restore não são permitidos no SQL Azure Database. É automático!

Código T-SQL suportado na plataforma Azure. É claro, algumas coisas podem mudar, mas estes códigos eu já testei.

T-SQL suportados:

Constantes / Constraints / Cursores / Índices (gerenciamento e rebuild) / Tabelas temporárias locais (com 1 #) / Stored Procedures / Gerenciamento de Estatísticas / Transações (Begin e End) / Triggers / joins de tabelas e de variáveis do tipo table / Create ou Drop Database / Create, Alter ou Drop Table / Create, Alter ou Drop usuários e logins / Views.

Algumas coisas que testei, mas não tive sucesso, logo entendo como não suportado:

CLR / Database Mirroring / Gerenciamento de Filegroup / Tabela temporária global (com 2 ##) / Service Broker

Sobre as Features permitidas e mais um pouquinho do código T-SQL não suportado: Falando das Features, vale lembrar que a plataforma Azure é gerenciada através de serviços, logo não temos acesso direto “ao servidor”, somente ao que é liberado através dos serviços. Ótimo, todo mundo lembrou disso. Então já que lembramos desse detalhe, agora vamos lembrar de outro, o SQL Azure Database não suporta todas as Features e Datatypes que o SQL Server local suporta, por exemplo o Analysis Services, Replication, Reporting Services e Service Broker não são suportados pelo SAD ainda, mas pode ser que estas Features sejam implantadas. Como a própria plataforma Azure cuida da parte física (hardware), algumas configurações que manipulam diretamente a questão de hardware do servidor estão bloqueadas, por exemplo o Resource Governor ou algumas configurações de DDL (Data Definition Language). Hah, também não é permitido utilizar o SQL Profiler ou o DB Tuning Advisor.

Outros códigos T-SQL não suportados são aqueles que fazem referência à algum filegroup ou caminho físico. Dependendo do código, ele pode até ser considerado “parcialmente” suportado. Bizzaro! rss

Modelo de dados relacional: O SQL Azure será bem familiar à todos os DBAs e DEVs (de banco) no quesito de armazenamento, porque é bem parecido com o SQL Server on-premise, usando T-SQL. Por conceito, o SQL Azure é como uma instância do SQL Server, só que com algumas restrições (vocês se lembram, né?!).

Em cada servidor de SQL Azure, você pode criar diversos bancos de dados, e em cada banco pode criar várias tabelas, views, stored procedures, índices, e vários outros objetos. Este modelo de dados faz um bom uso do design e codificação dos bancos que já temos on-premises e simplifica o processo de migração para a nuvem por serem bem similares e suportarem quase tudo um do outro.

Só lembrando que o SQL Azure Database são servidores virtuais e não correspondem exatamente como um SQL Server local (que é físico)! Então não tentem ter o mesmo desempenho, é muito pouco provável que consiga chegar próximo!

Alta Disponibilidade e Escalabilidade: Quando se pensa em Alta Disponibilidade, estamos pensando em 24X7 (24horas, 7 dias por semana). A Plataforma Azure é baseada em SQL e Windows Server, e é flexível o bastante para variar com relação à carga ou uso. O serviço replica os dados em diversos servidores diferentes para manter os dados redundantes e disponíveis para seu negócio, haja o que houver. No caso de um dos servidores cair, o Azure automaticamente faz o loadbalance e aponta para outro server.

Já com relação à escalabilidade, esse é um ponto bem positivo pra Plataforma Azure no ponto de vista da facilidade de se escalar (aumentar o desempenho) sua própria solução. No SQL Server, depois de particionar seus dados, a escalabilidade é automática e o banco vai crescendo de acordo com sua necessidade. Pela forma de licenciamento, você só pagará pelo que armazenar “economizando dinheiro”, e caso precise fazer um downgrade (diminuir o desempenho) de seu ambiente, é possível fazer quando achar necessário.