Banco de Dados Distribuídos

Transcrição

1 Banco de Dados Distribuídos Brasília-DF, 2011.

2 Elaboração: Ednewton de Vasconcelos Produção: Equipe Técnica de Avaliação, Revisão Linguística e Editoração Banco de Dados Distribuídos 2

3 Sumário Apresentação... 4 Organização do Caderno de Estudos e Pesquisa... 5 Organização da Disciplina... 6 Introdução... 8 Unidade I Introdução a Banco de Dados Distribuídos... 9 Capítulo 1 Conceito de Banco de Dados Distribuídos... 9 Capítulo 2 Algumas Questões Preliminares Capítulo 3 Funções Adicionais do Banco de Dados Distribuídos Unidade II Princípio de Banco de Dados Distribuídos Capítulo 4 Fundamentos do Banco de Dados Distribuídos Unidade III Arquitetura e Projeto de Banco de Dados Distribuídos Capítulo 5 Transações Capítulo 6 Tipos de Sistemas BDD Capítulo 7 Problemas de Sistemas Distribuídos Unidade IV Controle, Sincronização e Atualização em Sistemas Distribuídos Capítulo 8 Processamento de Consulta de Sistemas de Diretório e Protocolos de Acesso ao Diretório Para (Não) Finalizar Referências Pós-Graduação a Distância 3

4 Apresentação Caro aluno, Bem-vindo ao estudo da disciplina Banco de Dados Distribuídos. Este é o nosso Caderno de Estudos e Pesquisa, material elaborado com o objetivo de contribuir para a realização e o desenvolvimento de seus estudos, assim como para a ampliação de seus conhecimentos. Para que você se informe sobre o conteúdo a ser estudado nas próximas semanas, conheça os objetivos da disciplina, a organização dos temas e o número aproximado de horas de estudo que devem ser dedicadas a cada unidade. A carga horária desta disciplina é de 40 (quarenta) horas, cabendo a você administrar o tempo conforme a sua disponibilidade. Mas, lembre-se, há uma data-limite para a conclusão do curso, incluindo a apresentação ao seu tutor das atividades avaliativas indicadas. Os conteúdos foram organizados em unidades de estudo, subdivididas em capítulos de forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões para reflexão, que farão parte das atividades avaliativas do curso; serão indicadas também fontes de consulta para aprofundar os estudos com leituras e pesquisas complementares. Desejamos a você um trabalho proveitoso sobre os temas abordados nesta disciplina. Lembre-se de que, apesar de distantes, podemos estar muito próximos. A Coordenação Banco de Dados Distribuídos 4

5 Organização do Caderno de Estudos e Pesquisa Apresentação: Mensagem da Coordenação. Organização da Disciplina: Apresentação dos objetivos e da carga horária das unidades. Introdução: Contextualização do estudo a ser desenvolvido por você na disciplina, indicando a importância desta para sua formação acadêmica. Ícones utilizados no material didático Provocação: Pensamentos inseridos no material didático para provocar a reflexão sobre sua prática e seus sentimentos ao desenvolver os estudos em cada disciplina. Para refletir: Questões inseridas durante o estudo da disciplina, para estimulá-lo a pensar a respeito do assunto proposto. Registre sua visão, sem se preocupar com o conteúdo do texto. O importante é verificar seus conhtecimentos, suas experiências e seus sentimentos. É fundamental que você reflita sobre as questões propostas. Elas são o ponto de partida de nosso trabalho. Textos para leitura complementar: Novos textos, trechos de textos referenciais, conceitos de dicionários, exemplos e sugestões, para lhe apresentar novas visões sobre o tema abordado no texto básico. Sintetizando e enriquecendo nossas informações: Espaço para você fazer uma síntese dos textos e enriquecê-los com sua contribuição pessoal. Sugestão de leituras, filmes, sites e pesquisas: Aprofundamento das discussões. Praticando: Atividades sugeridas, no decorrer das leituras, com o objetivo pedagógico de fortalecer o processo de aprendizagem. Para (Não) finalizar: Texto, ao final do Caderno, com a intenção de instigá-lo a prosseguir com a reflexão. Referências: Bibliografia consultada na elaboração da disciplina. Pós-Graduação a Distância 5

6 Organização da Disciplina Ementa: Introdução aos conceitos de distribuição no contexto das tecnologias de gerência de bases de dados. Aspectos de arquiteturas de sistemas de banco de dados distribuídos. Projeto de bases de dados distribuídas. Apresentação de técnicas envolvidas no processamento distribuído de consultas. Características da gerência de transações. Tendências atuais enfocando os sistemas de banco de dados distribuídos orientados a objetos e os servidores de dados distribuídos. Características de processamento paralelo em sistemas de banco de dados. Algoritmos de processamento paralelo de consultas. Avaliação de desempenho. Análise dos principais sistemas de banco de dados com processamento paralelo. Objetivos: Apresentar as principais metodologias voltadas para a área de desenvolvimento de projetos de banco de dados distribuídos. Conhecer os procedimentos para um entendimento entre os bancos de dados distribuídos e paralelos. Apresentar os mecanismos para a implantação de banco de dados distribuídos. Refletir sobre a gerência, manutenção de banco de dados distribuídos. Elaborar algumas variedades de banco de dados diferentes gerenciados por vários SGBDs. Unidade I Introdução a Banco de Dados Distribuídos Carga horária: 8 horas Conteúdo Capítulo Conceito de Banco de Dados Distribuídos 1 Algumas Questões Preliminares 2 Funções Adicionais do Banco de Dados Distribuídos 3 Unidade II Princípio de Banco de Dados Distribuídos Carga horária: 12 horas Conteúdo Capítulo Fundamentos do Banco de Dados Distribuídos 4 Banco de Dados Distribuídos Unidade III Arquitetura e Projeto de Banco de Dados Distribuídos Carga horária: 15 horas Conteúdo Capítulo Transações 5 Tipos de Sistemas BDD 6 Problemas de Sistemas Distribuídos 7 6

7 Organização da Disciplina Unidade IV Controle, Sincronização e Atualização em Sistemas Distribuídos Carga horária: 5 horas Conteúdo Processamento de Consulta, de Sistemas de Diretório e Protocolos de Acesso ao Diretório Capítulo 8 Pós-Graduação a Distância 7

8 Introdução Imaginação é mais importante que inteligência. Albert Einstein As empresas, os bancos, o comércio, as indústrias e os mais diversos segmentos sociais têm estado muito interessados na descentralização do processamento de suas informações independentemente da localização geográfica de seus escritórios. E com a explosão da Internet ligada aos avanços tecnológicos e aos avanços nas telecomunicações, estas empresas estão cada vez mais propícias a utilizarem Banco de Dados Distribuídos (BDD). A tecnologia de BDD surgiu como uma fusão de duas tecnologias: a de banco de dados e a tecnologia de rede e telecomunicações de dados. Enquanto os primeiros bancos de dados se voltaram para a centralização e resultaram em bancos de dados monolíticos nos anos 1970, logo nas décadas seguintes, o sistema de banco de dados foi-se alterando em pequenas proporções até chegar aos dias de hoje com o avanço de sistemas distribuídos e também decorrente dos sistemas operacionais distribuídos. Ao contrário dos sistemas paralelos, em que os processadores são bastante acoplados e constituem um único sistema de banco de dados, um sistema de banco de dados distribuídos consiste em sites poucos acoplados, que não compartilham componentes físicos. Além do mais, os sistemas de banco que executam em cada site podem ter um grau de independência mútua substancial. Outro fator relevante foi a comunidade de pesquisa de banco de dados ter desenvolvido um trabalho considerável para tratar as questões de distribuição de dados distribuídos e de outros tópicos, bem como ter desenvolvido muitos protótipos de pesquisa. Neste caderno será abordado, o tema banco de Dados Distribuídos, desenvolvimento de tecnologia de banco de dados que está aproximadamente vinculada aos avanços da tecnologia de telecomunicações e de rede. Banco de Dados Distribuídos 8

9 Introdução a Banco de Dados Distribuídos Unidade I Unidade I Introdução a Banco de Dados Distribuídos Se vocês acham que os seus professores são rudes, esperem até terem um chefe. Ele não vai ter pena de vocês. Bill Gates Capítulo 1 Conceito de Banco de Dados Distribuídos Os bancos de dados distribuídos trazem as vantagens da computação distribuída para o domínio do gerenciamento de banco de dados. Um sistema de computação distribuída consiste em vários elementos de processamento, não necessariamente homogêneos, que são interconectados por uma rede de computador e cooperam na execução de certas tarefas. Como uma meta genérica, os sistemas de computação distribuídos dividem um problema grande e intratável em partes menores e os resolvem de maneira eficiente e coordenada. Podemos definir um Banco de Dados Distribuído (BDD) como uma coleção de múltiplos bancos de dados logicamente interrelacionados distribuídos por uma rede de computadores, e um sistema de Gerenciamento de Banco de Dados Distribuídos (SGBD) como um sistema de software que gerencia um banco de dados distribuído enquanto torna a distribuição transparente para o usuário. Uma coleção de arquivos armazenados em nós diferentes de uma rede e a manutenção de inter-relacionamentos entre eles via hiperlinks se tornou uma configuração comum na Internet, com os arquivos Web. As funções comuns de gerenciamento de banco de dados, incluindo o processamento uniforme de consultas e o processamento de transações, não se aplicam, contudo, a esse cenário. Porém, a tecnologia está se modificando em uma direção tal que bancos de dados distribuídos no World Wide Web (WWW) se tornarão uma realidade no futuro próximo. Banco de Dados Homogêneos e Heterogêneos Em um sistema de banco de dados distribuídos homogêneo, todos os sites possuem software de sistema de gerenciamento de banco de dados idêntico, conhecem um ao outro e concordam em cooperar nas solicitações dos usuários do processamento. Neste tipo de sistema, os sites locais entregam uma parte de sua autonomia em termos do seu direito de mudar esquemas ou software de sistema de gerenciamento de banco de dados. Esse software também precisa cooperar com outros sites na troca de informações sobre transações, para tornar o processamento da transação possível entre vários sites. Pós-Graduação a Distância 9

10 Introdução a Banco de Dados Distribuídos Unidade I Ao contrário, em um banco de dados distribuídos heterogêneo, diferentes sites podem usar diferentes esquemas e softwares de sistemas de gerenciamento de banco de dados. Os sites podem não ser cientes um do outro e podem oferecer facilidades apenas limitadas para cooperação no processo da transação. As diferenças nos esquemas normalmente são um problema importante para o processamento da consulta, enquanto a divergência no software se torna um obstáculo para o processamento de transações que acessam múltiplos sites. Arquitetura Cliente/Servidor O objetivo geral desses sistemas é fornecer suporte ao desenvolvimento e à execução de aplicações de banco de dados. Portanto, sob um ponto de vista de mais alto nível, um sistema desse tipo pode ser considerado de estrutura muito simples em duas partes, consistindo em um servidor, também chamado back end, e um conjunto de clientes, chamados front ends. O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBD, definição e manipulação de dados, segurança e integridade de dados, e assim por diante. Em outras palavras, o termo servidor neste contexto é tão somente um outro nome para o SGBD. Os clientes são as diversas aplicações executadas no SGBD, tanto aplicações escritas por usuários quanto aplicações internas. No que se refere ao servidor, não existe diferença alguma entre aplicações escritas pelos usuários e aplicações internas; todas elas empregam a mesma interface para o servidor especificamente, a interface de nível externo. Certas aplicações especiais, chamadas utilitárias, podem constituir uma exceção ao que vimos antes, já que elas às vezes podem ter de operar diretamente no nível interno do sistema. Esses utilitários normalmente são considerados componentes internos do SGBD, em vez de aplicações no sentido mais comum. As aplicações são divididas em dois tipos: aplicações escritas pelo usuário e aplicações fornecidas pelo fabricante. As aplicações escritas pelo usuário são basicamente programadas de aplicação comuns, escritas (em geral) em uma linguagem de programação convencional de terceira geração (L3G), como C++ ou COBOL, ou então em alguma linguagem proprietária de quarta geração (L4G), embora em ambos os casos a linguagem precisa ser, de algum modo, acoplada a uma sublinguagem de dados apropriada. As aplicações fornecidas por fabricante, também conhecidas de ferramentas, são aquelas cuja finalidade básica é auxiliar na criação e execução de outras aplicações. As criadas são aplicações adaptadas a alguma tarefa específica (elas podem não ser muito semelhantes às aplicações no sentido convencional). De fato, a finalidade das ferramentas é permitir aos usuários, em especial aos usuários finais, criar aplicações sem ter de escrever programas em uma linguagem de programação convencional. Por exemplo, uma ferramenta fornecida pelo fabricante será um gerador de relatórios cuja finalidade é permitir que os usuários finais obtenham relatórios formatados a partir do sistema sob requisição. Qualquer requisição de relatórios pode ser considerada um pequeno programa de aplicação, escrito em uma linguagem de geração de relatórios de nível muito alto. Banco de Dados Distribuídos Como o sistema por completo pode estar tão claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em máquinas diferentes. Em outras palavras, existe o potencial para o processamento distribuído. O processamento distribuído significa que máquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicações, de maneira que uma única tarefa de processamento de dados possa ser dividida entre várias máquinas na rede. Na verdade, essa possibilidade é tão atraente por diversos motivos, principalmente de ordem econômica, que o termo cliente/servidor passou a se aplicar quase exclusivamente ao caso em que o cliente e o servidor estão de fato localizados em máquinas diferentes. 10

11 Introdução a Banco de Dados Distribuídos Unidade I Processamento Distribuído A expressão processamento distribuído significa que máquinas diferentes podem estar conectadas entre si em uma rede de comunicações. Um exemplo clássico é a Internet, em que uma única tarefa de processamento de dados possa se estender a várias máquinas na rede. A comunicação entre as várias máquinas é efetuada por algum tipo de software de gerenciamento de rede, possivelmente uma extensão do gerenciador DC ou, mais provavelmente, um componente de software separado. Gerenciador DC Data Communications. As mensagens de comunicação são transmitidas sob o controle de um outro componente de software. O gerenciador não faz parte do SGBD. São possíveis muitos níveis ou variedades de processamento distribuído. Um caso simples envolve a execução do back end do SGBD (o servidor) em uma das máquinas e dos front ends da aplicação (os clientes), conforme a Figura 1. Figura 1 Cliente(s) e servidor funcionando em máquinas diferentes Como exercício de esclarecimento, esboce três exemplos de empresas que utilizem banco de dados distribuídos. Explique em detalhes, conforme a Figura 1. Pós-Graduação a Distância 11

12 Introdução a Banco de Dados Distribuídos Unidade I Como vimos no item Arquitetura Cliente/Servidor, o termo cliente/servidor passou a ser quase sinônimo da disposição ilustrada na Figura 1, na qual o cliente e o servidor funcionam em máquinas diferentes. De fato, há muitos argumentos em favor de um esquema desse tipo: a) o argumento mais comum sobre o processamento paralelo, especificamente, duas ou mais máquinas estão sendo agora aplicadas na tarefa geral, enquanto o processamento do servidor (o banco de dados) e do cliente (a aplicação) está sendo feito em paralelo. Assim, o tempo de resposta e a vazão (throughput) devem ser melhorados; b) além disso, a máquina servidora pode ser uma máquina feita por encomenda para se ajustar à função do SGBD e, assim, fornecer melhor desempenho ao SGBD; c) mesmo assim, a máquina cliente poderia ser uma estação de trabalho pessoal, adaptada às necessidades do usuário final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rápidas e, de modo geral, maiores com facilidade de utilização para o usuário; d) várias máquinas clientes distintas poderiam ser capazes (na verdade, normalmente serão capazes) de obter acesso à máquina servidora. Assim, um único banco de dados poderia ser compartilhado entre vários sistemas clientes distintos, conforme Figura 2. Figura 2 Uma máquina servidora, várias máquinas clientes Banco de Dados Distribuídos Como exercício de esclarecimento, analise a Figura 2 e cite exemplos de instituições que trabalham com esse tipo de serviço de banco de dados. Além dos argumentos anteriores, existe também o fato de que as execuções dos clientes e dos servidores em máquinas diferentes correspondem ao modo como as empresas operam na realidade. É bastante comum que uma única empresa, um banco, por exemplo, opere muitos computadores, de tal modo que os dados correspondentes a uma parte da empresa sejam armazenados em um computador e os dados de outra parte sejam armazenados em outro computador. Prosseguindo 12

13 Introdução a Banco de Dados Distribuídos Unidade I com o exemplo do banco, é muito provável que os usuários de uma agência ocasionalmente tenham de obter acesso a dados armazenados em outra agência. Portanto, observe que as máquinas clientes poderiam ter seus próprios dados armazenados, e a máquina servidora poderia ter suas próprias aplicações. Dessa forma, em geral, cada máquina atuará como um servidor para alguns usuários e como cliente para outros, conforme a Figura 3. Figura 3 Cada máquina pode executar tanto os clientes como o servidor Como exercício de esclarecimetno, analise a Figura 3 tente explicar com suas palavras o qeu você conseguiu entender. O último ponto a mencionar é que uma única máquina cliente poderia ser capaz de obter acesso a várias máquinas servidoras diferentes conforme mostrado na Figura 2. Esse recurso é desejável porque, como já estudamos, as empresas, em geral, operam de tal maneira que a totalidade de seus dados não fica armazenada em uma única máquina, mas se espalha por muitas máquinas distintas, e as aplicações às vezes precisarão ter a capacidade de acessar dados de mais de uma máquina. Basicamente, esse acesso pode ser fornecido de dois modos distintos: a) determinado cliente pode ser capaz de obter acesso a qualquer quantidade de servidores, mas somente um de cada vez, ou seja, cada requisição individual ao banco de dados tem de ser direcionada para apenas um servidor. Em um sistema desse tipo não é possível, dentro de uma única requisição, combinar dados de dois ou mais servidores diferentes. Além disso, o usuário de tal sistema tem de saber qual máquina em particular contém quais partes dos dados; b) O cliente pode ser capaz de obter acesso a vários servidores simultaneamente, isto é, uma única requisição ao banco de dados poderia ter a possibilidade de combinar dados de vários servidores. Nesse caso, os servidores aparentam para o cliente, de um ponto de vista lógico, ser raramente um único servidor, e o usuário não precisa saber qual máquina contém cada uma das partes constituintes dos dados. O item b constitui um exemplo daquilo que se costuma chamar sistema de banco de dados distribuído. Este tema é um grande tópico por si só. Levado a sua conclusão lógica, o suporte completo a bancos de dados distribuídos implica que uma única aplicação deve ser capaz de operar de modo transparente sobre dados espalhados por uma variedade de bancos de dados diferentes, gerenciados por uma variedade de SGBDs diferentes, funcionando em uma variedade de Pós-Graduação a Distância 13

14 Introdução a Banco de Dados Distribuídos Unidade I máquinas distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de comunicações diferentes. Modo transparente significa que a aplicação opera de um ponto de vista lógico, como se os dados fossem todos gerenciados por um único SGBD executado em uma máquina. Banco de Dados Distribuídos 14

15 Introdução a Banco de Dados Distribuídos Unidade I Capítulo 2 Algumas Questões Preliminares Um sistema de banco de dados distribuído consiste em uma coleção de sites, interligados por meio de algum tipo de rede de telecomunicações, em que: a) cada site é por ele próprio, um site completo do sistema de banco de dados; b) os sites concordam em atuar juntos, de modo que um usuário em qualquer site pode ter acesso aos dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site do próprio usuário. Ocorre que o chamado banco de dados distribuído é na verdade uma espécie de banco de dados virtual cujas partes componentes estão fisicamente armazenadas em vários bancos de dados reais distintos em vários sites distintos (com efeito, é a união lógica desses bancos de dados reais). Um exemplo claro é a Figura 4. Figura 4 Um sistema de banco de dados distribuído típico Como exercício de esclarecimento, analise a Figura 4. Se um cliente estiver em Lisboa, poderá acessar as mesmas informações do cliente que está em Brasília? Explique sua resposta. Observe que, repetindo, cada site é um site do sistema de banco de dados por si mesmo. Em outras palavras, cada site possui seus próprios bancos de dados locais reais, seus próprios usuários locais, seu próprio SGBD local e software de gerenciamento de transações, e seu próprio gerenciador de comunicações de dados local (gerenciador DC). Em particular, qualquer usuário pode executar operações sobre dados no seu site local exatamente como se esse site não participasse de modo algum do sistema distribuído. O sistema de banco de dados distribuído em geral pode, portanto, ser considerado Pós-Graduação a Distância 15

16 Introdução a Banco de Dados Distribuídos Unidade I como um tipo de parceria entre SGBD individuais locais nos sites locais individuais; um novo componente de software em cada site uma extensão lógica do SGBD local fornece a funcionalidade necessária à parceria e é a combinação desse novo componente com o SGBD existente, o que constitui aquilo que se costuma chamar sistema de gerenciamento de banco de dados distribuído. Vantagens O gerenciamento de bancos de dados distribuídos tem sido proposto por diversas razões que variam desde a descentralização organizacional e a economia de processamento até a maior autonomia. Destacamos algumas dessas vantagens a seguir: Gerenciamento de dados distribuídos com níveis diferentes de transparência de forma ideal, um SGBD deveria ser transparente na distribuição, no sentido de esconder os detalhes de onde cada arquivo (tabela, relação) está armazenado fisicamente dentro do sistema. Transparência de distribuição ou de rede esta se refere à liberdade para o usuário em relação aos detalhes operacionais da rede. Transparência de replicação cópias dos dados podem ser armazenadas em múltiplos sites para obter melhor disponibilidade, desempenho e confiabilidade. A transparência de replicação faz o usuário não precisar estar ciente da existência das cópias. Transparência de fragmentação existem dois tipos de fragmentação. A fragmentação horizontal distribui uma relação em conjuntos de tuplas (linhas). Exemplo: Se a relação r for fragmentada, r será dividida em uma série de fragmentos r1, r2,..., rn. Esses fragmentos contêm informações suficientes para permitir a reconstrução da relação original r. A fragmentação vertical distribui uma relação em sub-relações, nas quais cada sub-relação é definida por um subconjunto das colunas da relação original. Exemplo: A fragmentação vertical divide a relação decompondo o esquema R da relação r. A fragmentação vertical de r(r) envolve a definição de vários subconjuntos de atributos R1, R2,..., Rn. A fragmentação horizontal normalmente é usada para manter tuplas nos sites em que são mais usados, para minimizar a transferência de dados. Melhoria na confiabilidade e na disponibilidade estas são duas das potenciais vantagens mais comuns citadas para bancos de dados distribuídos. A confiabilidade é definida de maneira ampla como a probabilidade de que um sistema esteja em operação (não seja inoperante) em um determinado momento, ao passo que a disponibilidade é a probabilidade de que o sistema esteja continuamente disponível durante um intervalo de tempo. Quando os dados e o software do SGBD são distribuídos por vários sites, um site pode falhar, então os outros não podem ser acessados. Isso faz aumentar a confiabilidade e a disponibilidade. Uma melhoria é obtida por meio de replicação criteriosa de dados e de software em mais que um site. Em um sistema centralizado, a falha em um dado torna o sistema inteiro indisponível para todos os usuários. Em um banco de dados distribuído, alguns dos dados podem ficar inalcançáveis, mas os usuários ainda podem acessar outras partes do banco de dados. Banco de Dados Distribuídos Melhoria de desempenho um SGBD distribuído fragmenta o banco de dados mantendo os dados mais próximos de onde eles são mais necessários. A localização dos dados reduz a disputa pela CPU e por operações de Entrada/Saída, e simultaneamente reduz os atrasos de acesso envolvidos em redes remotas WAN. Quando um grande banco de dados é distribuído por múltiplos sites, bancos de dados menores existem em cada site. Como resultado, consultas e transações locais que acessam dados em um único site têm um desempenho melhor por causa dos bancos de dados menores locais. Além disso, cada site possui um número menor de transações que são executadas do que se todas as transações fossem submetidas a um único banco de dados centralizados. O paralelismo entre consultas (interqueries) e o paralelismo dentro das consultas (intraqueries) 16

17 Introdução a Banco de Dados Distribuídos Unidade I podem ser obtidos pela execução de múltiplas consultas em diferentes sites, ou pela quebra de uma consulta em diversas subconsultas que são executadas em paralelo. Isso contribui para a melhoria do desempenho. Expansão mais fácil em um ambiente distribuído a expansão do sistema quanto a acréscimo de mais dados, aumento do tamanho dos bancos de dados ou acréscimo de mais processadores é muito mais fácil. Por que bancos de dados distribuídos são desejáveis? A resposta básica a essa pergunta é que normalmente as empresas já são distribuídas, pelo menos logicamente, em divisões, departamentos, grupos de trabalho etc. e, com grande probabilidade, também, fisicamente em fábricas, laboratórios entre outros. Disso decorre que os dados também já estão normalmente distribuídos, porque cada unidade organizacional dentro da empresa necessariamente manterá dados que são relevantes para sua própria operação. O patrimônio total das informações da empresa é, desse modo, disseminado naquilo que às vezes se costuma chamar de ilhas de informações. Um sistema distribuído fornece as pontes necessárias para conectar essas ilhas. Em outras palavras, ele permite que a estrutura do banco de dados reflita a estrutura da empresa. Dados locais podem ser mantidos em instalações locais, às quais eles pertencem logicamente, enquanto dados remotos estão disponíveis para serem acessados quando for necessário. Um exemplo esclarecerá o que foi dito. Suponha que existam apenas dois sites, um em São Paulo e o outro no Rio de Janeiro, e que se trata de um sistema bancário, com dados de contas para as contas de São Paulo armazenadas em São Paulo e dados de contas para as contas do Rio de Janeiro armazenadas no Rio de Janeiro. Então, as vantagens são óbvias: o arranjo distribuído combina eficiência de processamento (os dados são mantidos próximos ao local em que são usados mais frequentemente) com maior facilidade de acesso (é possível ter acesso a uma conta no Rio de Janeiro a partir de São Paulo e vice-versa, por meio da rede de telecomunicações). Fazer com que a estrutura do banco de dados reflita a estrutura da empresa é provavelmente a principal vantagem dos sistemas distribuídos. Pós-Graduação a Distância 17

18 Introdução a Banco de Dados Distribuídos Unidade I Capítulo 3 Funções Adicionais do Banco de Dados Distribuído A distribuição leva a uma maior complexidade no projeto e na implementação do sistema. Para obter as vantagens potenciais listadas no tópico anterior, o software do SGBDD deve ser capaz de prover as seguintes funções, além daquelas de um SGBD centralizado: Rastreamento de dados habilidade para rastrear a distribuição, a fragmentação e a replicação dos dados por meio da ampliação do catálogo do SGBDD. Processamento de consultas distribuídas habilidade para acessar sites remotos e transmitir consultas e dados entre os vários sites por meio de uma rede de comunicação. Gerenciamento de transações distribuídas habilidade para conceber estratégias de execução para consultas e transações que acessam dados de mais de um site, e para sincronizar o acesso aos dados distribuídos e para manter a integridade do banco de dados global. Gerenciamento dos dados replicados habilidade para decidir qual a cópia de um item de dados replicado será acessada e para manter a consistência das cópias de um item de dados replicado. Recuperação de banco de dados distribuído habilidade para recuperar a partir de falhas em um site individual e a partir de novos tipos de falhas como a queda e dos links de comunicação. Segurança as transações distribuídas devem ser executadas com o gerenciamento adequado da segurança dos dados e dos privilégios de autorização/acesso dos usuários. Gerenciamento do diretório (catálogo) distribuído um diretório contém informações (metadados) sobre os dados no banco de dados. O diretório pode ser global para o BDD inteiro ou local para cada site. O posicionamento e a distribuição do diretório são questões de projeto e de política. Essas funções por si só aumentam a complexidade de um SGBDD em relação a um SGBD centralizado. Antes que possamos perceber completamente as vantagens potenciais da distribuição, precisamos encontrar soluções satisfatórias para essas questões e para esses problemas de projeto. A inclusão de toda essa funcionalidade adicional é difícil de ser obtida, e encontrar soluções ótimas é um passo mais avançado. No nível físico de hardware, os seguintes fatores principais distinguem um SGBDD de um sistema centralizado: a) existem múltiplos computadores, chamados sites ou nós; Banco de Dados Distribuídos b) esses sites devem ser conectados por algum tipo de rede de comunicação para transmitir dados e comandos entre sites. Os sites podem estar todos localizados fisicamente próximos, dentro do mesmo prédio ou do grupo de prédios adjacentes e conectados por uma rede local LAN, ou eles podem ser distribuídos geograficamente por grandes distâncias e conectados por uma rede de enlace longo ou por uma rede remota WAN. As redes locais geralmente utilizam cabos, ao passo que as redes de enlace longo utilizam linhas telefônicas ou satélites. Também é possível usar uma combinação dos dois tipos de redes. As redes podem ter topologias diferentes que definem caminhos de comunicação direta entre os sites. O tipo e a topologia de rede utilizados podem ter um efeito significativo no desempenho e, consequentemente, nas estratégias para 18

19 Introdução a Banco de Dados Distribuídos Unidade I o processamento de consultas distribuídas e para o projeto de banco de dados distribuído. Entretanto, para as questões arquitetônicas de alto nível, não importa o tipo de rede utilizado. Apenas é relevante que cada site seja capaz de se comunicar, direta ou indiretamente, com todos os outros sites. Pós-Graduação a Distância 19

20

21 Unidade II Princípio de Banco de Dados Distribuídos Capítulo 4 Fundamentos do Banco de Dados Distribuídos Em um sistema distribuído, usuários devem comportar-se exatamente como se o sistema não fosse distribuído. Todos os problemas dos sistemas distribuídos são, ou deveriam ser, problemas internos ou do nível de implementação; não, problemas externos ou do nível do usuário. O termo usuários no parágrafo anterior refere-se especificamente a usuários finais ou programadores de aplicações que estão executando operações de manipulação de dados. As operações de definição de dados exigirão alguma extensão em um sistema distribuído, por exemplo, para que um usuário (talvez o DBA) no site A possa especificar que determinada RelVar deve ser dividida em fragmentos que serão armazenados nos sites B e C. O fundamento de BDD conduz doze regras, conforme a seguir: 1. Autonomia local 2. Não dependência de um site central 3. Operação contínua 4. Independência de localização 5. Independência de fragmentação 6. Independência de replicação 7. Processamento de consultas distribuído 8. Gerenciamento de transações distribuído 9. Independência do hardware 10. Independência do sistema operacional 11. Independência da rede 12. Independência do SGDB Pós-Graduação a Distância 21

22 Princípio de Banco de Dados Distribuídos Unidade II Entenda que essas regras não são todas independentes umas das outras nem são necessariamente completas nem igualmente significativas (usuários diferentes darão graus diferentes de importância a objetivos diferentes em ambientes diferentes; na verdade, alguns delas podem ser totalmente não aplicáveis em algumas situações). Contudo, as regras são úteis como base para a compreensão da tecnologia distribuída e como uma estrutura para caracterizar a funcionalidade de sistemas distribuídos específicos. É importante distinguir sistemas de bancos de dados distribuídos verdadeiros, generalizados, dos sistemas que apenas fornecem alguma espécie de acesso a dados remotos (é tudo o que os sistemas cliente/servidor realmente fazem). Em um sistema de acesso a dados remotos, o usuário pode ser capaz de operar sobre dados em um site remoto ou mesmo sobre dados em vários sites remotos simultaneamente, mas as emendas aparecem, ou seja, o usuário está definitivamente ciente, em maior ou menor grau, de que os dados são remotos e precisa se comportar de acordo com esse fato. Ao contrário, em um verdadeiro sistema de banco de dados distribuídos, as emendas ficam escondidas. As 12 Regras Autonomia Os sites, em um sistema distribuído, devem ser autônomos. Autonomia local significa que todas as operações em determinado site são controladas por ele mesmo; nenhum site A deve depender de algum outro site B para sua operação ser bem-sucedida (de outra forma, o fato de que o site C esteja inativo poderia significar que o site A não poderia funcionar, mesmo que não houvesse nada de errado como o próprio site A, o que evidentemente seria indesejável). A autonomia local também implica que dados locais são de propriedade e gerenciamento locais, com contabilidade local; todos os dados realmente pertencem a algum banco de dados local, mesmo que sejam acessíveis a partir de outros sites. Assim, questões como segurança, integridade e representação de armazenamento físico de dados locais permanecem sob o controle e a jurisdição do site local. Na verdade, a regra de autonomia local não é completamente realizável; há várias situações em que um determinado site A precisa ceder um certo grau de controle a algum outro site B. O objetivo de autonomia, então, seria mais precisamente enunciado como: os sites devem ser autônomos na maior extensão possível. Não dependência de um site central Autonomia local implica que todos os sites devem ser tratados como iguais. Em particular, portanto, não haverá qualquer dependência de um site mestre central que forneça algum serviço central. Por exemplo: serviços centralizados de processamento de consultas, gerenciamento de transações ou nomeações tais que o sistema inteiro dependa desse site central. Desse modo, essa segunda regra é uma continuação da primeira regra (se a primeira regra for realizada, a segunda virá logo em seguida). Porém, a não dependência de um site central é desejável por si, mesmo que não seja alcançada a completa autonomia local, motivo pelo qual a enunciamos como uma regra separada. Banco de Dados Distribuídos A dependência de um site central seria indesejável pelo menos por estas duas razões: primeiro, esse site central poderia ser um gargalo; segundo, e mais importante, o sistema seria vulnerável se o site central caísse, todo o sistema cairia (o problema do único ponto de falha). 22

23 Princípio de Banco de Dados Distribuídos Unidade II Operação contínua Uma vantagem dos sistemas distribuídos em geral é que eles devem fornecer maior confiabilidade e maior disponibilidade. Assim como foi explicitado no item Vantagens, referenciado no Capítulo 2, a confiabilidade e a disponibilidade são questões preliminares (funções Adicionais de BDD) e tratadas como gerência, mas também são regras claras e precisas para a utilização de BDD. Confiabilidade é a probabilidade de o sistema funcionar sem queda em qualquer momento dado. A confiabilidade é melhor nos sistemas distribuídos porque esses sistemas não seguem a proposta de tudo ou nada. Eles podem continuar a funcionar (em nível reduzido) mesmo diante da falha de algum componente individual, como um site isolado. Disponibilidade é a probabilidade de o sistema estar pronto e funcionando continuamente sem queda durante um período especificado. Assim como a confiabilidade, a disponibilidade é melhor em um sistema distribuído, em parte pela mesma razão, em parte devido à possibilidade de replicação de dados. As discussões anteriores se aplicam ao caso em que uma parada não planejada (isto é, uma falha de algum tipo) ocorreu em algum momento no sistema. As paradas não planejadas são obviamente indesejáveis, mas difíceis de evitar inteiramente. Ao contrário, as paradas planejadas nunca devem ser necessárias; isto é, nunca deve ser preciso desligar o sistema para a execução de alguma tarefa, como adicionar um novo site ou atualizar o SGBD em um site existente para uma nova versão. Sem dúvida, você já deve ter percebido que a independência de localização é somente uma extensão do conceito familiar de independência (física) de dados. Independência de localização A idéia básica da independência de localização (também chamada transparência de localização) é simples: os usuários não devem ser obrigados a saber onde estão fisicamente armazenados os dados, mas devem ser capazes de se comportar pelo menos de um ponto de vista lógico como se os dados estivessem todos armazenados em seu próprio site local. A independência de localização é desejável porque simplifica os programas de aplicações e as atividades do usuário final; em particular, permite que dados migrem de um site para outro sem invalidar qualquer desses programas ou atividades. Essa capacidade de migração é desejável porque permite que dados sejam deslocados pela rede em resposta a alterações de exigências de desempenho. Independência de fragmentação Um sistema admite fragmentação de dados se determinada Relação Variável armazenada pode ser dividida em pedaços ou fragmentos para fins de armazenamento físico, e os fragmentos distintos podem ser armazenados em sites diferentes. A fragmentação é desejável por motivos de desempenho: os dados podem ser armazenados no local em que são utilizados mais frequentemente, de modo que a maior parte das operações seja apenas local, e o tráfego da rede seja reduzido. Por Pós-Graduação a Distância 23

24 Princípio de Banco de Dados Distribuídos Unidade II exemplo: considere o RelVar EMP ( empregados ), com a amostra de valores apresentada na parte superior da Figura 5. Em um sistema que admitisse a fragmentação, poderíamos definir dois fragmentos: FRAGMENT EMP AS S_EMP AT SITE SÃO PAULO WHERE DEPTO# = D1 OR DEPTO# = D3, R_EMP AT SITE RIO DE JANEIRO WHERE DEPTO# = D2 ; Figura 5 Um exemplo de fragmentação Vimos que existem duas espécies de fragmentação, horizontal e vertical, correspondentes às operações relacionais de restrição e projeção, respectivamente. (A Figura 5 ilustra uma fragmentação horizontal). Suponha que tuplas EMP são mapeadas no armazenamento físico de modo bastante direto, e que D1 e D3 são departamentos de São Paulo, e D2 é um departamento do Rio de Janeiro. Tuplas para empregados em São Paulo serão armazenadas no site de São Paulo, e tuplas para empregados no Rio de Janeiro serão armazenadas no site do Rio de Janeiro. Observe na Figura 5 os nomes dos fragmentos internos do sistema, S_EMP e R_EMP. Banco de Dados Distribuídos A reconstrução da RelVar básica original a partir dos fragmentos é feita através de operações de junção e união adequadas (junção para fragmentos verticais, união para fragmentos horizontais). A propósito, no caso de união, observe que a eliminação de duplicatas não será necessária, graças à primeira das duas regras anteriores, ou seja, a união será uma união disjunta. 24

25 Princípio de Banco de Dados Distribuídos Unidade II Se realmente quisermos armazenar o mesmo fragmento de informações em vários lugares diferentes, poderemos fazê-lo por meio do mecanismo de replicação do sistema, a fim de obter o efeito desejado. Devemos nos aprofundar mais um pouco sobre a questão de fragmentação vertical. Visto que tal fragmentação deve ser realizada sem perdas, fica claro que a fragmentação da RelVar EMP da Figura 5 em suas projeções sobre, digamos, {EMP#,DEPTO#} e {SALÁRIO} não seria válida. Contudo, em alguns sistemas, RelVars armazenadas são consideradas como tendo uma ID de tupla, ou atributo TID oculto, fornecido pelo sistema, onde a TID para determinada tupla armazenada é, em linhas gerais, o endereço da tupla em questão. Esse atributo TID é claramente uma chave candidata para a RelVar em questão. Assim, por exemplo, se a RelVar EMP incluísse tal atributo, ela poderia ser fragmentada de modo válido em suas projeções sobre {TID,EMP#,DEPTO#} e {TID,SALÁRIO}, pois essa fragmentação, sem dúvida, seria sem perdas. Observe ainda que o fato de os atributos TID serem ocultos não viola o Princípio da Informação, pois a independência de fragmentação, que discutiremos em seguida, significa que o usuário, de qualquer forma, não está ciente da fragmentação. A propósito, observe que a facilidade de fragmentação e a facilidade de reconstrução são duas das muitas razões pelas quais os sistemas distribuídos são relacionais; o modelo relacional fornece exatamente as operações necessárias para essa tarefa. Agora, chegamos ao ponto mais importante: um sistema que admita fragmentação de dados também deve admitir independência de fragmentação (também conhecida como transparência de fragmentação). Isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados na verdade não estivessem fragmentados de modo algum. A independência de fragmentação (como a independência de localização) é desejável porque simplifica programas do usuário e atividades de terminal. Em particular, ela permite que os dados sejam refragmentados a qualquer momento, e os fragmentos sejam redistribuídos a qualquer momento em resposta a mudanças nas exigências de desempenho, sem invalidar quaisquer desses programas ou atividades do usuário. A independência de fragmentação implica que será apresentada aos usuários uma visão dos dados na qual os fragmentos estão combinados logicamente por meio de junções e uniões adequadas. É responsabilidade do otimizador determinar a quais fragmentos é necessário ter acesso físico para satisfazer a qualquer requisição do usuário. Por exemplo, dada a fragmentação mostrada na Figura 5, se o usuário emitir a requisição: EMP WHERE SALÁRIO > 40K AND DEPTO# = D1 O otimizador saberá, pelas definições do fragmento que estarão armazenadas no catálogo que o resultado inteiro pode ser obtido no site de São Paulo. Não haverá necessidade alguma de acessar o site do Rio de Janeiro. Examinaremos esse exemplo com um pouco mais de detalhe. Em primeiro lugar, a RelVar EMP, tal como é percebida pelo usuário, pode ser considerada (informalmente) uma visão dos fragmentos básicos S_EMP e R_EMP: VAR EMP VIEW S_EMP UNION R_EMP; /*pseudocódigo*/ Assim, o otimizador transforma a requisição original do usuário na seguinte: (S_EMP UNION R_EMP) WHERE SALÁRIO >40, AND DEPTO# = DEPTO# ( D1 ) Pós-Graduação a Distância 25

26 Princípio de Banco de Dados Distribuídos Unidade II Essa expressão pode ainda ser transformada em: (S_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 )) UNION (R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 )) (porque a restrição é distributiva em relação à união). Em seguida, a partir da definição do fragmento R_EMP no catálogo, o otimizador sabe que o segundo desses dois operandos de UNION é equivalente a: EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO# ( D1 ) AND DEPTO# DEPTO# ( D2 ) Essa expressão deverá ser avaliada como uma relação vazia, pois a condição na cláusula WHERE nunca poderá ter o valor TRUE. A consulta original pode então ser simplificada para apenas: R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 ) Agora, o otimizador sabe que só precisa ter acesso ao site de São Paulo. Considere o que significa para o otimizador lidar com a requisição: EMP WHERE SALÁRIO > 40K Independência de replicação Um sistema admite replicação de dados se determinada RelVar básica, ou, mais geralmente, determinado fragmento de determinada RelVar básica pode ser representada por muitas cópias ou réplicas distintas, armazenadas em muitos sites distintos. Por exemplo: REPLICATE S EMP AS SR_EMP AT SITE SÃO PAULO ; REPLICATE R EMP AS RS_EMP AT SITE RIO DE JANEIRO ; Banco de Dados Distribuídos Veja a Figura 6. Observe os nomes internos de réplicas do sistema, SR_EMP e RS_EMP. 26

27 Princípio de Banco de Dados Distribuídos Unidade II Figura 6 Um exemplo de replicação A replicação é desejável por ao menos dois motivos. Primeiro, pode significar melhor desempenho (aplicações podem operar sobre cópias locais, em vez de terem de se comunicar com site remotos); segundo, também pode significar melhor disponibilidade (algum objeto replicado permanece disponível para processamento pelo menos para acesso, enquanto houver no mínimo uma cópia disponível). Naturalmente, a maior desvantagem da replicação é que, quando determinado objeto replicado é atualizado, todas as cópias desse objeto precisam ser atualizadas: o problema da propagação de atualizações. Exercício de esclarecimento. Qual é a diferença de independência de fragmentação e independência de replicação? Dê exemplos nos dois casos. Observamos de passagem que a replicação em um sistema distribuído representa uma aplicação específica da ideia de redundância controlada. A replicação, como a fragmentação, deve no caso ideal ser transparente para o usuário. Em outras palavras, um sistema que admita replicação de dados também deve admitir independência de replicação (também conhecida como transparência de replicação), isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados de fato não fossem replicados de modo algum. A independência de replicação (como a independência de localização ou de fragmentação) é desejável porque simplifica os programas de aplicações e as atividades do usuário final; em particular, ela permite que réplicas sejam criadas ou destruídas em qualquer momento, em resposta a mudanças de requisitos, sem invalidar quaisquer um desses programas ou atividades. A independência de replicação implica a responsabilidade do otimizador do sistema de determinar a quais réplicas é necessário atribuir acesso físico para satisfazer qualquer requisição de um determinado usuário. Omitimos aqui os detalhes específicos da questão. Muitos produtos comerciais atuais admitem uma forma de replicação que não inclui a independência de replicação total, ou seja, ela não é totalmente transparente para o usuário. Pós-Graduação a Distância 27

28 Princípio de Banco de Dados Distribuídos Unidade II Processamento de consultas distribuído Há dois aspectos gerais a serem analisados: I. Considere a consulta Obter fornecedores em São Paulo de peças vermelhas. Suponha que o usuário esteja no site do Rio de Janeiro e que os dados estejam armazenados no site de São Paulo. Suponha também que existem n fornecedores que satisfazem à requisição. Se o sistema for relacional, a consulta envolverá basicamente duas mensagens: uma para enviar a requisição de São Paulo para o Rio de Janeiro e outra para retornar o conjunto de resultados de n tuplas do Rio de Janeiro para São Paulo. Se, por outro lado, o sistema não for relacional, mas sim um sistema de um registro por vez, a consulta envolverá basicamente 2n mensagens: n de São Paulo para o Rio de Janeiro solicitando o próximo fornecedor, e n do Rio de Janeiro para São Paulo, a fim de retornar o próximo fornecedor. Assim, o exemplo ilustra o fato de que o sistema distribuído relacional provavelmente irá superar um sistema não relacional em desempenho, possivelmente por várias ordens de grandeza. II. A otimização é ainda mais importante em um sistema distribuído do que em um sistema centralizado. O detalhe é que, em uma consulta como a mencionada no item I, envolvendo diversos sites, haverá muitos modos possíveis de mover os dados pelo sistema de maneira a satisfazer à requisição e é de importância crucial que se encontre uma estratégia eficiente. Por exemplo, uma requisição de união de uma relação ra armazenada no site A e uma relação rb armazenada no site B poderia ser executada movendo-se rb para A ou movendo-se ra para B, ou ainda movendo-se ambas para um terceiro site C etc. Para resumir rapidamente o exemplo, são analisadas seis diferentes estratégias para processamento da consulta sob um certo conjunto de hipóteses plausíveis, e o tempo de resposta varia de um mínimo de um décimo de segundo a um máximo de aproximadamente seis horas. Portanto, a otimização é claramente crucial e esse fato, por sua vez, pode ser visto como mais uma razão pela qual os sistemas distribuídos são sempre relacionais (observando-se que as requisições relacionais podem ser otimizadas enquanto as requisições não relacionais não podem). Analise, com calma, os itens I e II e explique a principal diferença entre eles. Gerenciamento de transações distribuído Banco de Dados Distribuídos Existem dois aspectos principais do gerenciamento de transações: recuperação e concorrência. Cada um deles exige um extenso tratamento no ambiente distribuído. Para explicar esse extenso tratamento, é preciso antes introduzir um novo termo, agente. Em um sistema distribuído, uma única transação pode envolver a execução de código de vários sites; em particular, pode envolver atualizações em muitos sites. Dizemos então que cada transação consiste em vários agentes, em que um agente é o processo executado em favor de determinada transação em um site específico. E o sistema precisa saber quando dois agentes são ambos da mesma transação. Por exemplo: dois agentes que fazem parte da mesma transação obviamente não podem ter um impasse (deadlock) entre eles. Passando agora especificamente à recuperação: para garantir que determinada transação é atômica (tudo ou nada) no ambiente distribuído, o sistema deve, portanto, assegurar que o conjunto de agentes para essa transação tenha feito o commit em uníssono ou o roll back em uníssono. Esse efeito pode ser obtido por meio de protocolo de COMMIT em duas fases. 28