Hibernate Shards – Guilherme Chapiewski

[JBoss World 2008] Max Ross: Hibernate Shards

Max Ross, do Google, fez uma apresentação sobre o Hibernate Shards.

Desenvolvido em 6 meses como um “pet project” (projeto pessoal) usando 20% do tempo de 3 engenheiros, o Hibernate Shards foi lançado internamente no Google em dezembro de 2006 e depois doado para a JBoss em maio de 2007.

“Shard” é um termo que o pessoal do Google usa para falar de divisão/particionamento. O Hibernate Shards é um framework de persistência baseado no Hibernate, usado para dividir os dados entre vários bancos de dados diferentes, criando um particionamento horizontal das informações.

Resumidamente, o particionamento horizontal é usado quando você têm aplicações com bancos de dados monstruosamente grandes e você precisa distribuí-los em vários bancos de dados. Então, você tem várias instâncias de banco de dados diferentes, todas com o mesmo schema, e com os dados divididos entre elas. Quem gerencia onde está cada banco de dados e em qual “shard” (partição/bucket/o que você quiser) estão os dados é o Hibernate Shards, de forma transparente para a aplicação. O Shards pode usar qualquer banco de dados suportado pelo Hibernate (ele tira vantagem dos dialects).

Os criadores do projeto queriam que fosse fácil e natural para os usuários de Hibernate usá-lo, por isso ele usa vários conceitos familiares como, por exemplo, a ShardedSessionFactory, que implementa a interface SessionFactory. Eles tem uma ShardedSession, e por aí vai.

Apesar do Shards ser totalmente compatível com Hibernate do ponto de vista da aplicação (porque usa as mesmas interfaces), ele não suporta JPA, a implementação de Query ainda não funciona 100% e vários outros probleminhas e “gaps” em relação ao Hibernate…

Confesso que fiquei um pouco decepcionado, porque pelo que eu tinha conversado com o pessoal por aí, parecia que ele seria uma forma de ter um schema distribuído em vários bancos de dados diferentes, e isso ia resolver um problema gigante que tenho. Mas descobrí que isso que eu preciso é particionamento vertical. Perguntei para o Max se daria para fazer alguma adaptação e ele falou que até seria possível escrever um ShardStrategy que quebrasse um galho, mas eu teria muitos problemas maiores pra resolver.

Ao menos serviu para conhecer esses conceitos de banco de dados, que de certa forma eu conhecia mas não da maneira formal.

[JBoss World 2008] Emmanuel Bernard: Hibernate

A apresentação do Emmanuel Bernard sobre Hibernate foi muito boa. Inicialmente o Gavin King também iria participar, mas ele acabou não chegando a tempo. Fiquei com medo achando que eles fossem falar sobre coisas muito básicas que todo mundo já conhece, mas ao invés disso o Emmanuel se preocupou justamente em falar sobre coisas que as pessoas não estão muito acostumadas a ver por aí, como estratégias de replicação e ResultTransformers, por exemplo.

Roadmap do Hibernate 3.x

O Emmanuel deu uma visão muito ampla do que eles planejam para o futuro. O roadmap do Hibernate para as próximas versões (3.x), que serão lançadas durante os próximos meses, incluem dentre outras coisas o seguinte:

Second-level Cache

Re-design das estratégias de replicação em cluster usando JBoss Cache (aliás, muito necessário, porque isso definitivamente não funciona bem, já tive experiências não muito boas de aplicações que simplemente se afogam com isso).
Re-design da clusterização de um modo geral.

JDBC Work API

Quando o Hibernate se torna um impecilho para o desenvolvimento porque não te dá a flexibilidade que você precisa, use um “proxy” para JDBC provido pelo Hibernate.

Stateless API

Usada para operações em batch, esta API permitirá a inserção de milhões de objetos sem erros de “out of memory”, facilitará o desenvolvimento de tarefas para rodar em intervalos de tempo determinados (tipo cron jobs) e coisas do tipo.

Hibernate 4.0

Já o Hibernate 4.0, que não tem data marcada para sair e parece que não vai ser tão cedo, tem uma lista de features muito mais extensa e “agressiva”. Basicamente essa nova versão do Hibernate será focada nos seguintes objetivos:

Facilidade de desenvolvimento

Uso massivo de Java 5, generics, annotations, etc.
União de todos os projetos relacionados à persistência no Hibernate Core.

Configuração mais simples

Cada vez menos baseada em texto/String e xml e mais baseada em convenções e annotations.
Mutável em runtime, ou seja, alterar determinadas configurações não irá requerer que o contexto seja reiniciado.

Mais flexibilidade de mapeamento

Mais opções para mapeamento de componentes polimórficos.
Mais opções para mapeamento de coleções.

Otimizações

Melhorias no startup, que hoje é muito lento, especialmente quando se tem centenas ou milhares de entities.
Novas estratégias de fetching e melhorias no fetch automático.

Queries

Facilidades para geração de relatórios e data warehouse: incorporação de UNION e MINUS na HQL.
Incorporação de DELETE CASCADE na HQL.
Alinhar features da Criteria API e da HQL.

Funcionalidades de alto nível

Versionamento automático e transparente de dados “out of the box”.

Entity Manager

Uma das idéias é que não seja mais necessário registrar as entities em um arquivo de configuração, só a annotation @Entity será necessária.

Hibernate Tools

Criação de Ant tasks para que toda a DDL (tabelas, constraints, sequences, etc) necessária para a aplicação funcionar seja gerada automaticamente.
Leitura das informações para geração de DDL diretamente das entities, suportando tanto os mapeamentos feitos com Hibernate como com JPA.
Integração com JBoss Developer Studio.

Ampliação da plataforma

Outros projetos mais novos como Hibernate Search, Hibernate Validator e Hibernate Shards ganharão mais foco.

E a JPA?

Tudo isso automaticamente nos remete ao assunto Java Persistence API. A JPA foi lançada com um conjunto de featues muito pequeno que simplesmente não atende qualquer caso que não seja feijão-com-arroz. O que normalmente acaba acontecendo é que você sempre tem que recorrer a features específicas do Hibernate para resolver casos mais complexos. Isso simplesmente elimina o papel da JPA, que seria manter a aplicação desacoplada de um “vendor” específico. Então, o Emmanuel também falou um pouco do que podemos esperar para a JPA para resolver esses problemas:

Objetivo principal: padronização de um mecanismo de mapeamento objeto-relacional “lightweight”.
Focada em Domain Model.
Uso massivo de annotations: o objetivo é fazer tudo funcionar por annotations sem a necessidade de nenhum arquivo de configuração.
Incorporação das annotations avançadas específicas do Hibernate.
Fará parte do Java EE 6 padrão.
Terá uma Criteria API.