CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

Transcrição

1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA COM ÊNFASE EM BANCO DE DADOS ANDERSON PEREIRA GUEDES ELIEL LIMA DE OLIVEIRA AVALIAÇÃO DE DESEMPENHO DE SELEÇÃO DE DADOS EM BANCO DE DADOS DISTRIBUÍDO LINS/SP 1º SEMESTRE/2012

2 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA COM ÊNFASE EM BANCO DE DADOS ANDERSON PEREIRA GUEDES ELIEL LIMA DE OLIVEIRA AVALIAÇÃO DE DESEMPENHO DE SELEÇÃO DE DADOS EM BANCO DE DADOS DISTRIBUÍDO Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins Prof. Antonio Seabra, como parte dos requisitos necessários para obtenção do Título de Tecnólogo em Banco de Dados sob orientação do Prof. Me. Mário Henrique de Souza Pardo. LINS/SP 1º SEMESTRE/2012

3 ELIEL LIMA DE OLIVEIRA ANDERSON PEREIRA GUEDES AVALIAÇÃO DE DESEMPENHO DE SELEÇÃO DE DADOS EM BANCO DE DADOS DISTRIBUÍDO Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins Prof. Antonio Seabra, como parte dos requisitos necessários para obtenção do Título de Tecnólogo em Banco de Dados sob orientação do Prof. Me. Mário Henrique de Souza Pardo. Data de Aprovação: 25 de junho de 2012 Orientador: Prof. Me. Mário Henrique de Souza Prof. Me. Luiz Fernando de Oliveira Silva Prof. Me. João Luiz Cardoso de Moraes

4 Dedico este Trabalho de Conclusão de Curso a os meus pais, Arlindo Guedes e Valdira Guedes, aos meus avós, irmãos e a minha belíssima namorada Daniele Pavoni que foram pessoas mais do que especiais nos mementos de dificuldades. Vocês são a minha inspiração.

5 Dedico este trabalho a Deus, a minha querida esposa Daiane e aos meus pais, que grandiosamente apoiaram-me para que eu pudesse concluir essa pesquisa. Vocês são o espelho e a base para minha vida.

6 AGRADECIMENTOS Agradeço primeiramente a Deus, por ser quem me capacita e me dá inspiração do Espírito Santo, e que é o único quem presenciou minuciosamente cada fase para que este trabalho se concretizasse. Agradeço a minha família que são os pilares e a motivação para minhas conquistas. E a minha namorada que em muitos momentos de dificuldades soube me compreender e motivar até que esse trabalho se concretizasse. E deixo os agradecimentos em especial ao Eliel Oliveira, que sem medir esforços aceitou desenvolver este projeto e que nos momentos de desânimo foi quem fez com que esse projeto realmente se concretizasse. Aos amigos professores, funcionários e a todos que de alguma forma contribuíram para o meu salto qualitativo do saber, meus sinceros agradecimentos a todos.

7 AGRADECIMENTOS Agradeço a Deus por me ajudar, em todos os momentos de dificuldade que encontrei, sobre tudo, enviando-me seu Espírito, a quem também sou grato, pelas palavras que sei não são minhas, mas inspiradas por Ele. Ao meu compreensível e paciente orientador, que da motivação para pesquisa, bibliografia, até a implementação, foi fundamental para que esse trabalho se concluísse, a quem posso me referir como amigo e não apenas como orientador. Aos professores que em todos esses anos me proveram o saber e amizade, valores que eu considero mais preciosos que qualquer bem. A você Anderson Guedes, que aceitou encarar essa dura jornada comigo. A todos os amigos da Fatec de Lins, funcionários e tantos outros personagens dessa história, que me apoiaram direta e indiretamente nesse projeto.

8 RESUMO O presente estudo visa avaliar o desempenho de seleção de dados em Banco de Dados Distribuído, com foco na determinação de fatores influentes em um ambiente com uma estrutura interna baseada em transparência e replicação. Os resultados obtidos permitem a observação do comportamento de um Banco de Dados Distribuído sobre um ambiente experimental virtualizado, quando submetido a um grande número de requisições de consulta, envolvendo diferentes composições em vários hosts, através de metodologias de estruturação interna utilizando visões materializadas e sinônimos. Palavras chave: Banco de Dados Distribuído. Avaliação de Desempenho. Carga Sintética. Requisições de Seleção de Dados. Visões Materializadas e Sinônimos.

9 ABSTRACT The present study evaluates the performance data selection in Distributed Database, focusing on the determination of influencing factors in an environment with an internal structure based on transparency and replication. The results obtained allow the observation of the behavior of a Distributed Database on a virtualized laboratory environment, when subjected to a large number of requests consultation involving different compositions in different hosts, through internal structuring methodologies using materialized view and synonyms. Keywords: Distributed Database. Performance Evaluation. Synthetic Load. Requests for Data Selection. Materialized Views and Synonyms.

10 LISTA DE ILUSTRAÇÕES Figura 1.1-Exemplo de cluster Figura 1.2-Arquitetura em camadas para sistemas de computação em grade Figura 1.3-Fluxo e tempo de espera na visão cliente-servidor Figura 1.4-Possibilidades de configuração cliente-servidor (a)--(e) Figura 2.1-Arquitetura física de sistema de banco de dados paralelos Figura 2.2-Aumento de velocidade e aumento de escala Figura 2.3-Fragmentação Vertical e Horizontal Figura 2.4-Deadlock distribuído Figura 4.1-Disposição dos Hosts no Ambiente Experimental... 63

11 LISTA DE GRÁFICOS Gráfico 5.1-Índice de Confiança obtido em cada experimento IC Gráfico 5.2-TMR obtido em cada Experimento Gráfico 5.3-Estrutura Interna do BDD, agrupados pelo Nível 1 Synonym Gráfico 5.4-Estrutura interna do BDD, agrupados pelo Nível -1 Materialized View 70 Gráfico 5.5-Número de Requisições, agrupados pelo Nível Gráfico 5.6-Número de Requisições, agrupados pelo Nível Gráfico 5.7-Número de Tabelas, agrupados pelo Nível Gráfico 5.8-Número de Tabelas, agrupadas pelo Nível Gráfico 5.9-Influência dos Fatores sobre o BDD... 73

12 LISTA DE QUADROS Quadro 4.1-Disposição fatores e níveis Quadro 4.2-Disposição dos experimentos cruzando fatores e níveis a partir de fatorial completo Quadro 4.3-Disposição dos níveis a partir de representação matemática... 65

13 LISTA DE ABREVIATURAS E SIGLAS 2PC Two Phase Commit 3PC Three Phase Commit APEX Application Express API Application Programming Interface AVG Average BD Banco de Dados BDD Banco de Dados Distribuído BDOO Banco de Dados Orientado a Objetos BDOR Banco de Dados Objeto Relacionais CPU Central Processing Unit CSV Comma-Separated Values DVD Digital Versatile Disc ou Digital Vídeo Disc E/S Entrada e Saída FEC Forward Error Connection I/O Input / Out put IBM International Business Machines IC Índice de Confiança IDL Interface Definition Language IP Internet Protocol JDBC Java Database Connectivity JDK Java Development Kit MPI Message Passing Interface ODBC Open Data Base Connectivity QoS Quality on Services RAID Redundant Array of Independent Drives SD Sistema Distribuído SGBD Sistema Gerenciador de Banco de Dados SGBDD Sistema Gerenciador de Banco de Dados Distribuído SO Sistema Operacional SSA Soma dos quadrados de A

14 SST Soma Total dos quadrados TCP Transmission Control Protocol TMR Tempo Médio de Resposta TR Tempo de Resposta VM Virtual Machine VMM Virtual Machine Monitor

15 SUMÁRIO INTRODUÇÃO SISTEMAS DISTRIBUÍDOS TRANSPARÊNCIA EM SISTEMAS DISTRIBUÍDOS Acesso Localização Migração Relocação Replicação Concorrência Falha SISTEMA DISTRIBUÍDO ABERTO Interoperabilidade Portabilidade Extensibilidade Flexibilidade SISTEMA DISTRIBUÍDO ESCALÁVEL Escalabilidade MODELOS DE SISTEMAS DISTRIBUÍDOS Computação de Cluster Computação em Grade Camada Base Camada de Conectividade Camada de Recursos Camada Coletiva Camada de Aplicação ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS Arquiteturas Centralizadas Arquitetura Centralizada e Níveis da Camada de Aplicação Arquiteturas Multidivididas Middleware... 32

16 1.6 COMUNICAÇÃO Comunicação Transiente Orientada a Mensagem Message Passing Interface Comunicação Orientada a Fluxo QOS BANCOS DE DADOS DISTRIBUÍDOS E PARALELOS DISTINÇÃO ENTRE PARALELOS E DISTRIBUÍDOS ARQUITETURAS DE BANCOS DE DADOS PARALELOS AVALIAÇÃO DE CONSULTA PARALELA Particionamento de Dados OPERAÇÕES INDIVIDUAIS PARALELIZADAS Carregamento em Massa e Varredura Ordenação Junções Paralelizadas OTIMIZAÇÃO DE CONSULTA PARALELA BANCO DE DADOS DISTRIBUÍDOS Tipos de Bancos de Dados Distribuídos ARQUITETURAS DE SGBD DISTRIBUÍDO Sistema Cliente-Servidor Sistema de Servidor Colaborador Sistemas de Middleware TÉCNICAS DE DISTRIBUIÇÃO DE DADOS Fragmentação Replicação CATÁLOGO DISTRIBUÍDO Nomes Globais de Objetos Fragmentados e Replicados Estrutura de Catálogo Independência de Dados Distribuídos PROCESSAMENTO DE CONSULTA DISTRIBUÍDA Consulta sem Junção em SGBDD Junções em SGBDD Otimização de Consulta Baseada em Custo ATUALIZAÇÃO DE DADOS DISTRIBUÍDOS... 54

17 2.12 TRANSAÇÕES DISTRIBUÍDAS CONTROLE DE CONCORRÊNCIA DISTRIBUÍDO Deadlock Distribuído RECUPERAÇÃO DISTRIBUÍDA Protocolo de Efetivação de Duas Fases Reinício Após Falha Efetivação de Três Fases AVALIAÇÃO DE DESEMPENHO VARIÁVEIS FATORES E NÍVEIS DESENVOLVIMENTO DO PROJETO AMBIENTE DE TESTE METODOLOGIAS DE PESQUISA PLANEJAMENTO DE EXPERIMENTOS RESULTADOS ESPERADOS RESULTADOS E DISCUSSÃO CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS... 76

18 17 INTRODUÇÃO Atualmente as empresas necessitam gerir um volume de informações maior, com segurança e velocidade de forma descentralizada, o que tem gerado uma demanda crescente por recursos presentes nos Bancos de Dados Distribuídos (BDDs), recursos esses que, são, por exemplo, alta disponibilidade de dados, segurança dos dados, descentralização das informações, e um em especial, a velocidade no Tempo de Resposta (TR) as requisições dos clientes. (ELMASRI; NAVATHE, 2011). Segundo Tanenbaum e Steen (2007) não importa qual a área de atuação das organizações, elas dependem cada vez mais de recursos distribuídos, sejam bases de dados distribuídas, web services, computação em grade, dentre outras demandas, e ressalta o fato de que esta demanda só aumentará, tendo em vista que a cada dia o uso de aplicações para internet cresce rapidamente. Muitas questões surgem quando se propõe tal tema, por exemplo, como explorar os recursos de transparência e replicação dos BDDs? Esses recursos representam ganho de desempenho ou perca? Como utilizar esses recursos para prover ganho na resposta ao cliente do BDD e para que atendam as expectativas das organizações modernas? Estas são perguntas que motivam este estudo, e mesmo que não se responda a todas elas, existe uma meta simples a ser alcançada: avaliar recursos influentes em BDD de forma consistente, através de métricas estatísticas (JAIN, 1991). De acordo com Tanenbaum e Steen (2007), os maiores responsáveis por possibilitar um novo conceito e uma mudança de paradigma, passando de sistemas centralizados para Sistemas Distribuídos (SD), são também fatores fortemente ligados à evolução dos componentes e redução de preço dos mesmos. Não obstante, os Sistemas Gerenciadores de Bancos de Dados Distribuídos (SGBDDs), significam um passo importante para aceitação do modelo atual de BDD de acordo com Ramakrishnan e Gehrke (2008), por permitirem facilidades na implementação dos BDDs. A presente pesquisa se coloca, por sua vez, do ponto de vista prático, em um ambiente homogêneo, ou seja: se os dados são distribuídos, mas todos os

19 18 servidores executam o mesmo software de SGBD, temos um sistema de banco de dados distribuído homogêneo. (RAMAKRISHNAN; GEHRKE, 2008, p.614). Logo, a partir de um host simulando vários clientes no benchmark Jmeter, realizou-se várias cargas de trabalho sintéticas compostas por requisições de seleção ao BDD, que utiliza um modelo de servidores de BDD Master/Slave, com tal avaliação de desempenho de requisição de seleção, buscou-se a medição do Tempo Médio de Resposta (TMR) aos clientes, colocando a prova fatores e níveis que variam os principais recursos encontrados nos BDD atuais, determinando sobretudo, a influência dos fatores escolhidos para essa implementação, que possivelmente esclarecem algumas questões discutidas.

20 19 1 SISTEMAS DISTRIBUÍDOS Os SDs se tornaram pauta atual e relevante devido a sua importância no desenvolvimento de pesquisas, tecnologias, e na própria solidificação de conceitos e arquiteturas, usadas na computação distribuída, como peer-to-peer, computação em grade, clusters, redes de sensores, sistemas web distribuídos e bancos de dados distribuídos de acordo com Tanenbaum e Steen (2007). Ao pensar em SD e principalmente em um BDD, é comum que se tenha a ideia de se tratar de um enorme amontoado de seguimentos ou hosts, onde não se tem domínio do que esta ocorrendo internamente e, de uma verdadeira desordem nos dados, talvez por estarem logicamente e fisicamente em lugares distintos. No entanto, a seguinte definição traz uma visão clara de que, na verdade, tudo se trata de como se vê os dados, não de como estão logicamente e fisicamente distribuídos, logo: Um sistema distribuído é um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente. (TANENBAUM; STEEN, 2007, p.1). 1.1 TRANSPARÊNCIA EM SISTEMAS DISTRIBUÍDOS Existe uma grande importância atrelada à necessidade de transparência em um SD, isto é, que os seus utilizadores não percebam que seus recursos estão distribuídos em vários computadores, dessa maneira criou-se uma padronização, que foi definida pela International Organization for Standardization (ISO) quanto à transparência em um SD ao nível do usuário que a aplicação da tecnologia exigirá. Pode-se destacar nessa normalização: Acesso, Localização, Migração, Relocação, Replicação, Concorrência e Falha. No entanto, é preciso atenção nesse ponto, ao passo que: [...] visar à transparência de distribuição pode ser uma bela meta no projeto e na implementação de sistemas distribuídos, mas deve ser considerada em conjunto com outras questões, como desempenho e facilidade de

21 20 compreensão. Nem sempre vale a pena tentar conseguir total transparência, pois o preço que se paga por isso pode ser surpreendentemente alto. (TANENBAUM; STEEN, 2007, p.4). Neste ponto, o autor da bibliografia pesquisada enfatiza que é importante definir quanto se deve buscar a transparência nos SDs, propondo uma adequação do projeto no tocante ao nível de transparência versus o custo para se ter tal meta. As próximas seções abordam os níveis de transparência em um SD Acesso A seguinte definição apresenta um nível de acesso de muita importância, pois ele: "Trata de ocultar diferenças em representação de dados e o modo como os recursos podem ser acessados por usuários [...],[...]desejamos ocultar diferenças entre arquiteturas de máquinas[...]" (TANENBAUM; STEEN, 2007, p.3). Assim, Sistemas Operacionais (SOs) diferentes podem estar em execução em um SD, e possuir diferentes convenções de nomeação de arquivos, oculta-se do usuário as diferenças de acesso aos mesmos. (TANENBAUM; STEEN, 2007) Localização De acordo com Tanenbaum e Steen (2007), esta definição de transparência implica na visão dos usuários, não permitindo, por exemplo, que se saiba onde um determinado recurso esta localizado, ou seja, se o recurso se localiza no host x ou y, ou ainda se o recurso esta distribuído em hosts diversos Migração

22 21 Esta premissa prega que, se os dados ou recursos em um SD puderem ser movidos sem afetar o acesso aos mesmos, tem-se então um SD transparente a migração. (TANENBAUM; STEEN, 2007) Relocação Um SD que permita mover recursos enquanto estão sendo acessados, sem permitir que se note tais alterações, suporta transparência de relocação. (TANENBAUM; STEEN, 2007). Esta é uma meta muito almejada, pois garante flexibilidade na organização dos recursos em SDs Replicação Se um SD pode ocultar a presença das cópias dos recursos presentes em si, então ele possui transparência de replicação, para tal, o sistema geralmente nomeia estas cópias da mesma forma. Este SD também deverá suportar transparência de localização, pois assim garante a referência a cada uma das réplicas. (TANENBAUM; STEEN, 2007) Concorrência Segundo Tanenbaum e Steen (2007), para que se tenha um recurso transparente à concorrência de dois ou mais usuários, é necessário que o SD permita o acesso a este recurso, ocultando exatamente o fato de que outros usuários estão acessando o mesmo recurso.

23 Falha Está aqui uma das transparências em SDs mais almejadas, que o SD seja capaz de ocultar de seus usuários que o mesmo se recuperou de uma falha ou que esta falha nunca ocorreu, ou seja, ao ocorrer uma falha, esta seja imperceptível ao usuário. (TANENBAUM; STEEN, 2007). 1.2 SISTEMA DISTRIBUÍDO ABERTO Para afirmar que um SD é aberto ele precisa possuir interoperabilidade, portabilidade, ser extensível e flexível, também é preciso que ele atenda a seguinte definição, "[...] oferece serviços de acordo com regras padronizadas que descrevem a sintaxe e a semântica desses serviços." (TANENBAUM; STEEN, 2007, p.4). Em SD os serviços são geralmente especificados através de interfaces, que comumente são escritas em uma Linguagem de Definição de Interfaces, em inglês: Interface Definition Language (IDL). (TANENBAUM; STEEN, 2007). Quando as definições de interface são escritas em IDL geralmente elas apresentam apenas a sintaxe dos serviços, especificando os nomes das funções, tipos, valores de retorno e exceções. Por outro lado, a semântica dos serviços quase sempre é apresentada em linguagem natural, informalmente, de acordo com Tanenbaum e Steen (2007). Serão vistas nas seções a seguir, as características dos SDs abertos Interoperabilidade A interoperabilidade de um SD aberto tem como premissa que sistemas ou componentes de fornecedores diversos coexistam e trabalhem juntos, baseados em uma especificação comum. (TANENBAUM; STEEN, 2007).

24 Portabilidade A portabilidade de um SD aberto prima pela capacidade de transportar uma aplicação de um SD para outro que implemente as mesmas interfaces que o primeiro, sem afetar ou modificar o SD que recebe tal aplicação. (TANENBAUM; STEEN, 2007) Extensibilidade Esta premissa é observada quando, por exemplo, conectando-se dois BDs distintos, tornar o BD2 uma extensão do BD1. No entanto, isso não é uma tarefa tão simples, pois em um SD aberto e extensível a seguinte definição é uma premissa difícil de obter: "[...]deve ser fácil adicionar novos componentes ou substituir os existentes[...]".(tanenbaum; STEEN, 2007, p.5) Flexibilidade Objetivando um SD flexível, deve-se atentar para a organização do sistema, além de manter um conjunto de componentes relativamente pequenos e de fácil substituição ou adaptação, para tal deve-se definir também as interfaces para com as partes internas do sistema, e descrever como elas vão interagir. (TANENBAUM; STEEN, 2007). 1.3 SISTEMA DISTRIBUÍDO ESCALÁVEL A justificativa para desenvolvimento de SDs escaláveis está ligada aos fatores de evolução da Internet e aplicações distribuídas, se um SD pode ser ampliado nos

25 24 mais diversos aspectos então ele é escalável.(tanenbaum; STEEN, 2007). Segundo Tanenbaum (apud NEUMAN, 1994) a escalabilidade de um sistema pode ser medida no mínimo em três dimensões, sendo: Tamanho, onde um sistema é escalável por permitir fácil incremento ao seu potencial, recursos e usuários. Geográfica, por permitir que usuários e recursos estejam longe uns dos outros. Administrativa, significa que pode ser administrado mesmo sendo abrangente. Existe uma perca de desempenho considerável ao incrementar SD em qualquer uma dessas dimensões. (TANENBAUM; STEEN, 2007) Escalabilidade Existem atualmente três técnicas para ampliar sistemas: Ocultar latências de comunicação, distribuição e replicação. Ao ocultar latências de comunicação obtémse escalabilidade geográfica, neste caso, a latência nada mais é do que deixar de esperar por uma requisição remota, tornar o processo de espera, em trabalho do lado do requisitante. Isso é possível criando aplicações do lado do requisitante usando comunicação assíncrona. (TANENBAUM; STEEN, 2007). Utilizar distribuição também ajuda na escalabilidade, dividir um componente e distribuir pelo sistema os fragmentos. (TANENBAUM; STEEN, 2007). Esta técnica é precursora da técnica de fragmentação, quando lidamos com BDD, e será discutida no capítulo 2. São beneficiadas as questões de latência, a partir da técnica de replicação. "A replicação não somente aumenta a disponibilidade, mas ajuda a equilibrar a carga entre componentes, o que resulta em melhor desempenho."(tanenbaum; STEEN, 2007, p.9). 1.4 MODELOS DE SISTEMAS DISTRIBUÍDOS Conhecemos dois modelos, que se distinguem quanto à aplicação e

26 25 arquitetura, segundo Tanenbaum e Steen (2007) o SD no modelo de computação de cluster possui hardware e software em equilíbrio entre os nós, muitas vezes com hardware equivalente e SO também, aplicam-se a tarefas de alto desempenho e processamento paralelo, enquanto na computação em grade, uma mistura muito grande em termos de domínios, hardware e SO ocorrerá, e dos quais se trata nas seções adiante Computação de Cluster Os sistemas de computação de cluster vêm crescendo recentemente devido à queda do preço dos componentes em relação ao desempenho. Atualmente é tecnicamente viável montar um cluster além de ser financeiramente mais vantajoso do que um supercomputador de arquitetura proprietária. Este tipo de sistema geralmente é usado para programação paralela e permite que todos os nós executem as tarefas de forma distribuída. (TANENBAUM; STEEN, 2007). Figura 1.1 Exemplo de cluster. Fonte: Tanenbaum e Steen, 2007, p.10 Na Figura 1.1 pode ser observado o comportamento de um sistema de cluster, onde se tem em geral, uma rede de alta velocidade interconectando os nós Slaves ou nós de computação, são eles controlados por meio de um nó Master, e que tem em si um SO que permite a distribuição do processamento entre cada um dos nós Slaves. A rede que acessa remotamente este cluster conecta-se apenas ao nó Master, que por

27 26 sua vez direciona os processos aos nós Slaves, a partir de requisições feitas por uma rede subjacente ou padrão, esta não é uma rede de alta velocidade, pois se destina apenas a controle e sincronização dos nós Slaves. As tarefas do nó Master em geral, são de manipular a alocação de nós Slaves para as tarefas paralelas, manter uma fila de jobs e proporcionar uma interface para os usuários. (TANENBAUM; STEEN, 2007). De forma geral os nós Masters de um cluster executam o middleware para que o sistema, de forma transparente, possa executar os programas em paralelo, sendo assim, aos nós Slaves o SO apenas basta. (TANENBAUM; STEEN, 2007) Computação em Grade A computação em grade se distingue grandemente da computação de cluster pela heterogeneidade, a premissa que a rege é: não existem barreiras que limitem a fusão de domínios administrativos, hardware, SO, redes, políticas de segurança, etc. (TANENBAUM; STEEN, 2007). Figura 1.2 Arquitetura em camadas para sistemas de computação em grade. Fonte: Tanenbaum e Steen, 2007, p.11 Um aspecto muito interessante deste tipo de SD são as organizações virtuais. Elas comportam recursos distribuídos que podem ser servidores de computação (um supercomputador ou cluster integrado a grade sendo acessado como um domínio ou host), armazenamento, BD e serviços especiais, como telescópios, sensores, etc.

28 27 (TANENBAUM; STEEN, 2007). As questões de arquitetura são o foco dos sistemas de computação em grade, segundo Tanenbaum e Steen (2007, apud FOSTER et al, 2001). A Figura 1.2 exemplifica a arquitetura em camadas e será esclarecida nas seções a seguir Camada Base Esta camada é responsável por prover interfaces para recursos locais, destinados a hosts específicos, ela existe em essência, visando permitir que o compartilhamento de recursos dentro de uma organização virtual exclusiva exista. Esses recursos são em geral, funções para consultar o estado e a capacidade de um determinado recurso, trabalhando em paralelo com funções de gerenciamentos de recursos. (TANENBAUM; STEEN, 2007) Camada de Conectividade Em essência, provê protocolos de comunicação que dão suporte a transações que se estendam a múltiplos recursos. Esses protocolos permitem, por exemplo, que haja comunicação entre recursos, a fim de permitir a transferência de dados entre eles. A camada de conectividade também deve prover a consolidação de tarefas simplistas, como por exemplo, garantir que usuários remotos acessem recursos. (TANENBAUM; STEEN, 2007) Camada de Recursos Segundo Tanenbaum e Steen (2007), responsável por um único recurso, não menos importante, a camada de recursos utiliza funções fornecidas pela camada de conectividade, chamando as interfaces concedidas na camada base, assim:

29 28 "[...]oferecerá funções para obter informações de configuração sobre um recurso específico ou, em geral, para ler dados. [...]a camada de recursos é considerada responsável pelo controle de acesso [...]" (TANENBAUM; STEEN, 2007, p.12) Camada Coletiva A camada coletiva tem a premissa de manipular o acesso a múltiplos recursos, o que geralmente, permitirá a alocação e escalonamento de tarefas para os mesmos, além de adicionalmente garantir a descoberta de recursos, replicação de dados, etc. Sendo assim, esta camada se distingue grandemente das outras por possuir muitos protocolos diferentes que abrangem uma vasta quantidade de serviços. (TANENBAUM; STEEN, 2007) Camada de Aplicação Segundo Tanenbaum e Steen (2007), esta camada trabalha com aplicações que funcionam dentro de uma organização virtual e utilizam recursos de computação em grade. Sem esta camada não há porque pensar sistemicamente no uso de outras camadas, sendo a orientação dessas camadas voltadas exatamente a camada acima citada "[...] coletiva, de conectividade e de recursos formam o cerne daquilo que poderia ser denominado camada de middleware em grade. Em conjunto essas camadas dão acesso e gerenciam recursos[...]"(tanenbaum; STEEN, 2007, p.12). 1.5 ARQUITETURAS DE SISTEMAS DISTRIBUÍDOS Quando lidamos com sistemas distribuídos temos que imaginar componentes lógicos e físicos distribuídos entre vários computadores, de acordo com Tanenbaum e

30 29 Steen (2007), é então necessário tratar esses componentes de forma adequada para conseguir gerir tais recursos. Lidar com o estilo arquitetônico é fundamental, pois a partir deste, conseguimos definir os elementos que irão compor o sistema. Segundo Tanenbaum e Steen (2007) os estilos arquitetônicos mais importantes são os de camadas, objetos, eventos e espaços compartilhados de dados. A presente pesquisa tratará diretamente das arquiteturas de SD, abordando dentro da bibliografia pesquisada, os assuntos que servirão de base para o desenvolvimento do projeto, dessa forma, não se discorrerá sobre estes estilos com profundidade, para compreender os estilos consulte Tanenbaum e Steen (2007) Arquiteturas Centralizadas Com o objetivo de elucidar questões inerentes as arquiteturas centralizadas, é preciso compreender os processos de requisições. Ao falar de requisições, geralmente se utiliza o modelo de clientes e servidores, pois trazem uma visão mais clara dos processos de gerenciamento dos SDs. Ao pensar em um modelo clienteservidor básico, é possível dividi-los em dois grupos, sendo que "[...] um servidor é um processo que implementa um serviço específico[...]"(tanenbaum; STEEN, 2007, p.22). Por exemplo, serviços de sistemas de arquivos e serviços de BD. Figura 1.3 Fluxo e tempo de espera na visão cliente-servidor Fonte: Tanenbaum e Steen, 2007, p.22 Clientes contemplam o universo de requisições. "Um cliente é um processo que

31 30 requisita um serviço de um servidor enviando-lhe uma requisição e, na sequência esperando pela resposta do servidor." (TANENBAUM; STEEN, 2007, p.22). Segundo Tanenbaum e Steen (2007) este comportamento se nomeia requisição-resposta, e pode ser observado a partir da Figura 1.3, o fluxo de requisições parte do cliente para o servidor gerando um tempo ocioso do lado do cliente, o que é aceitável nesta arquitetura. Um protocolo simples fará a comunicação entre ambos. Um aspecto importante a ser visto é a possibilidade de falhas nesta troca de mensagens. Em algumas situações apenas executar o reenvio da requisição não será a melhor alternativa. Imagine se a requisição for "debite R$ ,00 da minha conta". Não é aplicável esta solução para esta ocasião. Melhor apenas comunicar o erro e não atender a 7ª premissa da transparência proposta pela ISO, vista neste capítulo na seção (TANENBAUM; STEEN, 2007). Contanto que não seja você o dono da instituição financeira, seria interessante reenviar a requisição: "Deposite na minha conta R$ ,00", é claro que isso é uma brincadeira, porém é totalmente aceitável esta solução, caso a mensagem seja um alerta, por exemplo: "Você não possui saldo para esta operação."(tanenbaum; STEEN, 2007). O que seria bastante realista também. "Quando uma operação pode ser repetida várias vezes sem causar dano, dizse que ela é idempotente." (TANENBAUM; STEEN, 2007, p.22). Não sendo possível estabelecer uma única solução para os problemas de mensagem, muitos sistemas utilizam protocolos orientados a conexão, o que para uma rede local, onde se possua uma confiabilidade razoável, seria dispendioso. No entanto, em um SD geograficamente, isso é totalmente aceitável. Grande parte, senão todos os protocolos de aplicação da internet, são baseados em Transmission Control Protocol (TCP) e Internet Protocol (IP), algumas vezes esses acrônimos aparecem juntos: TCP/IP, que utiliza conexões confiáveis, assim quando o cliente solicitar um serviço ele estabelece conexão com o servidor e depois envia a requisição, geralmente ele usará a mesma conexão para enviar a resposta, sendo encerrada em seguida. (TANENBAUM; STEEN, 2007). Quanto aos problemas, sim eles existem: "O problema é que estabelecer e encerrar uma conexão custa relativamente caro, em especial quando as mensagens de requisição e resposta forem pequenas." (TANENBAUM; STEEN, 2007, p.23).

32 Arquitetura Centralizada e Níveis da Camada de Aplicação Destacar-se-á ainda 3 níveis comumente presentes nesta arquitetura, dentro da camada de aplicação: 1º - Nível de interface de usuário, 2º - Nível de processamento, 3º - Nível de dados. O primeiro nível contém tudo que se faz necessário para atender a visão do usuário, sendo este um nível que controla o gerenciamento de interface com o usuário e exibição a ele. Este nível possui programas que garantem aos usuários finais interação com as aplicações. Em sistemas de mainframes, por exemplo, apenas interfaces de texto permitiam a entrada de solicitações, isto é diferente hoje, pois atualmente mesmo em sistemas mainframes possuem-se interfaces de comunicação mais avançadas. (TANENBAUM; STEEN, 2007). Interfaces modernas contêm recursos muito mais atraentes e funcionais, que garantem o uso mais eficaz do sistema e permitem que usuários menos técnicos utilizem e aprendam mais rapidamente os recursos do sistema. (TANENBAUM; STEEN, 2007). O segundo nível é o de processamento, que geralmente as aplicações possuem. Este nível é o cerne da aplicação, de forma distinta dos outros níveis, este é um nível bastante comum. Se pensarmos em um programa que requisita informações do BD e, ao receber, processa e trata esses dados, se esta observando a ação do nível de processamento. (TANENBAUM; STEEN, 2007). Responsável é o nível de dados pela gerência dos dados, onde se está executando uma ação. Intuitivamente sabe-se que esse nível é persistente, ou seja: "[...]ainda que nenhuma aplicação esteja sendo executada, os dados estarão armazenados em algum lugar para a próxima utilização." (TANENBAUM; STEEN, 2007, p.24). Já está muito consolidado neste nível, os BDs relacionais, por permitirem que se separe fisicamente e logicamente os níveis de processamento do nível de dados. No entanto, tem emergido bastante os Bancos de Dados Orientados a Objetos (BDOOs) e os Bancos de Dados Objetos Relacionais (BDORs) por aproximar a visão do desenvolvedor da aplicação, da lógica do negócio, facilitando o desenvolvimento de aplicações para SD. (TANENBAUM; STEEN, 2007).

33 Arquiteturas Multidivididas No que tange a distribuição física pode-se recomendar apenas 2 grupos de máquinas em uma arquitetura multidividida. 1 - Máquinas com programas que implementam apenas o nível de interface de usuário. 2 - Máquinas com todo o resto, ou seja, que implementam os níveis de processamento e dados. Essa arquitetura também é denominada arquitetura de duas divisões. (TANENBAUM; STEEN, 2007). A Figura 1.4 apresenta a seguir como se dispõe tal organização, e mostra como é possível customizar essa disposição, permitindo diferentes configurações de (a) a (e), para o uso dessa arquitetura. Figura 1.4 Possibilidades de configuração cliente-servidor (a)--(e). Fonte: Tanenbaum e Steen, 2007, p.25. Deve-se notar, no entanto, que estas configurações não são todas ótimas. Atualmente as configurações mais utilizadas são as das Figuras 1.4(a) a 1.4(c), por refletirem o que se denomina, clientes gordos e clientes magros, em inglês: fat clients e thin clients. (TANENBAUM; STEEN, 2007) Middleware Segundo Tanenbaum e Steen (2007), o middleware forma uma camada entre as aplicações e as plataformas distribuídas, seu papel é atuar sobre a transparência,

34 33 ocultando aspectos de distribuição, processamento e controle. Por razões de adequação, o middleware é na maioria das vezes, um software de arquitetura própria. Isso levou os desenvolvedores atualmente à separação das políticas e mecanismos, a partir dos quais se pode mudar o comportamento do middleware adaptando-o. Mas porque é preciso que ele seja adaptativo? SDs estão constantemente mudando e sem esta capacidade os sistemas ficariam estagnados. Para tal, se têm utilizado os interceptadores, funções em tempo de execução, que ao serem invocadas permitem que outro fluxo de execução não usual seja realizada. (TANENBAUM; STEEN, 2007). "O que os interceptadores oferecem na verdade é um meio de adaptar o middleware." (TANENBAUM; STEEN, 2007, p.34). Um ponto a destacar quanto ao middleware é a necessidade existente, de que ele ainda seja adaptativo, no que tange a manutenção dos SD. Um SD não pode ser parado para reparos ou substituição de componentes físicos, tão pouco desligado, o que motiva o desenvolvimento de novas alternativas e debate sobre soluções na área. (TANENBAUM; STEEN, 2007). 1.6 COMUNICAÇÃO Um fator capaz de reduzir a visibilidade da distribuição e também aumentar a transparência são as chamadas de procedimentos remotos e invocações de objetos remotos, isso gera benefícios a visão do cliente, porém aumenta a necessidade de serviços de comunicação alternativos. (TANENBAUM; STEEN, 2007). De acordo com Tanenbaum e Steen (2007), devido a ausência de memória compartilhada, a comunicação em SD é toda baseada em mensagens de baixo nível, por exemplo quantos volts são necessários para sinalizar um bit 0? E um bit 1? Fica claro então como deve haver uma convenção, esta é a justificativa para o uso de protocolos nas camadas mais baixas e também nas camadas de nível mais alto Comunicação Transiente Orientada a Mensagem

35 34 A camada de transporte oferece um modelo simples orientado à mensagem, dessa forma muitos sistemas se apoiam nessa camada e sobre ela se solidificam. A camada de rede TCP possui oito primitivas que são nomeadas nesta ordem e são as seguintes: Socket, Bind, Listen, Accept, Connect, Send, Receive e Close. (TANENBAUM; STEEN, 2007). Geralmente os servidores irão chamar as 4 primeiras primitivas, chamando Socket, é criado uma novo terminal de comunicação, a primitiva Bind associa um endereço local com o Socket já criado, definindo o IP juntamente com a porta especificada, entra em jogo a primitiva Listen, caso a comunicação seja orientada a comunicação, trata-se de uma chamada não bloqueadora que faz com que o SO possa aceitar conexões que o receptor possa comportar. A chamada Accept, bloqueará o chamador até que chegue uma requisição de conexão, o SO então cria um novo Socket e deixa o primeiro livre para o servidor novamente voltar a esperar outra requisição. No lado do cliente, a primitiva Connect permite que exista uma conexão entre o servidor e cliente, se a conexão for estabelecida ambos os lados podem trocar informações através de Send e Receive, ambos deverão chamar a primitiva Close, caso queiram encerrar a conexão. (TANENBAUM; STEEN, 2007) Message Passing Interface Pela necessidade de desenvolver aplicações de grande desempenho buscaram-se primitivas orientadas a mensagem, capazes de escrever mais facilmente, que atendesse as reais necessidades das aplicações, de maneira que a Interface Socket foi desenvolvida com propósito de permitir a troca de mensagens através de protocolos, assim como TCP/IP. (TANENBAUM; STEEN, 2007). Sabe-se, baseado em Tanenbaum e Steen (2007), que os protocolos usados em redes de alta velocidade como clusters, por exemplo, utilizam protocolos proprietários e isso inviabilizaria o uso de Sockets. Assim surge a Message Passing Interface (MPI) capaz de prover comunicação adequada para aplicações de alto desempenho. Tanenbaum e Steen (2007) declaram ainda que a premissa da MPI é a comunicação ocorrendo a partir de um grupo conhecido de processos.

36 Comunicação Orientada a Fluxo Esse é um tipo de comunicação da qual usuários de computadores domésticos gostam muito, é comum que a maioria não saiba que o filme que se assiste diretamente no navegador, é uma comunicação orientada a fluxo. Em geral se esta comunicação falhar ou sequer oscilar, o usuário do sistema ficará enraivecido, porque o resultado da informação não atingiu o receptor de forma aceitável. (TANENBAUM; STEEN, 2007). Este é um exemplo simples, mas que elucida claramente a importância da comunicação orientada a fluxo nos sistemas distribuídos. O tempo é crucial para a qualidade da mensagem, que nos casos de áudio e vídeo, fazem-se tão importantes. Uma música ao ser executada em uma frequência diferente da original, passará a soar distorcida, caso não exista uma temporização adequada do fluxo de dados. (TANENBAUM; STEEN, 2007). 1.7 QOS Temporização é um dos requisitos de Qualidade dos Serviços, em inglês: Quality on Service (QoS), em um ambiente tão instável quanto a internet é vital que se utilize também técnicas de correção de erros, visto que muitas vezes não se pode tomar todas as premissas do QoS como parâmetros únicos a se levar em conta. (TANENBAUM; STEEN, 2007). Forward Error Correction (FEC), é uma técnica de correção, que busca atender as premissas do QoS, largamente usada em SD que demandam de recursos conjuntos com a internet, através desta técnica, por exemplo, é possível ver VÍDEOS DE INSTRUÇÕES que tenham se corrompido por perca de pacotes. (TANENBAUM; STEEN, 2007).

37 36 2 BANCOS DE DADOS DISTRIBUÍDOS E PARALELOS Foram até aqui observadas questões no âmbito dos SDs, a fim de proporcionar esclarecimento e fundamentação teórica importante à presente pesquisa. A partir desse capítulo, tratar-se-á os fundamentos e conceitos de banco de dados distribuídos e paralelos, arquiteturas, comunicação, funcionalidades, avaliação de consultas, paralelização de código e distribuição, middleware, replicação, independência de dados, dentre outras, que servirão de apoio a implementação da estrutura, avaliação e embasamento para o tema dessa dissertação. 2.1 DISTINÇÃO ENTRE PARALELOS E DISTRIBUÍDOS Existe uma grande diferença entre BDD e sistemas paralelos com BD, ambos utilizam recursos distribuídos, porém eles diferem de acordo com sua arquitetura física e lógica, e também por diferentes motivações. Segundo Ramakrishnan e Gehrke (2008), sistemas de bancos de dados paralelos tem como premissa a melhora do desempenho, através de execuções em paralelo de diversas operações, como por exemplo, carregamento de dados, construção de índices e avaliações de consulta. Mesmo que os dados estejam distribuídos, a distribuição é governada por aspectos de desempenho. A definição dada por Elmasri e Navathe (2011) a respeitos dos BDDs é que eles se diferem principalmente quanto a : 1 - Vários computadores, chamados sites, nós ou hosts, conectados por uma rede de comunicação básica para poder transmitir os dados entre eles. 2 - Inter-relação entre os BDs conectados, pois é imprescindível a relação lógica entre os BDs. 3 - Não se encontra nesse modelo restrições quanto a homogeneidade, podendo se ter dados, software e hardware diferentes em cada site. Assim: "Podemos definir um Banco de Dados Distribuído como uma coleção de múltiplos bancos de dados logicamente inter-relacionados, distribuídos por uma rede de computadores[...]"(elmasri; NAVATHE, 2011, p.590). Ramakrishnan e Gehrke (2008) definem que os sistemas de BDDs são

38 37 motivados por fatores relacionados aos aspectos de: Maior disponibilidade: ao permitir que, caso uma relação pare de funcionar ela ainda estará disponível a partir de uma cópia em outro site; Acesso distribuído aos dados: permitindo, por exemplo, que se realize consultas locais de dados distribuídos; Análise de dados distribuídos: que pode ser um problema dado o nível de integração entre os BDs propriamente ditos. Em contrapartida, os sistemas de bancos de dados paralelos são motivados por uma meta simples: Desempenho. Agora que são diferenciáveis estes dois tipos de sistemas, e se compreende que na verdade eles utilizam recursos distribuídos e executam vários BDs, abstrairse-á melhor as seções que se seguem nesta pesquisa. 2.2 ARQUITETURAS DE BANCOS DE DADOS PARALELOS Os BDs são um dos casos mais bem sucedidos no uso da computação paralela, onde a ideia é realizar etapas de avaliação em paralelo (discutido na seção 2.3 deste capítulo), o Sistema Gerenciador de Banco de Dados (SGBD) permite isso, e para tal, foram propostas três arquiteturas para construção de SGBDs paralelos. A Figura 2.1 demonstra como está disposta sua organização: Shared Memory: várias Central Processing Unit (CPU) são ligadas em uma rede de interconexão, e acessam uma área comum de memória principal. Shared Disk: cada CPU tem uma memória privada e acesso direto aos discos, em uma rede de interconexão. Shared Nothing: cada CPU tem sua memória dedicada principal e uma porção do disco, porém duas CPUs não podem acessar a mesma área de armazenamento, a comunicação entre elas se dá através de uma conexão de rede. (RAMAKRISHNAN; GEHRKE, 2008).

39 38 Figura 2.1 Arquitetura física de sistema de banco de dados paralelos. Fonte: Ramakrishnan e Gehrke, 2008, p.606. É correto afirmar que, a arquitetura mais próxima de uma máquina convencional, é a de shared memory, vários sistemas comerciais tem sido portados para plataformas de memória compartilha com certa facilidade. Tem-se nesse tipo de arquitetura uma baixa sobrecarga de comunicação, devido o uso da memória principal para essa finalidade. Também é correto que se diga que o SO se beneficia muito das CPUs adicionais, o que aumenta a performance, e pode levar a motivação dos sistemas paralelos, ao rumo oposto, pois, ao adicionar uma quantidade excessiva de CPUs a um sistema, a disputa pela memória entre as CPUs torna-se um gargalo, e ao invés de mais desempenho temos perca. (RAMAKRISHNAN; GEHRKE, 2008). Um problema similar ocorre com a arquitetura shared disk, devido ao volume grande de dados que circulam na rede de interconexão. Pode-se afirmar ainda que, existe um problema básico entre estas duas arquiteturas: a interferência. Já foi dito que ao adicionar uma quantidade excessiva de CPU a um sistema ocorrerá uma gargalo, mas a interferência provocará a perca de desempenho nas CPUs já existentes. Assim: Tem-se observado que mesmo uma média de 1% de atraso por CPU adicional significa que o aumento de velocidade máximo é de um fator de 37 e acrescentar mais CPUs na verdade diminui a velocidade do sistema; um sistema com 1000 CPUs é apenas 4% mais eficiente do que um sistema de uma única CPU! (RAMAKRISHNAN; GEHRKE, 2008, p.606). Baseado em Ramakrishnan e Gehrke (2008), essa é uma observação muito importante, e que motivou o desenvolvimento da arquitetura shared nothing, tem-se

40 39 considerado esta, como a melhor arquitetura para bancos de dados paralelos grandes. Tal arquitetura exige uma reorganização ampla do código do SGBD, porém demonstra um aumento de velocidade linear, a medida que se adiciona CPU e disco, e também aumento de escala linear, de forma que o desempenho será mantido com o incremento de hardware. (RAMAKRISHNAN; GEHRKE, 2008). Observe a Figura 2.2: Figura 2.2 Aumento de velocidade e aumento de escala. Fonte: Ramakrishnan e Gehrke, 2008, p.607. O primeiro gráfico, visto a esquerda, denominado "Speed-up", ou : aumento de velocidade, demonstra que, conforme o numero de CPUs é incrementado (eixo - # of CPUs), mais velocidade o sistema terá para executar uma quantidade n de transações por segundo (eixo - # transactions per second). Note que o aumento no entanto, é sublinear (tracejado) em relação ao ideal (traço continuo). (RAMAKRISHNAN; GEHRKE, 2008). O segundo gráfico, visto no centro, denominado "Scale-up with DB size", ou no nosso contexto: aumento de escala com o tamanho do BD, demonstra que, conforme o numero de CPUs é incrementado (eixo - # of CPUs, database size), e o tamanho do BD também é incrementado, mais velocidade o sistema terá para executar uma quantidade n de transações por segundo (eixo - # transactions per second). Vale ressaltar que com o aumento de escala, no entanto, deverá ser cada vez menor a velocidade de resposta nas transações e será sublinear em relação ao ideal. (RAMAKRISHNAN; GEHRKE, 2008). O terceiro gráfico, visto a direita, denominado "Scale-up with # XACTS/Sec", ou no nosso contexto: aumento de escala com o número de transações por segundo, demonstra que, conforme o número de CPUs é incrementado (eixo - # of CPUs, #

41 40 transactions per second), mais velocidade o sistema terá para executar uma quantidade n de transações por segundo (eixo - # transactions per second) se o BD não for incrementado. Vale ressaltar que o aumento será sublinear em relação ao ideal e aumentará com o crescimento da escala. (RAMAKRISHNAN; GEHRKE, 2008). Isso nos leva a crer que é infinito a escalabilidade de desempenho, baseado nessa arquitetura, pois quanto mais CPUs conectadas, mais rápidas serão as execuções em sistemas com bancos de dados paralelos, é claro que esses recursos de hardware são físicos, e portanto, finitos. Dessa forma, não existe um sistema paralelo fisicamente escalável ao infinito. (RAMAKRISHNAN; GEHRKE, 2008). 2.3 AVALIAÇÃO DE CONSULTA PARALELA A partir da arquitetura shared nothing em um SGBD, denota-se nesta seção, a avaliação paralela de uma consulta relacional, onde é possível considerar a execução paralela de várias consultas, no entanto, é difícil a identificação das consultas concorrentes, de maneira que abordar-se-á apenas a execução paralela de uma única consulta. Assim: O plano de execução de uma consulta relacional é um grafo de operadores algébricos relacionais, e os operadores de um grafo podem ser executados em paralelo. Se um operador consome a saída de um segundo operador, temos o paralelismo em pipeline (a saída do segundo operador é manipulada pelo primeiro assim que é gerada); caso contrário, os dois operadores podem prosseguir de forma basicamente independente. Diz-se que um operador bloqueia se ele não produz nenhuma saída até ter consumido todas as suas entradas. O paralelismo em pipeline é limitado pela presença de operadores (por exemplo, ordenação ou agregação) que bloqueiam. (RAMAKRISHNAN; GEHRKE, 2008, p.607). É possível ainda avaliar cada operador individual de um plano de consulta em paralelo. Como isso pode ser feito? Basta que se particione os dados de entrada, assim é possível realizar um trabalho em cada partição em paralelo e unir os resultados. Essa estratégia se chama: avaliação em paralelo de dados particionados.

42 41 Os aspectos de portabilidade do código para avaliação sequencial de operadores relacionais, são beneficiados nesse contexto. (RAMAKRISHNAN; GEHRKE, 2008). Já foi dito que a arquitetura shared nothing é muito aceita, e exatamente por responder bem ao uso desta estratégia, enfatiza-se a afirmação de Ramakrishnan e Gehrke (2008, p.607): "[...] sistemas de banco de dados paralelos de nada compartilhado têm tido muito sucesso, é que a avaliação de consulta de banco de dados é muito receptiva à avaliação em paralelo de dados particionados.". A síntese então para o que se discutiu é: "[...] minimizar o envio de dados por meio de seu particionamento e da estruturação de algoritmos para realizarem a maior parte do processamento em processadores individuais." (RAMAKRISHNAN; GEHRKE 2008, p.608) Particionamento de Dados Algo que nos permite explorar a largura da banda de Entrada e Saída (E/S) dos discos é: o particionamento horizontal de um conjunto de dados. A partir deste particionamento é possível ler e gravar paralelamente. Dentre os vários algoritmos usados para particionar uma relação horizontalmente em sistemas paralelos, destacam-se: Particionamento Round - Robin: "Se houver n processadores, a i-ésima tupla será atribuída ao processador i mod n." (RAMAKRISHNAN; GEHRKE 2008, p.608). Este é adequado para avaliar consultas que afetam a relação inteira, não é tão eficiente quanto os dois outros, mas é bastante comum, além de ser um algoritmo encontrado em Redundant Array of Independent Drives (RAID) e escalonamento de processos nos processadores. Particionamento por Hashing: "[...] uma função de hashing é aplicada a (campos selecionados de) uma tupla para determinar seu processador" (RAMAKRISHNAN; GEHRKE 2008, p.608). Ainda segundo Ramakrishnan e Gehrke (2008), o particionamento por hashing tem a vantagem de manter os dados igualmente distribuídos, mesmo que aumentem ou diminuam com o tempo. Particionamento por Intervalos: As tuplas são ordenadas conceitualmente

43 42 através de n intervalos, assim são escolhidos os intervalos para os valores de chave de ordenação, de maneira que: "cada intervalo contenha aproximadamente o mesmo número de tuplas; as tuplas no intervalo i são atribuídas ao processador i." (RAMAKRISHNAN; GEHRKE 2008, p.608). Um aspecto a se observar sobre este algoritmo é que ele causa distorção de dados, que resulta em: "os processadores que lidam com partições grandes tornarem-se gargalos de desempenho." (RAMAKRISHNAN; GEHRKE 2008, p.608). Não serão aprofundados os detalhes destes algoritmos por questões de escopo de pesquisa, assim, para maiores esclarecimentos sobre algoritmos consulte a bibliografia recomenda no capítulo bibliográfico, mais especificamente Thomas et. al. (2002) e Ramakrishnan e Gehrke (2008). 2.4 OPERAÇÕES INDIVIDUAIS PARALELIZADAS A presente seção irá apresentar como várias operações individuais podem ser paralelizadas em uma arquitetura shared nothing. Para tal considere que as relações estarão particionadas de forma horizontal em vários discos Carregamento em Massa e Varredura Duas operações simples de realizar: carregamento e varredura de uma relação. As páginas são lidas em paralelo ao percorrer uma relação, e as tuplas recuperadas são intercaladas caso a relação for particionada em vários discos. De maneira mais simples pode-se dizer que estas duas operações consistem na recuperação de todas as tuplas que satisfazem a uma condição de seleção. Dependendo do algoritmo selecionado, as consultas de seleção serão respondidas usando-se os processadores que contém tuplas relevantes. (RAMAKRISHNAN; GEHRKE, 2008).

44 Ordenação Para realizar esta operação é preciso permitir que cada CPU ordene a parte da relação que possui, e mesclar esses conjuntos ordenados de tuplas. Um limitador do grau de paralelismo que pode-se obter será a fase de intercalação. O aspecto mais desafiador da ordenação paralela talvez seja o particionamento por intervalos, que busca uma aproximação do número de tuplas em cada processador. Logicamente se a diferença entre cargas de ordenamento de tuplas nos processadores existir, provocará um gargalo, forçando que outros processadores esperem o término dos procedimentos daqueles que estiverem com distribuição desigual quanto a quantidade de tuplas. (RAMAKRISHNAN; GEHRKE, 2008) Junções Paralelizadas Dois algoritmos em especial, respondem bem a operação de junção (Join). Junção por algoritmos hashing e sort-merge, ambos podem ser muito bem paralelizados. Caso deseje juntar duas relações A e B em idade paralelamente, supondo que elas estejam distribuídas em vários discos, e ainda inúteis para operações de junção, ou seja, não estão baseadas inicialmente em partições dos atributos de junção, decompõe-se a junção em uma coleção de k junções menores, como afirma Ramakrishnan e Gehrke (2008, p.610): "podemos decompor a junção particionando A e B em uma coleção de k buckets lógicos ou partições." Utiliza-se então a mesma função de particionamento em A e B, provocando o cálculo da junção de A e B, com a união de k junções menores. Em cada processador, todas as tuplas locais são recuperadas, em cada k partição elas passarão pela função de hashing usada (ou sort-merge) em cada site. Pode-se ainda dividir o intervalo do atributo de junção idade em k subintervalos disjuntos, atribuindo tuplas de A e B em partições de acordo com o subintervalo do qual pertençam seus respectivos valores de idade. (RAMAKRISHNAN; GEHRKE, 2008). Para que fique mais claro imagine 10 processadores, o atributo de junção seja idade e os valores variem de 0 a 100. Com uma distribuição igual, as tupla de A e B com 0 idade < 10

45 44 vão para o processador 1, e para o processador 2 vão as tuplas com 10 idade < 20, similarmente até o processador numero 10.(RAMAKRISHNAN; GEHRKE, 2008). 2.5 OTIMIZAÇÃO DE CONSULTA PARALELA Ramakrishnan e Gehrke (2008) propõem a paralelização de diversas tarefas executadas em sistemas paralelos, as consultas obviamente, também podem ser paralelizadas. Sobre tudo, podemos ressaltar a possibilidade de executar em paralelo varias operações contidas em uma consulta e ainda a consulta como um todo em paralelo. De maneira geral, os sistemas otimizam consultas sem dar grande atenção a outras consultas que estejam executando ao mesmo tempo (em um ambiente multiusuário). No entanto, devemos atentar a:"[...] o plano que retorna respostas mais rapidamente pode não ser o plano de menor custo." (RAMAKRISHNAN; GEHRKE, 2008, p.613). Por último ressalta-se que vários parâmetros como, espaço em buffer disponível e o número de processadores livres, serão conhecidos apenas na execução e deverão ser levados em conta ao se desejar otimizar consultas paralelas. (RAMAKRISHNAN; GEHRKE, 2008). 2.6 BANCO DE DADOS DISTRIBUÍDOS De acordo com as considerações feitas no início deste capítulo, sabe-se que os BDDs possuem seus dados armazenados em vários sites ou também chamados de hosts. Também ficou claro no capítulo primeiro que, sendo este um SD que possui um SGBDD e assim considerado um BDD, visa-se a transparência de distribuição. A presente seção nos apresentará alguns aspectos explorados nessa pesquisa, dentro do contexto dos BDDs. Segundo Ramakrishnan e Gehrke (2008) duas propriedades são almejáveis: Independência dos dados distribuídos: sem especificar onde as relações estão armazenadas os usuários conseguem fazer consultas. Esse princípio é uma extensão da independência física e lógica dos dados.

46 45 Atomicidade da transação distribuída: a escrita de transações que acessam e atualizam vários sites deve ser uma capacidade dos usuários, como se estivessem realizando transações locais. A partir de Ramakrishnan e Gehrke (2008, p.613) fica definido que: "[...] os efeitos de uma transação entre os sites devem continuar a ser atômicos; isto é, todas as alterações persistem se a transação é efetivada e nenhuma persiste se ela é cancelada.". Existem, claramente contradições a esse desejo, quando se possui um BDD global, ou seja, com sites distribuídos por todo o mundo, essas propriedades nem mesmo são desejáveis. Isso dadas as dificuldade de coordenar atividades e manter um desempenho considerável para o SGBDD. (RAMAKRISHNAN; GEHRKE, 2008) Tipos de Bancos de Dados Distribuídos Existem dois tipos bem definidos de BDD, homogêneo e heterogêneo. Os BDDs homogêneos foram definidos a partir de Ramakrishnan e Gehrke (2008) na introdução desta pesquisa para que fique ressaltado o rumo que se há de seguir nas etapas de implementação do projeto. Para esclarecer ainda mais este tipo de BDD, observe a definição de Elmasri e Navathe (2011, p.593) a seguir: "Se todos os servidores (ou SGBDs locais individuais) usarem software idêntico e todos os usuários (clientes) utilizarem software idêntico[...]". De outra forma, caso os sites sejam executados por diferentes SGBDs, e ainda basicamente autônomos e conectados de forma que permitam o acesso aos dados a partir de vários sites temos: "[...]um sistema de banco de dados distribuído heterogêneo, também referido como sistema de múltiplos bancos de dados (multidatabase)." (RAMAKRISHNAN; GEHRKE, 2008, p.614). Um ponto critico ao construir sistemas heterogêneos é possuir padrões para protocolos de gateway (conectores). A definição abaixo destaca que os gateways são na verdade uma Application Programming Interface (API), de modo que, baseado em Ramakrishnan e Gehrke (2008, p.614) pode-se afirmar: "O protocolo de gateway é uma API que expõe funcionalidades de SGBD para aplicativos externos [...]", dentre os possíveis conectores para bases de dados externas cita-se os dois mais importantes, o Open Data Base Connectivity (ODBC) e o Java Database Connectivity

47 46 (JDBC). 2.7 ARQUITETURAS DE SGBD DISTRIBUÍDO O desejo de separar as funcionalidades de diferentes processos inseridos no SGBD motivaram o uso de três estratégias, que por sua vez, nos levam a conceitos de arquiteturas; são elas: cliente-servidor, servidor colaborador e middleware; são apresentadas nas três seções seguintes: Sistema Cliente-Servidor Vários são os motivos que levaram esta arquitetura a se tornar muito aceita, primeiro por ser bastante simples de implementar, por manter o servidor centralizado dividindo muito bem suas funcionalidades. Segundo, as máquinas servidoras são caras e não ficam subutilizadas, lidando constantemente com interações simples dos usuários através dos clientes. E por último por permitir que os usuários utilizem uma interface gráfica com a qual estão familiarizados, que com certeza é bastante diferente da interface de linha de comando que possivelmente estará presente na maioria dos servidores. (RAMAKRISHNAN; GEHRKE, 2008). Para os desenvolvedores de aplicações voltadas para esse nicho de sistema, fica o conselho de Ramakrishnan e Gehrke (2008, p.614) a seguir: "Ao escrever aplicativos cliente-servidor, é importante lembrar o limite entre o cliente e servidor [...]" Sistema de Servidor Colaborador Ramakrishnan e Gehrke (2008) declaram que há uma dificuldade em distinguir entre servidor e cliente, devido ao fato de que, muitas vezes, os processos do cliente

48 47 se sobrepunham aos do servidor, sendo ainda muitas vezes mais complexos, levouse ao desenvolvimento de uma alternativa ao sistema cliente-servidor: o sistema servidor colaborador. Ao qual se define sendo uma coleção de servidores de BD, onde cada um é capaz de executar transações que abranjam cooperadamente vários servidores no BDD. Por exemplo, ao receber uma consulta vinda de outro servidor, e que acesse dados presentes em outros servidores, ele gerará subconsultas que serão executadas em vários servidores, depois comparadas com a consulta original após serem reunidos os resultados das subconsultas, apresentará então os dados retornados da consulta original. (RAMAKRISHNAN; GEHRKE, 2008) Sistemas de Middleware Uma arquitetura middleware é projetada com o intuito de permitir abrangência em consultas, sem exigir que os servidores de BD gerenciem estratégias de execuções em vários sites. Pode-se dizer ainda sobre a arquitetura de sistemas middleware, ser muito almejada, principalmente quando desejamos integrar vários sistemas legados, que possivelmente não podem ser estendidos. Assim precisamos de um único servidor capaz de realizar consultas pelos vários servidores, restando aos outros apenas executar transações e consultas locais. Considera-se esse servidor como uma camada de software, capaz de coordenar o BDD, juntar e realizar muitas outras operações relacionais, no entanto, ela não armazena dados em si. (RAMAKRISHNAN; GEHRKE, 2008). 2.8 TÉCNICAS DE DISTRIBUIÇÃO DE DADOS Um dos mais importantes objetos em um BD centralizado são as relações, em um BDD elas ganham mais importância ainda, e devem ser distribuídas pelos vários hosts, provendo o mais próximo acesso remoto a elas (algumas vezes ele acabará sendo local). O problema está neste ponto, o acesso remoto a relações contidos em outros sites tem um custo de passagem de mensagem, para que se possa reduzir

49 48 possíveis sobrecargas utiliza-se técnicas como: fragmentação e replicação, assim, onde existir maior demanda por essas relações, ali se tenha um fragmento ou réplica desta relação.(ramakrishnan; GEHRKE, 2008) Fragmentação A distribuição de dados, baseada em fragmentação das relações, pode ser definida da seguinte forma: A fragmentação consiste em subdividir uma relação em relações menores ou fragmentos e armazenar os fragmentos (em vez da relação em si), possivelmente em diferentes sites. Na fragmentação horizontal, cada fragmento consiste em um subconjunto de linhas da relação original. Na fragmentação vertical, cada fragmento consiste em um subconjunto de colunas da relação original. (RAMAKRISHNAN; GEHRKE, 2008, p.615). Figura 2.3 Fragmentação Vertical e Horizontal. Fonte: Ramakrishnan e Gehrke, 2008, p.616. A Figura 2.3 acima apresenta, a partir das linhas em destaque, a separação das colunas (Vertical) das linhas (horizontal) em uma fragmentação. Vale aproveitar a ilustração para dizer que, o fragmento horizontal pertence à cidade Chicago, seria adequado para aumentar a performance, diminuindo o custo com mensagens de acesso, manter esse fragmento em um site localizado em Chicago por exemplo, obtendo assim consultas e transações locais em um BDD como resultado da técnica.

50 49 (RAMAKRISHNAN; GEHRKE, 2008) Replicação Baseado em Ramakrishnan e Gehrke (2008) pode-se afirmar que técnica de replicação tem sido muito utilizada por duas motivações importantes, a primeira é a maior disponibilidade dos dados, a partir do princípio de que, caso um site fique impossibilitado de responder a consultas, por exemplo, tenha-se em outro site as mesmas informações, diminuindo as falhas de links de comunicação. A outra motivação principal é a avaliação de consultas mais rápida, a partir de cópias locais o retorno das consultas é mais rápido do que os fluxos de resposta provenientes de fontes remotas. Assim, Ramakrishnan e Gehrke (2008, p.616) defendem o seguinte: "Replicação significa que armazenamos várias cópias de uma relação ou fragmento de relação. Uma relação inteira pode ser replicada em um ou mais sites. [...]um ou mais fragmentos de uma relação podem ser replicados[...]". Imagine como exemplo da técnica, que uma relação se chame R, esta relação foi fragmentada em R1, R2 e R3, replica-se uma cópia de R1, R2 será replicada em outros dois sites e R3 replicado em todos, demonstrando assim, a flexibilidade alcançada com a replicação. (RAMAKRISHNAN; GEHRKE, 2008). 2.9 CATÁLOGO DISTRIBUÍDO Não é tarefa fácil acompanhar os dados distribuídos em fragmentos e réplicas. É preciso monitorar como as relações são distribuídas pelos sites e onde são armazenadas. As seções seguintes mostram algumas opções para esse monitoramento e dicas para manter a coerência dos dados em um BDD. (RAMAKRISHNAN; GEHRKE, 2008) Nomes Globais de Objetos Fragmentados e Replicados

51 50 Sempre que se possuir relações replicadas e fragmentadas, deve-se ter atenção em atribuir-lhes nomes. É necessário dar nomes unifocais a elas e caso se queira usar um servidor de nomes globais, a autonomia do sistema poderá ficar bastante prejudicada. Não obstante, precisa-se que cada site possa nomear objetos locais sem referenciar nomes do sistema. Uma solução para este problema é a criação de nomes compostos de vários campos. A partir de um nome local (nome dado localmente ao objeto), e um nome de site de nascimento (local onde foi criada a relação e têm-se informações das réplicas e fragmentos), pode-se chamar a combinação de: nome global da relação. Para as réplicas ou fragmentos de uma relação, usa-se o nome global da relação e adiciona-lhe um identificador (id) de réplica, assim, a essa nova combinação dá-se o nome de: nome global da réplica ou fragmento. (RAMAKRISHNAN; GEHRKE, 2008) Estrutura de Catálogo Em muitos BDDs, de acordo com Ramakrishnan e Gehrke (2008), pode-se ter uma cópia do catálogo de sistema global em um dos sites, esta é no entanto, uma estratégia que acarreta problemas de falhas e autonomia. Ao ocorrerem falhas em mais de um site, como por exemplo, indisponibilidade do catálogo por problemas de comunicação, simultaneamente no site com o catálogo original e o site com a cópia; e o problema com autonomia, onde as alterações de catálogo local deverão ser propagada para todos os sites, podendo sofrer o mesmo problema de falhas. O projeto System R da International Business Machines (IBM) culminou em um projeto chamado Distributed Databases R*, que preserva a autonomia e não é vulnerável a falhas de um único site ou dois. Conota uma estratégia de armazenamento de catálogos locais, onde cada catálogo descreve todas as cópias dos dados armazenados nesse site. Adicionalmente cada site de nascimento monitora o armazenamento das réplicas, com uma descrição exata do conteúdo de cada réplica, suas colunas e linhas, caso seja criada uma nova réplica o catálogo será atualizado no site de nascimento. Muitas vezes utiliza-se cache para acelerar o processo de consultas ao catálogo, porém ao realizar uma consulta ao catálogo em cache, este poderá estar desatualizado, necessita-se então uma atualização da cache

52 51 e posterior propagação baseado no catálogo de nascimento que sempre estará atualizado. (RAMAKRISHNAN; GEHRKE, 2008) Independência de Dados Distribuídos Trata-se de uma propriedade que possibilita aos usuários não especificar o nome completo dos objetos de dados acessados. Uma estratégia muito utilizada para se obter tal propriedade quando se deseja referenciar relações em outros sites, e até mesmo, relações criadas por outros usuários, é o uso de sinônimos para um nome global da relação. É possível ainda que os sinônimos sejam adaptados, permitindo que os usuários criem sinônimos de nomes globais de réplicas. (RAMAKRISHNAN; GEHRKE, 2008) PROCESSAMENTO DE CONSULTA DISTRIBUÍDA Baseado em Ramakrishnan e Gehrke (2008) sabe-se que existem problemas ligados à avaliação de operações da álgebra relacional em um BDD. Foca-se em duas relações, para que nas seções adiante se fale sobre esses problemas, e também da otimização de consulta distribuída. Considere: Marinheiros(id-marin: integer, nome-marin: String, avaliação: integer, idade: real), e Reservas(id-marin: integer, id-barco: integer, dia: date, nome-resp: String), ainda considere a relação Marinheiros com as seguintes propriedades delimitantes: 1 tupla = 50 bytes, 1 página pode ter até 80 tuplas, e são ao todo 500 páginas; e a relação Reservas com as propriedades delimitantes a seguir: 1 tupla = 40 bytes, 1 página pode ter até 100 tuplas, e ao todo temos 1000 páginas. De maneira que, nas próximas seções, o tempo de envio de uma página para outro site será denotado com Ts e o tempo gasto para ler ou gravar uma página no disco como Td. Com o intuito de saber quanto custa uma estratégia de avaliação, precisa-se contar o número de E/S de cada página, e contar o número de páginas enviadas de um site para outro. Precisa-se ainda, alterar o modelo de custo para permitir que se

53 52 conte o custo do envio das tuplas resultantes para o site onde foi realizada a consulta. (RAMAKRISHNAN; GEHRKE, 2008) Consulta sem Junção em SGBDD Algumas operações simples, como a que é apresentada a seguir, podem ser afetadas ao trabalhar com fragmentos e replicações em um SGBDD. Considere como exemplo ainda, que a relação Marinheiros (seção 2.10) esteja fragmentada horizontalmente, mantendo em um site A, localizado em Xangai, todas as tuplas com valores do atributo avaliação < 5. Em um site B localizado em Tóquio, apenas tuplas com valores do atributo avaliação > 5. SELECT M.idade FROM Marinheiros M WHERE M.avaliação > 3 AND M.avaliação < 7 A tarefa básica do SGBDD ao executar esta consulta é avaliá-la no site A e B, colhendo a união das repostas. No entanto, caso ainda se possua uma função de média de valores como Average (AVG), alterando a cláusula SELECT e adicionando AVG(M.idade), as respostas obtidas dos sites A e B não poderiam ser simplesmente unidas. Faz-se necessário que o SGBDD calcule a soma e realize uma contagem dos valores do atributo idade em A e B, usando essa informação para calcular a média de idade na relação Marinheiros. Alterando novamente a operação de consulta acima, pode-se considerar uma condição diferente na cláusula WHERE, por exemplo, M.avaliação > 6, isso implica que, o SGBDD tenha que reconhecer que avaliando apenas B, será possível obter a resposta. (RAMAKRISHNAN; GEHRKE, 2008) Junções em SGBDD Ramakrishnan e Gehrke (2008) declaram que as junções de relações em

54 53 diferentes sites, tornam-se muito impactantes no que diz respeito ao custo de envio, para atenuar este problema, destacam-se algumas opções de avaliação em BDD. Uso da cache e busca: é possível que se faça uma junção de loops aninhados com orientação a página no site A, usa-se então Marinheiros como relação externa e, em cada página de Marinheiros, busca-se todas as paginas de Reservas no site B. Caso se coloque as páginas do site B na cache elas serão recuperadas uma única vez, diminuindo muito o custo total da junção. (RAMAKRISHNAN; GEHRKE, 2008). Envio para um site: pode-se enviar a relação Marinheiros do site A para B e realizar a junção lá, enviar a relação Reservas de B para A, ou ainda enviar ambas para um site C requisitante. Como exemplo de custo, pode-se afirmar que enviar a relação Reserva para fazer a junção em A é de 1000(2Td + Ts) Td (notação na seção 2.10). (RAMAKRISHNAN; GEHRKE, 2008). Semijunções: Considere ainda a estratégia de enviar a relação Reservas para o site A, seguiremos 3 passos, 1º - No site A, calcule a projeção de Marinheiros nas colunas de junção, apenas o id-marin, e envie essa projeção para o site B. 2º No site B calcule a junção natural da projeção recebida com Reservas, ao resultado dá-se o nome de redução (de Reservas). 3º No site A, calcular a junção da redução de Reservas com Marinheiros. (RAMAKRISHNAN; GEHRKE, 2008). Bloomjoins: Muito parecida com a superior, percorre os mesmos passos, contudo no primeiro passo, um vetor de bits é enviado ao invés da projeção de Marinheiros. (RAMAKRISHNAN; GEHRKE, 2008) Otimização de Consulta Baseada em Custo Para otimização de consultas deve-se levar em conta os custos de comunicação e caso se possua várias cópias de uma relação será preciso decidir qual cópia usar, além disso, os sites individuais geralmente estão sobre o controle de SGBDs, a autonomia dos sites deverá ser respeita ao realizar um planejamento de otimização de consulta global. (RAMAKRISHNAN; GEHRKE, 2008). No plano global, a manipulação local de relações no site onde elas estão armazenadas é encapsulada em um plano local sugerido, de maneira que, o plano global inclui vários desses planos locais, os quais podem ser considerados como

55 54 subconsultas executadas em diferentes locais. No entanto Ramakrishnan e Gehrke (2008, p.623) descrevem: "Um site está livre para ignorar o plano local sugerido a ele, se for capaz de encontrar um plano mais barato [...]", isso é possível caso o SGBD do site local encontre informações mais atualizadas nos catálogos locais. Respeitando assim a autonomia do site nas avaliações de consultas distribuídas. (RAMAKRISHNAN; GEHRKE, 2008) ATUALIZAÇÃO DE DADOS DISTRIBUÍDOS A busca pela transparência em um BDD sempre será uma visão desejável, principalmente do ponto de vista do usuário, que não deseja saber onde estão as replicas da relação para efetuar uma propagação de uma transação qualquer. As atualizações não são diferentes em BDDs, elas precisam ser atômicas, independentes de fragmentos ou réplicas, o que leva-se a: "[...] todas as cópias da relação modificada devem ser atualizadas antes que a transação modificadora seja efetivada." (RAMAKRISHNAN; GEHRKE, 2008, p.624), a essa premissa dá-se o nome de replicação síncrona, pois ela sincroniza todas as outras cópias antes de serem efetivadas. (RAMAKRISHNAN; GEHRKE, 2008). Existe uma outra estratégia chamada replicação assíncrona, muitíssimo usada em SGBDDs comerciais. Tal estratégia faz uma atualização retardada das modificações, o que prejudica a independência dos dados, no entanto é mais fácil de ser implementada. (RAMAKRISHNAN; GEHRKE, 2008) TRANSAÇÕES DISTRIBUÍDAS Ao submeter uma transação em um site do BDD, pode ser que esta transação acesse dados em outros sites, dá-se o nome a esta atividade externa de subtransação, que é transparente ao usuário. Como o SGBD realiza isso? Existe um gerenciador de transação local, que por sua vez, subdivide a transação em um conjunto de subtransações, submetendo-as aos demais sites do BDD, e

56 55 coordenando-as. (RAMAKRISHNAN; GEHRKE, 2008). Caso a transação requisite recursos bloqueados, o gerenciador passa ao controlador de concorrência (responsável pela aquisição e liberação de bloqueios) a operação do BD e informações adicionais. É adiada então, até que o bloqueio seja adquirido. Assim que ele é adquirido, a operação é enviada ao processador em tempo de execução que trata da execução real da operação do BD, e quando concluída as operações, os bloqueios são liberados e o gerenciador de transação é atualizado com os resultados. (ELMASRI; NAVATHE, 2011) CONTROLE DE CONCORRÊNCIA DISTRIBUÍDO É importante que se saiba como os pedidos de bloqueio e liberação são tratados em um BDD, para tal, se elenca três formas bem definidas de tratamento dos objetos pelo gerenciador, segundo Ramakrishnan e Gehrke (2008): Centralizado: um site é responsável por tratar os pedidos de bloqueio e desbloqueio de todos os objetos, esta é uma forma muito propensa a falhas, visto que caso o site responsável falhe não haverá efetivação dos bloqueios e liberações. Cópia primária: os pedidos de bloqueio e desbloqueio são direcionados a cópias dos objetos, chamadas cópias primárias, são manipuladas pelo gerenciador de bloqueio do site que possui a cópia primária, não importando onde a cópia original esteja armazenada. Esta forma soluciona o problema citado acima, mas ainda possui o problema de precisar ler dois sites. Totalmente distribuído: os pedidos são manipulados pelo gerenciador de bloqueios do site onde a cópia esta armazenada. O bloqueio será feito onde a cópia a ser lida reside, esse é o mais eficaz, pois durante a gravação, bloqueios são estabelecidos em todos os sites onde as cópias forem alteradas, e isso justifica sua eficácia, pois em geral, ocorrem mais leituras do que escritas Deadlock Distribuído

57 56 Ao usar cópia primária ou bloqueio totalmente distribuído é preciso atentar para uma questão importante, a detecção de deadlocks (impasses), por ser uma estratégia amplamente usada. Da mesma forma que em um SGBD centralizado, os deadlocks deverão ser detectados e solucionados (cancelando alguma transação em impasse). (RAMAKRISHNAN; GEHRKE, 2008). Assim: "Cada site mantém um grafo de "espera por" e um ciclo em um grafo local indica um impasse." (RAMAKRISHNAN; GEHRKE, 2008, p.628), não obstante, ocorrerão impasses, ainda que nenhum grafo local contenha um ciclo. Suponha: [...] dois sites, A e B, contenham cópias de objetos O1 e O2 e que seja usada a técnica de ler qualquer uma, gravar todas. T1, que quer ler O1 e gravar O2, obtém um bloqueio S em O1 e um bloqueio X em O2 no Site A, então, solicita um bloqueio em O2 no Site B. Nesse meio tempo, T2, que quer ler O2 e gravar O1, obtém um bloqueio S em O2 e um bloqueio X em O1 no Site B, então, solicita um bloqueio X em O1 no Site A. (RAMAKRISHNAN; GEHRKE, 2008, p.628). A Figura 2.4 ilustra o deadlock, assim T2 espera por T1 no site A e T1 espera por T2 no site B. Um impasse que ambos não poderiam detectar unicamente pelo grafo Waits-for (espera por), também apresentado pela Figura 2.4 abaixo: Figura 2.4 Deadlock distribuído. Fonte: Ramakrishnan e Gehrke, 2008, p.629 Segundo Ramakrishnan e Gehrke (2008) pode-se usar três algoritmos de detecção de impasses distribuídos: Centralizado: envia periodicamente todos os grafos de waits-for locais para um

58 57 único site administrador de impasses globais, que por sua vez, gera um grafo de waits-for global. Hierárquico: posiciona os sites em uma hierarquia, pode ser uma hierarquia global, por exemplo, cidade, estado, país, continente. Dessa forma, os grafos de waits-for são enviados periodicamente (10 segundos por exemplo) a partir de seus grupos, para que se monte um grafo do grupo, que será posteriormente adicionado ao grafo global. Simples: uma transação que espere mais tempo do que um intervalo de tempo determinado é cancelado, este algoritmo pode causar muitos reinícios, porém em um BDD heterogêneo, onde os sites por algum motivo não possam compartilhar seus grafos waits-for, ele pode ser a única opção RECUPERAÇÃO DISTRIBUÍDA Vários são os fatores que tornam a recuperação em BDD mais complexa que em BD centralizados, por exemplo, falhas de links de comunicação, falhas de um site remoto onde uma subtransação é executada. Assim, baseado na premissa apresentada por Ramakrishnan e Gehrke(2008, p.630): "todas as subtransações de uma determinada transação devem ser efetivadas ou nenhuma deve ser efetivada[...][...]a despeito de qualquer combinação de falhas de site e de link.", como o SGBD deverá proceder caso subtransações não forem efetivadas? Essa pergunta leva a necessidade de uma garantia, que pode ser obtida através do protocolo de efetivação. (RAMAKRISHNAN; GEHRKE, 2008). Em todos os sites onde se origina uma transação, temos um coordenador da transação, os gerenciadores de transação locais, como vistos anteriormente, são chamados de subordinados nesse contexto, e tanto o protocolo de efetivação quanto os coordenadores, serão vistos nas seções seguintes. (RAMAKRISHNAN; GEHRKE, 2008) Protocolo de Efetivação de Duas Fases

59 58 De acordo com Ramakrishnan e Gehrke (2008), o protocolo de efetivação de duas fases, em inglês, Two Phase Commit (2PC), tem sido adotado como padrão para o setor. Ao decidir efetivar uma transação, o comando de efetivação é enviado ao coordenador da transação, assim, o protocolo 2PC começa a atuar da seguinte forma: 1º - O coordenador envia uma mensagem preparar para cada subordinado. 2º - Ao receber a mensagem de preparar o subordinado decide se vai cancelar ou efetivar sua subtransação, impõe a gravação de um registro de log de cancelamento ou preparação e envia uma mensagem de sim ou não para o coordenador. 3º - Caso todos os subordinados enviaram mensagens com sim, o coordenador impõe a gravação de um log de efetivação e depois envia a mensagem efetivar para todos. Se as mensagens dos subordinados forem não, mesmo que apenas uma, ou nenhuma por um tempo determinado, imporá a gravação de um log de cancelamento e enviará cancelar para todos os subordinados. 4º - Do lado do subordinado, ele pode receber cancelar ou efetivar do coordenador, grava um log de cancelamento ou efetivação de acordo com o que recebeu, envia mensagem de efetivar ou cancelar a subtransação para o coordenador, e cancela ou efetiva a subtransação. 5 - De posse das confirmações o coordenador grava um registro de log final para a transação. O protocolo de efetivação de duas fases é assim nomeado por se tratar de duas rodadas de trocas de mensagens entre o coordenador e os subordinados, uma de votação e outra de finalização, ambas são iniciadas pelo coordenador. (RAMAKRISHNAN; GEHRKE, 2008) Reinício Após Falha Depois de uma falha, o SGBDD ativa um processo de recuperação que realiza a leitura do log, retomando todas as transações que executavam o protocolo de efetivação no momento da falha. Para que o sistema se recupere, considere então um log de efetivação ou cancelamento para a transação T, conclui-se ou desfaz-se T de

60 59 acordo com o conteúdo do log. Caso o log seja de preparação este é um subordinado, deverá então retomar sua atividade dentro do protocolo de efetivação, baseado na resposta do coordenador. Pode ser que não se tenha nem mesmo um log, então, significa que o responsável por T não votou na efetivação antes da falha, o que garante que T pode ser cancelada e desfeita, em seguida, grava-se um log final. (RAMAKRISHNAN; GEHRKE, 2008). O Two Phase Commit (2PC) é vulnerável a falhas no coordenador durante a recuperação, mesmo que todos os subordinados tenham votado sim, o coordenador pode ter decidido cancelar T, e isso não poderá ser determinado, até que o coordenador se recupere, diz-se que T esta bloqueada. (RAMAKRISHNAN; GEHRKE, 2008) Efetivação de Três Fases De acordo com Ramakrishnan e Gehrke (2008), o protocolo de efetivação de três fases, em inglês, Three Phase Commit (3PC), pode evitar o bloqueio, ainda que o coordenador falhe durante a recuperação, basicamente ao enviar mensagens de preparar e receber votos sim de todos os subordinados, ele enviará uma mensagem de pré-efetivar, quando um número suficientes de mensagens forem recebidas, o coordenador requisita a gravação de um log de efetivação e envia efetivar para os subordinados. Caso ele falhe antes de enviar efetivar, os sites poderão se comunicar e detectar se devem ou não efetivar suas subtransações, isso baseado no retardo do coordenador ao efetivar até que todos soubessem do comum acordo de efetivação definido pelo 3PC. (RAMAKRISHNAN; GEHRKE, 2008).

61 60 3 AVALIAÇÃO DE DESEMPENHO Conforme Branco (2004) diversos trabalhos foram desenvolvidos com o objetivo de explorar os sistemas computacionais distribuídos, sendo assim, esta área trouxe uma sucessão de ideias e vantagens, como a redução de custos e utilização mais adequada de recursos computacionais. Desse modo, a utilização de índices corresponde a métricas usadas para quantificar o tempo de resposta provido por cada elemento do SD, podendo ser influenciada por diversas variáveis, pelos seus níveis e fatores. 3.1 VARIÁVEIS Assim como em outras áreas, na computação existem diversos parâmetros que possuem diferentes efeitos sobre o desempenho, é muito importante identificar estes parâmetros, pois podem trazer impactos significante sobre o desempenho, relacionados com a confiabilidade dos recursos e componentes dos sistemas computacionais. Quando uma quantidade é especificada, ou quando se refere a uma propriedade de recursos, essa grandeza ou propriedade é denominada variável. Valores quantificados de uma variável são denominados medida. Quando uma medida é quantificada, sua medida deve ser apresentada em termos de unidades padronizadas, por exemplo, tempo de resposta ou vazão em milissegundos. (JAIN, 1991). Segundo Branco (2004) o índice de teste de desempenho pode ser definido formalmente como uma variável numérica, não negativa, assumindo valor zero quando está ocioso e tendo seu valor acrescido positivamente quando a carga desse recurso aumenta e identificar o índice de desempenho de BDD apropriado, de maneira a obter um aumento considerável da utilização dos recursos ociosos, sendo um ponto importante a ser considerado no projeto de qualquer tentativa de avaliação de desempenho. Contanto que esta seja executada em uma determinada máquina e apontando o objetivo ao qual se propõe os testes. Informando não só o desempenho

62 61 atual do sistema, mas ser utilizado também para predizer um comportamento futuro, baseando-se em uma situação presente ou em um passado recente. 3.2 FATORES E NÍVEIS De acordo com Branco (2004) Fatores são os elementos que contribuem para um resultado ou uma situação em particular, pode-se dizer que existem fatores que são decisivos para atingir o melhor desempenho em BDD, assim sendo os fatores sofrem variação que podem ser tomados como níveis, que de forma agrupada e em conjunto denotam grau de peculiaridades e/ou dificuldades, podendo assim determinar estágio e quantidade de valores. Em seu valor etimológico, nível aqui, trata-se de uma escala que infere sobre os fatores. Portanto, para cada fator têm-se diferenças entre níveis, que por sua vez possuem variáveis. Conforme Branco (2004), as aplicações são classificadas como interativas por que necessitam de grande interação com os usuários. O tempo de resposta é um dos aspectos mais importante, devendo ser o mais rápido possível, evitando causar atrasos de respostas aos usuários. Dimensionar um teste de desempenho não é simples, uma vez que não existe uma única maneira correta para determinar se o desempenho está compatível com sua capacidade, além de que a demanda pelos recursos disponíveis em um sistema computacional distribuído pode variar de um tipo para outro.

63 62 4 DESENVOLVIMENTO DO PROJETO 4.1 AMBIENTE DE TESTE O ambiente de teste utilizado neste projeto pode ser divididos em três subambientes: Ambiente físico, ambiente virtual e o terceiro de BDD. O primeiro subambiente foi composto por oito computadores da marca Itaultec, modelo Infoway ST4253. Todos os computadores possuem hardware similar compostos por CPU Core 2 duo de 2.53 Ghz com cache L2 de 3MB, 2 módulos de memória Catalyst 01GN80KFUA8 DDR-2 800Mhz de 1GB cada, com temporizações de memória de , Disco Rígido 160 GB, placa de rede RealTek RTL8168C (P) PCI-E Gigabit Ethernet NIC, para realizar a conexão entre os hosts computacionais foi utilizado um Switch D-Link DES-1024D 10/100 Mbit/s e cabos de rede par trançado devidamente montados no padrão T-568A com conectores RJ45. Esses computadores utilizaram como SO Windows XP Professional Service Pack 3 (SP3) x86 com drivers dos dispositivos devidamente instalados e software monitor de máquina virtual, do inglês: Virtual Machine Monitor (VMM) Oracle VM VirtualBox versão r Essa composição de hardware serviu de estrutura para a construção do ambiente virtualizado, que foi composto por oito máquinas virtuais, do inglês: Virtual Machine (VMs), instaladas individualmente sobre cada um dos oitos computadores, também chamados de hospedeiros, por receber as VMs, que por sua vez são chamadas de convidados. Para cada VM foi utilizado SO Windows XP Professional SP3 x86, e, além disso, foi instalado os adicionais para o convidado, que são fornecidos no pacote da VMM utilizada. Em sete das VMs foi instalado o Oracle 11g XE 11.2, já com Application Express (APEX) e na oitava VM foi utilizado, com exceção do BD, os mesmo softwares das outras sete, incluindo apenas o software para realização dos experimentos do lado do cliente (Jmeter e Java Development Kit (JDK) 6 update 21). O terceiro ambiente dentro deste cenário é o BDD, que por sua vez foi composto de seis hosts Masters (Hm1 a Hm6 vide Figura 4.1) contendo cada um uma tabela já populada e um host Slave (MviewSynonym vide Figura 4.1), que em um

64 63 primeiro nível estrutural utiliza Synonym e Database-links para cada tabela em cada servidor de BD remoto, e em um segundo nível estrutural, contém Materialized View para cada uma das tabelas em cada servidor de BD remoto. A Figura 4.1 mostra a disposição dos hosts no ambiente experimental, de maneira que cada um deles integra o BDD, exceto o Host_Jmeter que é o cliente nesse ambiente. Figura 4.1 Disposição dos Hosts no Ambiente Experimental. Fonte: Elaborado pelos autores. É importante ainda destacar que o modelo de dados utilizado foi obtido juntamente com o pacote do BD, porém foi adaptado para que cada uma das chaves estrangeiras das tabelas referenciassem as outras tabelas remotamente. Para maiores detalhes sobre configurações do ambiente virtualizado e o ambiente de BDD, consulte os Anexos em DVD, lá estão disponíveis VÍDEOS DE INSTRUÇÕES de diversas etapas de implementação do projeto. 4.2 METODOLOGIAS DE PESQUISA Para melhor disponibilidade, desempenho e confiabilidade é usual que se implemente BDD utilizando réplicas, sinônimos ou ambos (NAVATHE, 2011). A definição da metodologia de pesquisa mediante a tantas possibilidade de implementação de BDD, foi definida baseando-se na necessidade de se medir o desempenho, de acordo com o TMR das operações de leitura em um BDD, que

65 64 possuísse transparência de réplicas e tabelas, buscando-se definir qual fator inserido neste contexto seria o mais influente. Com o objetivo de definir os fatores mais influentes foi implementado um BDD que possuísse em um primeiro momento Synonym para as tabelas em cada host Master, e em um segundo momento, Materialized View para cada uma das tabelas, concentrando essas réplicas em um host Slave, ainda foram implementados DbLinks entre os hosts Masters e de cada host Master para o host Slave. Foi necessário ainda que se implementassem comandos de seleção envolvendo três tabelas, sendo cada uma de um host diferente, e seis tabelas cada uma pertencendo a um host. Almejouse que estes comandos de seleção possuíssem um determinado custo de processamento e um dado nível de complexidade envolvendo junções e filtros totalmente aleatórios. Caso necessite, verifique os vinte comandos de seleção presente nos arquivos.csv dispostos no DVD anexo ao trabalho. Para os experimentos de desempenho foi considerado de maior relevância o TMR e para tal utilizamos a ferramenta Jmeter, que oferece as medições em milissegundos, este é usado como um aferidor para obtenção de valores em análise, conforme o quadro abaixo exemplifica os fatores e níveis (1 representa o nível Synonym, 5000, 03 Tabelas e -1 representa o nível Materialized View, e 06 Tabelas ). Quadro 4.1 Disposição fatores e níveis Fator 1-1 Estrutura interna do BDD Synonym Materialized View Quantidade de Requisições Número de Tabelas 03 Tabelas 06 Tabelas Fonte: Elaborado pelos autores. 4.3 PLANEJAMENTO DE EXPERIMENTOS Segundo Jain (1991) os valores tomados como parâmetros, são aspectos importantes na análise de desempenho e que devem ser levados em conta, como por exemplo o número de usuários, neste planejamento de experimentos foi utilizado dez

66 65 e vinte usuários com quinhentas requisições de leitura cada, satisfazendo assim, o fator Quantidade de Requisições, variando em dois níveis, e Para realizar o cruzamento de todas as possibilidades foi utilizado o fatorial completo. Quadro Disposição dos experimentos cruzando fatores e níveis a partir de fatorial completo A B C Experimentos Estrut. Int. Num. Requisições Núm. Tabelas 1 SYN ( 1 ) 5000 ( 1) 3 ( 1) 2 SYN ( 1 ) 5000 ( 1) 6 (-1) 3 SYN ( 1 ) (-1) 3 ( 1) 4 SYN ( 1 ) (-1) 6 (-1) 5 MAT (-1 ) 5000 ( 1) 3 ( 1) 6 MAT (-1 ) 5000 ( 1) 6 (-1) 7 MAT (-1 ) (-1) 3 ( 1) 8 MAT (-1 ) (-1) 6 (-1) Fonte: Elaborado pelos autores. A disposição dos experimentos é mostrada no Quadro 4.2, pode-se notar os oito experimentos na primeira coluna da esquerda, na primeira linha os três fatores e a partir da segunda linha seus respectivos níveis. Para entender a influência dos fatores no ambiente de experimento proposto foi necessário cruzar níveis de cada fator. Assim constituiu-se Quadro 4.3 onde qa, qb, qc representam influências sobre yx, e qab representa influência da união das influências de qa e qb e o mesmo se aplica as outras uniões de influências, qac, qbc, qabc. Quadro Disposição dos níveis a partir de representação matemática Tabela de Combinações qa qb qc qab qac qbc qabc y y y y y y y y Fonte: Elaborado pelos autores.

67 66 Exemplo: y5 que para qa =-1, qb =1, e qc =1 a união de qa e qb = (- 1)+(1)= -1, para a união de qa e qc = (-1)+(1)= -1, segundo Jain (1991) o valor obtido trata-se de uma representação numérica para o cálculo de influência dos fatores. E com base na seguinte fórmula de fatorial completo o Quadro 4.2 e 4.3 foram constituídos: Assim verifica-se que, são 2³ experimentos, onde 2 representa o número de níveis, e 3 o número de fatores, logo, o planejamento utilizando o fatorial completo irá gerar a seguintes combinações: Exemplo de calculo de influência de A (qa): ( ) ( ) ( ) ( )) Observe o Quadro 4.3, na primeira coluna (qa) pode-se notar todas as representações de níveis que se utiliza na formula acima. Dessa maneira as combinações proporcionam a influência dos fatores, que por sua vez permite calcular a soma total e individual dos quadrados com a fórmula a seguir: Exemplo de soma total dos quadrados de todas as influências (SST):

68 67 Exemplo de soma dos quadrados individual de A (SSA): O TMR de todas as repetições é expresso pelos valores, logo tornar-se possível verificar a influência dos fatores, bem como se relacionam. Segundo Jain (1991) fatores são considerados importantes quando resultam em altas variações, de modo que para obter a importância de cada fator em particular, toma-se o valor do fator dividido pelo valor de SST, conforme segue: Na presente avaliação de desempenho, por exemplo, o numerador na fórmula acima é a estrutura interna do BDD, é importante destacar que cada experimento foi realizado dez vezes, fato pelo qual pode se obter um nível confiável de amostras, baseando-se na fórmula de intervalo de confiança (IC): Distribuindo as dez repetições para cada experimento formulou-se a tabela t- student, que se trata de uma tabela constituída de todas as médias das repetições que pode ser observada nos Anexos em DVD, o desvio padrão foi obtido a partir dos índices de TMR de cada repetição, a variável t_student é representada pelo número dez, pois foram realizadas dez repetições. Exemplo de cálculo de IC: 4.4 RESULTADOS ESPERADOS

69 68 Espera-se que o fator Estrutura Interna do BDD, seja o mais influente, no entanto, a comprovação dos resultados deve ser mediante a metodologia discutida no capítulo 3 e 4. Espera-se, ainda, que por se realizar estes experimentos em um ambiente virtualizado, isso provoque um nível de processamento mais intenso, por parte dos hospedeiros, mas sem afetar a validade das amostras coletadas.

70 69 5 RESULTADOS E DISCUSSÃO Uma das garantias que se obteve quanto à validade dos experimentos, são os índices de confiança, apresentados no Gráfico 5.1, logo se percebe que o 4º experimento possui um IC mais alto, porém se justifica, pelo maior TMR visto no Gráfico 5.2 também para o 4º experimento. Gráfico Índice de Confiança obtido em cada experimento IC Fonte: Elaborado pelos autores. A partir do bombardeio de requisições realizado com a ferramenta Jmeter foi possível obter os indicadores de TR, de posse dos resultados de cada uma das dez repetições foi feita a média, para que se obtivesse o TMR apresentado no Gráfico 5.2. Gráfico TMR obtido em cada Experimento Fonte: Elaborado pelos autores.

71 70 No primeiro experimento percebe-se que o TMR, entre todas as dez repetições, foi de 215,70, no segundo experimento de 433,20, no terceiro de 559,20, no quarto de 1153,70, no quinto de 102,80, no sexto de 238,60, no sétimo de 223,70 e no oitavo de 486,10. É possível perceber que o quarto experimento resultou no maior TMR obtido dentre todos os experimentos, conclui-se previamente, que existem fatores inseridos neste experimento que provocam essa diferença, é necessário apontar tais fatores. Inicialmente observou-se o TMR agrupando-os pelo fator Estrutura Interna do BDD, perceba no Gráfico 5.3 o agrupamento dos experimentos que possuem o fator Estrutura Interna do BDD com nível Synonym (SYN). Gráfico Estrutura Interna do BDD, agrupados pelo Nível 1 Synonym Fonte: Elaborado pelos autores. O Gráfico 5.4 agrupa os experimentos por estrutura interna do BDD, porém com nível Materialized View (MAT). Gráfico Estrutura interna do BDD, agrupados pelo Nível -1 Materialized View Fonte: Elaborado pelos autores.

72 71 Comparando o Gráfico 5.3 com o Gráfico 5.4, é perceptível o aumento no TMR quando a estrutura interna do BDD possui sinônimos, por outro lado, o uso de réplicas realmente aumenta o desempenho em requisições de leitura de dados. Pode-se perceber ainda que nesse ambiente, o TMR sofreu uma latência de rede real, interferindo significativamente nesses índices, quando se utilizou sinônimos (SYN), provocou-se acesso a outros seis hosts remotos, enquanto que, com o uso de réplicas (MAT), que no ambiente proposto acessam um host, que por sua vez possui réplicas dos seis hosts remotos (HM1,HM2,HM3,HM4,HM5,HM6), não provocando assim, o acesso direto a eles, influenciando positivamente o desempenho do TMR, resultando em índices menores. Gráfico Número de Requisições, agrupados pelo Nível Fonte: Elaborado pelos autores. Gráfico Número de Requisições, agrupados pelo Nível Fonte: Elaborado pelos autores. Para os Gráficos 5.5 e 5.6 os dados estão agrupados por números de requisições, o que mostra nesse comparativo, que o número de requisições é um fator

73 72 muito influente dado à diferença entre o maior TMR com requisições e o maior TMR com requisições, um subfator já apresentado no Capítulo 4 e que está atrelado a essa diferença, é a quantidade de usuários, que para esse teste foi de dez usuários e vinte usuários com quinhentas requisições para ambos. Nos Gráficos 5.7 e 5.8 o agrupamento foi realizado por tabelas. Nota-se com este tipo de agrupamento que ao dobrar o número de tabelas, neste ambiente proposto, praticamente dobra-se o TMR de cada experimento, independente do tipo de estrutura interna, por exemplo, a diferença entre o primeiro experimento e o segundo experimento é de 217,5 milissegundo, o que mostra que, mesmo com a quantidade de requisições constante e o tipo de estrutura interna constante, ao dobrar-se o número de tabelas o TMR praticamente dobra. Gráfico Número de Tabelas, agrupados pelo Nível 1 03 Fonte: Elaborado pelos autores. Gráfico Número de Tabelas, agrupadas pelo Nível Fonte: Elaborado pelos autores.