Estratégias de particionamento de dados (criando aplicativos de nuvem Real-World com o Azure)

por Rick Anderson, Tom Dykstra

Baixar Corrigir Projeto ou Baixar Livro Eletrônico

O livro eletrônico Building Real World Cloud Apps with Azure é baseado em uma apresentação desenvolvida por Scott Guthrie. Ele explica 13 padrões e práticas que podem ajudá-lo a desenvolver aplicativos Web para a nuvem com êxito. Para obter informações sobre a série, consulte o primeiro capítulo.

Anteriormente, vimos como é fácil dimensionar a camada da Web de um aplicativo de nuvem, adicionando e removendo servidores Web. Mas se todos eles estiverem atingindo o mesmo armazenamento de dados, o gargalo do aplicativo passará do front-end para o back-end e a camada de dados será a mais difícil de dimensionar. Neste capítulo, examinaremos como você pode tornar sua camada de dados escalonável particionando dados em vários bancos de dados relacionais ou combinando o armazenamento de banco de dados relacional com outras opções de armazenamento de dados.

A configuração de um esquema de particionamento é melhor feita antecipadamente pelo mesmo motivo mencionado anteriormente: é muito difícil alterar sua estratégia de armazenamento de dados depois que um aplicativo está em produção. Se você pensar com antecedência sobre diferentes abordagens, poderá evitar ter um "momento do Twitter" quando seu aplicativo falhar ou ficar inativo por muito tempo enquanto você reorganiza os dados e o código de acesso a dados do aplicativo.

Os três vs de armazenamento de dados

Para determinar se você precisa de uma estratégia de particionamento e qual deve ser, considere três perguntas sobre seus dados:

• Volume – quantos dados você armazenará? Alguns gigabytes? Uns 200 gigabytes? Terabytes? Petabytes?
• Velocidade – Qual é a taxa na qual seus dados crescerão? É um aplicativo interno que não está gerando muitos dados? Um aplicativo externo no qual os clientes carregarão imagens e vídeos?
• Variedade – Que tipo de dados você armazenará? Relacional, imagens, pares chave-valor, grafos sociais?

Se você acha que vai ter muito volume, velocidade ou variedade, você precisa considerar cuidadosamente que tipo de esquema de particionamento permitirá que seu aplicativo seja dimensionado de forma eficiente e eficaz à medida que ele cresce e para garantir que você não encontre gargalos.

Há basicamente três abordagens para particionamento:

• Particionamento vertical
• Particionamento horizontal
• Particionamento híbrido

Particionamento vertical

Porções verticais é como dividir uma tabela por colunas: um conjunto de colunas entra em um armazenamento de dados e outro conjunto de colunas entra em um armazenamento de dados diferente.

Por exemplo, suponha que meu aplicativo armazene dados sobre pessoas, incluindo imagens:

Ao representar esses dados como uma tabela e examinar as diferentes variedades de dados, você pode ver que as três colunas à esquerda têm dados de cadeia de caracteres que podem ser armazenados com eficiência por um banco de dados relacional, enquanto as duas colunas à direita são essencialmente matrizes de bytes provenientes de arquivos de imagem. É possível armazenar dados de arquivo de imagem em um banco de dados relacional e muitas pessoas fazem isso porque não querem salvar os dados no sistema de arquivos. Eles podem não ter um sistema de arquivos capaz de armazenar os volumes de dados necessários ou talvez não queiram gerenciar um sistema de backup e restauração separado. Essa abordagem funciona bem para bancos de dados locais e para pequenas quantidades de dados em bancos de dados de nuvem. No ambiente local, pode ser mais fácil deixar o DBA cuidar de tudo.

Mas em um banco de dados de nuvem, o armazenamento é relativamente caro e um alto volume de imagens pode fazer com que o tamanho do banco de dados cresça além dos limites em que ele pode operar com eficiência. Você pode resolver esses problemas particionando os dados verticalmente, o que significa que você escolhe o armazenamento de dados mais apropriado para cada coluna em sua tabela de dados. O que pode funcionar melhor para este exemplo é colocar os dados de cadeia de caracteres em um banco de dados relacional e as imagens no Armazenamento de Blobs.

Armazenar imagens no Armazenamento de Blobs em vez de um banco de dados é mais prático na nuvem do que em um ambiente local porque você não precisa se preocupar com a configuração de servidores de arquivos ou o gerenciamento de backup e restauração de dados armazenados fora do banco de dados relacional: tudo o que é tratado automaticamente pelo serviço de Armazenamento de Blobs.

Essa é a abordagem de particionamento que implementamos no aplicativo Corrigir e examinaremos o código para isso no capítulo Armazenamento de Blobs. Sem esse esquema de particionamento e supondo um tamanho médio de imagem de 3 megabytes, o aplicativo Fix It só seria capaz de armazenar cerca de 40.000 tarefas antes de atingir o tamanho máximo do banco de dados de 150 gigabytes. Depois de remover as imagens, o banco de dados pode armazenar 10 vezes mais tarefas; você pode ir muito mais tempo antes de pensar em implementar um esquema de particionamento horizontal. E à medida que o aplicativo é dimensionado, suas despesas aumentam mais lentamente porque a maior parte das suas necessidades de armazenamento está entrando em um armazenamento de Blobs muito barato.

Particionamento horizontal (fragmentação)

A porção horizontal é como dividir uma tabela por linhas: um conjunto de linhas entra em um armazenamento de dados e outro conjunto de linhas entra em um armazenamento de dados diferente.

Dado o mesmo conjunto de dados, outra opção seria armazenar diferentes intervalos de nomes de clientes em bancos de dados diferentes.

Você deseja ter muito cuidado com seu esquema de fragmentação para garantir que os dados sejam distribuídos uniformemente para evitar pontos de acesso. Este exemplo simples usando a primeira letra do sobrenome não atende a esse requisito, porque muitas pessoas têm sobrenomes que começam com determinadas letras comuns. Você atingiria as limitações de tamanho da tabela antes do esperado, pois alguns bancos de dados ficariam muito grandes, enquanto a maioria permaneceria pequena.

Um lado inferior do particionamento horizontal é que pode ser difícil fazer consultas em todos os dados. Neste exemplo, uma consulta teria que ser desenhada de até 26 bancos de dados diferentes para obter todos os dados armazenados pelo aplicativo.

Particionamento híbrido

Você pode combinar o particionamento vertical e horizontal. Por exemplo, nos dados de exemplo, você pode armazenar as imagens no Armazenamento de Blobs e particionar horizontalmente os dados da cadeia de caracteres.

Particionamento de um aplicativo de produção

Conceitualmente, é fácil ver como um esquema de particionamento funcionaria, mas qualquer esquema de particionamento aumenta a complexidade do código e introduz muitas complicações novas com as quais você precisa lidar. Se você estiver movendo imagens para o armazenamento de blobs, o que você faz quando o serviço de armazenamento está inativo? Como você lida com a segurança do blob? O que acontece se o banco de dados e o armazenamento de blobs ficarem fora de sincronia? Se você estiver fragmentando, como lidará com a consulta em todos os bancos de dados?

As complicações são gerenciáveis desde que você esteja planejando para elas antes de ir para a produção. Muitas pessoas que não fizeram isso gostariam de ter feito mais tarde. Em média, nossa equipe cat (equipe de consultoria de clientes) recebe chamadas telefônicas em pânico cerca de uma vez por mês de clientes cujos aplicativos estão decolando de uma maneira muito grande, e eles não fizeram esse planejamento. E eles dizem algo como: "Ajuda! Eu coloquei tudo em um único armazenamento de dados, e em 45 dias eu vou ficar sem espaço nele!" E se você tiver muita lógica de negócios incorporada em como você acessa seu armazenamento de dados e tem clientes que estão usando seu aplicativo, não há um bom momento para ficar inativo por um dia durante a migração. Acabamos passando por esforços hercúleos para ajudar o cliente a particionar seus dados em tempo real sem tempo de inatividade. É muito emocionante e muito assustador, e não algo em que você quer se envolver se você pode evitá-lo! Pensar nisso antecipadamente e integrá-lo ao seu aplicativo tornará sua vida muito mais fácil se o aplicativo crescer mais tarde.

Resumo

Um esquema de particionamento eficaz pode permitir que seu aplicativo de nuvem seja dimensionado para petabytes de dados na nuvem sem gargalos. E você não precisa pagar antecipadamente por computadores massivos ou infraestrutura extensiva como você poderia se estivesse executando o aplicativo em um data center local. Na nuvem, você pode adicionar capacidade incrementalmente conforme necessário e só está pagando pelo que está usando ao usá-la.

No próximo capítulo , veremos como o aplicativo Corrigir Implementa o particionamento vertical armazenando imagens no Armazenamento de Blobs.

Recursos

Para obter mais informações sobre estratégias de particionamento, consulte os recursos a seguir.

Documentação:

• Práticas recomendadas para o design de serviços de Large-Scale no Windows Azure Serviços de Nuvem. White paper de Mark Simms e Michael Thomassy.
• Padrões e práticas da Microsoft – Padrões de design de nuvem. Consulte Diretrizes de particionamento de dados, Padrão de fragmentação.

Vídeos:

• FailSafe: criando Serviços de Nuvem escalonáveis e resilientes. Série de nove partes de Ulrich Homann, Marc Mercuri e Mark Simms. Apresenta conceitos de alto nível e princípios arquitetônicos de maneira muito acessível e interessante, com histórias extraídos da experiência da CAT (Equipe de Consultoria de Clientes) da Microsoft com clientes reais. Confira a discussão de particionamento no episódio 7.
• Criando grandes: lições aprendidas com os clientes do Windows Azure – Parte I. Mark Simms discute esquemas de particionamento, estratégias de fragmentação, como implementar fragmentação e federações de Banco de Dados SQL, a partir das 19h49. Semelhante à série Failsafe, mas entra em mais detalhes de instruções.

Exemplo de código:

• Conceitos básicos do Serviço de Nuvem no Windows Azure. Aplicativo de exemplo que inclui um banco de dados fragmentado. Para obter uma descrição do esquema de fragmentação implementado, consulte DAL – Fragmentação do RDBMS no blog do Windows Azure.

AnteriorAvançar