SQL Server Data Services – O fim do DBAssauro que conhecemos?


(Artigo em PDF para download)


 


Estou aproveitando um problema no joelho e a chegada do fim do nosso ano fiscal para parar um pouco, estudar e repensar algumas coisas... Como recebo diversos e-mails, estava conversando com o Deyvid William e tocamos no assunto do futuro do DBA. Achei interessante ele ter mencionado sobre o SQL Server Data Services (SSDS) e questionado sobre o impacto que isso terá na vida de um DBA (prova de que existem pessoas ligadas no futuro), então resolvi elucubrar um pouco sobre o assunto e escrever algumas palavras.


 


Antes de continuarmos, para quem não sabe o que é o SQL Server Data Services, acesse:


http://www.microsoft.com/sql/dataservices/default.mspx (aconselho ler o FAQ também)


 


Uau... Colocar nosso banco de dados lá com a Microsoft e acessá-lo através de serviços. Chique no último! Agora vou pagar a Microsoft por mês, de acordo com os recursos de máquina, disco e rede que minha aplicação utiliza, além de ter um SLA para garantir a disponibilidade dos dados. PS: A maneira como será cobrado e os preços ainda não foram definidos, estou fazendo uma suposição.


Mas espera um minuto, esse anúncio faz a cabeça do pessoal ir a mil (segundo o Deyvid, “vai dar uma sacudida no mercado, não é...”) e começam a surgir as perguntas. Como é que o SSDS funciona? Vou mandar meu esquema para a Microsoft e eles cuidam do meu banco? O que isso impacta na minha vida? Será que alguém vai realmente usar isso? Quem? Quais as vantagens e desvantagens? Desafios?


O que vou escrever agora é puramente minha visão sobre o SSDS, que ainda está amadurecendo, então que tal debatermos sobre o assunto?


 


Entendendo o SSDS


 


Em primeiro lugar, existe um erro conceitual quando eu falo “colocar nosso banco de dados lá com a Microsoft”. Fiz questão de colocar dessa forma porque é assim que muitas pessoas recebem a notícia, mas não é assim que o SSDS funciona, então a Microsoft não vai colocar o seu tradicional banco de dados com ela. Isso é diferente de um serviço de hosting fornecido por empresas especializadas.


A idéia é que você trabalhe com entidades, que ficarão organizadas em containeres específicos, agrupados por autoridade (modelo ACE). Então quando você assina o serviço, deve criar uma autoridade (representada por um nome DNS), como luti.data.beta.mssds.com. Com a autoridade criada, você passa a definir containeres, como Livros, Vendas2008 ou Vendas2007. Os containeres por sua vez são repositórios de entidades, que possuem propriedades fixas (metadata – definidas pelo SSDS: ID, versão e tipo) e propriedades flexíveis (flex – definidas pelo usuário: nome, autor, data publicação, ISBN, ImagemCapa, etc.).


Como você cria e manipula tudo isso? Através de requisições WEB utilizando interfaces REST ou SOAP, sempre utilizando verbos específicos para consultar, criar, apagar e atualizar suas entidades. Então se o SSDS recebe uma requisição para a URL https://luti.data.beta.mssds.com/v1/Livros/Livro38947382, será retornado uma entidade de acordo com o id especificado no último elemento da URL, por exemplo.


Internamente, a Microsoft possui um (ou mais) data Center com milhares de máquinas trabalhando em conjunto, para armazenar e atender as requisições. Então você nem fica sabendo como isso funciona, pois a arquitetura é diferente do modelo tradicional de servidor de banco de dados que conhecemos, mas seu dado está lá e você pode acessá-lo.


Com essa breve descrição eu espero que você possa ver claramente como a minha frase introduz um tremendo erro conceitual. Além disso, o SSDS não é para todo tipo de solução que nós conhecemos, existem aplicações específicas que poderão se beneficiar desse modelo, outras não.


 


Vantagens do SSDS


 


- Não tenho custo de compra hardware, software e equipe técnica para manter meus bancos de dados, só pago pelo o que eu utilizar. O TCO disso deve ser bom... Qual será o ponto onde essa vantagem ser reverte? Será que reverte?


- Garantia de altíssima disponibilidade do serviço. Serviço fora do ar? A chance de acontecer deve ser bem pequena e a garantia de disponibilidade não é problema seu, o Service Level Agreement (SLA) do seu contrato com a Microsoft vai garantir 99,9% (é um exemplo, não sei a quantidades de casas decimais após a vírgula). Se não atingir esse número, processe! Credo...J


- Nada melhor do que colocar meus dados nas mãos de quem sabe tudo sobre o produto (DBAs Microsoft dentro dos DataCenters). Tenho certeza que a Microsoft vai garantir as melhores práticas em seu ambiente.


* Nota 1: já cansei de ver ambientes mal configurados, impactando a performance por simples problemas de configuração. E depois o problema é do produto.


* Nota 2: a estrutura é baseada em SQL Server, mas a organização/partição/distribuição de dados é diferenciada, então pare de pensar no modelo tradicional!


- Garantia dos dados, com backups sempre disponíveis e confiáveis, além de existir dados replicados (possivelmente, outro palpite) pelos nós dentro do Data Center – não conheço os detalhes internos.


- Maior facilidade para escalar sua aplicação, pois a estrutura já está montada para isso. Se precisar de novos containeres e entidades, vá criando que a malha de computadores vai dar conta do recado.


 


Desafios do SSDS


 


- Confidencialidade. Entregar os dados para outra organização sempre foi um problema, como as empresas vão se sentir com o SSDS?


- Alta latência para o acesso aos dados, pois querendo ou não, estamos falando de um servidor na América do Norte. Existem planos de expansão, mas deve incluir Europa e Ásia primeiramente, não sei como ficamos.


- Como arquitetar das aplicações. Esse ponto é complexo, a mudança do paradigma e a maneira como vamos utilizar a nuvem, requer que sejamos conscientes na hora de tomar decisões sobre nossa solução. Não vejo, por exemplo, empresas pegando aplicações atuais e simplesmente atualizando-as para utilizar o SSDS, pois o modelo de conversa “chatty” (muitas idas e vindas) entre a aplicação e o banco de dados (freqüentemente usada), não se adéqua ao SSDS.


- Como vamos interagir com a Microsoft na mudança dos nossos esquemas e serviços disponíveis? A Microsoft vai me ajudar a indexar minhas entidades? Tenho controle sobre isso?


- O time do SSDS está conhecendo o perfil das empresas e como seus serviços serão utilizados, então existem muitas perguntas e algumas “apostas” de respostas. Então arrisco a dizer que o SSDS está sendo moldado de acordo com nossa demanda, e isso é excelente para o consumidor. Faça sua parte e participe do Beta!


 


 


Respondendo ao título do blog: não, não é o fim dos DBAs. Da mesma forma que alguns disseram que o T-SQL iria sumir com a nova programação em CLR, os DBAs vão continuar firme e forte, atendendo às diversas soluções OLTP/OLAP tradicionais e que exigem um tempo de resposta muito pequeno, que não se aplicam à latência do SSDS.


Por outro lado, fica cada vez mais evidente o surgimento de um novo perfil de profissional, que sabe utilizar a nuvem e compor os serviços de forma eficiente, entendo qual aplicação se aplica nesse cenário. No que toca o SSDS, o que eu espero desse profissional:


 


- Saber como modelar os containeres e entidades de forma eficiente, otimizando o espaço necessário para armazenamento (afinal, você está pagando por mês) e o desempenho das consultas (é eficiente criar entidades menores com chaves de entidades? Esse profissional vai saber!).


- Saber como manipular os dados e o cache local para diminuir o tempo de resposta do sistema, além do número de roundtrips entre minha aplicação e o SSDS. Exemplo: vale a pena utilizarmos um mecanismo de prefetching e armazenamento dos dados localmente? Como vou invalidar os dados na cache?


        * Padrões de arquitetura vão surgir (será que já não estão aí?), indicando como utilizar combinar essas peças.


- Conhecer como gerenciar eficientemente as versões das entidades e serviços, garantindo compatibilidade de aplicações.


- Entender o que está acontecendo por debaixo dos panos, sabendo dimensionar corretamente os recursos necessários (latência de rede será crucial) para as soluções. O conhecimento de todos esses componentes será essencial no troubleshooting e performance tuning.


 


Interessante também com vemos as tecnologias sendo criadas com um incrível potencial quando combinadas: LINQ, Entity Framework, ADO.NET Data Services (Astoria), Sync Framework, SQL Server Data Services e Velocity (não acabei de falar sobre cache? Esse acabou de sair do forno - http://blogs.msdn.com/velocity/).


 


O impacto do SSDS e do mundo S+S é algo que estamos vivenciando (e aprendendo), então pense, por exemplo, no profissional que trabalha no setor de vendas de um parceiro da Microsoft. O que vai acontecer com suas métricas de venda? Ele vai poder vender o SSDS? Isso eu não sei responder, então por enquanto vamos pensar no DBA e nas especialidades que podemos conseguir para estarmos preparados para quando o mercado demandar...


 


[]s


Luciano Caixeta Moreira


luciano.moreira@microsoft.com


 


=============================================================


This posting is provided "AS IS" with no warranties, and confers no rights


=============================================================

20080605 - SQL Server Data Services - o fim do DBAssauro que conhecemos.pdf

Comments (2)

  1. Luciano,

    muito bom o artigo, conseguiu fazer um bom resumo do que é o SSDS. Eu acrescentaria apenas uma comparação entre o acesso a dados do SSDS e um Webservice normal.

    Parabéns e obrigado pela força à comunidade aqui no DF.

Skip to main content