Universidade Federal do ABC Ps-graduao em Tecnologias e Sistemas de Informao

Aurelienne Aparecida Souza Jorge

UM ESTUDO SOBRE A CLUSTERIZAO DE BANCOS DE DADOS COM O POSTGRES-XC

Monografia

So Jos dos Campos SP 2013

Aurelienne Aparecida Souza Jorge

UM ESTUDO SOBRE A CLUSTERIZAO DE BANCOS DE DADOS COM O POSTGRES-XC

Monografia

Dissertao apresentada ao Curso de Ps-graduao da Universidade Federal do ABC, como requisito parcial para obteno do grau de Especialista em Tecnologias e Sistemas de Informao

Orientador: Prof. Dr. Francisco Isidro Massetto

So Jos dos Campos SP 2013

"A verdadeira viagem de descobrimento no consiste em procurar novas paisagens, e sim em ter novos olhos." Marcel Proust

AGRADECIMENTOS

Universidade Federal do ABC e Universidade Aberta do Brasil, pelo oferecimento do curso. Ao meu orientador, Prof. Dr. Francisco Isidro Massetto, e ao tutor Ederson Silva, pelas orientaes e correes. A todos os professores do curso de Tecnologias e Sistemas de Informao, pelos conhecimentos transmitidos. Aos meus pais, por sempre incentivarem meus estudos. Ao meu namorado, Mrcio, por toda a ajuda e apoio, principalmente nos momentos mais difceis durante a realizao deste trabalho. Ao meu irmo, Lener Aurlio, e minha concunhada, Viviane Duarte, por terem fornecido parte dos recursos necessrios para a concluso deste trabalho. A todos que direta ou indiretamente contriburam para a realizao desta monografia.

RESUMO

O uso de estratgias de distribuio de dados, como a fragmentao e a replicao, tem aumentado consideravelmente, especialmente no ambiente corporativo. As motivaes so diversas: alta disponibilidade de dados, distribuio geogrfica, maior eficincia no processamento dos dados, entre outras. Os clusters de bancos de dados esto relacionados nesse contexto, principalmente no que diz respeito a aumentar o poder de processamento dos dados. O Postgres-XC uma ferramenta de cluster totalmente baseada no PostgreSQL, composta por um conjunto de componentes que podem ser instalados em diferentes mquinas (fsicas ou virtualizadas), cujo objetivo fornecer escalabilidade de escrita e leitura de dados. Assim como o PostgreSQL, o Postgres-XC tambm est sob licena livre, que permite sua utilizao, modificao e distribuio sem qualquer encargo financeiro envolvido. A presente monografia tem o objetivo de comparar o desempenho de um cluster Postgres-XC, utilizando as estratgias de fragmentao e replicao, com uma nica instncia de banco de dados PostgreSQL. Para atingir esse objetivo, so demonstrados: a definio e preparao da estrutura computacional necessria, a instalao e configurao do Postgres-XC, o processo de modelagem e criao do banco de dados utilizado para os testes, bem como os scripts utilizados para gerar a carga de dados e calcular a quantidade de transaes por segundo. Ao final, so apresentados os resultados obtidos nos testes realizados e os grficos comparativos de desempenho.

Palavras-chave: Bancos de dados distribudos, Clusters, Fragmentao, Replicao, Postgres-XC.

ABSTRACT

The use of distribution data strategies, as fragmentation and replication, has been increasing considerably, especially in the corporative environment. The motivations are diverse: high availability of data, geographic distribution, more efficiency in data processing, among others. Database clusters are related to this context, mainly with respect to increasing processing power of data. Postgres-XC is a cluster tool totally based on PostgreSQL, composed by a set of components that can be installed in different machines (physical or virtual), whose aim is to provide write and read scalability. As well as PostgreSQL, Postgres-XC is also under a free license, which allows its use, modification and distribution without any financial charges involved. The present monograph has the purpose of comparing the performance of a Postgres-XC cluster, using fragmentation and replication strategies, with a single instance of PostgreSQL database. To achieve this goal, it is demonstrated: the definition and preparation of the computational structure needed, the installation and configuration of Postgres-XC, the processes of modeling and creation of the database used for the tests, as well as the scripts used to generate the data load and to calculate the number of transactions per second. At the end, it is presented the acquired results in the accomplished tests and the performance comparative graphs.

Keywords: Distributed database, Clusters, Fragmentation, Replication, Postgres-XC.

LISTA DE ILUSTRAES

Ilustrao 1 Exemplo de Banco de Dados Distribudo ....................................................... 14 Ilustrao 2 Replicao Mestre/Escravo ............................................................................ 22 Ilustrao 3 Replicao em grupo ...................................................................................... 23 Ilustrao 4 Estrutura proposta para o cluster de banco de dados ....................................... 32 Ilustrao 5 - MER do banco de dados ................................................................................. 35 Ilustrao 6 Criao da Mquina Virtual para o node01..................................................... 36 Ilustrao 7 Configurao do modo de rede na VM ........................................................... 37 Ilustrao 8 Mquina Virtual criada para node01 ............................................................... 37 Ilustrao 9 - Dados replicados no datanode 1...................................................................... 43 Ilustrao 10 - Dados replicados no datanode 2.................................................................... 43 Ilustrao 11 - Dados replicados no datanode 3.................................................................... 44 Ilustrao 12 - Dados distribudos no datanode 1 ................................................................. 44 Ilustrao 13 - Dados distribudos no datanode 2 ................................................................. 45 Ilustrao 14 - Dados distribudos no datanode 3 ................................................................. 45 Ilustrao 15 - Estrutura de testes para o cluster Postgres-XC ............................................... 46 Ilustrao 16 - Estrutura de testes para a instncia do PostgreSQL ....................................... 47 Ilustrao 17 - Exemplo de sada do script de insero de clientes ........................................ 50 Ilustrao 18 - Exemplo de sada do script de consulta de CEPs ........................................... 52 Ilustrao 19 - Grfico comparativo do desempenho de insero entre o Postgres-XC e o PostgreSQL.......................................................................................................................... 57 Ilustrao 20 - Grfico comparativo do desempenho de consulta entre o Postgres-XC e o PostgreSQL.......................................................................................................................... 60 Ilustrao 21 - Escalabilidade do Postgres-XC ..................................................................... 61

LISTA DE TABELAS

Tabela 1 Limites do PostgreSQL ....................................................................................... 28 Tabela 2 - Resultados das inseres no PostgreSQL ............................................................. 54 Tabela 3 - TPS por quantidade de usurios nas inseres do PostgreSQL ............................. 55 Tabela 4 - Resultados das inseres no Postgres-XC ............................................................ 55 Tabela 5 - TPS por quantidade de usurios nas inseres do Postgres-XC ............................ 56 Tabela 6 - Resultados das consultas no PostgreSQL ............................................................. 58 Tabela 7 - TPS por quantidade de usurios nas consultas do PostgreSQL ............................. 58 Tabela 8 - Resultados das consultas no Postgres-XC ............................................................ 59 Tabela 9 - TPS por quantidade de usurios nas consultas do Postgres-XC ............................ 59

LISTA DE SIGLAS

2PC Two-Phase Commit BDD Bancos de Dados Distribudos GTM Global Transaction Manager NAT Network Address Translation RAM Random Access Memory SGBD Sistema Gerenciador de Bancos de Dados SGBDD Sistema Gerenciador de Bancos de Dados Distribudos TPS Transa es Por Segundo VM Virtual Machine

SUMRIO

INTRODUO ........................................................................................................... 12 1.1 1.2 Justificativa............................................................................................................ 12 Objetivos ............................................................................................................... 13

BANCOS DE DADOS DISTRIBUDOS (BDD) ......................................................... 14 2.1 Arquiteturas ........................................................................................................... 15 Cliente-servidor .............................................................................................. 15 Servidor colaborador ...................................................................................... 15 Middleware..................................................................................................... 16

2.1.1 2.1.2 2.1.3 2.2 2.3 2.4

Histria dos BDDs ................................................................................................. 16 Vantagens e Desvantagens ..................................................................................... 17 Protocolos de confiabilidade .................................................................................. 18 Protocolo Two-Phase Commit ........................................................................ 18 Variaes do Two-Phase Commit ................................................................... 19

2.4.1 2.4.2 3

REPLICAO DE DADOS ........................................................................................ 20 3.1 Tipos de Replicao ............................................................................................... 20 Replicao Sncrona ....................................................................................... 20 Replicao Assncrona .................................................................................... 21

3.1.1 3.1.2 3.2

Modelos de Replicao .......................................................................................... 21 Replicao Mestre/Escravo (Master/Slave) ..................................................... 21 Replicao em grupo (Multi Master)............................................................... 22

3.2.1 3.2.2 4

FRAGMENTAO DE DADOS ................................................................................ 24 4.1 4.2 4.3 Fragmentao Horizontal ....................................................................................... 24 Fragmentao Vertical ........................................................................................... 25 Fragmentao Hbrida ............................................................................................ 26

O POSTGRESQL E O POSTGRES-XC....................................................................... 27 5.1 5.2 PostgreSQL ........................................................................................................... 27 Postgres-XC........................................................................................................... 28

METODOLOGIA ........................................................................................................ 31 6.1 Definio do ambiente computacional.................................................................... 32 Cluster Postgres-XC ....................................................................................... 32 Instncia do PostgreSQL ................................................................................ 34 Sistema Operacional ....................................................................................... 34

6.1.1 6.1.2 6.1.3

6.2 7

Definio e modelagem do banco de dados ............................................................ 35

TESTES E DEMONSTRAES ................................................................................. 36 7.1 7.2 Preparao do ambiente computacional .................................................................. 36 Postgres-XC........................................................................................................... 38 Instalao ....................................................................................................... 38 Configurao .................................................................................................. 38 Implantao do cluster ................................................................................... 40

7.2.1 7.2.2 7.2.3 7.3 7.4

Banco de Dados ..................................................................................................... 41 Estrutura para testes ............................................................................................... 46 Postgres-XC ................................................................................................... 46 PostgreSQL .................................................................................................... 47

7.4.1 7.4.2 7.5

Gerao da carga de testes ..................................................................................... 47 Testes de insero de dados ............................................................................ 48 Testes de consulta de dados ............................................................................ 50

7.5.1 7.5.2 8

RESULTADOS OBTIDOS .......................................................................................... 54 8.1 Insero de dados................................................................................................... 54 PostgreSQL .................................................................................................... 54 Postgres-XC ................................................................................................... 55 Comparao ................................................................................................... 56

8.1.1 8.1.2 8.1.3 8.2

Consulta de dados .................................................................................................. 57 PostgreSQL .................................................................................................... 57 Postgres-XC ................................................................................................... 58 Comparao ................................................................................................... 60

8.2.1 8.2.2 8.2.3 8.3 9

Comparao com outros estudos ............................................................................ 60

CONCLUSO ............................................................................................................. 62

REFERNCIAS BIBLIOGRFICAS .................................................................................. 63

12

INTRODUO

Recentemente, tem se tornado cada vez mais comum o uso de Bancos de Dados Distribudos (BDD), que como o prprio nome diz, consistem em dados distribudos por diferentes locais, mas sua distribuio transparente aos usurios finais (SIQUEIRA, 2006). Existem vrios motivos para seu crescimento, dentre os quais podemos citar, conforme sugere Casanova (1999):
Expanso geogrfica das empresas; Necessidade de maior disponibilidade e confiabilidade dos dados, para tomada de decises cada vez mais dinmicas; Evoluo das tecnologias, fazendo com que a comunicao e processamento de dados sejam cada vez mais eficientes e a menor custo.

Os BDDs oferecem muitas vantagens em se tratando das novas exigncias de mercado, mas em contrapartida, existem tambm as desvantagens e complexidades envolvidas em sua implantao. Neste trabalho, sero abordados esses aspectos com maior detalhamento. Independentemente de qual foi a motivao que levou determinada empresa ou organizao a adoo de um Banco de Dados Distribudos, a replicao e a fragmentao so etapas que se fazem necessrias na maior parte dos casos. Dentro deste contexto, esto os clusters de bancos de dados, que fazem uso de tcnicas de distribuio de dados, como a fragmentao e a replicao. O PostgresXC uma soluo de cluster construda sobre o Sistema Gerenciador de Bancos de Dados (SGBD) PostgreSQL, cujo principal objetivo fornecer escalabilidade de escrita e leitura.

1.1

Justificativa

A distribuio de dados pode ser feita de diversas formas, dependendo da necessidade a ser atendida, mas sempre uma tarefa complexa e que requer planejamento. A proposta do presente trabalho avaliar at que ponto vantajoso

13

adotar a distribuio de dados, com todas as suas complexidades, atravs da clusterizao de bancos de dados. 1.2 Objetivos

Esse trabalho tem como foco os principais objetivos: Apresentar os conceitos relacionados ao tema abordado, esclarecendo as motivaes para o uso de bancos de dados distribudos, incluindo a fragmentao e replicao de dados. Implementar um cluster de bancos de dados. Apresentar os testes realizados e analisar as vantagens e desvantagens obtidas comparando-se uma nica instncia de banco de dados PostgreSQL e um cluster Postgres-XC.

14

BANCOS DE DADOS DISTRIBUDOS (BDD)

De acordo com Mesquita (1998), um banco de dados distribudo constitudo de um banco de dados integrado que foi construdo em uma rede de computadores e no somente em um nico computador. Com isso, os dados ficam armazenados em vrios locais dentro da rede, mas para os usurios essa distribuio transparente. A figura abaixo ilustra um exemplo de BDD, em que o banco de dados est distribudo nos computadores A, B e C, cada um em uma localizao fsica diferente, mas todos esto conectados atravs de uma rede de comunicao.

Ilustrao 1 Exemplo de Banco de Dados Distribudo Fonte: Prpria autora

Os BDDs podem ser classificados como heterogneos ou homogneos. Um banco distribudo homogneo se composto por SGBDs semelhantes, ou seja, que possuem interfaces similares e oferecem os mesmos servios. Caso contrrio, o mesmo pode ser considerado heterogneo. Os BDDs heterogneos normalmente surgem quando h a necessidade de integrar sistemas j existentes. (CASA NOVA e MOURA, 1999)

15

Dois aspectos que normalmente precisam ser considerados nesse tipo de estrutura so a replicao e a fragmentao. Ambos sero abordados nos prximos captulos. Dependendo da necessidade a ser atendida, uma dessas duas opes precisa ser adotada na construo de um BDD, ou at mesmo uma combinao das duas.

2.1

Arquiteturas

Ramakrishnam e Gehrke (2008) citam trs tipos de arquitetura para SGBDs distribudos: cliente-servidor, servidor colaborador e middleware, conforme descritas a seguir. 2.1.1 Cliente-servidor Esse tipo de arquitetura composto por processos clientes e processos servidores, em que um processo cliente pode enviar uma consulta para qualquer processo servidor. Os clientes so responsveis pela interface com o usurio e os servidores ficam encarregados pelo gerenciamento dos dados e execuo de transaes. Normalmente o processo cliente fica localizado em um computador pessoal e o processo servidor executado em um computador de grande porte. Sistemas cliente-servidor tornaram-se muito populares por sua simplicidade de

implementao, pois separam claramente a funcionalidade de cada uma das partes. Outra motivao para seu uso que os usurios podem trabalhar atravs de uma interface grfica no cliente, que muito mais intuitiva e fcil de familiarizar-se do que a interface complexa e especfica do servidor. (RAMAKRISHNAM e GERKE, 2008) 2.1.2 Servidor colaborador Segundo Ramakrishnam e Gerke (2008), a arquitetura cliente-servidor descrita acima no oferece a possibilidade de distribuir uma consulta entre vrios servidores. Para que isso fosse possvel, o processo cliente precisaria fragmentar a consulta em subconsultas para que cada uma fosse executada em um servidor distinto, e em seguida, seria necessrio reunir todas as respostas recebidas em uma nica; isso aumentaria muito a complexidade do processo cliente e dificultaria a distino de funcionalidade entre cliente e servidor. No havendo mais essa distino, surge uma nova alternativa de arquitetura: servidor colaborador. Nessa alternativa, existe uma

16

coleo de servidores que executam cooperativamente transaes que abrangem mais de um servidor, fazendo-se a fragmentao da consulta. Porm, deve-se levar em conta o custo da comunicao atravs da rede e os custos do processamento local. 2.1.3 Middleware Essa arquitetura foi projetada para permitir que uma nica consulta seja executa por vrios servidores, assim como o modelo servidor colaborador, porm, no exige que os servidores gerenciem a estratgia de fragmentao da consulta. A idia que exista apenas um servidor de bancos de dados para gerenciar a fragmentao de consultas que abranjam vrios servidores, e os demais manipulam normalmente consultas e transaes locais. Esse servidor especial pode ser considerado como uma camada de software que coordena todo o processo, mas ela mesma no armazena dados; essa camada denominada middleware. (RAMAKRISHNAM e GERKE, 2008)

2.2

Histria dos BDDs

Para entender como surgiram os bancos de dados distribudos e quais as diferenas comparando-se aos bancos de dados centralizados, interessante analisar as mudanas que ocorreram ao longo do tempo no ambiente corporativo. De acordo com Coronel, Morris e Rob (2011), durante a dcada de 70, empresas implementaram sistemas gerenciadores de bancos de dados centralizados para atender suas necessidades de informaes estruturadas, que normalmente eram geradas por linguagens de programao procedural (ou seja, linguagens estruturadas por meio de chamadas de procedimentos) em resposta a pedidos recebidos de forma organizada e selecionada. Sistemas centralizados atendiam bem a esse tipo de necessidade, mas em contrapartida, deixavam a desejar em termos de velocidade de resposta e acesso rpido informao em situaes de mudanas repentinas de cenrio, dificultando a tomada de decises em ambientes dinmicos. Em seguida surgiram os sistemas gerenciadores de bancos de dados baseados no modelo relacional, que poderiam atender em ambientes cuja necessidade de

17

informao no estruturada. Isso era feito atravs de queries ad hoc , ou seja, consultas especficas para cada necessidade, permitindo aos usurios terem acesso aos dados que desejassem a qualquer momento (CORONEL, MORRIS e ROB, 2011). Conforme Coronel, Morris e Rob (2011), nas ltimas duas dcadas surgiram vrias mudanas tecnolgicas e sociais que afetaram diretamente no desenvolvimento e modelagem dos bancos de dados. Dentre elas: as operaes de negcio tornaramse descentralizadas; a competio expandiu para o nvel global; as demandas dos clientes e necessidades de mercado favoreceram o estilo de gerenciamento descentralizado; o rpido crescimento tecnolgico permitiu a criao de

equipamentos com custo mais baixo e maior poder computacional, alm de dispositivos portteis com uma rpida rede de comunicao para conect-los. Esses fatores criaram um ambiente de negcios dinmico em que as empresas tinham que responder rapidamente s presses de mercado e evolues de tecnologia. Com isso, para atender o estilo de gerenciamento descentralizado, tornaram-se necessrios bancos de dados descentralizados com mltiplo acesso e mltipla localizao. Os autores destacam ainda que, nos ltimos anos, a crescente aceitao da Internet como plataforma de distribuio e acesso de dados e a evoluo da rede sem fio favoreceram ainda mais o uso de bancos de dados distribudos.

2.3

Vantagens e Desvantagens

Dentre as principais vantagens em se utilizar bancos de dados distribudos, Coronel, Morris e Rob (2011) citam as seguintes:
Acesso aos dados de forma mais rpida, pois normalmente os usurios trabalham com a parte da base de dados localizada localmente; Processamento de dados mais eficiente, pois a carga de processamento dos dados distribuda por vrios ns do BDD; Facilidade de crescimento, devido possibilidade de acrescentar novos ns estrutura sem prejudicar os que j esto em funcionamento; Melhora nas comunicaes entre membros da companhia e seus clientes, devido localizao de bases de dados locais mais prximas aos clientes;

18

Reduo de custos de operao, pois muito menos custoso adicionar computadores de menor poder computacional do que modificar um servidor central; Maior tolerncia a falhas, pois os dados no ficam localizados em um nico ponto, normalmente esto replicados e/ou fragmentados entre vrios ns da rede.

Todavia, existem tambm algumas desvantagens nesse tipo de estrutura, conforme citam os mesmos autores:
Complexidade de gerenciamento e controle, pois as aplicaes precisam reconhecer a localizao dos dados e serem capazes de juntar dados de vrios ns diferentes; Dificuldade tecnolgica, por ser difcil manter a integridade dos dados, o gerenciamento de transaes, o controle de concorrncia, backup e etc. num contexto de bancos de dados distribudos; Menor segurana, pois quanto mais ns existem na estrutura, maior a probabilidade de falhas de segurana. Alm disso, dados sero compartilhados e manipulados por diferentes pessoas em diferentes localizaes; Necessidade de maior capacidade de armazenamento; mltiplas cpias de dados so necessrias em diferentes locais, por isso necessria maior disponibilidade de espao de armazenamento em disco.

2.4

Protocolos de confiabilidade

Para garantir a atomicidade e durabilidade das transaes executadas sobre bancos de dados distribudos, existem os protocolos de confiabilidade especficos para tal. Esses protocolos controlam a execuo distribuda dos comandos

begin_transaction, read, write, abort, commit e recover. szu e Valduriez (2011) propem a seguinte abstrao para ilustrar o funcionamento desses protocolos: pode-se considerar que no ponto originrio da transao existe um processo coordenador, e nos demais ns em que a transao distribuda existem os processos participantes; dessa forma, os protocolos so implementados entre o coordenador e os participantes. Nesse contexto, um dos principais protocolos o Two-Phase Commit (2PC). Existem tambm algumas variaes do mesmo. 2.4.1 Protocolo Two-Phase Commit De acordo com szu e Valduriez (2011), o 2PC um protocolo muito simples e elegante que garante a atomicidade de efetivao de transaes distribudas. Sua

19

funo controlar se todos os ns envolvidos na execuo da transao concordam em efetiv-la antes de propriamente faz-la. Se a transao no puder ser efetivada por algum n, todas as alteraes feitas nos demais ns envolvidos na transao so desfeitas para manter a consistncia do banco de dados (CORONEL, MORRIS e ROB, 2011). 2.4.2 Variaes do Two-Phase Commit Segundo Mohan e Lindsay (1983, apud szu e Valduriez, 2011, p. 434), foram propostas duas variaes do 2PC: presumed abort e presumed commit. Essas variaes visam melhorar o desempenho do 2PC de duas formas: diminuindo o nmero de mensagens trocadas entre o coordenador e os participantes, e o nmero de vezes em que os logs so escritos.

20

REPLICAO DE DADOS

Segundo Ramakrishnam e Gehrke (2008), a replicao consiste em armazenar vrias cpias de uma relao ou fragmento de uma relao em um ou mais locais distintos. E as principais motivaes para fazer a replicao so:
Maior disponibilidade dos dados, pois se um dos ns fica indisponvel por algum motivo, possvel encontrar uma rplica desses dados em outro n. Maior agilidade nas consultas, pois possvel fazer a consulta em uma rplica local ao invs de ir at a origem dos dados em uma localizao remota. Balanceamento de carga, ao poder distribuir os processamentos de dados entre vrios servidores que contenham as mesmas rplicas.

3.1

Tipos de Replicao

Para cada tipo de necessidade, existe um tipo de replicao mais adequado a ser utilizado. Pode ser implantada uma replicao sncrona, assncrona ou at mesmo uma mescla dos dois tipos. 3.1.1 Replicao Sncrona De acordo com Santos (2011), como o prprio nome diz, esse tipo de replicao feito de forma sncrona, ou seja, os bancos de dados so configurados para serem replicados de forma sincronizada. Assim, quando h qualquer alterao em uma das rplicas, as demais so atualizadas automaticamente em tempo real. Com isso, h a vantagem de se poder fazer um balanceamento de carga nesse tipo de estrutura: as consultas podem ser divididas entre os vrios ns, pois as rplicas esto sempre atualizadas. Por outro lado, essa metodologia no tolerante a falhas, pois se um dos ns fica indisponvel, a replicao para os outros ns comprometida. Com isso, o processo de replicao paralisado e nenhuma transao pode ser efetivada at que todos os ns estejam disponveis novamente e a sincronizao seja restabelecida. Tudo isso para evitar a inconsistncia de dados entre as rplicas. (SANTOS, 2011)

21

3.1.2 Replicao Assncrona J a replicao assncrona, segundo Santos (2011), consiste em fazer a replicao periodicamente, mas no em tempo real. Dessa forma, se uma cpia do banco sofrer atualizaes, as mesmas so replicadas para as demais cpias em algum outro momento, manualmente ou automaticamente conforme freqncia

previamente configurada. Esse um tipo de replicao tolerante a falhas, pois caso haja algum problema na comunicao entre os ns, as alteraes ficam armazenadas para serem replicadas posteriormente quando a conexo for restabelecida. De acordo com o autor h a desvantagem, porm, no fato de que as rplicas esto quase sempre diferentes, e o usurio precisa estar ciente dessa inconsistncia caso faa uso de dados provenientes desse tipo de situao. Caso haja a perda de um banco de dados, por exemplo, a rplica pode at ser utilizada como backup, mas muitos dados podem ter sido perdidos devido ao no sincronismo.

3.2

Modelos de Replicao

Santos (2011) cita dois modelos de replicao de dados: mestre/escravo e em grupo. 3.2.1 Replicao Mestre/Escravo (Master/Slave) Nesse modelo, existe um servidor primrio (mestre) e um secundrio (escravo), e um pode substituir o outro em caso de falha ou eventual manuteno. um modelo de replicao unidirecional, pois os dados sempre so replicados do servidor mestre para o escravo. O servidor escravo fica em estado de standby, recebendo apenas consultas, enquanto as inseres, alteraes e excluses so feitas exclusivamente no servidor mestre. Essas atualizaes so repassadas automaticamente para o servidor secundrio, para que o mesmo mantenha-se sempre atualizado com relao ao servidor primrio. (SANTOS, 2011) De acordo com Santos (2011), a principal vantagem em utilizar esse tipo de modelo ter uma cpia de atualizao constante do banco de dados para poder utiliz-la em

22

caso de falha. Nessa situao o servidor secundrio assume imediatamente a posio do servidor primrio. Outra vantagem a possibilidade de poder dividir a carga de consultas entre os dois servidores, afinal, as duas bases de dados esto sempre sincronizadas. J a desvantagem nesse tipo de modelo o custo maior de processamento envolvido para manter os servidores envolvidos sempre atualizados.

Ilustrao 2 Replicao Mestre/Escravo Fonte: Prpria autora, baseada na definio de Santos (2011)

3.2.2 Replicao em grupo (Multi Master) Segundo Santos (2011), na replicao em grupo, a comunicao ocorre de forma bidirecional. Todos os servidores so mestres e escravos ao mesmo tempo, conforme ilustra a figura a seguir.

23

Ilustrao 3 Replicao em grupo Fonte: Prpria autora baseada na definio de Santos (2011)

Todos os servidores podem sofrer atualizao de dados, e repassam as alteraes para os demais servidores da estrutura, para que todos os bancos de dados fiquem consistentes e garantam a integridade dos dados. O uso desse modelo traz como vantagens: alta disponibilidade de dados, distribuio de carga das transaes entre os servidores, e disponibilizao dos dados em localizaes distintas. Mas pode-se considerar como desvantagem a grande complexidade envolvida para configurar o ambiente de forma a gerenciar as transaes concorrentes e manter a consistncia entre as bases de dados dos diversos servidores. (SANTOS, 2011)

24

FRAGMENTAO DE DADOS

Segundo Coronel, Morris e Rob (2011), a fragmentao de dados consiste na diviso de um nico objeto em dois ou mais fragmentos, podendo o objeto ser um banco de dados ou uma tabela. Cada fragmento pode ser alocado em uma diferente localizao dentro da rede computacional, e as informaes referentes a essa distribuio so armazenadas em um catlogo especfico, que deve ser consultado para processar as requisies dos usurios. Existem diferentes estratgias de fragmentao, que so baseadas em nvel de tabela e consistem na diviso desta em fragmentos lgicos. szu e Valduriez (2011) citam as estratgias de fragmentao horizontal e vertical como sendo as principais. De acordo com os autores h ainda a possibilidade de utilizar uma estratgia hbrida.

4.1

Fragmentao Horizontal

Nesse tipo de estratgia, o particionamento da tabela ocorre de acordo com os registros, de forma que cada fragmento contenha um conjunto de registros nicos da tabela em questo. Entretanto, cada um desses registros contm todas as colunas da tabela. Dessa forma, cada fragmento pode at conter um nmero diferente de registros, mas os atributos devem ser necessariamente os mesmos. Em resumo, cada fragmento seria o equivalente ao resultado de um SELECT com uma clusula WHERE aplicada a um nico atributo. (CORONEL, MORRIS e ROB, 2011) Existem dois tipos de fragmentao horizontal: primria e derivada. A fragmentao horizontal primria consiste em utilizar como parmetros caractersticas da prpria tabela. J a fragmentao horizontal derivada baseia-se nas caractersticas de particionamento de outra tabela, com a qual a tabela em questo tem relacionamento. (SZU e VALDURIEZ, 2011) Segundo Dewitt e Gray (1992, apud Florentino, 2003, p. 11), a fragmentao horizontal primria pode ser aplicada de trs diferentes formas:

25

Fragmentao por faixa de valores - nesse caso a fragmentao baseada em clusulas condicionais (predicados lgicos). Por exemplo, o predicado lgico "idade < 70" sobre a tabela professor indica a fragmentao horizontal desta tabela de acordo com o valor do atributo idade, e sugere a criao de duas parties: uma com os registros referentes aos professores com idade abaixo de 70 anos, e a outra partio com aqueles com idade igual ou superior a 70. Funes de disperso (Funes Hash) - consiste na aplicao de uma funo hash (faz a transformao de uma grande quantidade de dados em uma pequena quantidade de informaes, atravs da gerao de cdigos identificadores nicos para cada dado) sobre o valor de um atributo da tabela a ser fragmentada. Como resultado, a funo indica a que fragmento cada registro deve ser direcionado. Fragmentao circular (Round-Robin) - a diviso dos registros da tabela nos devidos fragmentos feita de forma sequencial e circular conforme os dados vo sendo inseridos. Esta forma de fragmentao muito aplicada em situaes em que se deseje explorar o processamento paralelo.

4.2

Fragmentao Vertical

Na fragmentao vertical, a diviso da tabela feita de acordo com os seus atributos (colunas). Como resultado, cada fragmento contm um conjunto de diferentes colunas, com exceo da coluna chave, que comum para todas as parties. Porm, todos os fragmentos verticais contm sempre o mesmo nmero de registros. (CORONEL, MORRIS e ROB, 2011) O objetivo da fragmentao vertical particionar uma tabela em um conjunto de tabelas menores de forma que as transaes sejam executadas em apenas um dos fragmentos gerados. Como benefcio, se a fragmentao for bem planejada, o tempo de execuo das aplicaes de usurio tende a diminuir consideravelmente. (SZU e VALDURIEZ, 2011)

26

4.3

Fragmentao Hbrida

De acordo com szu e Valduriez (2011), em grande parte dos casos, uma simples fragmentao horizontal ou vertical no suficiente para atender os requisitos das aplicaes de usurio. Nesse tipo de situao pode ser aplicada uma fragmentao horizontal e posteriormente uma fragmentao vertical, ou vice-versa. Esse tipo de estratgia, que utiliza um tipo de fragmentao em seguida de outro, denominada fragmentao hbrida, tambm conhecida como mista.

27

O POSTGRESQL E O POSTGRES-XC

O presente trabalho prope a comparao entre o desempenho do Sistema Gerenciador de Bancos de Dados PostgreSQL e o Sistema Gerenciador de Bancos de Dados Distribudos (SGBDD) Postgres-XC, ambos descritos a seguir.

5.1

PostgreSQL

De acordo com o site do PostgreSQL (POSTGRESQL, 2013), o mesmo um sistema gerenciador de banco de dados de cdigo aberto, com forte reputao de confiabilidade, integridade de dados e conformidade a padres. compatvel com todos os grandes sistemas operacionais, e suporta tambm o armazenamento de objetos binrios, incluindo figuras, sons ou vdeos. Alm disso, possui interfaces nativas de programao para vrias linguagens como C/C++, Java, .Net, Perl, Python, Ruby, entre outras. Ainda segundo o site, para atender necessidades de nvel corporativo, o PostgreSQL tem algumas funcionalidades mais sofisticadas como, por exemplo:
Controle de concorrncia multiversionado (MVCC, em ingls), para suportar ambientes com alto volume de transaes; Recuperao em um ponto no tempo (PITR, em ingls), que permite restaurar um banco de dados a um ponto especfico no passado; Replicao assncrona; Sofisticado Planejador/Otimizador de consultas.

Na pgina do PostgreSQL (POSTGRESQL, 2013), este descrito tambm como customizvel, pois permite a importao de triggers e stored procedures escritas na linguagem C para a biblioteca do banco de dados estendendo suas funcionalidades padro, assim como tambm permite o acesso a funes escritas em outras linguagens como Java e Python atravs de interfaces de biblioteca. Os desenvolvedores podem tambm criar seus prprios tipos de dados customizados atravs de um framework do prprio SGBD. O cdigo fonte do PostgreSQL est disponvel sob uma licena de cdigo fonte aberto que permite usar, modificar e distribuir o mesmo da forma como o usurio quiser. Uma caracterstica importante destacada pelo website do PostgreSQL

(POSTGRESQL, 2013) a alta escalabilidade desse SGBD, pois pode armazenar e

28

gerenciar uma quantidade muito grande de dados, assim como consegue controlar um alto nmero de usurios simultaneamente. Para se ter idia de sua grande capacidade, na tabela a seguir possvel observar alguns limites do PostgreSQL.

Tamanho Mximo do Banco de Dados

Ilimitado

Tamanho Mximo de uma Tabela

32 TB

Tamanho Mximo de uma Linha

1.6 TB

Tamanho Mximo de um Campo

1 GB

Mximo de Linhas por Tabela

Ilimitado

Mximo de Colunas por Tabela

250-1600 dependendo do tipo de coluna

Mximo de ndices por Tabela

Ilimitado

Tabela 1 Limites do PostgreSQL Fonte: POSTGRESQL (2013)

Outro ponto muito favorvel desse SGBD, tambm citado pelo site do PostgreSQL, o grande suporte existente por parte de sua comunidade, que auxilia em seu desenvolvimento e disponibiliza vrios recursos para auxiliar os usurios, entre eles: uma documentao completa e bem detalhada, FAQs, artigos, listas de discusso, sites, blogs, etc. Para concluir, pode-se dizer que o PostgreSQL um SGBD que atende perfeitamente desde sistemas caseiros at grandes sistemas a nvel corporativo.

5.2

Postgres-XC

Segundo Donato (2007), um cluster pode ser definido, na sua forma mais bsica, como um sistema que compreende dois ou mais computadores que trabalham em

29

conjunto para executar determinada tarefa de forma que isso seja transparente aos usurios. Ou seja, um sistema gerenciador de bancos de dados distribudos pode ser considerado um cluster. Segundo a pgina do Posgres-XC no SourceForge (SOURCEFORGE, 2013), este uma soluo de cluster PostgreSQL composta por um conjunto de componentes que podem ser instalados em mais de um servidor fsico ou virtualizado, e que fornece: escalabilidade de escrita (pois suporta uma quantidade de escritas muito maior do que uma nica instncia PostgreSQL), sincronismo simtrico (porque qualquer atualizao feita em uma das instncias de banco imediatamente visualizada nas demais instncias) e transparncia (pois no importa como os dados so armazenados internamente, a viso do banco nica). O Postgres-XC na verdade uma extenso do PostgreSQL e herda a maior parte de suas caractersticas, inclusive a licena, que tambm permite que o Postgres-XC possa ser utilizado, modificado e distribudo, para fins particulares, comerciais ou acadmicos, sem que haja qualquer tipo de cobrana envolvida. Bapat e Douglas (2012) descrevem o Postgres-XC como sendo composto por trs tipos de elementos: Global Transaction Manager (GTM), coordinators

(coordenadores) e datanodes . O GTM basicamente coleta e gerencia informaes sobre transaes no cluster, mas no armazena nenhum dado, apenas informaes de controle. Os coordenadores possuem a funo de receber as requisies dos clientes e retornar os respectivos resultados quando necessrio, pois controlam a localizao dos dados. Os datanodes so os componentes que efetivamente armazenam os dados no banco fazendo a comunicao com os coordenadores. Visando diminuir o trfego de dados entre os ns e o GTM, existe tambm o componente gtm_proxy, que agrupa as conexes antes de fazer a comunicao dos ns com o GTM. O Postgres-XC oferece dois modos para o armazenamento de tabelas nos datanodes, conforme citado por Costa (2012): distribuio ou replicao. O primeiro faz a distribuio das tabelas nos datanodes por meio de estratgias como hash, round-robin, ou particionamento em mdulos. J o segundo faz a replicao das tabelas em um conjunto de datanodes por meio de replicao em nvel de transao,

30

que possui um desempenho muito melhor do que solues baseadas em replicao por logs.

31

METODOLOGIA

Conforme foi citado na introduo, o presente trabalho consiste em implementar um cluster de bancos de dados e analisar as vantagens e desvantagens obtidas comparando-se a um nico banco de dados central. Ser utilizado o Postgres-XC, descrito no captulo anterior, utilizando as estratgias de fragmentao e replicao de dados. Para atingir o objetivo proposto, a metodologia adotada pode ser dividida nas seguintes fases: Reviso bibliogrfica dos temas relacionados ao presente trabalho; Definio do ambiente computacional; Definio e modelagem do banco de dados de testes; Preparao do ambiente computacional; Instalao e configurao do Postgres-XC; Criao do banco de dados no cluster Postgres-XC e na instncia do PostgreSQL, utilizando no cluster as estratgias de fragmentao e replicao; Desenvolver scripts para gerar a carga de dados e calcular a quantidade de transaes por segundo; Realizar testes no cluster com diferentes quantidades de transaes e de usurios simultneos; os testes devem abordar consultas em tabelas replicadas, e inseres em tabelas fragmentadas; os mesmos testes devem ser feitos na instncia do PostgreSQL; Tabular os resultados obtidos e gerar grficos comparativos de desempenho.

A primeira fase foi realizada nos captulos anteriores. A segunda e terceira fases so descritas a seguir. J a execuo das demais fases ser demonstrada nos prximos

32

captulos, que abordam os testes e demonstraes e os resultados obtidos com o trabalho. 6.1 Definio do ambiente computacional

6.1.1 Cluster Postgres-XC Como foi descrito no captulo anterior, o Postgres-XC composto por trs componentes: o GTM, o coordenador e o datanode. De acordo com a documentao online do Postgres-XC (SOURCEFORGE, 2013), aconselhvel executar o GTM em um servidor a parte, para que a carga de transaes seja melhor distribuda. Tambm recomendado instalar um coordenador e um datanode, juntos, em cada servidor. Partindo desse princpio, e considerando que com trs pares de coordenador e datanode j possvel construir um cluster que demonstre algum resultado, sero necessrios quatro servidores para compor toda a estrutura. Para diminuir o trfego de dados na rede, ser instalado o componente gtm_proxy junto com cada um dos datanodes. A Ilustrao 4 mostra o desenho da arquitetura proposta.

Ilustrao 4 Estrutura proposta para o cluster de banco de dados Fonte: Prpria autora

33

O servidor denominado gtm o responsvel por alocar o componente GTM. J os servidores node01, node02 e node03 possuem a funo de abrigar um coordenador e um datanode em cada um deles. Para criar essa estrutura, foi optado por virtualizar esses servidores, por indisponibilidade de hardware para uso exclusivo do cluster. Mesmo fazendo uso da virtualizao, cada mquina virtual (em ingls, Virtual Machine VM) ser criada em uma mquina fsica separada (todas com a mesma configurao de hardware), visando ter um maior poder de processamento e um disco de armazenamento distinto para cada servidor. Para fazer a conexo entre os servidores, todos estaro conectados a uma rede 10/100, teoricamente suficiente para o caso de estudo em questo, pois o trfego de dados no ser maior do que isso. Para criar as VMs, ser utilizado o Virtual Box (VIRTUAL BOX, 2013), por ser uma ferramenta de virtualizao gratuita e compatvel com os principais sistemas operacionais do mercado. Algumas configuraes precisam ser definidas para a criao das mquinas virtuais, como a quantidade de memria Random Access Memory (RAM), o tamanho e o tipo do disco rgido virtual e o modo de rede. Com relao memria RAM, os servidores node01, node02 e node03 sero configurados com 2 GB. Esse valor foi definido basicamente pela disponibilidade das mquinas fsicas na qual foram instaladas as mquinas virtuais. J o gtm, que tem uma carga de trabalho bem menor, ficar com 1 GB de RAM. Quanto aos discos virtuais, sero criados discos do tipo Virtual Box Disk Image (VDI) - formato prprio do Virtual Box para arquivos de imagens de disco - com tamanho fixo de 12 GB (tamanho suficiente para armazenar um banco de dados no muito grande) para os servidores node01, node02 e node03 e 5 GB para o gtm. Este ltimo com tamanho menor por no armazenar os dados do banco efetivamente. No que se refere ao modo de rede, o Virtual Box oferece as seguintes opes de placa de rede de acordo com Madeira (2012): No conectado: simula a retirada do cabo de rede, deixando a VM sem conexo;

34

Network Address Translation (NAT): modo padro de rede do Virtual Box. A VM recebe um IP mascarado que na realidade no faz parte da rede externa, mas a comunicao com a mesma possvel. Porm, na criao de mais de uma mquina virtual, estas no fazem parte da mesma rede e portanto, no podem se comunicar. Modo Bridge: neste modo o sistema convidado recebe um IP vlido na rede externa e consegue realizar a comunicao com a mesma de forma direta. Rede interna: somente as VMs selecionadas podem se comunicar entre elas. Nenhuma mquina da rede externa, nem mesmo a mquina fsica hospedeira pode ter acesso s mesmas. Placa de rede exclusiva de hospedeiro: um misto do modo Bridge e o modo de rede interna. As VMs so visveis entre si e ao hospedeiro, mas o acesso rede externa no habilitado. Driver genrico: raramente usado. Permite que o usurio selecione um driver de rede, mas para tal, deve ser fornecido em um pacote de extenso ou includo no cdigo fonte do Virtual Box para ser recompilado. Neste projeto ser adotado o modo Bridge, por dois motivos principalmente: Permite o acesso rede externa, necessria para baixar e instalar pacotes provenientes da Internet no Linux, e para possibilitar que outras mquinas da rede externa (inclusive o prprio hospedeiro) possam se conectar aos servidores criados; Possibilita que as VMs faam parte de uma mesma rede, essencial para a criao da estrutura proposta. 6.1.2 Instncia do PostgreSQL Para a criao do servidor PostgreSQL tambm ser criada uma mquina virtual, com o propsito de deixar este nas mesmas condies do cluster. As configuraes adotadas so as mesmas de um dos ns do cluster. 6.1.3 Sistema Operacional O sistema operacional a ser utilizado nos servidores, tanto do cluster quanto da instncia nica, ser o Linux Debian na verso 7. A adoo do Linux justificada por

35

ser de uso livre, assim como o Virtual Box, e tambm pelo fato de o Postgres-XC e o PostgreSQL serem compatveis com o mesmo.

6.2

Definio e modelagem do banco de dados

Pensando em um modelo de banco de dados que favorecesse a utilizao da replicao e da fragmentao, foi criado um modelo para armazenar dados de clientes e endereos, conforme ilustrao abaixo.

Ilustrao 5 - MER do banco de dados Fonte: Prpria autora

A proposta replicar todas as tabelas relacionadas a endereo (uf, cidade, bairro e cep), de modo a agilizar as consultas relacionadas a esse tipo de informao, como por exemplo, consultas de endereo por CEP. J a tabela cliente ser fragmentada e distribuda pelos trs ns do cluster, visando melhorar o desempenho de insero de clientes.

36

7 7.1

TESTES E DEMONSTRAES Preparao do ambiente computacional

Para criar cada mquina virtual, o primeiro passo foi indicar um nome, o tipo e a verso do sistema operacional, como pode ser visto na figura a seguir referente criao do servidor node01.

Ilustrao 6 Criao da Mquina Virtual para o node01 Fonte: Prpria autora

Em seguida, foi definida a quantidade de memria RAM, alm do tipo e do tamanho do disco rgido virtual, conforme previamente definidos. O prximo passo foi definir o modo de rede, que tambm j havia sido estabelecido na metodologia. A ilustrao a seguir demonstra a escolha do modo de rede.

37

Ilustrao 7 Configurao do modo de rede na VM Fonte: Prpria autora

A figura abaixo se refere ao servidor node01 depois de finalizada a sua criao e configurao.

Ilustrao 8 Mquina Virtual criada para node01 Fonte: Prpria autora

38

Basicamente o mesmo processo foi feito para a criao e configurao das mquinas virtuais dos demais servidores. Por ltimo, foi feita a instalao do Debian em todos os servidores, sem a opo de interface grfica, e indicando o host de cada servidor.

7.2

Postgres-XC

7.2.1 Instalao Foi encontrado um pacote de instalao do Postgres-XC disponvel em um repositrio do Debian, mas que no veio listado por padro na lista dos endereos de repositrios. Para realizar a sua instalao, foi necessrio adicionar a linha deb http://ftp.de.debian.org/debian sid main ao arquivo sources.list em /etc/apt/, e executar o comando apt-get update para atualizar as fontes. Feito isso, bastou fazer a instalao do pacote atravs do comando apt-get install postgres-xc. Dessa forma, no foi necessrio seguir o procedimento de instalao que consta na documentao do Postgres-XC. Tal procedimento instrui a baixar o cdigo fonte do produto e depois compil-lo manualmente, o que demanda um tempo muito maior para completar a instalao. 7.2.2 Configurao Antes de fazer as configuraes, aconselhvel parar todos os servios, pois a instalao desse pacote j inicia a execuo dos componentes automaticamente. Para parar os servios precisam ser utilizados os seguintes comandos: GTM: gmt_ctl Z gtm D <diretrio> stop Coordenador: pg_ctl Z <nome_coordenador> -D <diretrio> stop Datanode: pg_ctl Z <nome_datanode> -D <diretrio> stop

O diretrio que precisa ser indicado nestes comandos o diretrio de instalao dos componentes, que no caso dessa instalao no diretrio /var/lib/postgres-xc/, acrescido da pasta do componente.

39

preciso tambm definir as portas de acesso de cada componente, a serem indicadas no arquivo de configurao. No caso sero utilizadas as seguintes portas: gtm 6666 gtm_proxy 6666 cn1, cn2 e cn3 5432 dn1, dn2 e dn3 15432

Antes de partir para as configuraes, algumas intervenes so necessrias. Fazendo a instalao como descrita na seo 7.2.1, economiza-se tempo, mas h uma pequena desvantagem: o pacote j faz a configurao do cluster de forma automtica, com um GTM, um coordenador (cn) e dois datanodes (dn1 e dn2) em cada mquina em que feita a instalao, o que no est de acordo com a arquitetura proposta neste trabalho. O coordenador tambm no poder ter a denominao cn nos trs servidores, pois cada coordenador precisa ter um nome nico no cluster. Alm disso, necessrio adicionar o componente gtm_proxy a cada n. Todos os componentes foram ento removidos do diretrio de instalao e recriados. Seguem os comandos utilizados para criar cada um dos componentes: GTM: initgtm Z gtm D <diretrio> gtm_proxy: initgtm Z gtm_proxy D <diretrio> Datanode e Coordinator: pg_ctl -D <diretrio> --nodename=<nome>

Algumas alteraes devem ser feitas no arquivo de configurao de cada um dos componentes. Seguem as alteraes realizadas para cada tipo de componente: GTM (arquivo gtm.conf): listen_addresses = * port = 6666

40

Gtm_proxy (arquivo gtm_proxy.conf): gtm_host = gtm gtm_port = 6666 Coordenador (arquivo postgresql.conf): listen_addresses = * port = 5432 gtm_host = localhost gtm_port = 6666 Datanode (arquivo postgresql.conf): listen_addresses = * port = 15432 gtm_host = localhost gtm_port = 6666

Assim como na instalao do PostgreSQL, o arquivo de configurao de segurana, (pg_hba.conf) tambm precisa ser modificado em cada um dos servidores para incluir os IPs que devem ter o acesso liberado nos mesmos. 7.2.3 Implantao do cluster Depois de finalizada a fase de configurao, para colocar o cluster em funcionamento efetivamente preciso iniciar os servios dos componentes. Para fazer isso, os comandos utilizados so os mesmos que foram descritos anteriormente para parar os servios. Basta trocar o stop por start. No caso do gtm_proxy, utilizado o comando gtm_ctl trocando-se o tipo do componente de gtm para gtm_proxy. Em seguida, necessrio fazer com que cada um dos coordenadores tenha conhecimento da existncia dos outros coordenadores e dos datanodes . Para isso, preciso criar esses componentes no banco de cada um dos coordenadores da seguinte forma: Acessar o console psql (mesmo do PostgreSQL) informando o host, a porta e o nome do banco, que deve ser o postgres (banco padro criado na instalao);

41

Criar os ns atravs dos comandos (o exemplo abaixo seria para o coordenador cn1): CREATE NODE cn2 WITH (TYPE = 'coordinator', HOST = 'node02', PORT = 5432); CREATE NODE cn3 WITH (TYPE = 'coordinator', HOST = 'node03', PORT = 5432); CREATE NODE dn1 WITH (TYPE = 'datanode', HOST = 'node01', PORT = 15432); CREATE NODE dn2 WITH (TYPE = 'datanode', HOST = 'node02', PORT = 15432); CREATE NODE dn3 WITH (TYPE = 'datanode', HOST = 'node03', PORT = 15432);

Por fim, basta executar o comando SELECT pgxc_pool_reload(); para recarregar as informaes de conexo dos ns, e o cluster j est pronto para receber conexes e executar transaes.

7.3

Banco de Dados

Para a criao do modelo de banco de dados proposto na seo 6.2 no servidor do PostgreSQL, nenhuma alterao necessria. J no Postgres-XC preciso definir a estratgia de distribuio de dados na criao de cada tabela. Conforme definido na metodologia, as tabelas uf, cidade, bairro e cep sero replicadas a todos os ns, e a tabela cliente ser fragmentada e distribuda tambm a todos os ns. A funo de fragmentao utilizada a hash, aplicada sobre o campo id_cliente. Abaixo esto descritos como ficaram os comandos de criao de cada tabela. CREATE TABLE bairro ( id_bairro integer NOT NULL, bairro character varying(72), abrev_bairro character varying(36), id_cidade integer ) distribute by replication to node dn1,dn2,dn3;

42

CREATE TABLE cep ( id_cep integer NOT NULL, logradouro character varying(125), id_bairro integer, cep character varying(8) ) distribute by replication to node dn1,dn2,dn3; CREATE TABLE cidade ( id_cidade integer NOT NULL, cidade character varying(50), cep character varying(8), uf character(2), tipo_localidade character(1), cod_ibge character varying(15) ) distribute by replication to node dn1,dn2,dn3; CREATE TABLE uf ( codigo character(2) NOT NULL, descricao character varying(72), regiao_pais character varying(20) ) distribute by replication to node dn1,dn2,dn3; CREATE TABLE cliente ( id_cliente integer NOT NULL, nome character varying(60), id_cep integer, numero integer, complemento character varying(20), telefone character varying(15), email character varying(60) ) distribute by hash(id_cliente) to node dn1,dn2,dn3;

Aps a criao das tabelas, foi feita uma carga inicial de dados em todas as tabelas, exceto a tabela cliente, para utilizao nos testes. As ilustraes 9, 10 e 11 demonstram que realmente foi feita a replicao dos registros da tabela uf, como exemplo. O comando 'execute direct on <nodename>' que aparece nas imagens faz a execuo da SQL diretamente no n desejado.

43

Ilustrao 9 - Dados replicados no datanode 1 Fonte: Prpria autora

Ilustrao 10 - Dados replicados no datanode 2 Fonte: Prpria autora

44

Ilustrao 11 - Dados replicados no datanode 3 Fonte: Prpria autora

Apenas para demonstrar a fragmentao, foram inseridos alguns registros de clientes. Como pode ser visualizado nas ilustraes a seguir, a funo hash fez a alocao de dois clientes no segundo n e um cliente no terceiro n.

Ilustrao 12 - Dados distribudos no datanode 1 Fonte: Prpria autora

45

Ilustrao 13 - Dados distribudos no datanode 2 Fonte: Prpria autora

Ilustrao 14 - Dados distribudos no datanode 3 Fonte: Prpria autora

46

7.4

Estrutura para testes

7.4.1 Postgres-XC Para realizar os testes no cluster Postgres-XC, foram adicionados mais dois servidores na estrutura, conforme demonstra a ilustrao a seguir.

Ilustrao 15 - Estrutura de testes para o cluster Postgres-XC Fonte: Prpria autora

O servidor denominado loader responsvel por gerar a carga de dados (consultas e inseres) para os testes. J o balancer tem a funo de balancear a carga de transaes recebidas pelo loader entre os coordenadores do cluster. Ambos servidores foram criados da mesma forma que os demais de forma virtualizada, com o sistema operacional Debian instalado e foram adicionados rede do cluster. Para fazer o balanceamento de carga, foi utilizado o balance da Inlab Software GmbH, que uma soluo de cdigo fonte aberto para balanceamento de carga

47

atravs de um proxy tcp genrico com mecanismos de failover e balanceamento do tipo round robin. (INLAB, 2013) Basicamente, o balance apenas redireciona as conexes recebidas na porta 5432 para os coordenadores do cluster de forma balanceada. 7.4.2 PostgreSQL A estrutura de testes referente instncia do PostgreSQL bem mais simplificada, sendo composta apenas pelo loader e pelo prprio servidor de banco de dados, conforme ilustrao abaixo.

Ilustrao 16 - Estrutura de testes para a instncia do PostgreSQL Fonte: Prpria autora

7.5

Gerao da carga de testes

Para gerar a carga de transaes para os testes, foi criado um script na linguagem python, que faz a conexo com o banco de dados atravs da biblioteca psycopg2 (PSYCOPG, 2013), especfica para o PostgreSQL. Como o Postgres-XC foi desenvolvido sobre o prprio PostgreSQL, esta biblioteca tambm pode ser utilizada para fazer a conexo com o cluster. E para simular vrios usurios efetuando transaes simultaneamente na estrutura, foi utilizado o mdulo parallel python, que fornece mecanismos de execuo paralela de cdigos python em sistemas com multiprocessamento simtrico ou clusters (PARALLEL PYTHON, 2013)

48

Os scripts, tanto o de insero quanto o de consulta, recebem dois parmetros por argumento: a quantidade de usurios simultneos e a quantidade de transaes por usurio. A quantidade de usurios a quantidade de processos paralelos que sero disparados, e a quantidade de transaes a quantidade de vezes que o comando de insero ou de consulta ser executado a cada processo. Ao final da execuo calculada a quantidade de transaes por segundo (TPS), de acordo com a durao total do teste e da quantidade total de transaes realizadas. No h diferena nos scripts executados no teste do Postgres-XC e no teste do PostgreSQL, exatamente os mesmos scripts so utilizados. A nica alterao necessria no host e no usurio definidos dentro do script. Enquanto no teste do Postgres-XC a conexo feita no balancer, no teste do PostgreSQL a conexo feita diretamente no prprio. Quanto ao usurio, cada estrutura possui um login especfico para realizar a conexo com o banco de dados. 7.5.1 Testes de insero de dados O script de insero de dados simula a insero de novos clientes no banco de dados. Para isso selecionado um CEP aleatoriamente dentre os que esto cadastrados na tabela para poder relacionar ao cadastro do cliente. Como apenas um teste, os demais atributos foram fixados. Segue abaixo o cdigo em python para realizar o teste de insero. #------------------------------------------------------# # Script...: insere_cliente.py # Autora...: Aurelienne Jorge # Data.....: 28/08/2013 # Descricao: Script para simular a insercao de clientes # por varios usuarios simultaneamente. # Recebe como argumentos: # 1) quantidade de usuarios simultaneos # 2) quantidade de transacoes por usuario #------------------------------------------------------# import pp import sys from datetime import datetime def insert(t): #Bibliotecas import psycopg2 import random

49

#Variaveis dbname = 'tcc' username = "postgres-xc" host = '192.168.0.130' #host do load balancer port = '5432' #Conexao com o banco conn = psycopg2.connect('dbname='+dbname+' user='+username+' host='+host+' port='+port) cur = conn.cursor() for i in range(0,t): id_cep = random.randint(1,653252) cur.execute("insert into cliente (nome,id_cep,numero,complemento,telefone,email) values('Fulano da Silva',%s,9999,'complemento','(99)9999-9999', 'cliente@email.com.br')", (id_cep,)) conn.commit() conn.close() print "\n********************" print "INSERCAO DE CLIENTES" print "********************\n" print ">> Argumentos:" users = int(sys.argv[1]) print " - Usuarios = "+str(users) t = int(sys.argv[2]) print " - Transacoes por usuario = "+str(t) print "\n>> Processamento:" inicio = datetime.now() print " - Inicio = "+str(inicio) job_server = pp.Server(secret='cluster123') for f in range(0,users): p = job_server.submit(insert,(t,)) p() fim = datetime.now() print " - Fim = "+str(fim) #Calcula duracao duracao = (fim - inicio).seconds if duracao == 0: duracao = 1 print " - Duracao = "+str(duracao)+' segundo(s)' #Calcula Transacoes por Segundo tps = (users*t)/duracao

50

print " -----------------" print " > TPS = "+str(tps) print " -----------------\n"

A ilustrao abaixo demonstra um teste de insero realizado no cluster com seis usurios simultneos, cada um executando dez mil transaes.

Ilustrao 17 - Exemplo de sada do script de insero de clientes Fonte: Prpria autora

No prximo captulo so demonstrados todos os resultados obtidos nos testes de insero nos dois ambientes.

7.5.2 Testes de consulta de dados O script de consulta de dados simula a consulta de endereos por CEP no banco de dados. Para isso selecionado um CEP aleatoriamente dentre os que esto cadastrados na tabela para poder consultar o endereo relacionado (uf, cidade, bairro, etc.). Segue o cdigo em python para realizar o teste de consulta. #------------------------------------------------------# # Script...: consulta_cep.py

51

# Autora...: Aurelienne Jorge # Data.....: 28/08/2013 # Descricao: Script para simular a consulta de CEPs # por varios usuarios simultaneamente. # Recebe como argumentos: # 1) quantidade de usuarios simultaneos # 2) quantidade de transacoes por usuario #------------------------------------------------------# import pp import sys from datetime import datetime def consulta(t): #Bibliotecas import psycopg2 import random #Variaveis dbname = 'tcc' username = "postgres" host = '192.168.0.130' #host do load balancer port = '5432' #Conexao com o banco conn = psycopg2.connect('dbname='+dbname+' user='+username+' host='+host+' port='+port) cur = conn.cursor() for i in range(0,t): id_cep = random.randint(1,653252) cur.execute("select cep.logradouro, b.bairro, c.cidade, c.uf, uf.regiao_pais from cep inner join bairro as b on cep.id_bairro = b.id_bairro inner join cidade c on c.id_cidade = b.id_cidade inner join uf on uf.codigo = c.uf where cep.id_cep = %s",(id_cep,)) conn.close() cur.close() print "\n********************" print "CONSULTA DE CEPs" print "********************\n" print ">> Argumentos:" users = int(sys.argv[1]) print " - Usuarios = "+str(users) t = int(sys.argv[2]) print " - Transacoes por usuario = "+str(t) print "\n>> Processamento:" inicio = datetime.now() print " - Inicio = "+str(inicio)

52

job_server = pp.Server(secret='cluster123') for f in range(0,users): p = job_server.submit(consulta,(t,)) p() fim = datetime.now() print " - Fim = "+str(fim) #Calcula duracao duracao = (fim - inicio).seconds if duracao == 0: duracao = 1 print " - Duracao = "+str(duracao)+' segundo(s)' #Calcula Transacoes por Segundo tps = (users*t)/duracao print " -----------------" print " > TPS = "+str(tps) print " -----------------\n"

A ilustrao abaixo demonstra um teste de consulta realizado no cluster com seis usurios simultneos, cada um executando dez mil transaes.

Ilustrao 18 - Exemplo de sada do script de consulta de CEPs Fonte: Prpria autora

53

No prximo captulo so demonstrados todos os resultados obtidos nos testes de consulta nos dois ambientes.

54

8 8.1

RESULTADOS OBTIDOS Insero de dados

8.1.1 PostgreSQL O script de insero foi executado para diferentes quantidades de usurios simultneos e de transaes. Na tabela abaixo esto tabulados os resultados obtidos, demonstrando a quantidade de TPS resultante de cada situao.
Usurios Simultneos 1 1 1 1 2 2 2 2 3 3 3 3 Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000 Usurios Simultneos 4 4 4 4 5 5 5 5 6 6 6 6 Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 1000 3000 2500 2500 2000 3000 2500 2222 1500 2250 2500 2307

TPS 2000 2400 2222 2222 2500 2142 2272 2173 2000 2250 2142 2068

Tabela 2 - Resultados das inseres no PostgreSQL Fonte: Prpria autora

Calculando a mdia de TPS de acordo com a quantidade de usurios, observa-se que o PostgreSQL ficou na mdia de 2 mil transaes por segundo, sem grandes variaes, como demonstra a Tabela 3.

55

Usurios Simultneos 1 2 3 4 5 6

Mdia TPS 1750 2111 1903,5 2111 2336,5 2034

Tabela 3 - TPS por quantidade de usurios nas inseres do PostgreSQL Fonte: Prpria autora

8.1.2 Postgres-XC Os testes no Postgres-XC seguiram os mesmos parmetros de execuo do PostgreSQL. Na tabela abaixo esto tabulados os resultados obtidos, demonstrando a quantidade de TPS resultante de cada situao.
Usurios Simultneos 1 1 1 1 2 2 2 2 3 3 3 3 Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000 Usurios Simultneos 4 4 4 4 5 5 5 5 6 6 6 6 Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 500 750 714 769 1000 1200 1250 1250 1500 1800 1875 1764

TPS 1000 1500 1538 1600 1250 1666 1562 1666 1500 2000 1875 1875

Tabela 4 - Resultados das inseres no Postgres-XC Fonte: Prpria autora

Calculando a mdia de TPS de acordo com a quantidade de usurios, como pode ser observado na Tabela 5, observa-se que o Postgres-XC teve um melhor desempenho a partir de trs usurios simultneos. Isso porque a escalabilidade de

56

escrita est justamente no fato de distribuir a carga de inseres em todos os ns do cluster.

Usurios Simultneos 1 2 3 4 5 6

Mdia TPS 634,5 1125 1632 1300 1458 1687,5

Tabela 5 - TPS por quantidade de usurios nas inseres do Postgres-XC Fonte: Prpria autora

8.1.3 Comparao Comparando-se o desempenho das duas estruturas na Ilustrao 19, observa-se que o PostgreSQL foi ainda superior ao Postgres-XC com relao insero de dados. Porm, pode-se verificar tambm que o PostgreSQL ficou praticamente estvel independentemente da situao fornecida. O Postgres-XC teve um resultado muito baixo quando teve apenas um usurio conectado, o que poder ser justificado pela maior complexidade de sua estrutura, incluindo o grande trfego de dados necessrio para a comunicao dos ns, especialmente na fragmentao dos dados; mas quando teve uma quantidade de processos paralelos maior em que pde fazer uso de todo o seu poder de processamento, o mesmo mostrou uma escalabilidade de escrita considervel conforme a distribuio da carga de transaes. Aparentemente, a probabilidade de que o Postgres-XC poderia ultrapassar o PostgreSQL na insero de dados se contasse com mais ns em sua estrutura.

57

Ilustrao 19 - Grfico comparativo do desempenho de insero entre o Postgres-XC e o PostgreSQL Fonte: Prpria autora

8.2

Consulta de dados

8.2.1 PostgreSQL Assim como nos testes de insero, o script de consulta foi executado para diferentes quantidades de usurios simultneos e de transaes. Na Tabela 6 esto tabulados os resultados obtidos, demonstrando a quantidade de TPS resultante de cada situao.

58

Usurios Simultneos 1 1 1 1 2 2 2 2 3 3 3 3

Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 833 882

Usurios Simultneos 4 4 4 4 5 5 5 5 6 6 6 6

Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 1000 1000 952 1000 1000 1000 1000 943 1000 1000 967 1000

Tabela 6 - Resultados das consultas no PostgreSQL Fonte: Prpria autora

Calculando a mdia de TPS de acordo com a quantidade de usurios, observa-se que o PostgreSQL ficou na mdia de mil transaes por segundo, sem grandes variaes, de acordo com a tabela abaixo.
Usurios Simultneos 1 2 3 4 5 6

Mdia TPS 1000 1000 941 1000 971,5 1000

Tabela 7 - TPS por quantidade de usurios nas consultas do PostgreSQL Fonte: Prpria autora

8.2.2 Postgres-XC Os testes no Postgres-XC seguiram os mesmos parmetros de execuo do PostgreSQL. Na tabela a seguir esto tabulados os resultados obtidos,

demonstrando a quantidade de TPS resultante de cada situao.

59

Usurios Simultneos 1 1 1 1 2 2 2 2 3 3 3 3

Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 500 600 555 526 666 857 833 869 1000 1285 1363 1200

Usurios Simultneos 4 4 4 4 5 5 5 5 6 6 6 6

Transaes por usurio 1000 3000 5000 10000 1000 3000 5000 10000 1000 3000 5000 10000

TPS 1000 1200 1176 1111 1000 1250 1250 1162 1200 1285 1363 1176

Tabela 8 - Resultados das consultas no Postgres-XC Fonte: Prpria autora

Assim como foi verificado nos testes de insero, calculando a mdia de TPS de acordo com a quantidade de usurios, observa-se que o Postgres-XC teve um melhor desempenho a partir de trs usurios simultneos. Isso porque a escalabilidade de leitura est justamente no fato de distribuir a carga de inseres em todos os ns do cluster.
Usurios Simultneos 1 2 3 4 5 6

Mdia TPS 513 767,5 1100 1055,5 1081 1188

Tabela 9 - TPS por quantidade de usurios nas consultas do Postgres-XC Fonte: Prpria autora

60

8.2.3 Comparao Comparando-se o desempenho das duas estruturas na Ilustrao 20, observa-se que o Postgres-XC foi razoavelmente superior ao Postgres-XC com relao consulta de dados. Assim como foi visto na insero, na consulta o Postgres-XC tambm obteve um melhor desempenho quando teve uma quantidade de processos paralelos maior, no qual pde fazer uso de todo o seu poder de processamento, mostrando uma escalabilidade de leitura considervel conforme a distribuio da carga de transaes. Aparentemente, a probabilidade de que o Postgres-XC poderia ter um desempenho ainda melhor se contasse com mais ns em sua estrutura.

Ilustrao 20 - Grfico comparativo do desempenho de consulta entre o Postgres-XC e o PostgreSQL Fonte: Prpria autora

8.3

Comparao com outros estudos

De acordo com Bapat e Douglas (2012), testes realizados com o benchmark DBT-1 mostraram resultados significantes de escalabilidade, como pode ser visto no grfico da Ilustrao 21. O fator de escalabilidade representado no eixo vertical do grfico

61

a razo entre o nmero de transaes completadas em um determinado intervalo de tempo pelo Postgres-XC com relao ao que foi realizado pelo PostgreSQL. Podese observar que a partir de dois servidores, cada um composto por um par de coordenador e datanode, j houve um ganho de performance comparando-se ao PostgreSQL. Um resultado diferente do obtido no presente trabalho, mas que pode ser justificado devido s diferenas na estrutura do ambiente e no formato dos testes realizados. Provavelmente foi utilizada uma rede de alta velocidade para fazer a conexo dos ns do cluster, o que no pode ser realizado neste estudo por indisponibilidade de recursos. Outra diferena o tipo de benchmark realizado, pois o DBT-1 realiza transaes de diversos tipos (insert, update, select) em um mesmo teste, enquanto aqui foram realizados testes especficos de insero e consulta para avaliar as estratgias de fragmentao e replicao isoladamente. Mesmo com as diferenas de performance, ambos os estudos mostram que possvel obter escalabilidade no Postgres-XC. O presente trabalho demonstra a escalabilidade de acordo com a distribuio de carga pelos ns, e o grfico abaixo ilustra a escalabilidade conforme so aumentados os ns na estrutura do cluster.

Ilustrao 21 - Escalabilidade do Postgres-XC Fonte: BAPAT e DOUGLAS (2012)

62

CONCLUSO

Foi implementado um cluster de bancos de dados, utilizando a ferramenta PostgresXC, visando comparar as vantagens obtidas ao utilizar estratgias de distribuio de dados, como a fragmentao e a replicao, em relao a um banco de dados normal, no caso o PostgreSQL com uma nica instncia. Aps aplicar a tcnica de fragmentao em uma das tabelas do cluster e realizar testes de insero na mesma, foi verificado que o Postgres-XC teve um desempenho um pouco inferior ao PostgreSQL. Porm, com mais ns adicionados ao cluster, provavelmente o Postgres-XC ultrapassaria o PostgreSQL, pois teria uma capacidade maior de distribuio da carga de transaes. J com a aplicao da estratgia de replicao nas demais tabelas do cluster, os testes de consulta de dados demonstraram que o Postgres-XC chegou a ser mais eficiente que o PostgreSQL. E assim como no caso da insero, com mais ns, possivelmente haveria um desempenho ainda melhor. Observando-se que o ganho de performance do Postgres-XC resultado da distribuio de transaes concorrentes, possvel dizer que somente h vantagem em utiliz-lo se o banco de dados em questo realmente tiver uma grande carga de transaes simultneas, o que justificaria a necessidade dessa escalabilidade.

63

REFERNCIAS BIBLIOGRFICAS

BAPAT, Ashutosh; DOUGLAS, Susan. 2012. Postgres-XC: A PostgreSQL Clustering Solution. Disponvel em: <http://www.linuxforu.com/2012/01/postgres-xcdatabase-clustering-solution/>. Acesso em: 03 julho 2013. CASANOVA, Marco A.; MOURA, Arnaldo V. 1999. Princpios de Sistemas de Gerncia de Bancos de Dados Distribudos. Disponvel em: <http://www.inf.pucrio.br/~casanova/Publications/Books/1985-BDD.pdf>. Acesso em: 10 abril 2013. CORONEL, Carlos; MORRIS, Steven; ROB, Peter. Database Systems. 9. Ed. Boston: Cengage Learning, 2011. 692 p. COSTA, Marcelo. Postgres-XC: Uma soluo de cluster para o Postgres-XC. InfoQ. Disponvel em: < http://www.infoq.com/br/news/2012/11/postgres-xc-cluster >. Acesso em: 03 julho 2013. DONATO, Rafael. Gerenciando um cluster PostgreSQL com PGCluster. SQL Magazine, v. 4, n. 41, 2007. p. 46-51. Disponvel em: <http://www.devmedia.com.br/revista-sql-magazine-edicao-41/6998>. Acesso em: 20 abril 2013. FLORENTINO, P. V. ODARA: Metodologia para Projeto de Fragmentao de Bases de Dados. 2003. 108 f. Dissertao (Mestrado em Engenharia de Sistemas e Computao) Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2003. INLAB. Balance. Disponvel em: <http://www.inlab.de/balance.html>. Acesso em: 10 agosto 2013. MADEIRA, Daniel. 2012. Modos de Rede no Virtual Box. Disponvel em: <http://dan-scientia.blogspot.com.br/2012/03/modos-de-rede-no-virtualbox.html>. Acesso em: 02 julho 2013. MESQUITA, E. J. S. Projeto de Dados em Bancos de Dados Distribudos. 1998. 87 f. Dissertao (Mestrado em Matemtica Aplicada) Instituto de Matemtica e Estatstica, Universidade de So Paulo, So Paulo, 1998. ZSU, M. T.; VALDURIEZ, P. Principles of Distributed Database Systems. 3. ed. Nova Iorque: Springer, 2011. 845 p. PARALLEL PYTHON. Parallel Python Software. Disponvel em: <http://www.parallelpython.com/>. Acesso em: 15 agosto 2013. POSTGRESQL. Sobre. Disponvel em: <http://www.postgresql.org.br/sobre/>. Acesso em: 5 maio 2013. PSYCOPG. Psycopg. Disponvel em: <http://initd.org/psycopg/>. Acesso em: 30 agosto 2013.

64

RAMAKRISHNAM, Raghu; GEHRKE, Johannes. Sistemas de Gerenciamento de Banco de Dados. 3. Ed. McGraw-Hill: So Paulo, 2008. 912 p. SANTOS, Paulo H. dos. Trabalhando com replicao de dados. SQL Magazine, v.8, n. 95, 2011. p. 65-76. Disponvel em: <http://www.devmedia.com.br/revista-sqlmagazine-95/23323>. Acesso em: 13 abril 2013. SIQUEIRA, Frank. [2006]. Banco de dados distribudos. Disponvel em: <http://www.inf.ufsc.br/~frank /BDD/BDDIntro.pdf>. Acesso em: 11 novembro 2012. SOURCEFORGE. Postgres-XC 1.0.3 Documentation. Disponvel em: <http://postgres-xc.sourceforge.net/docs/1_0_3/>. Acesso em: 15 maio 2013. VIRTUAL BOX. About Virtual Box. Disponvel em: <https://www.virtualbox.org/>. Acesso em: 11 junho 2013.