Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
(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:
https://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 - https://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
=============================================================
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
Anonymous
June 05, 2008
PingBack from http://www.basketballs-sports.info/basketball-chat/?p=1596Anonymous
June 06, 2008
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.