Javafree

Space4J - Persistência de Objetos em RAM

Publicado por Flavio R. Bianchi em 09/09/2009 - 7.454 visualizações

por Sergio Oliveira Jr.



Introdução

Conceitualmente, o Space4J está todo baseado no Prevayler, um projeto open-source criado por Klaus Wuestefeld. A verdade é que eu gostei tanto da idéia do Prevayler que, para entendê-la completamente, eu resolvi codificar minha própria versão do sistema do zero. Meus principais objetivos eram:

- Enteder claramente a teoria por trás do prevayler.
- Criar uma API bastante simples e clara, acessível a qualquer um.
- Suportar replicação e load balance de uma forma transparente.

Dessa maneira foi possível me familiarizar com as entranhas do sistema, que não são triviais e inicialmente estavam totalmente obscuras para mim. Não posso deixar de agradecer ao Klaus e ao pessoal da lista de discussão (em inglês) do Prevayler, que esclareceram minhas dúvidas teóricas e me colocaram no caminho certo.

O código do Space4J também é aberto (LGPL), e pode ser baixado clicando aqui.

A API do Space4J pode ser consultada aqui.


O que é o Space4J ?

A premissa do Space4J, assim como do Prevayler, é:

"Para que utilizar um banco-de-dados se você pode ter todos os seus objetos em memória ???"

Inicialmente quando li essa frase achei que a coisa era uma brincadeira. Para os céticos como eu sugiro que consultem o Skeptical FAQ do Prevayler.

Abaixo listo alguns dos pontos principais do Space4J:

- Memória RAM está cada vez mais abundante, barata e rápida. Com a provável popularização dos processadores de 64 bits da Intel (Itanium), o limite de RAM de 4Gb dos processadores de 32 bits passará para 18 bilhões de Gb !!!

- Se desligarem o cabo de força da máquina que está rodando o Space4J, você não perde nada. Todas as transações são logadas em disco e podem ser reaplicadas quando o sistema for reiniciado. Além disso o sistema, de tempos em tempos, grava um snapshot no HD de todos os objetos em RAM. Dessa maneira o sistema não precisará reaplicar as transações de um ano inteiro, mas apenas aquelas que ocorreram após o último snapshot !!!

- O Space4J roda na mesma máquina virtual que os seus clientes. Não há requisições remotas. Os dados (objetos) estão logo ali na memória e o cliente pode acessá-los diretamente.

- Para o caso de vários clientes distribuídos, haverá um sistema de replicação das alterações entre eles, como um cluster. Um dos clientes ficará sendo o principal (master) e ficará responsável pelo broadcast das alterações para os outros clientes (slaves). Qualquer alteração feita por um slave será enviada para o master, que notificará o slave quando a mesma for efetivada. Utilizando esse esquema de replicação, garantiremos a mesma ordem de execução das transações em cada máquina e consequentemente a sincronia total do sistema distribuído.

- Cada cliente poderá fazer suas consultas diretamente no seu Space4J, ou seja, em um ambiente distribuído temos um load balance transparente do sistema.

- De tempos em tempos, o sistema faz um snapshot (dump) dos objetos em memória para o HD. Durante um snapshot, não é necessário que o sistema pare, nem que entre em modo read-only. Na verdade o snapshot deverá ser feito por um slave isolado, que poderá entrar tranquilamente em modo read-only durante a execução do snapshot. Dessa maneira nenhuma parte do sistema vai perceber quando o snapshot estiver sendo executado.


Entidades do Space4J

Abaixo estão as principais entidades (ou interfaces) do sistema.

Space: Um espaço onde os objetos serão guardados. Pode ser qualquer estrutura de dados onde eu possa colocar e remover objetos por um nome. Naturalmente uma hashtable é a estrutura de dados mais recomendada aqui.

Logger: Responsável por toda atividade em disco (HD) do sistema, principalmente snapshots e log de transações (comandos).

Space4J: Nosso sistema em questão. Sua principal responsabilidade é executar os comandos que lhe são passados para a alteração dos objetos no Space.

Command: Um comando que representa uma alteração no Space e que deverá ser executado pelo Space4J. Precisa ser obrigatoriamente serializable para que possa ser logado em disco e replicado para os outros clientes.


PhoneBook e SimpleSpace4J

A versão mais simples do Space4J é aquela onde não há replicação. Temos um sistema simples que precisa de um banco-de-dados para armazenar informações. Um Space4J local, rodando na mesma VM do sistema em questão resolve o problema. Para esse caso básico temos o SimpleSpace4J.




Como vocês podem ver, a coisa é simples pois toda a complexidade do sistema está encapsulada no objeto SimpleSpace4J.
É fundamental também entender como construimos Commands:




Pontos Importantes:

- Ao invés de tabelas, agora você tem Collections, Maps, e qualquer estrutura de dados para armazenar dados em memória.

- Ao invés de SQL para a leitura dos dados, agora você pode acessar os dados diretamente em memória.

- Ao invés de SQL para a alteração dos dados, agora você precisa criar Commands.


Escalabilidade do Space4J: Replicação e Load Balance

Para aplicações mais críticas, é obrigatório o suporte a clientes distribuídos, e para isso temos MasterSpace4J e SlaveSpace4J. Como vocês podem ver abaixo, o Space4J suporta replicação (cluster) e load balance de uma forma totalmente transparente para o cliente.




Desafios

Como fazer queries complexas com estruturas de dados?
Como fazer queries pesadas sem engargalar o sistema?
Como fazer relatórios ou data warehousing?
Como trabalhar com índices compostos?
O que fazer se por algum motivo o master perder a comunicação com um slave ou vice-versa?


Conclusão

O Space4J é um framework mínimo para a persistência de dados em memória RAM. Seu ponto forte é a simplicidade da API e o suporte transparente a ambientes distribuídos via replicação. Na teoria ele funciona muito bem, e gostaria muito de vê-lo testado em um ambiente pesado de produção. Se a idéia vai pegar e se veremos mais e mais sistemas utilizando persistência de dados em RAM eu não sei, mas por via das dúvidas estou apostando. Em teoria, um sistema simples como o Space4J e o Prevayler podem desbancar grandes produtos de grandes empresas. Mas só o tempo vai medir a credibilidade desse novo paradigma, por isso finalizo com uma frase do um amigo cético:

"Na teoria, se você viaja mais rápido do que a luz, volta no tempo."



Sobre o Autor: [color=blue:626f86e28d]Sergio Oliveira Jr.[/color:626f86e28d] é engenheiro de computação certificado pela Sun Microsystems em programação Java. Trabalhou na Accenture (ex-Andersen Consulting) como consultor de Internet e atualmente trabalha no ParPerfeito, o maior site de relacionamentos da América Latina. Também presta consultoria Java para empresas de médio e grande porte.

[color=red:626f86e28d]Copyright (c) 2001 - Todos os direitos dessa publicação estão reservados ao autor, sendo expressamente proibida a reprodução total ou parcial desse artigo de acordo com o Art. 184 do Código Penal e Art. 30 da Lei 5.988/73.[/color:626f86e28d]

comentários: 0