Este documento descreve um sistema de banco de dados distribuído em memória construído a partir do Berkeley DB, permitindo que tabelas sejam armazenadas em diferentes nós de um cluster de computadores de forma transparente para os clientes. O sistema implementa controle de concorrência localmente mas ainda não garante coerência entre versões distribuídas, o que será abordado em trabalhos futuros.

1. BANCO DE DADOS EM MEMÓRIA SOBRE
CLUSTERS DE COMPUTADORES
Guilherme Dal Bianco, Jeison Luiz Ferreira Vieira, Nelson Duarte Filho
Fundação Universidade Federal do Rio Grande – FURG
Rio Grande - RS
gui_bianco@yahoo.com.br, jeison.ecomp@pop.com.br, dmtnldf@furg.br
Resumo. Com o advento de redes de comunicação de alta velocidade e de sistemas de computação com grande capacidade de processamento e de armazenamento em memórias do tipo RAM, ambos a relativos baixos custos, se tornou possível construir clusters de computadores capazes de oferecer funcionalidades até então realizáveis apenas em grandes computadores com arquiteturas proprietárias. Banco de dados em memória é uma delas. Este trabalho descreve o esforço de pesquisa e desenvolvimento que está sendo realizado com o objetivo de construir um sistema de banco de dados distribuído, em memória, para ser implantado em clusters de computadores.
Palavras-chave: banco dados em memória, clusters de computadores, sistemas distribuídos.
1. INTRODUÇÃO
A grande capacidade de memória RAM, disponível de forma distribuída em clusters de computadores, tem motivado a busca por soluções de bancos de dados capazes de manter permanentemente em memória as tabelas que compõem os bancos, como descrito por Fernando, Rachid e André[1]. Neste trabalho utiliza-se o Berkeley Data Base (BDB), banco de dados desenvolvido pelo grupo Sleepycat da Universidade de Berkeley [2], atualmente disponibilizado pela Oracle [3] sob a forma de software aberto, como ponto de partida para implementação de um banco de dados distribuído em memória, num cluster de computadores. Para tal, foi aplicado um processo de engenharia reversa para se obter entendimento sobre o funcionamento do BDB. A opção de armazenamento em memória, que é realizada de forma centralizada, foi então remodelada para tornar-se distribuída entre os vários nodos do cluster. Para isso, foi utilizado o paradigma Distributed Shared Memory (DSM), que oferece a abstração de uma única memória compartilhada, proposto por Li [4] e Li and Hudak [5]. Nessa abstração, quando a área acessada em um nodo não pertence à memória local, ela é buscada através da rede de comunicação. A seguir apresentam-se uma descrição simplificada do funcionamento do BDB, a proposta de funcionamento distribuído implementada e tecem-se comentários conclusivos sobre o trabalho realizado.
2. DESCRIÇÃO SIMPLIFICADA DO BDB
O BDB é um conjunto de métodos para gerenciamento de bancos de dados, fornecido sob a forma de uma biblioteca. Algumas das suas funcionalidades são aqui descritas, principalmente as que se encontram no escopo das idéias adotadas neste trabalho.
Duas são as possibilidades de utilizar o BDB: local ou remotamente. Devido a isso, a biblioteca de métodos que o constitui é dividida em dois subconjuntos: métodos locais e métodos remotos. É nessa perspectiva que aqui se apresenta o BDB.
2.1 Utilização local
Para utilizar o BDB localmente, há que construir aplicações que invoquem métodos de gerenciamento de bancos de dados do

2. subconjunto de métodos locais, e linkeditá- las junto à biblioteca que constitui o BDB. Portanto, as aplicações que realizam acesso aos bancos de dados compartilham espaço de endereços com o BDB. Ou seja, o BDB é um software embarcado nas aplicações.
No BDB, o conceito de banco de dados corresponde ao de uma tabela composta de registros constituídos de dois campos: key e data. Esses campos podem possuir uma estrutura heterogênea qualquer, em conformidade com o admitido no tipo struct da linguagem C.
Os bancos de dados são implementados sobre os aqui denominados subespaços de endereços paginados, sendo que cada subespaço pode conter um ou mais bancos de dados. Tais subespaços são realizados na memória sobre um buffer pool (memory pool), onde cada buffer contém uma página de um subespaço.
Na Figura 1 é ilustrado o esboço da organização de uma sessão de uso local do BDB, que corresponde a duas aplicações utilizando um ou mais bancos de dados, num único computador. Ali se podem ver alguns conceitos até aqui apresentados, assim como outros que ainda serão introduzidos.
Está indicado na figura que a camada APLICAÇÂO trata as informações que lhe correspondem invocando funções que implementam métodos de acesso à bancos de dados. Como o BDB admite acesso concorrente às tabelas, através de aplicações multithreads e/ou multiprocessos, há que ser garantida a manutenção de consistência dos dados envolvidos. E isso é realizado através do conceito de transações, implementado com o uso de mecanismos de locking, logging e detecção de deadlocks. Os lockings de acesso, para bancos de dados estruturados como b-trees ou hash tables, são realizados em nível de páginas.
Típicos métodos da camada ACESSO que podem ser invocadas pela camada APLICAÇÂO para manipular tabelas são:
- DB->put (*db, *txnid, *key, *data, flags);
- DB->get (*db, *txnid, *key, *data,
flags).
Sendo DB->put um método para ACESSO APLICAÇÃO ARMAZENAMENTO ACESSO APLICAÇÃO ARMAZENAMENTO Informações Tabelas Páginas (buffers) ControleTransacional ControleFigura 1 –Descrição BDB local. Transacional
inserir um par key/data no banco de dados
db, no contexto da transação txnid, de acordo com especificações (aqui irrelevantes) indicadas em flags. O método DB->get recupera um par key/data.
Para realizarem os seus serviços, os métodos que constituem a camada ACESSO mantém os dados pertencentes aos bancos, assim como os metadados que proporcionam a estruturação dos dados, no memory pool. As páginas são inseridas e recuperadas dos subespaços de armazenamento através do acionamento de métodos da camada ARMAZENAMENTO. Típicos métodos desta camada que podem ser invocados pela camada ACESSO são:
- MP->get (*mpf, *pgnoaddr, flags, **pagep);
- MP->put (*mpf, *pgaddr, flags);
Sendo MP->get um método que retorna em pagep o conteúdo da página pgaddr do subespaço de endereços identificado como mpf, de acordo com as especificações (aqui irrelevantes) indicadas em flags. O método MP->put devolve a página pgaddr ao memory pool.

3. 2.2 Utilização remota
Para executar aplicações remotas no BDB deve-se escolher um host para abrigar os bancos de dados envolvidos; instalar nesse host um servidor que executa métodos do subconjunto de métodos locais, quando acionado via RPC; e instalar em hosts remotos as aplicações que executam os métodos do subconjunto de métodos remotos. Ao iniciar o servidor e as aplicações, os métodos remotos executados nas aplicações invocam o servidor, via RPC, para que este acione os métodos locais a eles correspondentes. Na Figura 2 ilustra-se o funcionamento aqui descrito, numa configuração em que duas aplicações estão utilizando remotamente um ou mais bancos de dados.
Como se vê na figura, os dados são armazenados sob a forma de páginas no host servidor, da mesma forma como descrito para caso da utilização local, portanto centralizados num único computador.
Os métodos remotos possuem a mesma assinatura dos métodos locais, e são selecionados ao invés destes pela indicação, em uma flag de controle, que se trata de uma aplicação remota. Tais métodos são construídos de forma a invocar seus correspondentes métodos locais no host servidor. Esse mecanismo é implementado através do paradigma Remote Procedure Call (RPC) proposto por Birrell and Nelson [6].
Pode-se então referir que, mesmo no caso de utilização remota, o BDB gerencia as tabelas e os subespaços de armazenamento de modo centralizado. Na verdade, ele é organizado de tal forma que um servidor, executando localmente no âmbito das aplicações remotas, invoca os métodos locais correspondentes aos métodos remotos invocados nas aplicações.
Devido ao possível acesso compartilhado das tabelas entre o servidor e outras aplicações locais (situação não representada na figura por motivo de clareza), na utilização remota também é oferecida a possibilidade de manutenção de consistência dos dados através de controle transacional. Isso é realizado da mesma forma que no caso de utilização local, pela própria estrutura funcional escolhida para o BDB, conforme descrito.
No entanto, como os mecanismos de manutenção de consistência são
implementados na camada aqui denominada Figura 2 –Acesso remotoACESSO_REMOTO APLICAÇÃO ACESSO ARMAZENAMENTO Informações Tabelas Páginas (buffers) ControleSERVIDOR APLICAÇÃO ACESSO_REMOTO Host Servidor Hosts Remotos Transacional
ACESSO, apenas os métodos dessa camada podem ser acionados remotamente. Ou seja, o subconjunto dos métodos locais não possui correspondência um para um com os remotos. Isso pode ser melhor esclarecido através da situação exemplo a seguir descrita.
Suponha que duas transações executando em aplicações remotas tentem acesso de escrita ao mesmo registro de uma

4. determinada tabela, através do método DB->put. Apenas um será realizado e o outro ficará no aguardo do desfecho da transação escolhida.
Por outro lado, se fosse possível executar o método MP->put remotamente, duas aplicações tentando acesso concorrente, invocados indiretamente no âmbito da execução de métodos da camada de ACESSO, resultariam inconsistentes.
Na utilização local essa situação também ocorre, porém, talvez por decisão de projeto, os métodos da camada ARMAZENAMENTO podem ser executados de forma direta pelas aplicações. Assim, neste caso, os conflitos não são automaticamente impedidos, sendo as suas soluções delegadas às próprias aplicações.
3. FUNCIONAMENTO DO BANCO DE DADOS DISTRIBUÍDO
Após o entendimento básico do BDB, descrevemos as modificações nele introduzidas, por nós realizadas.
O conjunto das tabelas que constitui os dados de uma aplicação é distribuído entre os nós. Ou seja, quando um CLIENTE cria uma tabela, esta poderá ser colocada em
qualquer nodo, de forma transparente. A escolha é realizada por um dos servidores, que possui a função especial de manter registros de configuração, como o próximo servidor a receber uma tabela a ser criada. Com isso, se possibilita que as tabelas sejam distribuídas entre os vários nodos que constituem o cluster.
Relembrando que uma tabela é implementada sobre um subespaço de endereços paginado, e que esse subespaço é realizado na memória sobre um buffer pool (memory pool), onde cada buffer contém uma página de um subespaço, a seguir se descreve a alteração no BDB por nós realizada, através do exemplo ilustrado na Figura 3.
O exemplo envolve uma aplicação CLIENTE executando no nodo X e acessando duas tabelas: a tabela A armazenada no mesmo nodo em que a aplicação está sendo executada e a tabela B armazenada em um outro (nodo Y). Diz-se que a tabela A tem home no nodo X e a tabela B tem home no nodo Y.
Além do processo CLIENTE, a figura apresenta os processos CLIENTE ESPECIAL (CE) e SERVIDOR (um em cada nodo). O CLIENTE acessa as tabelas através dos métodos DB->put e DB->get como descrito na seção 2.2.
Em cada nodo existe um CE que tem por finalidade servir como “ponte” de comunicação entre os servidores. Ou seja, quando um servidor necessita uma página Host Remoto Figura 3 – Troca de páginas ente dois servidores, através do cliente ACESSOMEMORY POOLCLIENTE Informações Tabelas Páginas (buffers) MEMORY POOLInformações Tabelas Páginas (buffers) SERVIDORCLIENTE ESPECIALSERVIDOR Nodo Y
que não se encontra nos buffers do nodo em que ele está sendo executado, ela é por ele
solicitada, via CE remoto, ao servidor que executa no nodo home da referida página. Dentre as funcionalidades especiais dos CEs, eles tem acesso direto à camada de

5. armazenamento, através das primitivas MP- >put e MP->get. Os servidores invocam os CEs informando as páginas necessárias.
Os processos SERVIDORes tem por função atender pedidos dos CLIENTES: inserindo ou alterando dados nas tabela; e dos CE: fornecendo dados a servidores remotos. Como esse funcionamento acaba introduzindo um gargalo no sistema, na medida em que o número dos servidores é acrescido, foram adicionados threads aos processos servidores, de acordo com o número de nós, de modo a mitigar esse problema. As threads são alimentadas através de uma fila de solicitações de páginas e se assegura que as requisições irão esperar o mínimo tempo até serem atendidas.
Quando o CLIENTE realiza um acesso a uma porção da tabela A o servidor identifica a página que ela deve ser lida/escrita e, caso esta não esteja nos buffers locais, é realizado acesso ao disco. Note-se que o armazenamento das páginas em disco é apenas necessário para manter a propriedade de durabilidade do banco. Uma vez trazida do disco a página passará a residir na memória e só retornará ao disco caso o usuário requisite explicitamente uma sincronização da memória com o disco.
Quando o CLIENTE realiza um acesso a uma porção da tabela B, se as páginas necessárias estiverem nos buffers locais os dados necessários são retornados. Caso contrário será realizada uma solicitação ao CE para que a página necessária seja trazida do host Y, sendo ela adicionada ao buffer pool do host X.
4. Conclusões e trabalhos futuros
Este trabalho tem como proposta o estudo, o projeto e a construção de um banco de dados distribuído em memória, a ser executado sobre clusters de computadores. Como principal contribuição, até o presente momento, cita-se um protótipo do sistema, construído a partir do Berkeley DB, que se encontra em fase de testes.
Apesar de proporcionar controle de concorrência sobre os dados de cada nodo individualmente, o sistema proposto não implementa controle de coerência entre versões de páginas distribuídas entre os nodos. Por exemplo, se dois servidores possuem cópias da mesma página de uma tabela, e um deles atualiza a sua cópia, no outro restará a versão antiga.
Assim sendo, na atual versão do banco de dados distribuído, as inconsistências tem que ser evitadas pelas próprias aplicações. Por exemplo, através da estratégia “múltiplos leitores ou um único escritor”, descrito em Chris [7].
Na continuidade do desenvolvimento do trabalho essas inconsistências serão evitadas através da implementação de uma camada entre o banco e a aplicação. Tal camada deverá utilizar o conceito de transações e será responsável por sincronizar os acessos de acordo com o método descrito em Vaid e Fernando[8].
5. Bibliografia
[1] F. Pedone, R. Guerraoui, and A. Schiper. The database state machine approach. Journal of Distributed and Parallel Databases and Technology, 2002.
[2] Oracle (2006). Berkeley db reference guide. http://www.oracle.com/technology/
documentation/berkeley-db/db/ref/toc.html.
[3] http://www.oracle.com/corporate/
index.html
[4] Li, K. (1986). Shared virtual memory on loosely coupled multiprocessors.
[5] Li, K. and Hudak, P. (1989). Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, www.cs.virginia.edu/zaher/classes/56/li.pdf.
[6] Birrell, A. D. and Nelson, B. J. (1984). Implementing remote procedure calls. ACM Transactions on Computer Systems, 2(1). citeseer. ist.psu.edu/birrell84implementing.
[7] Date C. An introduction to database system. Addison Wesley Longman Publishers. In the 5th edition.
[8] Vaid Zuikeviĕiūtė e Fernando Pedone (2006). Conflict-Aware Load-Balancing Techniques for Database Replication. University of Lugano (USI), Switzerland.