Azure Table Storage e o NoSQL – Sharding

Cloud Computing & Microsoft Azure & Microsoft Azure Storage

Vamos continuar nossa viagem no mundo do cloud storage, agora com foco na necessidade da escalabilidade para a computação na nuvem.

ShardDiagram-4

A escalabilidade é um tema amplo, portanto para este post vamos vislumbrar este tema sobre o ângulo dos Bancos de Dados, um assunto extremamente delicado no cenário de desenvolvimento atual. Não espere algo no nível internals, vou apenas introduzir o assunto para prosseguir no assunto desta mini-série.

Vamos pensar no cenário atual que já me referi anteriormente. Sistemas web e aplicativos mobile com milhares de usuários simultâneos cada vez mais exigentes. Seu banco de dados têm de ser "escalado", porque, com um número X de usuários não importa o quanto você otimizar o desempenho, em algum ponto você não será capaz de processar tudo dentro de um servidor db. Isto é particularmente verdade para os prestadores de serviços on-line, os softwares como serviço (SaaS), empresas e sites de redes sociais. Com isso você será obrigado a dividir seus dados em vários servidores. Isso acaba criando um novo problema: Você precisa ser capaz de descobrir em qual servidor seus dados estão...

              ... A solução .... Sharding

O movimento NoSQL tenta proteger seus usuário desta complexidade implementando o sharding de maneira transparente, embora eu ache que mesmo assim, devemos conhecer o conceito básico de sharding antes de prosseguirmos neste assunto.

 

Necessidade

Sharding é uma abordagem altamente escalável para melhorar o desempenho. Desde o início do banco de dados relacional que os engenheiros e arquitetos de software têm exigido cada vez maior desempenho e capacidade pela simples observação que os bancos de dados envolvidos nos negócios atuais crescem rapidamente com o tempo.

Vamos usar de exemplo o poderoso Facebook. No início de 2004 ele era "só" um anuário online utilizado apenas pelos estudantes de Harvard. Não era necessário mais do que um servidor para suprir todos os requisitos de armazenamento e carga de consulta. Quatro anos depois apenas os aplicativos para o Facebook contabilizavam cerca de 5.000 visualizações por segundo, sendo que cada um requer consultas em back-end para o preenchimento de dados. Isso demanda custos para a CPU, Memória e capacidade de armazenamento. Em 2009 o Facebook tinha 40.000.000.000 arquivos físicos para representar cerca de 10 bilhões de fotos que é mais de um petabyte de armazenamento. Mesmo sendo improvável o armazenamento real de fotos em um banco de dados relacional, seus metadados e identificadores ainda exigiriam de maneira extrema do armazenamento para representar essas fotos no banco de dados. Você acha que o banco de dados original do Facebook estava preparado para os terabytes de armazenamento vindouros?

Como qualquer DBA ou desenvolvedor experiente sabe, é evidente que o tamanho e o volume de transações de um banco de dados cresce de maneira linear, neste caso o tempo de resposta tende a crescer exponencialmente. Observe o diagrama abaixo:

 

0001

O crescimento nas transações e do volume do banco de dados tem impacto no tempo de resposta.

 

Conceito

Sharding banco de dados fornecem um método para escalabilidade em servidores independentes, cada um com a sua própria CPU, memória e disco. O conceito de uma implementação de banco de dados "shared-nothing" tem estado sob observação na última década, mas ao que parece, somente agora o mercado de aplicativos de negócios está demandando desta tecnologia devido o aumento exponencial do volume de dados nos últimos anos.

Sharding é um padrão que permite aumentar a escalabilidade e a performance de grandes bases de dados. Aplicar este padrão a uma base de dados significa “partir” essa base de dados em pedaços menores e distribui-los por vários servidores de modo a obter escalabilidade. A cada pedaço resultante chamamos de shard (fragmento).

Um fragmento é um ou mais servidores em cluster* que são responsáveis por um subconjunto de dados. Se tivéssemos um cluster com 1.000.000 de documentos que representam os usuários de um site, neste caso um shard pode conter informações sobre 200 mil destes usuários.

Cluster na sua forma mais básica é um sistema que compreende dois ou mais computadores ou sistemas (denominados nodos) na qual trabalham em conjunto para executar aplicações ou realizar outras tarefas, de tal forma para que os usuários que os utilizam tenham a impressão que somente um único sistema responde para eles, criando assim uma ilusão de um recurso único (computador virtual).

O conceito básico de Sharding é muito simples: pegue um grande banco de dados, e quebre-o em uma série de bancos de dados menores. O conceito é ilustrado no diagrama a seguir:

white-paper-dbshards

 

Neste padrão são as linhas das tabelas que são divididas pelos vários servidores. Uma outra opção seria realizar o particionamento vertical. No particionamento vertical os dados são separados por distribuição de tabelas completas entre os servidores. Meter a tabela de clientes num servidor e a tabela de vendas noutro servidor seria um exemplo de partição vertical. A partição de dados por valor (sharding) permite atingir maior escalabilidade porque, por exemplo, não está limitada ao número de tabelas existentes na aplicação e permite a divisão de tabelas com mais acessos.

5165.image005

Sharding de uma base de dados

 

Nas aplicações multi-tenant podemos começar com uma única base de dados e, à medida que o volume de carga vai crescendo, usar o padrão de sharding para distribuir os dados dos clientes por várias bases de dados.

3250.image006

Sharding numa aplicação multi-tenant

 

Sharding requer algum tipo de search (pesquisa). Imagine que você criou uma tabela para armazenar nomes de cidades em ordem alfabética. Precisamos de algum mecanismo para identificar as cidades por exemplo, de A até D estão no servidor SERVER1, e de P até Z estão no SERVER4 e etc.

 

Categorias

Conceitualmente, Sharding pode ser enquadrado em três categorias:

  1. O particionamento Vertical - Todos os dados relacionados com uma característica específica são armazenadas nas mesmas máquinas.
  2. Chaves de particionamento - Um fragmento de dados em si é usado para fazer o particionamento. A forma mais comum é a utilização de um algoritmo de hashing para mapear os dados que serão direcionados a um dos fragmentos para serem armazenados. Utilizar hashes com intervalos de tempo também é uma prática comum.
  3. Diretório de particionamento - Neste esquema, uma tabela que mantém o controle de quais dados são armazenados em que fragmento é mantido no cluster. A desvantagem desta abordagem: o diretório se torna um ponto único de falha e há uma sobrecarga de desempenho já que o diretório precisa ser acessado constantemente.

 

Vantagens

A vantagem óbvia da abordagem do Sharding é a melhoria, escalabilidade crescente de uma forma quase linear como mais servidores sendo adicionados à rede. No entanto, existem várias outras vantagens de bases de dados mais pequenas, que não devem ser ignoradas quando se considera uma solução sharding:

  • Bancos de dados menores são mais fáceis de gerenciar. Bases de dados de produção devem ser totalmente gerenciados para backups regulares, otimização e outras tarefas comuns. Com uma base de dados única (estamos falando de um DB grande), estas tarefas de rotina podem ser muito difíceis de realizar. Algumas tarefas podem durar horas ou dias, tornando em alguns casos a manutenção regular inviável. Ao utilizar a abordagem sharding, cada "shard" individual pode ser mantida de forma independente, proporcionando um cenário muito mais gerenciável, realizando tarefas de manutenção, em paralelo.
  • Bancos de dados menores são mais rápidos. A escalabilidade do sharding é aparente, conseguida através da distribuição e processamento de múltiplos fragmentos de servidores na rede. Ao hospedar cada banco de dados shard em um próprio servidor, a relação entre memória e os dados no disco é muito melhor, reduzindo assim o consumo de I/O. Isso resulta em menos contenção de recursos, maior desempenho de junção, buscas mais rápidas de índice e menos bloqueios de banco de dados.

Não há dúvida de que Sharding de banco de dados é uma solução viável para muitas organizações, apoiadas pelo número de grandes organizações de SaaS que implementaram a tecnologia (gigantes como a Microsoft, Amazon, eBay e Google).

 

Até mais e bom estudo a todos!

Me Azul

Twitter: @vitormeriat

vitormeriat@gmail.com

vitor.pereira@studentpartner.com


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


8 minutes to read