0055 - 085 8112 2187
wiebe@docner.comSharding é uma técnica bastante conhecida para aumentar a escalabilidade de uma aplicação existente. Combina particularmente bem com empresas que tem recentemente feito grandes investimentos em técnicas SQL tradicional e recorrem a empresas que usam técnicas essenciais comprovadas em elaborar uma compartilhada confiança necessária para ter o projecto on-line. ( Veja tambem nossos websites escaláveis ).
Sharding é um passo natural quando a aplicação está ficando lenta devido a carga. Como milhares de linhas por tabela viram centenas de milhares, você vai querer resolver isso primeiro optimizando a tabela e indexando campos. Então, desenvolveres vão começar a fazer optimização de queries ; tentando melhorar o desempenho mudando como o optimizador de query automático do SGBD funciona com a query do desenvolvedor.
Agora nos acabamos de deixar o espaço da 'implementação independente' de desenvolvimento da aplicação. Mas isso continua ainda pior, após isso, existe uma série de bandos dependente de medidas para serem testadas, como por exemplo, adicionando memória para indexação de buffers da tabela. Num certo ponto, vai ficar mais e mais pesado, com menos e menos ganhos por 'melhorias'. Então , o ponto fraco dos clássicos SQL aparece: Uma centralizada tabela indexada é um gargalo. Nesse ponto o SQL permanece estruturado, mas não tão padrão como era.
Sharding basicamente quebra um indice and sub-indices menores, localizando os sub-indices numa série de maquinas. Podendo reduzir seriamente o tamanho do indicee o tempo de busca em um ''shard''. Sendo logicamente e tecnologicamente um passo fácil, porém, há outros fatores a se considerar.
A mudança mais importante, você precisa decidir qual shard para usar quando a aplicação precisa de dados. Isso significa que decidir como dividir os dados. Nós tivemos um projecto que o cliente provia um serviço para outras empresas e nós pudemos quebrar um grande dataset em pedaços por empresas. Esse projecto está rodando no MySQL, só adicionar um banco é fácil e não possui muito overhead.
Nós decidimos por todos os documentos de uma organização num banco de dados. Para mantê-lo gerenciável, nos escrevemos código que automaticamente cria o banco, usando um simples gerenciador de recursos para alocar novos bancos de novas organizações em um banco servidor de um conhecido conjunto de servidores. Movendo mais responsabilidade para o desenvolvedor da aplicação , já que a aplicação precisa não só da criação da tabela, mas precisa criar os índices corretos também.
Até esse ponto, nós parecemos estar o mais perto possível das ''conhecidas'' práticas de aplicações web em java. Nós estamos criando a aplicação web com uma camada de implementação EclipeLink JPA. Na verdade, criar um banco usando JPA é menos doloroso e mais automático, nós somente precisamos adicionar alguma lógica para juntar alguns comandos para setar os corretos índices.
A mudança mais importante com EclipseLink for fazer a troca entre shards de maneira transparente. Era logicamente simples e um protótipo dessa solução estava on-line e rodando em algumas horas. Os problemas vieram quando vários shards com dados foram preenchidos e então, iniciaram a rodar queries paralelas neles e todas concorrentes. EclipseLink está colocando no cache tantos meta dados sobre uma única conexão de banco e suas relações com as classes ,que trocando várias conexões rápidas fizeram-nos a ficar sem memória.
Nunca descobrimos como desabilitar o caching, então, decidimos que provavelmente não seria uma boa ideia. Terminamos simplesmente codificando quereis em puro JDBC e mapeando nós mesmos os campos. Um pouco mais trabalhoso inicialmente, mas no final tivemos resultados muito mais precisos e rápidos. O qual foi notavelmente um eficiente recurso, não importando o número de documentos, nem o número de shards.
Numa normal codificação diária a única coisa que foi realmente diferente , foi o desenvolvedor ter que entender a relação entre dados que vieram de fora de um shard não são mais automáticos e a consistência dos dados precisam ser gerenciadas. No nosso caso, isso não chegou realmente a mostrar nenhum problema como a partição de dados, uma vez que não existiam relações entre os dados de um shard para o outro.
Conhecendo o que sabemos agora, nós podemos provavelmente por nosso projeto em Hbase ao invés de nós mesmos codificarmos a lógica de distribuição. Mas ainda existem razões boas e práticas para usar o SQL nesse aspecto. Não somente pelos investimentos existentes nessa infra-estrutura , mas também quando você precisa de várias formas de fazer suas queries de vários ângulos para satisfazer as quereis do usuários imediatamente, SQL ainda é um pratico e estável utilitário . E sharding pode ajudar a dar escalabilidade eficiente.