Faz pouco mais de uma semana, mas eu me diverti muito e aprendi algumas coisas com a sessão e as discussões no CloudCamp de Los Angeles. Propus e, por fim, conduzi uma sessão sobre dimensionamento de dados. Na verdade, eu a propus como "Dimensionando seus dados: Antes e depois de você precisar".
Parte do motivo pelo qual eu o propus foi o fato de que houve uma discussão sobre o teorema CAP durante a proposta de sessões, e o que foi dito estava um pouco errado. O CAP é bem discutido em vários lugares (um bom blog é o de Jonathan Gray, CTO e cofundador da Fluxo. CAP significa Consistência, Disponibilidade e tolerância a Partição de rede. É interessante notar que muitas pessoas continuaram tentando transformar o último P em desempenho ou introduzir o desempenho na mistura. O desempenho (ou pelo menos as compensações envolvidas) é melhor discutido em outro conjunto de letras W+R>N. Tínhamos uma sala na sede da Microsoft no centro de Los Angeles praticamente dedicada ao dimensionamento de dados. A primeira sessão foi conduzida por .... e abordou o teorema CAP. No início, houve um pouco de controvérsia, pois havia algumas afirmações de que era possível obter todos os três com o uso criterioso da tecnologia da Microsoft, mas, por meio da discussão na sala, acabamos no lugar certo e concordando uns com os outros. Essa sessão foi conduzida por Abhijit Gadkari, da ZimbaTech. Depois disso, a própria Microsoft SoCalDevGal (Lynn Langit) fez uma apresentação sobre SQL Azure. Certamente aprendi um pouco sobre o que a Microsoft está oferecendo e o que seus desenvolvedores estão pedindo. Até aprendi alguns novos acrônimos de três letras :) O SQL Azure é o banco de dados relacional hospedado da Microsoft como um serviço. Na apresentação, ficou claro que, inicialmente, a Microsoft não estava planejando um armazenamento de dados hospedado totalmente compatível com SQL (o que a tornaria mais parecida com o SimpleDB da Amazon ou com o BigTable do Google, acessado por meio do App Engine do Google). No final, o feedback dos clientes fez com que eles voltassem a fornecer o máximo de SQL possível, incluindo a integração com todas as ferramentas de desenvolvimento da Microsoft. É interessante notar que a Microsoft está sugerindo a fragmentação de dados para escala. Isso se deve, em parte, ao fato de o produto inicial estar limitado a bancos de dados de 10 GByte. A SoCalDevGal deixou bem claro que essa é apenas uma limitação inicial, e que algumas coisas tiveram que ser feitas para cumprir seu cronograma. A outra parte realmente interessante sobre o SQL Azure, que eu achei pertinente, dado o restante da discussão, foi a aparente decisão de tornar o SQL Azure um sistema de CA, em relação ao CAP. Eu até pedi para verificar, e essa era de fato a intenção. A razão pela qual isso é tão importante para mim é que a decisão de design aqui, juntamente com a replicação entre os datacenters, significa que a única maneira de fazer isso corretamente é colocar o sistema off-line (ou uma parte de sua segurança) no caso de um datacenter ser cortado da rede. Como todos os dados estão em pelo menos dois datacenters, e você não sabe quais são os dois, é possível que os datacenters sejam mais do que "pares", o que significa que uma partição completa de um único datacenter pode significar uma interrupção de pelo menos dois, e talvez mais. Isso é bom para seus usuários, pois é totalmente compatível com seus aplicativos, mas também significa que pode haver um "momento CNN" algum dia, o que significa que algumas falhas de telecomunicações podem deixar off-line um grande número de clientes do SQL Azure. Para que isso não seja mal interpretado, não se trata de uma crítica à tecnologia da Microsoft ou a alguma deficiência que ela deveria ter superado. Foi apenas uma escolha de design feita pela equipe do SQL Azure. É aí que está a "engenharia" em nossa disciplina... há compensações em qualquer projeto. A última sessão da sala, à noite, acabou sendo a minha. Fiz uma rápida apresentação de mim mesmo e uma rápida avaliação de quem já havia pesquisado coisas como memcached, gearman, Haoop HBase, Cassandra e similares. Descobri que quase ninguém havia pensado sobre isso. Acho que isso se deve, em parte, ao fato de a Microsoft ter feito um ótimo trabalho ao colocar os participantes nos assentos para esse evento. Devido à experiência do público com essas coisas, conduzi a sessão como um exercício cerebral de compreensão por que alguém pode querer pesquisar maneiras diferentes de armazenar dados. Tenho certeza de que não abordei tudo, mas citei alguns motivos:
- Dimensionamento - Transferir parte da inteligência para os clientes em uma arquitetura de computação distribuída simplifica a divisão dos componentes e, portanto, o dimensionamento. Também fica muito mais fácil mover o armazenamento em cache para mais perto de onde os dados são usados, o que ajuda a dimensionar.
- Produtividade do desenvolvedor - Isso tem dois lados: o fato de ter que aprender uma nova maneira de armazenar e recuperar dados é um fator de perda de produtividade, mas a capacidade de desenvolver estruturas de dados e mecanismos de persistência sem precisar declarar alterações em um modelo de dados (envolver DBAs etc.) é libertadora.
- Disponibilidade - Para algumas classes de aplicativos, pode fazer todo o sentido que a maioria dos dados esteja disponível, mesmo que uma pequena parte não esteja disponível no momento.
- Distribuição geográfica - Se você começar a pensar nos dados de forma um pouco diferente, será fácil distribuí-los geograficamente.
Terei que escrever mais sobre isso em um futuro não muito distante. Estive analisando vários trabalhos anteriores (até mesmo alguns artigos acadêmicos) e há algumas ideias interessantes por aí. p.s.: o pessoal da TechZulu gravou a sessão. Talvez ela esteja em seu site em algum momento... Verifiquei o link, mas ainda não está lá.
