Para atender às demandas crescentes de carga sobre o banco de dados (BD) PostgreSQL, iniciou-se um processo de prospecção que resultou na escolha da estratégia de Sharding[1] como solução para escalar horizontalmente o BD. Essa decisão permite o uso de máquinas com menos recursos e consequentemente menor custo, além de proporcionar adequação do parque computacional de forma mais ágil.

Após avaliação das novas tecnologias (NoSQL, NewSQL etc), optou-se por implementar a solução na aplicação, seguindo uma abordagem que gerasse menor impacto na infraestrutura, mantendo as tecnologias já em uso por questões de confiabilidade, maturidade e para reaproveitar o conhecimento existente. Foi decidido, pelas equipes, que uma solução de Sharding[1] de banco de dados deveria ser implementada diretamente na aplicação Expresso V3.

A escolha do login do usuário como Shard Key[2] demandou a classificação das tabelas em três categorias: Shard (cada um de seus registros está relacionado a somente um usuário), Shared (seus registros estão relacionados a dois ou mais usuários ou a nenhum usuário) e Hibrid (alguns registros são Shard e outros são Shared). Por essa abordagem é possível supor que a maior parte dos dados do Expresso V3 é Shard e que os registros Shared sofrem poucas atualizações. Nesse trabalho também foram avaliados campos de autoincremento e chaves estrangeiras.

"Essa decisão permite o uso de máquinas com menos recursos e consequentemente menor custo, além de proporcionar adequação do parque computacional de forma mais ágil"

A implementação da arquitetura Shard Shared Nothing (Shard Key[2], Virtual Shard[4], Conexão com BD e suas respectivas associações) foi realizada com sucesso.

Desde que as tabelas com registros Shared fossem replicadas, via SGBD Postgres, em todos os BDs do Sharding, poucas alterações seriam necessárias na aplicação. Somente algumas consultas SQL precisariam ser enviadas para todos os BDs e seus resultados unidos na aplicação. A ideia pareceu interessante, principalmente porque as tabelas seriam replicadas com baixa frequência. Essa solução ficou disponível, mas não foi viabilizada devido a restrições para habilitar a replicação do Postgres.

Devido à impossibilidade de realizar replicação, foi prospectado e iniciou-se a implementação de um mecanismo genérico para realizar consultas e atualizações distribuídas de forma transparente, sem necessidade de alteração dos comandos SQL implementados no sistema. Esse mecanismo se mostrou muito complexo e inviável de ser implementado com os recursos e tempo disponíveis.

Finalmente, criou-se a possibilidade da construção de múltiplas configurações de conexão com BD (backend separado). Antes, como o sistema possuía somente um backend de BD, o Shard era habilitado para todas as tabelas. Com a opção de separação, tornou-se possível habilitar o Shard somente para parte das tabelas. Dessa forma, enquanto as tabelas Shared ficaram em um backend com acesso compartilhado por todos, as tabelas Shard puderam ficar em backends separados. Com essa solução, algumas consultas SQL que fazem união entre tabelas que estão em backends diferentes precisaram ser reescritas.

Um backend separado para realizar Sharding[1] de parte das tabelas Shard foi implementado com sucesso. A implementação da operação de Resharding[3] teve como premissas ser eficiente, garantir atomicidade dos dados e não bloquear o uso do sistema. A implementação foi testada em laboratório usando cópia de um banco de dados de produção (mais de dez mil usuários). Funcionou de forma satisfatória.

Como trabalho futuro, é recomendado criar backends separados para tratar tabelas Shard que ainda estão no backend de acesso compartilhado.

A documentação e exemplos de uso já estão disponíveis na comunidade[5]. A implementação já está funcional e será disponibilizada em breve como parte do Expresso V3.

Notas:

[1] Sharding de BD é uma forma de particionar os dados de um BD em dois ou mais BDs, distribuindo a carga. Todos BDs possuem o mesmo esquema de tabelas, mas os registros destas são distribuídos entre os BDs do Shard.
[2] Shard Key é uma chave única, que identifica de forma única um conjunto de registros de uma ou mais tabelas relacionadas. Todos os dados relacionados a um determinado valor de Shard Key são persistidos em um único BD do Shard.
[3] Resharding é a operação de mover dados associados a uma ou mais Shard Keys de um BD origem para um BD destino. Possibilita a adição de novos BDs ao Shard e a redistribuição de carga entre BDs existentes.
[4] Virtual Shard é um agrupamento lógico de Shard Keys. Quando uma operação de Resharding é executada para um Virtual Shard, todas Shard Keys agrupadas por este sofrem a ação. Uma ou mais Shard Keys estão associadas a um Virtual Shard, o qual está associado a um BD.
[5] Site da comunidade Expresso V3 (http://comunidadeexpresso.serpro.gov.br)

Emerson Faria Nobre
Ingressou no Serpro em 2005, onde atua como desenvolvedor do Expresso V3. Antes trabalhou com suporte à infraestrutura de TI e gerência de projetos de software. É mestre em informática com ênfase em métodos formais pela UFPR.