Banco de dados distribuído

SOAM
(Redirecionado de Banco de dados distribuídos)

Banco de dados distribuído (BDD) é um banco de dados no qual nem todos os dispositivos de armazenamento estão conectados a um processador comum. Pode ser armazenado em vários computadores, localizados no mesmo local físico, ou podem ser dispersos por uma rede de computadores interconectados. Ao contrário dos sistemas paralelos, nos quais os processadores são fortemente acoplados e constituem um único sistema de banco de dados, um sistema de banco de dados distribuído consiste em sites fracamente acoplados que não compartilham componentes físicos.

Segundo Elmasri (2010)[1], um Banco de Dados é uma coleção de dados relacionados. Dados são fatos conhecidos que podem ser registrados e possuem significado implícito. Ou seja, um banco de dados é um conjunto de dados interligados que tem por objetivo atender os usuários.

Sistemas gerenciador de bancos de dados distribuídos (SGBDDs) estendem as facilidades usuais de gerência de dados de tal forma que o armazenamento de um banco de dados possa ser dividido ao longo dos nós (diferentes locais físicos) de uma rede de comunicação de dados, sem que com isto os usuários percam uma visão integrada do banco.

Os administradores do sistema podem distribuir coleções de dados (por exemplo, em um banco de dados) em vários locais físicos. Um banco de dados distribuído pode residir em servidores de rede organizados ou em computadores independentes descentralizados na Internet, em intranets ou extranets corporativos ou em outras redes de organizações. Como os bancos de dados distribuídos armazenam dados em vários computadores, os bancos de dados distribuídos podem melhorar o desempenho nos locais de trabalho do usuário final, permitindo que as transações sejam processadas em muitas máquinas, em vez de limitadas a uma.

Dois processos garantem que os bancos de dados distribuídos permaneçam atualizados e atuais: replicação e duplicação.

A replicação envolve o uso de software especializado que procura alterações no banco de dados distributivo. Depois que as alterações forem identificadas, o processo de replicação fará com que todos os bancos de dados tenham a mesma aparência. O processo de replicação pode ser complexo e demorado dependendo do tamanho e do número dos bancos de dados distribuídos. Esse processo também pode exigir muito tempo e recursos do computador. A Duplicação, por outro lado, tem menos complexidade. Basicamente, ele identifica um banco de dados como um mestre e depois duplica esse banco de dados. O processo de duplicação é normalmente feito em um horário definido após o horário. Isso é para garantir que cada local distribuído tenha os mesmos dados. No processo de duplicação, os usuários podem alterar apenas o banco de dados mestre. Isso garante que os dados locais não sejam sobrescritos. Tanto a replicação quanto a duplicação podem manter os dados atualizados em todos os locais distributivos.


Existem dois tipos de banco de dados distribuídos, os homogêneos e os heterogêneos. Os homogêneos são compostos pelos mesmos bancos de dados, já os Heterogêneos são aqueles que são compostos por mais de um tipo de banco de dados.

Arquitetura básica editar

Um usuário do banco de dados acessa o banco de dados distribuído por meio de:

  • Aplicações locais: Aplicativos que não exigem dados de outros sites;
  • Aplicações globais: Aplicativos que exigem dados de outros sites;

Os usuários locais ou globais podem ser classificados em quatro grandes grupos: o administrador do banco, analistas e programadores de aplicação, usuários casuais, e usuários paramétricos. Para satisfazer às necessidades destas classes de usuários, tradicionalmente um SGBD centralizado oferece:

Um banco de dados distribuído homogêneo possui software e hardware idênticos executando todas as instâncias de bancos de dados e pode aparecer por meio de uma única interface como se fosse um único banco de dados. Um banco de dados distribuído heterogêneo pode ter hardware, sistemas operacionais, sistemas de gerenciamento de banco de dados e até mesmo modelos de dados diferentes para bancos de dados diferentes.

Sistema gerenciador de Banco de Dados Distribuídos Homogêneo editar

Em um banco de dados distribuído homogêneo, todos os sites têm software idêntico e estão cientes um do outro e concordam em cooperar no processamento de solicitações do usuário. Cada site entrega parte de sua autonomia em termos de direito de alterar o esquema ou o software. Um SGBD homogêneo aparece para o usuário como um sistema único. O sistema homogêneo é muito mais fácil de projetar e gerenciar. As seguintes condições devem ser satisfeitas para banco de dados homogêneo:

  • As estruturas de dados usadas em cada local devem ser iguais ou compatíveis;
  • O aplicativo de banco de dados (ou SGBD) usado em cada local deve ser igual ou compatível;


Sistema gerenciador de Banco de Dados Distribuídos Heterogêneo editar

Em um banco de dados distribuído heterogêneo, sites diferentes podem usar esquemas e softwares diferentes. A diferença no esquema é um grande problema para processamento de consultas e processamento de transações. Os sites podem não estar cientes uns dos outros e podem fornecer apenas recursos limitados para cooperação no processamento de transações. Em sistemas heterogêneos, diferentes “nós” podem ter hardware e software diferentes, e estruturas de dados em vários nós ou locais também são incompatíveis. Diferentes computadores e sistemas operacionais, aplicativos de banco de dados ou modelos de dados podem ser usados em cada um dos locais. Por exemplo, um local pode ter a mais recente tecnologia de gerenciamento de banco de dados relacional, enquanto outro local pode armazenar dados usando arquivos convencionais ou uma versão antiga do sistema de gerenciamento de banco de dados. Da mesma forma, um local pode ter o sistema operacional Windows, enquanto outro pode ter o UNIX. Sistemas heterogêneos são geralmente usados quando sites individuais usam seu próprio hardware e software. No sistema heterogêneo, as traduções são necessárias para permitir a comunicação entre diferentes sites (ou SGBD). Nesse sistema, os usuários devem poder fazer solicitações em um idioma de banco de dados em seus sites locais. Normalmente, a linguagem do banco de dados SQL é usada para essa finalidade. Se o hardware é diferente, então a tradução é direta, na qual códigos de computador e comprimento de palavra são alterados. O sistema heterogêneo geralmente não é tecnicamente ou economicamente viável. Nesse sistema, um usuário em um local pode ler, mas não atualizar os dados em outro local.

Importantes considerações editar

Cuidados com um banco de dados distribuído devem ser tomados para garantir as transações e distribuições transparentes.

  • A distribuição é transparente, os usuários devem poder interagir com o sistema como se fosse um sistema lógico. Isso se aplica ao desempenho do sistema e aos métodos de acesso, entre outras coisas.
  • As transações são transparentes, cada transação deve manter a integridade do banco de dados em vários bancos de dados. As transações também devem ser divididas em subtransações, cada subtransação afeta um sistema de banco de dados.

Regras Básicas editar

O autor da teoria de dados relacionais, Christopher Date, criou 12 regras básicas de um SGBDD, que são elas:

  1. Automomia Local: Cada nó participante de um sistema distribuído deve ser independente dos outros nós. Cada nó deve prover mecanismos de segurança, bloqueio, acesso, integridade e recuperação após falha.
  2. Não dependência de um nó central: Um sistema de banco de dados distribuído não deve depender de um nó central, pois isso acarretaria um único ponto de falha, afetando todos os outros nós. Um nó central também poderia ficar sobrecarregado resultando em perda de desempenho do sistema.
  3. Operação contínua: Um sistema de banco de dados distribuído nunca deve precisar ser desativado. As operações de backup e recuperação devem ser suportadas on-line. Essas operações devem ainda ser rápidas o bastante para não afetarem o funcionamento do sistema (backup incremental, por exemplo).
  4. Transparência/independência de localização: Os usuários do sistema não devem precisar saber o local onde estão localizados os dados; devem se comportar como se os dados estivessem armazenados localmente.
  5. Independência de fragmentação: As tabelas que fazem parte de um sistema de banco de dados distribuído podem estar divididas em fragmentos, localizados fisicamente em diferentes nós, de forma transparente para o usuário.
  6. Independência de replicação: Dados podem estar replicados em vários nós da rede, de forma transparente. As réplicas de dados devem ser mantidas sincronizadas automaticamente pelo SGBD.
  7. Processamento de consultas distribuído: O desempenho de uma consulta deve ser independente do local onde a mesma é submetida. Um SGBDD deve possuir um otimizador capaz de selecionar não apenas o melhor caminho para o acesso a um determinado nó da rede, mas também otimizar o desempenho de uma consulta distribuída, levando em conta a localização dos dados, utilização de CPU, I/O e o tráfego na rede.
  8. Gerenciamento de transações distribuídas: Um SGBDD deve suportar transações atômicas. As propriedades ACID (Atomicidade, Consistência, Independência e Durabilidade) das transações e a serialização devem ser suportadas não apenas para transações locais, mas para transações distribuídas também.
  9. Independência de hardware: Um SGBDD deve poder operar e acessar dados em uma variedade de plataformas de hardware, sem depender de uma em específico.
  10. Independência de sistema operacional: Um SGBDD deve poder executar em sistemas operacionais diferentes. Assim como na regra anterior, um SGBDD não deve depender de um sistema operacional em especial.
  11. Independência de rede: Um SGBDD deve ser projetado para executar independentemente do protocolo de comunicação e da topologia de rede usada para interligar os vários nós que fazem parte da rede.
  12. Independência de SGBD: Um SGBDD ideal deve possuir capacidades para se comunicar com outros sistemas de gerenciamento de banco de dados executando em nós diferentes, mesmo se estes sistemas de bancos de dados são diferentes (heterogêneos).

Vantagens de bancos de dados distribuídos editar

  • Reflete a estrutura organizacional — fragmentos do banco de dados estão localizados nos departamentos que se relacionam com os dados que estes persistem.
  • Autonomia Local — um departamento pode controlar seus dados (já que é o mais familiarizado com estes).
  • Maior disponibilidade — uma falha em um banco de dados afetará somente um fragmento, ao invés do banco de dados inteiro.
  • Melhor performance — os dados estão localizados próximo do local de maior demanda e os sistemas de banco de dados por si só são paralelizáveis, permitindo carregar no banco de dados para o balanceamento entre servidores (a elevada carga em um módulo do banco de dados não irá afetar os outros módulos de banco de dados em um banco de dados distribuído).
  • Econômico — custa menos criar uma rede de pequenos computadores com o mesmo poder que um único computador maior.
  • Modularidade — sistemas podem ser modificados, adicionados ou removidos do banco de dados distribuído sem afetar os outros módulos (sistemas).

Desvantagens de banco de dados distribuídos editar

  • Complexidade — trabalho extra deve ser feito pelos DBAs para garantir que a natureza da distribuição do sistema seja transparente. Trabalho extra deve ser feito para manter sistemas múltiplos diferentes, ao invés de um único grande. Design de banco de dados extra deve também ser feito para levar em conta a natureza desconectada do banco de dados - por exemplo, joins tornam-se proibitivamente caros quando são rodados entre múltiplas plataformas.
  • Implantação mais cara — o aumento da complexidade e uma infraestrutura mais extensa significa custo extra de trabalho
  • Segurança — fragmentos de banco de dados remotos devem ser seguros e, como eles não são centralizados então os lugares remotos também devem ser seguros. A infraestrutura também deve ser segura (por exemplo, pela encriptação dos links de rede entre os lugares remotos).
  • Difícil de manter a integridade — em sistemas distribuídos, reforçar a integridade ao longo de uma rede pode exigir demais dos recursos da rede para ser viável.
  • Inexperiência — Dificuldades no gerenciamento. Pode ser difícil trabalhar com banco de dados distribuídos e como é uma área relativamente nova ainda não há tantos casos (ou experiências) práticos de seu uso disponíveis como exemplo.
  • Falta de padrões – ainda não há metodologias e ferramentas para ajudar usuários a converter um SGBD centralizado para um SGBD distribuído.
  • Design do banco de dados mais complexo – além das dificuldades normais, o design de um banco de dados distribuídos tem que considerar a fragmentação dos dados, alocação dos fragmentos em lugares específicos e a replicação de dados.

Referências

  1. Segundo Elmasri (2010)
  • ELMASRI, Ramez. SISTEMA DE BANCO DE DADOS – 6 Edição – Pag. 23
  • M. T. Ozsu and P. Valduriez, Principles of Distributed Databases (2nd edition), Prentice-Hall, ISBN 0-13-659707-6
  • Elmasri and Navathe, Fundamentals of database systems (3rd edition), Addison-Wesley Longman, ISBN 0-201-54263-3
  • CUNHA, Samuel L. O. Gerenciamento de Dados em Banco de Dados Distribuídos. 2003. 55f. Trabalho de Conclusão de Curso -  Centro Universitário do Triangulo, Uberlândia, 2003.
  • FILETO, Renato. Banco de Dados Distribuídos. 2009. 30f. Artigo Científico – Universidade Federal de Santa Catarina, Santa Catarina, 2009.
  • NUMATA, Cesar A. Banco de Dados Distribuídos. 2012. 41f. Trabalho de Conclusão de Curso – FATEC, São Paulo, 2012.
  • ROSARIO, Luiz G. O que é Banco de Dados Distribuído? IMasters. Disponível em: https://imasters.com.br/banco-de-dados/o-que-e-banco-de-dados-distribuido/?trace=1519021197&source=single Acesso em: 25 de março de 2018.
  • ALMEIDA, Roniere. O que é um Banco de Dados Distribuído? Devmedia. Disponível em: https://www.devmedia.com.br/o-que-e-um-banco-de-dados-distribuido/24762 Acesso em 25 de março de 2018.
  • CASANOVA, Marco A; MOURA, Arnaldo V. Princípios de Gerência de Bancos de Dados Distribuídos. 1999.

Ver também editar