Capitulo 14Sistemas de Banco de Dados Parelelos

Muitas aplicações de dados intensos requerem suporte para bancos de dados muito grandes (por exemplo, centenas de terabytes ou petabytes). Exemplos de tais aplicações são e-commerce, data warehousing e data mining. Grandes bancos de dados normalmente são acessados através de um elevado número de transações simultâneas (por exemplo, realizar on-line orderson uma loja eletrônica) ou consultas complexas (por exemplo, consultas de apoio à decisão). O primeiro tipo de acesso é representante da On-Line Transaction Processing (OLTP) aplicativos enquanto o segundo é representante da On-Line Analytical Processing (OLAP) aplicações. Apoiar grandes bancos de dados de forma eficiente tanto para OLTP ou OLAP pode ser abordada através da combinação de computação paralela e gestão de banco de dados distribuído.Como apresentado no Capítulo 1, um computador paralelo, ou multiprocessador, é um tipo especial de sistema distribuído feito de um número de nós (processadores, memórias e discos), conectados por uma rede muito rápida dentro de um ou mais armários na mesma sala.A idéia principal é construir um computador muito potente partindo de muitos computadores pequenos, numa relação muito boa de custo / performance, a um custo muito menor do que computadores de grande porte equivalentes. Como discutido no Capítulo 1, a distribuição de dados pode ser explorada para aumentar o desempenho (através de paralelismo) e disponibilidade (através da replicação).Este princípio pode ser usado para implementar sistemas de banco de dados paralelos, ou seja, sistemas de banco de dados em computadores paralelos [DeWitt e Gray, 1992; Valduriez, 1993]. Sistemas de banco de dados paralelos podem explorar o paralelismo em gerenciamento de dados, a fim de entregarde alto desempenho e alta disponibilidade de servidores de banco de dados. Assim, eles podem suportar grandes bancos de dados com cargas muito elevadas.A maior parte da investigação em sistemas de base de dados paralelos foi feito no contexto do modelo relacional que proporciona uma boa base para os dados baseado em paralelismo. Neste capítulo, apresentamos a abordagem de um sistema paralelo de banco de dados como uma solução de alto desempenho e alta disponibilidade de gerenciamento de dados. Discutimos, as vantagens e desvantagens das várias arquiteturas de sistemas paralelos e apresentamos as técnicas de implementação de genéricos.Implementação de sistemas de banco de dados paralelos, naturalmente, depende de técnicas de banco de dados distribuídos. No entanto, as questões críticas são dados colocação, processamento de consultas paralelas, e balanceamento de carga, porque o número de nós pode ser muito maior do que em um DBMS distribuída. Além disso, um computador paralelo normalmente fornece comunicação confiável e rápido que pode ser explorado de forma eficiente implementar o gerenciamento de transação distribuída e replicação. Portanto, embora os princípios básicos são os mesmos que no DBMS distribuída, as técnicas para sistemas de base de dados paralelos são bastante diferentes.Este capítulo está organizado da seguinte forma. Na Seção 14.1, esclarecemos os objetivos, e discutir os aspectos funcionais e arquitetônico de sistemas de banco de dados paralelos. Em particular, discutiremos as respectivas vantagens e limitações das arquiteturas de sistemas paralelos (memória compartilhada, compartilhada disco, compartilhou nada) ao longo de várias dimensões importantes, incluindo a perspectiva de ambos os usuários finais, administradores de dados e desenvolvedores do sistema. Em seguida, apresentamos as técnicas para particionamento de dados na Seção 14.2, processamento de consultas na Seção 14.3 e balanceamento de carga na Seção 14.4.Na Seção 14.5, apresentamos o uso de técnicas de gestão de dados em paralelo em clusters de banco de dados, um tipo importante do sistema de banco de dados paralelo implementado em um cluster de computadores.

14.1 Arquiteturas de sistemas paralelos de banco de dadosNesta seção, vamos mostrar o valor de sistemas paralelos de banco de dados eficiente de gestão. Nós motivar as necessidades de sistemas de banco de dados paralelos através da revisão dorequisitos de sistemas de informação muito grandes usando as tendências de tecnologia de hardware atual. Apresentamos os aspectos funcionais e arquitetônico do sistema paralelo de banco de dados. Em particular, apresentar e comparar as arquiteturas principais: memória compartilhada e disco compartilhado, nada-compartilhado e arquiteturas híbridas.

14.1.1 ObjetivosProcessamento paralelo explora computadores com múltiplos processadores para executar programas de aplicação usando vários processadores cooperativamente, a fim de melhorar o desempenho. seuuso tem sido proeminente na computação científica, melhorando a resposta tempo de aplicações numéricas [Kowalik, 1985; Sharp, 1987]. Os desenvolvimentos em ambos os computadores de uso geral paralelas utilizando microprocessadores padrão e técnicas de programação paralela [Osterhaug, 1989] permitiram processamento paralelo para entrar no campo de processamento de dados.Sistemas de banco de dados paralelos combinam gerenciamento de banco de dados e processamento paralelo para aumentar o desempenho e disponibilidade. Nota-se que o desempenho também foi o objetivo das máquinas de banco de dados na década de 70 e 80 [Hsiao, 1983]. O problema enfrentado pela administração de banco de dados convencional tem sido conhecido como "gargalo de E / S" [Boral e DeWitt, 1983], induzida por hora de acesso ao disco em relação ao tempo da memória principal de acesso (tipicamente centenas de milhares vezes mais rápido).Inicialmente, os projetistas de máquinas de banco de dados resolveram este problema através de finalidade especial por exemplo, hardware, através da introdução de dados de filtragem dispositivos dentro das cabeças do disco. No entanto, esta abordagem falhou por causa da má relação custo / desempenho em relação ao software solução, que pode facilmente beneficiar do progresso hardware em tecnologia de silício. A notável exceção a essas falhas foi o CAFS-ISP com base em hardware dispositivo de filtragem [Babb, 1979] que foi empacotado dentro de controladores de disco para pesquisa associativa rápido. A idéia de ampliar as funções de banco de dados mais perto para o disco tem recebido um interesse renovado com a introdução de microprocessadores de uso geral em controladores de disco, levando a discos inteligentes [Keeton et al., 1998]. Por exemplo, as funções básicas que requerem busca sequencial dispendioso, por exemplo selecionar operações em tabelas com predicados difuso, pode ser mais eficientemente realizada em nível de disco, uma vez que evitar sobrecarregar a memória DBMS com blocos de disco irrelevantes. No entanto, explorando discos inteligentes requer adaptação do DBMS, em particular, o processador de consultas para decidir se a usar as funções de disco. Como não há tecnologia de disco padrão inteligente, adaptando as diferentes tecnologias de disco inteligentes de portabilidade DBMS.

Um resultado importante, no entanto, é em geral a solução para o gargalo de I / O. Nós podemos resumir esta solução com o aumento da largura de banda de I / O meio paralelismo. Por exemplo, se armazenar um banco de dados de tamanho D em um único disco com a T vazão, o rendimento do sistema é limitada por T. Pelo contrário, se a partição do banco de dados através de n discos, cada um com capacidade D = n e a taxa de transferência T 0 (equivalente a espera T), temos um rendimento ideal de n? T 0 que pode ser melhor consumida por vários processadores (idealmente n). Note que a memória principal solução de sistema de banco de dados [Eich, 1989], que tenta manter o banco de dados na memória principal, é que alternativa complementar. Em particular, o "gargalo de acesso à memória" na memória principal sistemas podem também ser resolvidos usando paralelismo de uma maneira semelhante. Portanto, projetistas de sistemas paralelos de banco de dados têm se esforçado para desenvolver software de soluções orientadas em Para explorar computadores paralelos.

Um sistema de banco de dados paralelo pode ser vagamente definido como um SGBD implementado emum computador paralelo. Esta definição inclui muitas alternativas que variam a partir da portabilidade simples de um SGBD existente, que pode exigir apenas reescrever as rotinas op relacionais do sistema de interface, para uma sofisticada combinação de processamento aralelo e funções do sistema de banco de dados em uma arquitetura de hardware / software novo.

Como sempre, temos o tradicional trade-off entre portabilidade (para várias plataformas) e eficiência. A abordagem sofisticada é mais capaz de explorar plenamente as oportunidades oferecidas pela oportunidade de um multiprocessador à custa da portabilidade. Curiosamente, este dá vantagens diferentes para fabricantes de computadores e fornecedores de software. É portanto, importante para

caracterizar os principais pontos do espaço de alternativas de arquiteturas de sistemas paralelos. Para fazer isso, será preciso a solução de um sistema paralelo de banco de dados e as funções necessárias. Isso será útil na comparação das arquiteturas de sistemas paralelos de banco de dados.Os objectivos dos sistemas de base de dados paralelos são cobertos por aqueles de distribuídosDBMS (desempenho, disponibilidade, extensibilidade). Idealmente, um sistema de banco de dados paralelo deve fornecer as seguintes vantagens.

1. De alto desempenho. Isto pode ser obtido através de várias soluções complementares: banco de dados orientado suporte ao sistema operacional, gerenciamento de dados paralelos, a otimização da consulta, e balanceamento de carga. Tendo o sistema operacional limitado e "consciente" das necessidades de banco de dados específicas (por exemplo, gerenciamento de buffer) simplifica a implementação de funções de baixo nível de banco de dados e, portanto, diminui seu custo. Por exemplo, o custo de uma mensagem pode ser significativamente reduzida a algumas centenas de instruções por um protocolo de comunicação especializado. O paralelismo pode aumentar o rendimento, utilizando inter-consulta paralelismo, e diminuir os tempos de resposta de transações, usando intra-consulta paralelismo. No entanto, diminuindo o tempo de resposta de uma consulta complexa através de grande escala paralelismo pode muito bem aumentar o seu tempo total (por adicional comunicação) e ferir transferência como um efeito colateral. Portanto, é crucial para optimizar e paralelizar consultas a fim de minimizar a sobrecarga de par alelismo, por exemplo, através da limitação do grau de paralelismo para a consulta. O equilíbrio de carga é a capacidade do sistema para dividir uma determinada carga igualmenteentre todos os processadores. Dependendo da arquitetura do sistema paralelo, que pode ser alcançado estaticamente pelo projeto de banco de dados físico adequado ou dinamicamenteem tempo de execução.

2. Alta disponibilidade. Porque um sistema de banco de dados paralelo é composto de muitos componentes redundantes, pode aumentar bastante a disponibilidade de dados e tolerância a falhas.Em um sistema altamente paralelo com muitos nós, a probabilidade de uma falha de nó em qualquer momento pode ser relativamente elevada. A replicação de dados em diversos nós é útil para suportar failover, uma técnica de tolerância a falhas que permite o redirecionamento automático de transações a partir de um nó com falha para outro nó que armazena uma cópia dos dados. Este serviço fornece não interrupção para os usuários. No entanto, é essencial que uma falha do nó não cause um desequilíbrio de carga da caixa, por exemplo, dobrando a carga sobre a cópia disponível. As soluções para este problema requerem cópias de particionamento de tal modo que eles podem também ser acessados em paralelo.

3. Extensibilidade. Em um sistema paralelo, as exigências de desempenho acomodam tamanhos de banco de dados cada vez maiores ou aumentar (por exemplo, o rendimento) deve ser mais fácil. Extensibilidade é a capacidade de expandir o sistema suavemente através da adição de processamento e armazenamento de energia para o sistema. Idealmente, o sistema de banco de dados paralelo deve demonstrar duas vantagens extensibilidade [DeWitt e Gray, 1992]: speedup linear e linear scaleup veja a Figura 14.1. Aumento de velocidade linear refere-se a um aumento linear no desempenho para uma base de dados de tamanho constante enquanto que o número de nós (isto é, de processamento e armazenamento de energia) são aumentou linearmente. Linear scaleup se refere a um desempenho sustentado por um aumento linear no tamanho do banco de dados e número de nós. Além disso, estendendo-se o sistema deve exigir reorganização mínima da base de dados existente.

14.1.2 Arquitetura FuncionalAssumindo uma arquitetura cliente / servidor, as funções suportadas por um sistema de banco de dados paralelo pode ser dividido em três subsistemas, como muito em um SGBD típico. As diferenças, porém, têm a ver com a implementação destas funções, que devem agora lidar com paralelismo particionamento de dados e replicação e transações distribuídas. Dependendo da arquitetura, um nó processador pode suportar tudo (ou um subconjunto) desses subsistemas. Figura 14.2 mostra a arquitetura usando esses subsistemas, devido à Bergsten et al. [1991].

1. Session Manager. Ele desempenha o papel de um monitor de transações, proporcionando suporte para as interações do cliente com o servidor. Em particular, ele executa as ligações e desligamentos entre os processos de cliente e os dois outros subsistemas.Portanto, ele inicia e fecha sessões de utilizador (que pode conter operações múltiplas). Em caso de sessões de OLTP, o gerenciador de sessão é capaz de desencadear a execução pré-carregada de código de transação dentro dos módulos Data Manager.

2. Transação Manager. Ele recebe as transações de clientes relacionados com a compilação de consulta e execução. Ele pode acessar o diretório de banco de dados que contém todos as meta-informações sobre os dados e programas. O próprio diretório deve ser gerido como um banco de dados no servidor. Dependendo da operação, ele ativa as fases de compilação diferentes, desencadeia a execução da consulta, e retorna os resultados, bem como os códigos de erro para o aplicativo cliente. Porque ele supervisiona a execução da transação e commit, ele pode disparar o processo de recuperação em caso de falha da transação. Para acelerar a execução da consulta, ele pode otimizar e paralelizar a consulta em tempo de compilação.

3. Data Manager. Ele fornece todas as funções de baixo nível necessários para executar consultas compiladas em paralelo, ou seja, execução de operador de banco de dados, operação paralela supporta, gestão de dor, etc Se o gerenciador de transações é capaz de compilar o controle de fluxo de dados, em seguida, sincronização e comunicação entre os gerentes de dados módulos é possível. Caso contrário, o controle de transação e sincronização deve ser feito por um módulo gerenciador de transações.

14.1.3 Arquiteturas Paralelas SGBDComo qualquer sistema, um sistema de banco de dados paralelo representa um compromisso em opções de design, a fim de proporcionar as vantagens mencionadas com uma boa relação custo / desempenho. Uma decisão de projeto norteador é a forma como os principais elementos de hardware, ou seja, processadores, memória principal e discos, são conectados através de alguma rede de interconexão rápida. Há basicamente três arquiteturas de computadores paralelos, dependendo de como a memória principal ou disco é compartilhado: memória compartilhada, disco compartilhado e nada-compartilhado. Arquiteturas híbridas, tais como NUMA ou cluster tentar combinar as vantagens das arquiteturas básicas. No restante desta seção, ao descrever arquiteturas paralelas, que incidem sobre os quatro elementos principais: interconexão de hardware, processadores (P), memória principal (M) e discos. Para simplificar, podemos ignorar outros elementos, como cache do processador e I / O bus.

14.1.3.1 Memória compartilhadaNa abordagem de memória partilhada (ver Figura 14,3), qualquer processador tem acesso a qualquer módulo de memória ou unidade de disco através de uma interligação rápida (por exemplo, um barramento de alta velocidade ou um interruptor de barra transversal). Todos os processadores estão sob o controle de um único sistema operacional.Projetos de mainframe atuais e multiprocessadores simétricos (SMP) seguem esta abordagem. Exemplos de memória compartilhada sistemas de banco de dados paralelas incluem XPRS [Hong, 1992], DBS3 [Bergsten et al., 1991], e Volcano [Graefe, 1990], portings bem como dos principais SGBDs comerciais em SMP. Em certo sentido, a implementação do DB2 em um IBM3090 com 6 processadores [Cheng et al., 1984] foi o primeiro exemplo. Todos os produtos de memória compartilhada do banco de dados paralelos hoje pode explorar inter-consulta paralelismo para fornecer throughput de transações de alta e paralelismo intra-consulta para reduzir o tempo de resposta de consultas de apoio à decisão.

Memória compartilhada tem duas grandes vantagens: simplicidade e balanceamento de carga. Desde meta-informação (diretório) e informações de controle (por exemplo, travamento de tabelas) pode ser partilhado por todos os processadores, escrevendo software de banco de dados não é muito diferente do que para um único processador computadores. Em particular, inter-consulta paralelismo vem de graça. Paralelismo intra-consulta requer algum paralelismo mas continua a ser bastante simples. O balanceamento de carga é fácil de conseguir, uma vez que pode ser obtida em tempo de execução usando a memória compartilhada, através da atribuição de cada nova tarefa para o processador menos ocupado.

Memória compartilhada tem três problemas: alto custo, extensibilidade limitada e baixa disponibilidade. Alto custo é pago pela interconexão que requer um hardware bastante complexo devido à necessidade de vincular cada processador para cada módulo de memória ou disco. Com processadores mais rápidos (mesmo com caches maiores), acessos conflitantes para a memória compartilhada aumentar rapidamente e degradar o desempenho [Thakkar e Sweiger, 1990]. Portanto, a extensibilidade é limitada a algumas dezenas de processadores, normalmente até 16 para a melhor relação custo / performance usando 4 processadores placas. Finalmente, uma vez que o espaço de memória é compartilhado por todos os processadores, uma falha de memória pode afetar a maioria dos processadores, assim, prejudicando a disponibilidade. A solução é usar a memória duplex com uma interligação redundante.

14.1.3.2 Discos compartilhadosNa abordagem de disco partilhado (ver Figura 14.4), qualquer processador tem acesso a qualquer unidade de disco através da interconexão, mas o acesso exclusivo (não compartilhado) para a memória principal. Cada nó processador-memória está sob o controle da sua própria cópia do sistema operacional. Então, cada processador pode acessar páginas de banco de dados sobre o disco compartilhado e cache-los em sua própria memória. Desde processadores diferentes podem acessar a mesma página em modos de atualização conflitantes, consistência do cache global é necessária. Isto é tipicamente conseguido usando um gestor de bloqueio distribuído que pode ser implementado usando as técnicas descritas no Capítulo 11. O SGBD primeiro paralelo

que utilizou compartilhada disco é o Oracle com uma implementação eficiente de um gerente de fechadura distribuído para consistência do cache. Outros grandes fornecedores de DBMS, como IBM, Microsoft e Sybase fornecer compartilhada disco implementações.

Compartilhada disco tem uma série de vantagens: menor custo, extensibilidade elevada, disponibilidade, balanceamento de carga e fácil migração de sistemas centralizados. O custo da interconexão é significativamente menor do que com memória partilhada desde bus padrão tecnolo-gia pode ser usado. Dado que cada processador tem memória suficiente principal, a interferência no disco compartilhado pode ser minimizada. Assim, a extensibilidade pode ser melhor, tipicamente até uma centena de processadores. Uma vez que as falhas de memória pode ser isolado a partir de outros nós, a disponibilidade pode ser mais elevada. Finalmente, a migração de um sistema centralizado de disco compartilhado é relativamente simples desde que os dados no disco não precisa ser reorganizada. Compartilhada disco sofre de maior complexidade e problemas de desempenho. Ela exige protocolos de banco de dados distribuídos do sistema, tais como bloqueio e distribuídos de duas fases. Como já discutido nos capítulos anteriores, estes podem ser complexos. Além disso, manter a consistência do cache pode implicar em um overhead de comunicação de alta entre os nós. Finalmente, o acesso ao disco compartilhado é um gargalo em potencial.

14.1.3.3 Nada compartilhadaNa abordagem nada-compartilhada (ver Figura 14,5), cada processador tem acesso exclusivo para a sua memória principal e da unidade de disco (s). Similar ao disco partilhado, cada nó-processador de memória de disco está sob o controlo da sua própria cópia do sistema operacional.Em seguida, cada nó pode ser visto como um site local (com a sua própria base de dados e software) em um sistema de base de dados distribuída. Portanto, a maioria das soluções projetadas para bancos de dados distribuídos, tais como a fragmentação do banco de dados, gerenciamento de transações distribuídas e processamento de consultas distribuído podem ser reutilizados. Usando uma interconexão rápido, é possível acomodar um grande número de nós. Ao contrário do SMP, essa arquitetura é muitas vezes chamado Massively Parallel Processor (MPP).

Muitos protótipos de pesquisa adotaram a arquitetura shared-nothing, por exemplo, BUBBA [Boral et al., 1990], EDS [Group, 1990] GAMA, [DeWitt et al., 1986], GRACE [Fushimi et al., 1986], e PRISMA [Apers et al., 1992], porque ele pode escalar. O primeiro grande produto SGBD paralelo era Computer Teradata banco de dados quepoderia acomodar mil processadores em sua versão inicial. Outros grandes fornecedores de DBMS, como IBM, Microsoft e Sybase fornecer compartilhada nada implementações.

Como demonstrado pelos produtos existentes, partilhou-nada tem três virtudes principais:menor custo, a extensibilidade elevada, e grande disponibilidade. A vantagem do custo é melhor do que a do disco partilhado que requer uma interconexão especial para os discos. Ao implementar um projeto de banco de dados distribuído que favorece o crescimento suave incremental do sistema de pela adição de novos nós, a extensibilidade pode ser melhor (em milhares de nós). Com o particionamento cuidadosa dos dados em múltiplos discos, speedup quase linear e linear scaleup poderia ser alcançado para cargas de trabalho simples. Finalmente, por replicação de dados em vários nós, disponibilidade elevada pode também ser alcançado.Nada compartilhado é muito mais complexa de gerir do que qualquer memória compartilhada ou de disco compartilhado. Maior complexidade é devido à aplicação necessária de funções de base de dados distribuídos

assumindo um grande número de nós. Além disso, o equilíbrio de carga é mais difícil de alcançar porque confia na eficácia de banco de dados de particionamento para as cargas de trabalho de consulta. Ao contrário sharedmemory e partilhada-disco, o equilíbrio de carga é decidido com base em dados de localização e não a carga real do sistema. Além disso, a adição de novos nós no sistema presumivelmente exige a reorganização do banco de dados para lidar com as questões de balanceamento de carga.

14.1.3.4 Arquiteturas HíbridasVárias combinações possíveis dos três arquiteturas básicas são possíveis de obter diferentes trade-offs entre custo, performance, extensibilidade, disponibilidade, etc. Arquiteturas Híbridas de tentar obter as vantagens de arquiteturas diferentes: tipicamente a eficiência e simplicidade de memória compartilhada e a extensibilidade e custo de qualquer disco compartilhado ou nada compartilhado. Nesta seção, discutimos dois populares arquiteturas híbridas: NUMA e cluster.

NUMACom memória compartilhada, cada processador tem acesso à memória uniforme (UMA), com tempo de acesso constante, já que tanto a memória virtual e memória física são compartilhados. Uma grande vantagem é que o modelo de programação baseado em virtual compartilhada memória é simples. Com qualquer disco partilhado ou nada comum, tanto virtual e memória compartilhada são distribuídos, o que permite uma escalabilidade a um grande número de processadores. O objetivo do NUMA é fornecer um shared-memory modelo de programação e todos os seus benefícios, em uma arquitetura escalável, com memória distribuída. O termo NUMA reflete o facto de um acesso à memória (virtualmente) partilhada pode ter um custo diferente dependendo se a memória física é local ou remoto para o processador.

A classe mais bem sucedido de multiprocessadores NUMA é cache coerente NUMA (CC-NUMA) [Goodman e Woest, 1988; Lenoski et al, 1992.]. Com CC-NUMA, a memória principal está fisicamente distribuída entre os nós como com nada-compartilhado ou disco compartilhado. No entanto, qualquer processador tem acesso a todas as memórias de outros processadores (ver Figura 14.6). Cada nó pode-se ser um SMP. Similar ao compartilhada de disco, processadores diferentes podem acessar os mesmos dados em um modo de atualização conflitantes, protocolos de consistência de cache tão globais são necessários. A fim de tornar o acesso à memória remota eficiente, a única solução viável é ter consistência do cache feito no hardware através de uma interconexão de cache especial consistente [Lenoski et al., 1992]. Porque a memória compartilhada e consistência do cache são suportadas por hardware, o acesso à memória remota é muito eficiente, apenas várias vezes (normalmente entre 2 e 3 vezes) o custo de acesso local.

A maioria dos fabricantes de PMS já estão oferecendo sistemas NUMA que pode escalar até uma centena de processadores. O argumento forte para NUMA é que ele não necessita de qualquer reescrita do software de aplicação. No entanto, alguns reescritas ainda é necessário no motor de banco de dados (e do sistema operacional) para tirar o máximo partido da localidade de acesso [Bouganim et al., 1999].

CLUSTERUm cluster é um conjunto de nós de servidores independentes interligados para compartilhar recursos e formar um único sistema. Os recursos compartilhados, chamados de recursos de cluster, pode ser hardware, tais como disco ou software como serviços de gerenciamento de dados. Os nós do servidor são feitas de off-the-shelf componentes que vão desde componentes do PC simples a SMP( sistema de multiprocessadores) mais poderoso. Usando muitos off-the-shelf componentes é essencial para obter a melhor relação custo / performance ao explorar o progresso contínuo em componentes de hardware. Na sua forma mais barata, a interconexão pode ser uma rede local. No entanto, há agora um padrão rápido interconexões de clusters (por exemplo, Myrinet e Infiniband) que oferecem alta largura de banda (Gigabits / seg), com baixa latência para o tráfego de mensagens. Em comparação com um sistema distribuído, um aglomerado é geograficamente concentrada (em um único local) e feita de nós homogéneos. Sua arquitetura pode ser nada comum ou disco compartilhado. Nada compartilhado de clusters têm sido amplamente utilizados, pois eles podem fornecer a melhor relação custo / desempenho e escalar até configurações muito grandes (milhares de nós). No entanto, porque cada disco está directamente ligado a um computador através de um barramento, adicionar ou substituir

os nós do cluster requer disco e reorganização de dados. Disco compartilhado evita essa reorganização, mas exige discos para ser globalmente acessível pelos nós do cluster. Existem duas principais tecnologias para compartilhar discos em um cluster:Armazenamento anexado à rede (NAS) e de Área de armazenamento de rede (SAN). Um NAS é um dispositivo dedicado para discos compartilhados em uma rede (normalmente TCP / IP) utilizando um sistema distribuído protocolo do sistema de arquivos, tais como Network File System (NFS). NAS é bem adequado para aplicações de baixo custo, como backup de dados e arquivamento de discos rígidos do PC.No entanto, é relativamente lento e não adequado para a gestão de base de dados como torna-se rapidamente um gargalo com muitos nós.

Um storage area network (SAN) fornece funcionalidade similar, mas com uma interface de baixo nível. Para a eficiência, ele usa um protocolo baseado em blocos, tornando assim mais fácil de gerenciar consistência do cache (em nível de bloco). Na verdade, os discos em uma SAN são ligados à rede, em vez de um barramento como acontece em armazenamento diretamente anexado (DAS), mas caso contrário, eles são tratados como discos locais compartilháveis. Protocolos existentes para SANs estendem os seus homólogos de disco local para executar através de uma rede (por exemplo, i-SCSI estende SCSI e ATA-over-Ethernet estende ATA). Como resultado, SAN fornece transferência de dados elevada e pode escalar até um grande número de nós. Sua única limitação com relação ao shared-nothing é o seu maior custo de propriedade.A arquitetura de cluster tem vantagens importantes. Ele combina a flexibilidade eo desempenho da memória compartilhada em cada nó com a extensibilidade e disponibilidade de nada-compartilhado ou disco compartilhado. Além disso, o uso off-the-shelf memória compartilhada nós com uma interconexão de cluster padrão faz com que seja uma alternativa de custo-benefício para proprietários de alta qualidade, como multiprocessadores NUMA ou MPP. Finalmente, usando SAN gerenciamento de disco e facilita a colocação de dados.

14.1.3.5 DiscussãoFaçamos uma breve comparação entre as três arquiteturas básicas com base em suas potenciais vantagens (de alto desempenho, alta disponibilidade e capacidade de extensão). É justo dizer que, para uma configuração de pequeno porte (por exemplo, menos de 20 processadores), memória partilhada pode fornecer o mais alto desempenho devido a uma melhor equilíbrio de carga.

Arquiteturas de disco compartilhado e nada compartilhado podem superar memória compartilhada em termos de extensibilidade. Alguns anos atrás, nada compartilhado era a única escolha para sistemas de alta qualidade. No entanto, os progressos recentes nas tecnologias de conectividade, tais como disco SAN fazer um disco compartilhado uma alternativa viável com a principal vantagem de simplificar a administração de dados e implementação do SGBD. Em particular, o disco-partilhada é agora a arquitectura preferida para aplicações OLTP porque é mais fácil para suportar as operações ACID e controle de concorrência distribuída. Mas, para bancos de dados OLAP que são tipicamente muito grande e principalmente só de leitura, nada-compartilhado é a arquitetura preferida. A maioria dos fornecedores principais DBMS agora fornecer uma implementação nada-partilhada da sua DBMS para OLAP, para além de uma versão compartilhada-disco para OLTP. O execption só é o Oracle que usa disco compartilhado, tanto para OLTP e OLAP.Arquiteturas híbridas, como o NUMA e cluster, pode combinar a eficiência e simplicidade de memória compartilhada ea extensibilidade e custo de qualquer disco compartilhado ou nada compartilhado. Em particular, eles podem explorar o progresso contínuo na PMS e usar memória compartilhada nós com relação custo / desempenho excelente. Ambos NUMA e cluster pode escalar até grandes configurações (centenas de nós). A principal vantagem do NUMA sobre um cluster é o modelo (memória compartilhada) de programação simples que facilita a administração de banco de dados e otimização. No entanto, usando nós de PC padrão e interconexões, os clusters de proporcionar uma melhor relação custo total / performance, e, usando compartilhada nada, eles podem escalar até configurações muito grandes (milhares de nós).

14.2 Particionamento de Dados ParalelosNesta seção, assumimos uma arquitetura nada compartilhado, porque é o caso mais geral e suas técnicas de execução também se aplicam, por vezes, de forma simplificada, para outras arquiteturas. Dados colocação em um sistema de banco de dados paralelo apresenta-dades semelhantes com a fragmentação dos dados em bancos de dados distribuídos (ver Capítulo 3). Uma semelhança óbvia é que a fragmentação pode ser usado para aumentar o paralelismo. No que se segue, usamos a compartimentação termos e partição em vez de fragmentação horizontal e fragmento horizontal, respectivamente, para contrastar com a estratégia alternativa, o qual consiste de aglomeração de uma relação a um único nó. O declustering termo é por vezes usado para significar particionamento [Livny et al., 1987]. Fragmentação vertical pode também ser usado para aumentar o paralelismo e equilíbrio de carga mais do que em bancos de dados distribuídos.

Outra semelhança é que uma vez que os dados são muito maiores do que os programas, a execução deve ocorrer, tanto quanto possível, onde os dados residem. No entanto, existem duas diferenças importantes com a abordagem de base de dados distribuída. Em primeiro lugar, não há necessidade de maximizar o processamento local (em cada nó), uma vez os utilizadores não estão associados com os nós particulares.Em segundo lugar, o equilíbrio de carga é muito mais difícil de conseguir, na presença de um grande número de nós. O principal problema é o de evitar a contenção de recursos, o que pode resultar na debulha sistema inteiro (eg, um nó acaba fazendo todo o trabalho enquanto os demais permanecem ociosos). Dado que os programas são executados onde os dados residem, a localização de dados é um problema de desempenho crítico.Colocação de dados deve ser feito de modo a maximizar o desempenho do sistema, que pode ser medido através da combinação da quantidade total de trabalho realizado pelo sistema e do tempo de resposta de consultas individuais. No capítulo 8, temos visto que a maximização tempo de resposta (através de paralelismo intra-consulta) resulta em aumento de trabalho total devido a sobrecarga de comunicação. Pela mesma razão, os resultados inter-consulta paralelismo em aumento do trabalho total. Por outro lado, o agrupamento de todos os dados necessários para um programa de comunicação minimiza e, assim, o trabalho total realizado pelo sistema na execução esse programa. Em termos de posicionamento de dados, temos o seguinte trade-off: tempo de resposta de maximização ou inter-consulta paralelismo leva a particionamento, enquanto minimizando a quantidade total de trabalho leva à aglomeração. Como vimos no capítulo 3, este problema é abordado em bancos de dados distribuídos de uma forma bastante estática.O administrador de banco de dados é responsável por examinar periodicamente as frequências de acesso de fragmentos e, quando necessário, mover e reorganizar fragmentos. Uma solução alternativa para a localização de dados é o particionamento completo, em que cada relação é horizontalmente fragmentado em todos os nós do sistema. Há três estratégias básicas para o particionamento de dados: partilha de round-robin, hash, range e (Figura 14.7).

1.Particionamento Round-Robin é a estratégia mais simples, assegura a distribuição de dados uniforme. Com n partições, a tupla i na ordem de inserção é atribuído a partição (i mod n). Essa estratégia permite o acesso seqüencial a uma relação a ser feito em paralelo. No entanto, o acesso directo ao tuplas individuais, com base em um predicado, exige acesso a relação inteira.

2. Particionamento Hash aplica uma função hash para algum atributo que produz o número da partição. Esta estratégia permite-match exato consultas sobre o atributo de seleção a ser processados por exatamente um nó e todas as outras consultas a serem processados por todos os nós em paralelo.

3. Faixa de particionamento distribui tuplas com base nos intervalos de valor (varia) de algum atributo. Além de apoiar correspondência exata consultas (como no hash), é bem adequada para consultas por abrangência. Por exemplo, uma consulta com um predicado "Uma entre A1 e A2" pode ser processado pelo nó apenas (s) contendo tuplas Um cujo valor está na faixa [A1, A2]. No entanto, o particionamento de intervalo pode resultar em uma alta variação de tamanho da partição.

Em comparação com as relações de agrupamento em um disco (possivelmente muito grande) único, cheio de particionamento desempenho melhor rendimento [Livny et al., 1987]. Apesar de particionamento completo tem vantagens óbvias de desempenho, execução altamente paralelo pode causar uma sobrecarga de desempenho sério para consultas complexas que envolvem junções. Além disso, o particionamento completo não é apropriada para pequenas relações que se estendem por alguns poucos blocos de disco. Estas desvantagens sugerem que um compromisso entre aglomeração e particionamento completo (ou seja, o particionamento variável), precisa ser encontrado.A solução é fazer a colocação dos dados por particionamento variável [Copeland et al., 1988]. O grau de separação, isto é, o número de nós sobre a qual uma relação é fragmentada, é uma função do tamanho e da

frequência de acesso da relação. Esta estratégia é muito mais envolvido do que qualquer um particionamento de agrupamento ou completo, porque as mudanças na distribuição de dados pode resultar na reorganização. Por exemplo, uma relação inicialmente colocado através oito nós pode ter a sua cardinalidade duplicado por inserções subsequentes, caso em que deve ser colocado através de 16 nós. Em um sistema altamente paralelos com o particionamento variável, reorganizações periódicas para balanceamento de carga são essenciais e devem ser freqüentes, a menos que a carga de trabalho é bastante estático e experimenta apenas algumas atualizações. Tais reorganizações deve permanecer transparente para os programas compilados que rodam no servidor de banco de dados. Em particular, os programas devem não ser recompilados por causa da reorganização. Portanto, os programas compilados deve permanecer independente dos dados de localização, que podem mudar rapidamente. Tal independência pode ser conseguido se o sistema de tempo de execução suporta o acesso associativa para dados distribuídos. Isto é diferente de um SGBD distribuído, onde o acesso associativo é alcançado em tempo de compilação pelo processador de consulta usando o diretório de dados.Uma solução para o acesso associativo é ter um mecanismo de índice global replicado em cada nó [Khoshafian e Valduriez, 1987]. O índice global indica a colocação de uma relação em um conjunto de nodos. Conceitualmente, o índice global é um índice de dois níveis com um agrupamento importante sobre o nome da relação e um agrupamento menorem alguns atributo da relação. Este índice global suporta particionamento variável, onde cada relação tem um grau diferente de particionamento. A estrutura do índice pode ser baseada em hashing ou em uma árvore B como organização [Bayer e McCreight, 1972]. Em ambos os casos, consultas de correspondência exacta pode ser processada de forma eficiente com um nó de acesso único.No entanto, com hash, range queries são processadas através do acesso de todos os nós que contêm dados da r elação consultados. Usando um índice B-tree (geralmente muito maior do que um índice hash) permite um processamento mais eficiente de consultas por abrangência, onde somente os nós que contêm dados no intervalo especificado são acessados.Exemplo 14.1. Figura 14.8 fornece um exemplo de um índice global e um local em dex para relação EMP (ENO, ENAME, DEPT, TITLE) do exemplo de banco de dados de engenharia que têm vindo a utilizar neste livro. Suponha que queremos localizar os elementos EMP relação com o valor ENO "E50". O índice de primeiro nível em mapas nome definido o EMP nome para o índice em ENO atributo para EMP relação. Em seguida, o índice de segundo nível mais mapeia o cluster"E50" valor para j número de nó. Um índice de local dentro de cada nó é também necessário

para mapear uma relação em um conjunto de páginas de disco dentro do nó. O índice local tem dois andares, com um agrupamento maior em nome da relação e um agrupamento menor em algum atributo. O atributo agrupamento menor para o índice local é o mesmo que para o índice global. Assim roteamento associativa é melhorada de um nó para outro com base em (valor de cluster nome da relação). Este índice local ainda mapeia o cluster valor "E5" em número de página 91. ?Os resultados experimentais para o particionamento variável de uma carga de trabalho constituído por uma mistura de transações curtas (débito, crédito-like) e os complexos indicam que partição ing é aumentada, o rendimento continua a aumentar para transações curtas. No entanto, para transações complexas envolvendo várias grandes junções, particionamento reduz ainda mais o rendimento por causa da sobrecarga de comunicação [Copeland et al., 1988]. Um problema sério na colocação de dados está lidando com distribuições de dados distorcidos que podem levar ao não-uniforme de particionamento e ferir o balanceamento de carga. Faixa de particionamento é mais sensível à inclinação do que qualquer um particionamento round-robin, ou hash. Uma solução consiste em tratar não uniformes partições apropriadamente, por exemplo, por fragmentando ainda mais partições grandes. A separação entre os nós lógico e físico também é útil uma vez

que um nó lógico pode corresponder a vários nós físicos.Um último fator complicador é a replicação de dados para alta disponibilidade. A solução mais simples é manter duas cópias dos mesmos dados, um primário e uma cópia de segurança, em dois nós separados. Este é o espelhado arquitectura discos promovida por muitos fabricantes de computadores. No entanto, no caso de uma falha de nó, a carga do nó com a cópia pode dobrar, assim, prejudicar o equilíbrio de carga. Para evitar este problema, várias estratégias de alta disponibilidade de replicação de dados têm sido propostos para sistemas de base de dados paralelos [Hsiao e DeWitt, 1991]. Uma solução interessante é o particionamento interleaved da Teradata que as partições mais a cópia de backup em um número de nós. Figura 14,9 ilustra a compartimentação intercalada de R relação ao longo de quatro nós, onde cada

cópia primária de uma partição, por exemplo, R1, é futher dividido em três partições, por exemplo, r11, r12, r13 e, cada um a um nó cópia de segurança diferente. Em modo de falha, a carga da cópia primária fica equilibrada entre os nós de cópias de backup. Mas se dois nós falhar, então a relação não pode ser acessado assim prejudicando a disponibilidade. Reconstruindo a cópia primária de suas cópias de segurança separadas pode ser caro. No modo normal, mantendo a consistência de cópia pode também ser dispendiosa.

Uma solução melhor é o particionamento acorrentado Gamma [Hsiao e DeWitt, 1991], que armazena a cópia primária e de backup em dois nós adjacentes (Figura 14.10). A ideia principal é que a probabilidade de que dois nós adjacentes falhar é muito menor do que a probabilidade de que quaisquer dois nós falhar. Em modo de falha, a carga do nó que falhou e os nós de backup são equilibradas entre todos os nós restantes usando nós cópia primário e backup. Além disso, mantendo a consistência de cópia é mais barato. Uma questão em aberto é como executar a colocação de dados tendo em conta a replicação de dados. Similar à alocação fragmento em bancos de dados distribuídos, esta deve ser considerada um problema de otimização.

14,3 Processamento de consulta paralelaO objetivo do processamento de consulta paralelo é transformar consultas em planos de execução que pode ser eficientemente executadas em paralelo. Isto é conseguido através da exploração paralelo posicionamento de dados e as várias formas de paralelismo oferecidas pelo alto nível consultas. Nesta seção, apresentamos as várias formas de paralelismo consulta. Então tiramos básicas algoritmos paralelos para processamento de dados. Finalmente, discute-se a otimização da consulta paralela.

14.3.1 Paralelismo ConsultaExecução de consulta paralela pode explorar duas formas de paralelismo: inter-e intra-consulta. Inter-consulta paralelismo permite a execução paralela de várias consultas geradas por transações simultâneas, a fim de aumentar a taxa de transferência transacional. Dentro de uma consulta (intra-consulta paralelismo), operador de inter-e intra-operador paralelismo são usados para diminuir o tempo de resposta. Inter-operador paralelismo é obtido por meio da execução paralela vários operadores da árvore de consulta em vários processadores enquanto com intra-perator paralelismo, o mesmo operador é executado por muitos processadores, cada um trabalha em um subconjunto dos dados. Note-se que estas duas formas de paralelismo também existem no processamento de consultas distribuídas.

14.3.1.1 paralelismo intra-operadorIntra-operador paralelismo é baseado na decomposição de um operador de um conjunto de sub-independente operadores, chamados de instâncias do operador. Esta decomposição é feito usando o particionamento estático e / ou dinâmica das relações. Cada instância operador irá então processar uma partição relação, também chamado de um balde. A decomposição do operador fre quentemente-benefícios decorrentes da compartimentação inicial dos dados (por exemplo, os dados são particionado no atributo de junção). Para ilustrar intra-operador paralelismo, vamos considerar uma consulta selecione-join simples. O operador de seleção pode ser diretamente decomposta em vários operadores de seleção, cada um em uma partição diferente, e não redistribuição é necessária (Figura 14.11). Note-se que, se a relação é particionada no atributo select, particionamento prop-priedades pode ser utilizado para eliminar alguns casos seleccionados. Por exemplo, em um arquivo. De correspondência exata de seleção, apenas uma instância de seleção será executado se a relação era dividida por hashing (ou faixa) no atributo select É mais complexo para decompor o operador de junção. A fim de ter independente junta-se, cada balde da relação R primeiro lugar, podem ser unidas a toda a relação S. Tal junção será muito ineficiente (a menos que S é muito pequeno) porque implica uma transmissão de S em cada processador participante. Uma maneira mais eficiente é usar propriedades de particionamento. Por exemplo, se R e S são particionados por hash no atributo de junção e se a junção é uma equijoin, então podemos particionar a juntar-se em junta independente (ver Algoritmo 14,3 na Seção 14.3.2). Este é o caso ideal que não pode ser sempre utilizado, porque depende da compartimentação inicial de R e S. Em outros casos, um ou dois operandos podem ser repartitioned [Valduriez e Gardarin, 1984]. Finalmente, podemos notar que a função de particionamento (intervalo, hash, round robin) é independente do algoritmo local (por exemplo, loop aninhado, hash, merge sort) usado para processar o operador de junção (ou seja, em cada processador). Por exemplo, um hash juntar-se usando um particionamento por hash precisa de duas funções de hash. A primeira, h1, é usado para partição as duas relações de base sobre o atributo de junção. A um segundo, h2, que pode ser diferente para cada processador, é usado para processar a junção em cada processador.

14.3.1.2 Paralelismo Inter-operador

Duas formas de inter-operador paralelismo pode ser explorado. Com o paralelismo de pipeline, vários operadores com uma ligação do produtor-consumidor são executados em paralelo. Para nstance, o operador de seleção na Figura 14,12 será executado em paralelo com o operador de junção. A vantagem de tal execução é que o resultado intermediário, não se materializa, economizando assim memória e acessos ao disco. No exemplo da Figura 14,12, apenas S pode encaixar na memória. Paralelismo independente é alcançada quando não há nenhuma dependência entre os operadores que são executadas em paralelo. Por exemplo, os dois operadores escolha da Figura 14,12 pode ser executado em paralelo. Esta forma de paralelismo é muito atraente porque não há interferência entre os processadores.

14.3.2 Algoritmos Paralelos para Processamento de DadosParticionada colocação de dados é a base para a execução paralela de consultas de dados. Dada a colocação de dados particionado, uma questão importante é o projeto de algoritmos paralelos para um processamento eficiente dos operadores de banco de dados (ou seja, os operadores da álgebra relacional) e consultas de banco de dados que combinam múltiplos operadores. Esta questão é difícil, porque um bom trade-off entre paralelismo e custo de comunicação deve ser alcançado uma vez que o aumento de paralelismo envolve mais a comunicação entre nós. Algoritmos paralelos para operadores da álgebra relacional são os blocos de construção necessários para o processamento de consulta paralela.Processamento paralelo de dados deve explorar intra-operador paralelismo. Nós nos concentramos nossa apresentação de algoritmos paralelos para operadores de banco de dados sobre os operadores selecionar e juntar-se, uma vez que todos os outros operadores binários (como união) pode ser tratado muito bem como juntar-se [Bratbergsengen, 1984]. O processamento do operador seleccione num contexto de dados particionado colocação é idêntica à que, em uma base de dados fragmentada distribuído. Dependendo do predicado select, o operador pode ser executado a um único nó (no caso de um predicado correspondência exacta) ou, no caso de predicados arbitrariamente complexos, em todos os nós sobre a qual a relação é particionada. Se o índice mundial é organizado como um B-árvore-como estrutura (ver Figura 14.8), um operador de seleção com um predicado de intervalo só possa ser executado por nós que armazenam dados relevantes.O processamento paralelo de junção é significativamente mais envolvidos do que seleção.Os algoritmos de junção distribuídos projetados para redes de alta velocidade (ver Capítulo 8) pode ser aplicado com sucesso em um contexto de banco de dados particionado. No entanto, a disponibilidade de um índice global em tempo de execução oferece mais oportunidades para a execução paralela eficiente. A seguir, apresentamos três paralelo básico algoritmos de junção para bancos de dados particionados: o loop aninhado paralelo algoritmo (PNL), o paralelo associativa junção algoritmo (PAJ), eo paralelo hash algoritmo (PHJ). Descrevemos cada um usando uma linguagem de programação pseudo-concorrente com três construções principais: paralelo fazer, enviar e receber. Paralelo-fazer especifica que o bloco de ações a seguir é executado em paralelo. Por exemplo:for i from 1 to n in parallel do action A

indica que a acção A é para ser executado por n nós em paralelo. Enviar e receber são as primitivas básicas de comunicação para transferência de dados entre os nós. Enviar permite que os dados a serem enviados a partir de um nó a um ou mais nós. Os nodos de destino são tipicamente obtido a partir do índice global. Receber obtém o conteúdo dos dados enviados a um nó particular. No que se segue, consideramos a junção de duas relações R e S que são particionadas sobre os nós m e n, respectivamente. Por razões de simplicidade, assumimos que os nós m são distintas das n nós. Um nó em que um fragmento de R (respectivamente, S) reside é chamado um R-nó (respectivamente, S-nó). O algoritmo de nested loop paralelo [Bitton et al., 1983] é o mais simples e mais geral. É basicamente compõe o produto cartesiano das relações R e S em paralelo. Portanto, os predicados de junção arbitrariamente complexas podem ser apoiados. Este algoritmo foi introduzido no Capítulo 8, no contexto de Ingres distribuídas. É mais precisamente descrita no Algoritmo 14,1, onde o resultado de junção é produzida com os S-nodos. O algoritmo procede em duas fases.Na fase primeira, cada fragmento de R é enviado e replicado em cada nó contendoum fragmento de S (há n nós mesmos). Esta fase é feito em paralelo pelos nós me é efi ciente ¬ se a rede de comunicação tem uma capacidade de difusão. Neste caso, cada fragmento de R pode ser transmitido para n nós em uma única transferência, incorrendo um custo de comunicação total de mensagens m. Caso contrário, (M n) mensagens são necessárias.Na segunda fase, cada j S-nó recebe R relação inteiramente, e junta-se localmente com R j fragmento S. Esta fase é feito em paralelo por n nós. A junção local pode ser feito como em um SGBD centralizado. Dependendo do algoritmo de junção local, o processo de junção pode ser ou não começar assim que os dados são recebidos. Se um loop aninhadoalgoritmo é usado, juntar-se o processamento pode ser feito de uma forma em conduta, logo que um de R tupla chega. Se, por outro lado, uma espécie-fundir algoritmo de junção é usado, todos os dados devem ter sido recebido antes da junção das relações ordenados começa. Para resumir, o algoritmo de loop paralelo aninhado pode ser visto como a substituição do operador

Exemplo 14.2. Figura 14,13 mostra a aplicação do algoritmo de loop paralelo aninhada com m = n = 2.O paralelo algoritmo de junção associativa, mostrado na Algoritmo 14,2, aplica-se apenas no caso de equijoin com uma das relações de operando particionado de acordo com o atributo de junção. Para simplificar a descrição do algoritmo, assumimos que o predicado equijoin está no atributo A a partir de R, e B a partir de S. Além disso, a relação S é particionado de acordo com a função hash h aplicada para aderir B atributo, o que significa que todos os tuplos de S, que têm o mesmo valor para h (B) são colocados no mesmo nó. Nenhum conhecimento de como R é particionado é assumido.A aplicação do algoritmo de junção paralelos associativo irá produzir a junçãoresultar nos nodos onde existe Si (isto é, o S-nós).

O algoritmo procede em duas fases. Na primeira fase, a relação R é enviado como-sociatively para o S-nodos com base na função hash h aplicado a atribuir A. Estegarante que uma tupla de R com v valor de hash é enviado apenas para o nó S-que con-tém tuplas com valor de hash v A primeira fase é feito em paralelo por nós m, onde está Ri existir. Assim, ao contrário do loop

aninhado paralelo algoritmo, os tuplos de R são distribuídos, mas não imitado em todo o S-nós. Isto reflecte-se nas duas primeiras Paralelo-fazer afirmações do algoritmo onde cada nodo i produz fragmentos m de Ri e envia cada j Ri fragmento para o nó de armazenamento de S j.Na segunda fase, cada j S-nó recebe em paralelo a partir do diferente de I-nodes o subconjunto relevante de R (isto é, R j) e junta-se localmente com j os fragmentos de S. Processamento de junção local pode ser feito como no circuito paralelo aninhado algoritmo. Para resumir, o algoritmo de junção paralelos associativo substitui o operador

Exemplo 14.3. Figura 14,14 mostra a aplicação do associativa paralela juntar algoritmo com m = n = 2. Os quadrados que são incubados com o mesmo padrão indicam fragmentos cuja tuplas coincidir com a mesma função hash.

O paralelo algoritmo de junção hash, mostrado no Algoritmo 14.3, pode ser visto como uma generalização do algoritmo de junção paralela associativo. Também se aplica no caso de equijoin mas não exige qualquer particionamento específico das relações operando. A idéia básica é a partição relações R e S na p mesmo número de conjuntos mutuamente exclusivos (fragmentos) R1, R2; ...; Rp e S1; S2; ...; Sp, tal que

Tal como no paralelo algoritmo de junção associativa, a compartimentação de R e S podem basear-se na mesma função hash aplicada ao atributo de junção. Cada junção individual é feito em paralelo, eo resultado de junção é produzido nos nós p. Estes nós p pode efectivamente ser seleccionadas em tempo de execução com base na carga do sistema. A principal diferença com o paralelo algoritmo de junção associativo é que o particionamento de S é necessário, eo resultado é produzido nos nós de p em vez de N S-nós. O algoritmo pode ser dividido em duas fases principais, uma fase de construção e uma fase de sonda [DeWitt e Gerber, 1985]. A compilação fase hashes R no atributo de junção, envia para os nós de destino p que construir uma tabela de hash para as tuplas de entrada. A fase de sonda envia S associativamente para os nós de destino p que sondam a tabela de hash para cada tupla de entrada. Assim, logo que as tabelas de hash foram construídos para R, as tuplas de S pode ser enviada e processada no pipeline sondando as tabelas de hash. 14,4 exemplo. Figura 14,15 mostra a aplicação do hash paralelo algoritmo de junção com 2 = m = n. Assumiu-se que o resultado é produzido nos nós 1 e 2. Portanto, uma seta do nó 1 para o nó 1 ou 2 nó para nó 2 indica uma transferência local. ? Como é comum, cada algoritmo de junção paralela aplica-se e domina em diferentes condições. O processo de junção é conseguido com um grau de paralelismo de ser n ou p.

Uma vez que cada algoritmo requer mover pelo menos uma das relações de operando, um bom indicador do seu desempenho é o custo total. Para comparar estes algoritmos, nós agora dar uma análise simples de custo, definido em termos de custo total custo (CCOM ) e de processamento da comunicação (Cpro). O custo total de cada algoritmo é, portanto

Por simplicidade, Ccom não inclui mensagens de controlo, que são necessários para iniciar e terminar tarefas locais. Denotamos por msg (# tup) o custo de transferir uma mensagem de # tup tuplas de um nó para outro. Custos de processamento (que incluem total de I / O e custo da CPU) baseiam-se a função CLOC (m, n), que calcula o custo de processamento local para unir duas relações com cardinalidades M e N. Presumimos que o algoritmo de junção local é a mesma para todos paralelo três algoritmos de junção. Finalmente, assumimos que a quantidade de trabalho feito em paralelo é distribuído uniformemente sobre todos os nós alocados para o operador.Sem capacidade de transmissão, o algoritmo de nested loop paralelo incorre em um custo de mensagens mn, onde uma mensagem contém um fragmento de R cartão de tamanho (R) tuplas = m. Assim, temos

Cada um dos S-nós devem aderir todos R com fragmentos seus S. Assim, temos

O paralelo algoritmo de junção associativo exige que cada um de nós partições R-nodefragmento de R em subconjuntos de n de cartão de tamanho (R) / (m*n) e envia-os a n S-nós.Assim, temos

O paralelo algoritmo de junção de hash requer que ambos R e S relações ser particionada entre os nós de p de um modo semelhante ao algoritmo de junção paralelos associativa. Assim, temos

Vamos primeiro supor que p = n. Neste caso, o custo de processamento de junção para a PAJ e algoritmos PHJ é idêntica. No entanto, é mais elevado para o algoritmo de PNL, porque cada nó-S deve executar a junção com R inteiramente. A partir das equações acima, é evidente que o algoritmo PAJ incorre o menor custo de comunicação. No entanto, a comparação do custo de comunicação entre o PNL e algoritmos PHJ depende dos valores de cardinalidade relação e grau de compartimentação. Se escolhermos p <n, o algoritmo PHJincorre o menor custo de comunicação, mas à custa de processamento de juntar-se aumentocusto. Por exemplo, if p = 1, a junção é processado de um modo puramente centralizada. Em conclusão, o algoritmo PAJ é mais provável de dominar e deve ser usado quando aplicável. Caso contrário, a escolha entre o PNL e algoritmos PHJ requer a estimativa do seu custo total com o valor ideal para p. A escolha de um algoritmo de junção paralelos podem ser sintetizados pelo procedimento ESCOLHER JA mostrado na gorithm14,4, onde o perfil de uma relação indica se é particionada e sobre a qualatributo.

14.3.3 Otimização de consulta paralelaOtimização da consulta paralela exibe semelhanças com o processamento de consulta distribuída. No entanto, concentra-se muito mais em aproveitar tanto paralelismo intra-operador (usando os algoritmos descritos acima) e inter-operador paralelismo. Como qualquer otimizador de consulta (ver Capítulo 8), um otimizador de consulta paralela pode ser visto como três componentes: um espaço de busca, um modelo de custos, e uma estratégia de pesquisa. Nesta seção, descrevemos as técnicas para esses componentes.

14.3.3.1 Pesquisa EspacialOs planos de execução são captada por meio de árvores de operador, que definem a ordem em que os

operadores são executados. Árvores do operador são enriquecidos com anotações, que indicam os aspectos de execução adicionais, tais como o algoritmo de cada operador. Em um SGBD paralelo, um aspecto importante para a execução ser refletida por anotações é o fato de que dois operadores subseqüentes podem ser executadas em pipeline. Neste caso, o segundo operador pode começar antes da primeira é concluída. Em outras palavras, o segundooperador começa tuplas consumindo assim que a uma primeira produz-los. Execuções pipeline não requerem relações temporários para ser materializada, isto é, um nó da árvore correspondente a um operador executado em oleoduto não é armazenada.

Alguns operadores e alguns algoritmos exigem que um operando é armazenado. Por exemplo, no hash paralelo algoritmo de junção (ver Algoritmo 14,3), na fase de construção, uma tabela de dispersão é construído em paralelo no atributo de junção da menor relação. Na fase de investigação, a maior relação é digitalizado e sequencialmente a tabela hash é consultado para cada uma de suas tuplas. Portanto, as anotações de oleodutos e armazenados restringir a programação de planos de execução, dividindo uma árvore de operador em que não se sobrepõem subárvores, correspondendo a fases de execução. Operadores pipeline são executados na mesma fase, geralmente chamado de cadeia oleoduto Considerando que uma indicação de armazenamento estabelece o limite entre uma fase e uma fase subsequente.

Exemplo 14.5. Figura 14.16 mostra duas árvores de execução, um sem gasoduto e um com pipeline. Pipelining uma relação é indicado por uma seta com cabeça maior. Figura 14,16 (a) mostra uma execução sem pipeline. O Temp1 relação temporária deve ser completamente produzido e tabela de hash em build2 deve ser construído antes Probe2 pode começar R3 consumidores. O mesmo é verdadeiro para Temp2, Build3 e Probe3. Assim, a árvore é executado em quatro fases consecutivas: (1) construir tabela hash R1, (2) sondá-lo com R2 e construir tabela hash Temp1 de (3), sondá-lo com R3 e construir tabela hash Temp2 de (3), sondá-lo com R3 e produzir o resultado. Figura 14,16 (b) mostra uma execução pipeline. A árvore pode ser executado em duas fases, se há memória suficiente para construir as tabelas de hash: (1) construir as tabelas para R3 R1 e R4, (2) executar Probe1, Probe2 e Probe3 em pipeline. ?

O conjunto de nós, onde uma relação é armazenado é chamado a sua casa. A casa de um operador é o conjunto de nós, onde ele é executado e deve ser a casa de seus operandos em ordem para o operador para acessar seu operando. Para operadores binários, tais como junção, isto poderia implicar reparticionar um dos operandos. O otimizador pode atéàs vezes achar que reparticionar os operandos é de interesse. Árvores Operador conter anotações de execução para indicar reparticionamento.

Figura 14,17 mostra quatro árvores que representam operadoras de planos de execução para uma de três vias participar. Large-cabeça setas indicam que a relação de entrada é consumido no pipeline, isto é, não é armazenado localmente. Árvores operador pode ser linear, isto é, pelo menos, um operando de cada nó de junção é uma relação de base ou espessa. É conveniente para representar relações em conduta de entrada como o lado direito de um operador. Assim, o direito-profundas árvores expressar pipelining completo enquanto de profundidade à esquerda árvores expressar plena materialização de todos os resultados intermediários. Assim, longos direito profundas árvores são mais eficientes, em seguida, correspondente à esquerda de profundidade

árvores, mas tendem a consumir mais memória para armazenar as relações lado esquerdo. Em uma árvore da esquerda profunda tal como o da Figura 14,17 (a), só o operador última pode consumir a sua relação de entrada direita no pipeline, desde que a relação de entrada esquerda, pode ser inteiramente armazenado na memória principal.

Formatos de árvores paralelas que não sejam da esquerda ou da direita profunda também são interessantes. Por exemplo, árvores espessas (Figura 14.17 (d)) são os únicos que permitem o paralelismo independente e um certo paralelismo de pipeline. Paralelismo independente é útil quando as relações são divididas em casas disjuntos. Suponha-se que as relações na Figura 14,17 (d) são particionada tal que (R1 e R2) têm a mesma casa h1 e (R3 e R4 têm o mesmo casa h2), separado a partir de h1. Em seguida, junta-se a duas das relações de base poderia ser executada de forma independente em paralelo pelo conjunto de nodos que constitui H1 e H2.Quando o paralelismo de pipeline é benéfica, árvores em ziguezague, que são formatos intermediários entre as árvores de profundidade à esquerda e à direita de profundidade, às vezes pode superar direito profundas árvores devido a uma melhor utilização da memória principal [Ziane et al., 1993]. Uma heurística razoável é favorecer árvores direita profundas ou em ziguezague, quando as relações são parcialmente fragmentado em lares separados e as relações intermediárias são bastante grandes. Neste caso, as árvores espessas necessita normalmente mais fases e levam mais tempo para executar. Pelo contrário, quando as relações intermédias são pequenas, pipelining não é muito eficiente, porque é difícil para equilibrar a carga entre os estágios de pipeline.

14.3.3.2 Modelo de CustoLembre-se que o modelo de custo otimizador é responsável por estimar o custo de um plano de execução determinado. É composto de duas partes: dependentes de arquitetura e arquitetura independente [Lanzelotte et al, 1994.]. A parte de arquitetura independente é constituída das funções de custo para os algoritmos de operador, de alça, por exemplo, aninhada para junção e sequen-cial de acesso para seleção. Se ignorar as questões de concorrência, apenas as funções de custo para os dados e reparticionamento consumo de memória diferentes e representam a parte dependente da arquitetura. Na verdade, reparticionamento tuplas de uma relação em um sistema nada compartilhada implica em transferências de dados através da interconexão, enquanto reduz a hash em sistemas de memória compartilhada. O consumo de memória no caso nada-compartilhada é compli-cado pelo operador inter-paralelismo. Em memória partilhada sistemas, todos os operadores de ler e escrever dados através de uma memória global, e é fácil de testar se existe espaço suficiente para executar as mesmas em paralelo, isto é, a soma do consumo de memória de indivi-duais operadores é menor do que a memória disponível. Em comum, nada, cada processador tem sua própria memória, e torna-se importante saber quais os operadores são executados em paralelo no mesmo processador. Assim, por simplicidade, pode presumir-se que o conjunto de processadores (casa) atribuídos aos operadores não se sobrepõem, isto é, ou intersecção do do conjunto de processadores está vazio ou os conjuntos são idênticos.O tempo total de um plano pode ser calculado por uma fórmula que simplesmente adiciona toda a CPU, I / O e componentes de custo de comunicação como na otimização da consulta distribuída. O tempo de resposta é mais complexa, pois deve levar em conta pipelining. O tempo de resposta de p plano, programado em fases (cada denotada pelo pH), é com-puted como se segue [Lanzelotte et al, 1994.]:

onde Op denota um operador e respTime (Op) é o tempo de resposta de Op, tubo de atraso (Op) é o período de espera de Op necessário para que o produtor de fígado de as tuplas primeiro resultado (que é igual a 0, se as relações de entrada de O são armazenados), armazenar atraso (ph) é o tempo necessário para armazenar o resultado de saída do pH fase (que é igual a 0 Se o pH é a última fase, assumindo que o resultado são entregues logo que eles são produzidos).Para estimar o custo de um plano de execução, o modelo de custos utiliza estatísticas de banco de dados e informações da organização, tais como cardinalidades relação e particionamento, como com a otimização de consultas distribuídas.

14.3.3.3 Estratégia de PesquisaA estratégia de pesquisa não precisa ser diferente de qualquer otimização da consulta centralizada ou distribuída. No entanto, o espaço de busca tende a ser muito maior porque há mais parâmetros que os planos de execução paralela de impacto, no gasoduto, particular e anotações da loja. Assim, estratégias de busca ao acaso (ver Seção 8.1.2) geralmente superam estratégias deterministas na otimização de consulta paralela.Desfazer edições

14,4 Balanceamento de cargaBalanceamento de carga Bom é crucial para o desempenho de um sistema paralelo. Como observado no Capítulo 8, o tempo de resposta de um conjunto de operadores paralelas é que a mais longa de um. Assim, minimizando o tempo de uma a mais longa é importante para minimizar o tempo de resposta. Equilibrar a carga de diferentes transações e consultas entre os diferentes nós também é essencial para maximizar o rendimento. Embora o otimizador de consulta paralela incorpora decisões sobre como executar um plano de execução paralela, balanceamento de carga pode ser ferido por vários problemas incorrendo em tempo de execução. Soluções para esses problemas podem ser obtidas nos níveis intra e inter-operador. Nesta seção, discutimos esses problemas de execução paralela e suas soluções.

14.4.1 paralelas problemas de execução

Os principais problemas introduzidos pela execução de consulta paralela são interferências de inicialização, e inclinação.

Inicialização.Antes da execução tem lugar, uma etapa de inicialização é necessário. Este primeiro passo é geralmente sequencial. Ele inclui a criação do processo (ou thread) e inicialização, inicialização comunicação, etc A duração desta etapa é proporcional ao grau de paralelismo e podem realmente dominar o tempo de execução de consultas simples, por exemplo, uma consulta de selecção de uma relação única. Assim, o grau de paralelismo deve serfixado de acordo com a complexidade da consulta.Uma fórmula pode ser desenvolvido para estimar o aumento de velocidade máxima alcançável durante a execução de um operador e para deduzir o número óptimo de processadores [Wilshut e Apers, 1992]. Vamos considerar a execução de um operador que N processos tuplas com n processadores. Seja C o tempo médio de processamento de cada tupla e um tempo a inicialização por processador. No caso ideal, o tempo de resposta do operador de execução é

Por derivação, podemos obter o número ideal de processadores para alocar e n0 o speedup máximo possível (S0).

O número óptimo de processadores (n0) é independente de n, e apenas depende do tempo de processamento total e tempo de inicialização. Assim, maximizar o grau de paralelismo para um operador, por exemplo, usando todos os processadores disponíveis, pode prejudicar a velocidade-up por causa da sobrecarga de inicialização.

Interferências.A execução altamente paralelo pode ser retardado por interferência. A interferência ocorre quando vários processadores simultaneamente acessar o mesmo recurso de hardware ou software.Um exemplo típico de interferência de hardware é a contenção criado no barramento de um sistema de memória

partilhada. Quando o número de processadores é aumentado, o número de conflitos sobre os aumentos de autocarros, limitando assim a extensibilidade da memória partilhadasistemas. A solução para essas interferências é duplicar recursos compartilhados. Por exemplo, a interferência de acesso ao disco pode ser eliminada pela adição de vários discos e particionamento as relações.Software interferência ocorre quando vários processadores deseja acessar dados compartilhados.Para evitar a incoerência, variáveis de exclusão mútua são usadas para proteger dados compartilhados, bloqueando assim a todos, mas um processador que acessa os dados compartilhados. Isto é semelhante ao das bloqueio baseados algoritmos de simultaneidade de controlo (ver Capítulo 11).No entanto, variáveis compartilhadas pode muito bem se tornar o gargalo da execução da consulta, a criação de hot spots e os efeitos do comboio [Blasgen et al., 1979]. Um exemplo típico de interferência de software é o acesso das estruturas de base de dados internos tais como índices e tampões. Para simplificar, as versões anteriores de sistemas de banco de dados eram protegidos por uma variável única exclusão mútua. Estudos têm demonstrado a sobrecarga de tais estratégia: 45% do tempo de execução de consulta foi consumido por interferência entre 16 processadores. A solução geral para interferência software é particionar o recurso compartilhado em vários recursos independentes, cada uma protegida por uma variável diferente de exclusão mútua. Assim, dois recursos independentes podem ser acedida em paralelo, o que reduz a probabilidade de interferência. Para reduzir ainda mais a interferência em uma fonte independente (por exemplo, uma estrutura de índice), a replicação pode ser usado. Assim, o acesso aos recursos replicados também pode ser paralelizadas.

Skew

Problemas de balanceamento de carga pode aparecer com intra-operador paralelismo (variação no tamanho da partição), ou seja, dados de inclinação, e inter-operador de paralelismo (variação na complexidade dos operadores).Os efeitos da distribuição assimétrica dos dados em uma execução paralela pode ser classificada da seguinte forma [Walton et al., 1991]. Valor do atributo de inclinação (AVS) é a inclinação inerente ao conjunto de dados (por exemplo, existem mais cidadãos em Paris do que em Waterloo), enquanto a colocação tupla inclinação (TPS) é a distorção introduzida quando os dados são inicialmente particionado (por exemplo, com particionamento de intervalo). Selectividade de inclinação (SS) é introduzida, quando há uma variação da selectividade dos predicados escolha em cada nó. A redistribuição de inclinação (RS) ocorre na etapa de redistribuição entre dois operadores. É semelhante a TPS. Por fim juntar-se produto de inclinação (JPS) ocorre porque a seletividade de junção pode variar entre nós. Figura 14,18 ilustra esta classificação em uma consulta sobre duas relações R e S que são mal particionadas. As caixas são proporcionais ao tamanho das partições correspondentes.Particionamento pobre tal deriva tanto os dados (EVA) ou a função de particionamento (TPS). Assim, os tempos de processamento dos dois casos Scan1 e Scan2 não são iguais.O caso do operador de junção é pior. Em primeiro lugar, o número de tuplas recebidos é diferente de um para outro exemplo por causa da redistribuição pobre das partições de R (RS) ou selectividade variável de acordo com a partição de R processada (SS). Finalmente, o tamanho irregular de partições S (EAV / TPS) produz os tempos de processamento diferentes para tuplas enviados pelo operador de verificação ea dimensão resultado é diferente de uma partição para o outro devido ao juntar-se a selectividade (JPS).

14.4.2 Load Balancing Intra-OperadorBom equilíbrio de carga intra-operador depende do grau de paralelismo e da atribuição de processadores para o operador. Para alguns algoritmos, por exemplo, o hash paralelo algoritmo de junção, estes parâmetros não são limitados pela colocação dos dados. Assim, a casa do operador (o conjunto de processadores, onde ele é executado) deve ser cuidadosamente decidido. O problema de inclinação faz com que seja difícil para um otimizador de consulta paralela a tomar esta decisão estaticamente (em tempo de compilação), como seria necessário um modelo de custo muito precisas e detalhadas. Por conseguinte, as soluções principais dependem adaptativa ou especializado

técnicas que podem ser incorporados em uma otimizador híbridos. Descrevemos abaixo estas técnicas no contexto da junta paralelo, o que tem recebido muita atenção. Para simplificar, vamos supor que cada operador é dada uma casa, tal como decidido pelo processador de consulta (estaticamente ou apenas antes da execução).Técnicas adaptativas. A idéia principal é estaticamente decidir sobre uma alocação inicial dos processadores para o operador (usando um modelo de custo) e, em tempo de execução, adaptar-se a inclinação usando carga reafectação-cação. Uma abordagem simples para carregar realocação é detectar as partições muito grandes e de partição-los novamente para vários processadores (entre os processadores já alocadospara a operação) para aumentar o paralelismo [Kitsuregawa e Ogawa, 1990; Omiecinski, 1991]. Esta abordagem é generalizada para permitir mais ajuste dinâmico do grau de paralelismo [Biscondi et al., 1996]. Ele usa os operadores de controle específicos no plano de execução para detectar se as estimativas estáticas para o tamanho dos resultados intermediáriosserá diferente a partir dos valores de tempo de execução. Durante a execução, se a diferença entre a estimativa tje eo valor real é suficientemente elevada, o operador controle executa redistribuição relação a fim de evitar aderir produto de inclinação e de redistribuição de inclinação.

Técnicas adaptativassão úteis para melhorar intra-operador de balanceamento de carga em todos os tipos de arquiteturas paralelas. No entanto, a maior parte do trabalho tem sido feito no contexto da partilhada nada-se os efeitos de carga desequilíbrio são mais graves no desempenho. DBS3 [Bergsten et al, 1991;.. Dageville et al, 1994] foi pioneiro no uso de uma técnica de adaptativo com base na relação particionamento (como no nada- partilhada) para a memória partilhada. Ao reduzir a interferência do processador, essa técnica produz o balanceamento de carga excelente para intra-operador paralelismo [Bouganim et al., 1996a, b].

Técnicas especializadas.

Paralelo algoritmos de junção pode ser especializado para lidar com inclinação. Uma abordagem é usar vários algoritmos de junção, cada um especializado em um diferente grau de inclinação, e determinar, em tempo de execução, que é o melhor algoritmo [DeWitt et al., 1992]. Ele se baseia em duas técnicas principais: partilha de gama e de amostragem. Faixa de particionamentoé usado em vez de particionamento hash (no paralelo algoritmo de junção hash) para evitar a redistribuição de inclinação da relação edifício. Assim, os processadores podem ter partições de igual número de tuplas, correspondendo a diferentes intervalos de juntar-se os valores dos atributos. Para determinar os valores que delineiam os valores de intervalo, a amostragem da relação edifício é usado para produzir um histograma dos valores de atributo de junção, ou seja, os números de tuplas para cada valor de atributo. A amostragem é também útil para determinar qual algoritmousar e qual a relação a ser usado para construir ou sondagem. Utilizando estas técnicas, o algoritmo de junção paralelos hash pode ser adaptado para lidar com a inclinação do seguinte modo:

1. Amostrar na relação de construção para determinar os intervalos de separação.2. Redistribuir a relação de construção para os processadores usando os intervalos. Cada processador cria uma tabela hash contendo as tuplas de entrada.3. Redistribuir a relação de sondagem utilizando os mesmos intervalos para os processadores. Para cada tupla receberam, cada processador sondas da tabela para executar a associação.Este algoritmo pode ser melhorado para lidar com inclinação elevada usando técnicas adicionais e estratégias de alocação de processadores diferentes [DeWitt et al., 1992]. Uma abordagem semelhante é o de modificar os

algoritmos de junção através da inserção de um passo de programação que é responsável pela redistribuição da carga no tempo de execução [Wolf et al., 1993].

14.4.3 Load Balancing Inter-OperadorA fim de obter o equilíbrio de carga boa ao nível inter-operador, é necessário escolher, para cada operador, quantas e quais os processadores para atribuir para a sua execução. Isto deve ser feito tendo em conta o paralelismo de pipeline, o que exige do operador inter-comunicação. Isso é mais difícil de alcançar em nada partilhado pelas seguintes razões [Wilshut et al., 1995]. Primeiro, o grau de paralelismo e da atribuição de processadores para os operadores, quando decidiu na fase de otimização paralela, são baseados em um modelo de custo possivelmente impreciso. Em segundo lugar, a escolha do grau de paralelismo é sujeito a erros, porque ambos os processadores e os operadores são entidades discretas. Finalmente, os processadores associados com as últimas operadores em uma cadeia de oleoduto pode permanecer inactivo um tempo significativo. Isto é chamado o problema do atraso pipeline. A principal abordagem em nada-compartilhado é determinar dinamicamente (imediatamente antes da execução) o grau de paralelismo ea localização dos processadores para cada operador. Por exemplo, o algoritmo de corresponder à taxa [Mehta e DeWitt, 1995]. utiliza um modelo de custo, a fim de corresponder a taxa à qual tuplas são produzidos e consumidos. É a base para a escolha do conjunto de processadores que será utilizado para a execução de consulta (Baseado na memória disponível, CPU e utilização do disco). Muitos outros algoritmos são possíveis para a escolha do número e localização dos transformadores, por exemplo, maximizando a utilização de vários recursos, usando estatísticas sobre a sua utilização [Rahm e Marek, 1995; Garofalakis e Ioannidis, 1996].No disco compartilhado e memória compartilhada, há mais flexibilidade, já que todos os processadores têm igualdade de acesso aos discos. Uma vez que não há necessidade para o particionamento relação física, qualquer processador pode ser atribuído a qualquer operador [Lu et ai, 1991;. Shekita et al, 1993.]. Em particular, um processador pode ser atribuída todos os operadores da cadeia mesmo canal, assim, com o paralelismo inter-operador. No entanto, inter-operador paralelismo é útil para executar redes de dutos independentes. A abordagem proposta por Hong [1992], para memória compartilhada permite a execução paralela de cadeias de gasodutos independentes, chamado de tarefas. A idéia principal é combinar I / O-bound tarefas e CPU-bound para aumentar a utilização de recursos do sistema. Antes da execução, uma tarefa é classificado como I / O-bound ou CPU-bound utilizando a informação modelo de custo da seguinte forma. Vamos supor que, se executadas sequencialmente, tarefa t gera acessos ao disco a uma taxa de taxa de IO (t), por exemplo, no número de acessos a disco por segundo. Vamos considerar um sistema de memória compartilhada com n processadores e uma largura de banda total do disco de B (número de acessos ao disco por segundo). Tarefa t é definido como I / O-bound se a taxa de IO (t)> B = n e CPU-bound contrário. CPU-bound e I / O-bound fala pode ser executado em paralelo ao seu ideal I / O-CPU ponto de equilíbrio. Isto é conseguido através ajustando dinamicamente o grau deintra-operador paralelismo das tarefas, a fim de chegar a máxima utilização de recursos.

14.4.4 Load Balancing intra-consultaIntra-query balanceamento de carga deve combinar paralelismo intra-e inter-operador. Até certo ponto, dada uma arquitetura paralela, as técnicas para qualquer carga intra-ou inter-operador balançando que acaba de ser apresentado pode ser combinado. No entanto, no contexto importante dos sistemas híbridos, tais como NUMA ou cluster, os problemas de equilíbrio de carga são exacerbados porque têm de ser dirigida a dois níveis, localmente entre os processadores de cada nó de memória partilhada (SM-nó) e globalmente entre todos nós. Nenhuma das abordagens para balanceamento de carga intra-e inter-operador que acabamos de discutir pode ser facilmente estendido para lidar com este problema. Estratégias de balanceamento de carga para compartilhada nada iria ter problemas ainda mais grave piora (por exemplo, a complexidade ea imprecisão do modelo de custo). Por outro lado, adaptando soluções dinâmicas desenvolvidas para sistemas de memória compartilhada seria incorrer em sobrecarga de comunicação de alta.A solução geral para o balanceamento de carga em sistemas híbridos é o modelo de execução chamado Processamento Dinâmico (DP) [Bouganim et al., 1996c]. A ideia fundamental é que a consulta é decomposto em unidades independentes de processamento sequencial, cada um dos quais pode ser efectuada por qualquer processador. Intuitivamente, um processador pode migrar horizontalmente (intra-operador paralelismo) e verticalmente (inter-operador paralelismo) ao longo dos operadores de consulta. Isso minimiza a sobrecarga de comunicação de inter-nó de balanceamento de carga, maximizando o balanceamento de carga intra e inter-operador dentro de memória compartilhada nós. A entrada para o modelo de execução é um plano de execução paralela como produzido pelo otimizador, ou seja, uma árvore de operador com a programação do operador e alocação de recursos de computação para os operadores. As restrições de programação do operador expressar uma ordem parcial entre os operadores da consulta: O1 <O2 indica que O1 operador não pode começar antes O2 operador.

Exemplo 14.6. Figura 14,19 mostra uma junção árvore com quatro relações R1, R2, R3 e R4, ea árvore de operador correspondente com as cadeias de gasodutos claramente identificados. Assumindo que junção

paralela hash é usado, as restrições de programação do operador são entre a compilação associado e operadores de sonda:

Há também heurísticas de escalonamento entre os operadores de redes de dutos diferentes que decorrem das restrições de programação:

Supondo que três SM-nós i, j e k com R1 armazenado no nó i, R2 e R3 ao nó j e R4 no nó k, podemos ter as casas seguinte operador:

Dado tal árvore um operador, o problema consiste em produzir uma execução em uma arquitetura híbrida que minimiza o tempo de resposta. Isto pode ser feito usando um mecanismo de compensação de carga dinâmica em dois níveis: (i) dentro de um equilíbrio de carga SM-node, é conseguida através de comunicação entre rápido, (ii) entre SM-nodos, mais caro comunicação de passagem de mensagens é necessária. Assim, o problema é o de chegar a um modelo de execução de modo que o uso de balanceamento de carga local é maximizada enquanto o uso de equilíbrio de carga global (por meio de passagem de mensagens) é minimizada.

Chamamos a activação a menor unidade de processamento sequencial que não podem ser ainda mais particionada. A principal propriedade do modelo DP é permitir que qualquer processador para processar qualquer ativação de sua SM-nó. Assim, não há associação estática entre segmentos e operadores. Este rendimento bom balanceamento de carga para o operador intra-e inter-operador de paralelismo dentro de um nó-SM, e, portanto, reduz ao mínimo a necessidade de balanceamento de carga global, isto é, quando não há mais trabalho a fazer em um nó-SM.

O modelo de execução DP é baseada em alguns conceitos: activações, filas de ativação e segmentos.

Ativações.Uma activação representa uma unidade sequencial de trabalho. Uma vez que qualquer ativação pode ser executada por qualquer segmento (por qualquer processador), ativações deve ser auto-suficiente e referência a todas as informações necessárias para sua execução: a execução do código e os dados para processar. Dois tipos de ativações podem ser distinguidos: ativações gatilho e ativações de dados. Uma activação do gatilho é utilizado para iniciar a execução de um operador de folha, isto é, de digitalização. Ele é representado por um (Operador; Bucket) par que faz referência ao operador de digitalização eo balde relação de base para a digitalização. Uma activação de dados descreve umtupla produzido no modo de pipeline. Ele é representado por um (Operador; Bucket; Tupla) triple que faz referência ao operador de processar. Para um operador de criação, a ativação de dados especifica que a tupla deve ser inserido na tabela de hash do balde e para um operador de sonda, que a tupla deve ser sondado com tabela hash da caçamba. Apesar de ativações são auto-suficientes, eles só podem ser executados no nó SM-

onde os dados associados (tabelas hash ou relações de base) são.

Filas de ativação.Movendo activações de dados ao longo das cadeias de pipeline é feito usando filas de activação, também chamado filas tabela [Pirahesh et al., 1990], associada com os operadores. Se o produtor e consumidor de uma ativação estão na mesma SM nó, então o movimento é feito via memória compartilhada. Caso contrário, ele exige de passagem de mensagens. Para unificar o modelo de execução, as filas são usados para acionar ativações (insumos para operadores de verificação), bem como ativações tupla (insumos para a construção ou operadores de sonda). Todos os tópicos têm acesso irrestrito a todas as filas instaladas em suas SM-nó. A gestão de um pequeno número de filas (por exemplo, um para cada operador) pode produzir interferência. Para reduzir a interferência, um fila é associado com cada segmento de trabalho sobre um operador. Note-se que um maior número de filas provavelmente comércio interferência para a sobrecarga de gerenciamento de fila. Para reduzir ainda mais a interferência sem aumentar o número de filas, cada segmento é dada prioridade de acesso a um conjunto diferente de filas, chamado suas filas primários. Assim, um fio sempre tenta primeiro consumir ativações em suas filas primários. Durante a execução, as restrições de escalonamento operador pode implicar que um operador está a ser bloqueada até que o fim de alguns outros operadores (os operadores de bloqueio). Portanto, uma fila para um operador bloqueado também é bloqueado, isto é, as suas activações não pode ser consumida, mas eles podem ainda ser produzido se o operador produzindo não está bloqueado. Quando todos os seus operadores de bloqueio terminar, a fila se torna consumível bloqueado, ou seja, os tópicos podem consumir suas ativações. Isto é ilustrado na Figura 14,20 com um instantâneo de execução para a árvore operador da Figura 14,19.

Tópicos.Uma estratégia simples para a obtenção de bom balanceamento de carga dentro de um nó-SM é para atribuir um número de segmentos que é muito maior do que o número de processadores e deixar o sistema operacional fazer agendamento de discussão. No entanto, esta estratégia acarreta um elevado número de chamadas do sistema devido ao agendamento de segmento, a interferência e problemas de comboio [Pira-Hesh et al, 1990;. Hong, 1992]. Em vez de depender do sistema operacional para balanceamento de carga, é possível a atribuição de apenas um segmento por processador por consulta. Isto é tornado possível pelo facto de qualquer segmento pode executar qualquer operador atribuído à suaSM-nó. A vantagem desta estratégia de alocação de um segmento--per-processador é reduzir significativamente a sobrecarga de interferência e de sincronização, desde que um segmento nunca é bloqueada.

O balanceamento de carga dentro de um nó-SM é obtido através da atribuição de todas as filas de ativação em um segmento de memória compartilhada e permitindo que todos os segmentos para consumir ativações em qualquer fila. Para limitar a interferência fio, um fio vai consumir tanto quanto possível do seu conjunto de filas primário antes de considerar as outras filas do SM-nó. Portanto, um fio se torna ocioso apenas quando há a ativação não mais de qualquer operador, o que significa que não há mais trabalho a fazer em seu SM nó que está morrendo de fome.Quando um passa fome SM-nó, podemos aplicar o compartilhamento de carga com outro nó-SM através da aquisição de parte de sua carga de trabalho [Shatdal e Naughton, 1993]. No entanto, ativações de aquisição (através de passagem de mensagens) incorre em sobrecarga de comunicação. Além disso, a aquisição de

ativação não é suficiente, pois os dados associados, ou seja, tabelas hash, também deve ser adquirido. Assim, precisamos de um mecanismo que dinamicamente pode estimar o benefício de adquirir ativações e dados.Vamos chamar, transactioner, que adquire o trabalho, o SM-nó e, "provedor", que fica off-carregado, proporcionando trabalho ao transactioner, o SM-nó. O problema é selecionar uma fila para adquirir ativações e decidir o quanto trabalhamos para adquirir. Este é um problema de otimização dinâmica uma vez que há um trade-off entreo ganho potencial de off-loading o provedor ea sobrecarga de adquirir Activa-ções e dados. Esta compensação pode ser expressa pelas seguintes condições: (i) a transactioner deve ser capaz de armazenar na memória e as activações de dados correspondentes;(Ii) o trabalho deve ser adquirido suficiente para amortizar a sobrecarga de aquisição;(Iii) aquisição de muito trabalho deve ser evitado; (iv) ativações de sonda só pode ser adquirida desde ativações acionados exigem acessos a disco e ativações de construção exigem a construção de tabelas de hash localmente; (v) não há nenhum ganho em ativações em movimento associados com os operadores bloqueados que não pode ser processado de qualquer maneira. Finalmente, a respeitar as decisões do otimizador, um nó-SM não pode executar ativações de um operador que não próprio, ou seja, o SM-nó não está na casa do operador.A quantidade de balanceamento de carga depende do número de operadores que estão concorrem-mente executado, o que oferece oportunidades para Ô ¨ Anding algum trabalho para compartilhar em caso de tempo ocioso. Aumentar o número de operadores concorrentes pode ser feito permitindo a execução simultânea de várias cadeias de oleodutos ou usando non-blocking junção-hash algoritmos, que permite a execução simultânea de todos os operadores da árvore bushy [Wilshut et al., 1995]. Por outro lado, a execução de mais operadores concorrentemente pode aumentar o consumo de memória. Agendamento operador estática, tal como previsto pelo otimizador deve evitar que a memória Overo ¨ vaca e resolver essa compensação.Avaliação do desempenho de DP com um processador-72 organizado como um conjunto de SM-nodes DP mostrou que executa bem como um modelo dedicado em memória compartilhada e podem escalar-se muito bem [Bouganim et al., 1996c].

14,5 Clusters de Banco de DadosClusters de servidores PC são outra forma de computador paralelo que fornece uma alternativa rentável para supercomputadores ou multiprocessadores fortemente acoplados. Pois em posição, eles têm sido usados com sucesso em computação científica, web recuperação de informação (por exemplo, motor de busca Google) e data warehousing. No entanto, estas aplicações são tipicamente de leitura intensiva, o que torna mais fácil para explorar o paralelismo. A fim de apoiar atualização aplicações intensivas que são típicos de processamento de dados de empresas, recursos completos de bancos de dados paralelos, incluindo suporte a transações, devem ser fornecidas. Isto pode ser conseguido usando um DBMS paralelo executado durante um cluster. Neste caso, todos os nós do cluster são homogêneos, sob o controlo total do SGBD paralelo.

A solução SGBD paralelo pode não ser viável para algumas empresas, como Application Service Providers (ASP). No modelo ASP, as aplicações dos clientes e bancos de dados (incluindo dados e SGBD) são hospedados no site do provedor e precisa estar disponível, normalmente por meio da Internet, de forma tão eficiente como se fossem locais para o site do cliente. Um requisito importante é que as aplicações e bases de dados permaneçam autónoma, isto é, permanecem inalterados quando movido para agrupar o local prestador e sob o controlo dos clientes. Assim, preservando a autonomia é crítica para evitar os elevados custos e problemas associados com a modificação de código de aplicação. Utilizaçãoum SGBD paralelo, neste caso, não é apropriado, pois é caro, requer forte migração para o SGBD paralelo e fere a autonomia do banco de dados.

A solução é usar um cluster de banco de dados, que é um cluster de bancos de dados autônomos, cada um gerido por um off-the-shelf DBMS [R ¨ ohm et al., 2000, 2001]. Uma diferença principal com um DBMS paralelo implementado em um cluster é o uso de um "blackbox" DBMS em cada nó. Desde que o código fonte não é necessariamente SGBD disponível e não pode ser alterado para ser "clusters", recursos de gerenciamento de dados paralelos devem ser implementada através de middleware. Na sua forma mais simples, um cluster de base de dados pode ser visto como um sistema de multidatabase em um cluster. No entanto, muita pesquisa tem sido dedicado a tirar o máximo proveito do ambiente de cluster (com a comunicação rápida e confiável), a fim de melhorar o desempenho e disponibilidade, explorando a replicação de dados. Os principais resultados desta pesquisa são novas técnicas para a carga de replicação, balanceamento, processamento de consultas, e tolerância a falhas. Nesta seção, apresentamos estas técnicas depois de introduzir uma arquitetura de cluster de banco de dados.

14.5.1 Arquitetura Cluster de Banco de DadosConforme discutido na Seção 14.1.3.4, um cluster pode ter um disco compartilhado ou arquitetura shared-

nothing. Shared-disco requer uma interconexão especial que proporciona um espaço de disco compartilhado para todos os nós, com possibilidade de consistência do cache. Shared nada pode melhor apoiar a autonomia do banco de dados sem o custo adicional de uma interconexão especial e pode escalar até configurações muito grandes. Isso explica porque a maioria dos trabalhos em clusters de banco de dados tem assumido uma arquitetura shared-nothing. No entanto, técnicas concebidas para shared-nothing podem ser aplicados, talvez em uma maneira mais simples, para o disco compartilhado. Figura 14,21 ilustra um cluster de banco de dados com uma arquitetura shared-nothing. Gerenciamento de dados paralelo é feito por SGBDs independentes orquestrados por um middleware replicado em cada nó. Para melhorar o desempenho e disponibilidade, os dados podem ser replicados em diferentes nós, usando o SGBD local. Aplicações cliente (por exemplo, em servidores de aplicação) interagir com o middleware de uma forma clássica de apresentar as operações de banco de dados, ou seja, consultas ad-hoc, transações, ou chamadas para procedimentos armazenados. Alguns nós podem ser especializada como nós de acesso para receber transações, caso em que eles compartilham um serviço de diretório global que capta informações sobre os usuários e bancos de dados. O tratamento geral de uma transação para uma única base de dados é como se segue. Primeiro, a transação é autenticado e autorizado usando o diretório. Se bem sucedida, a operação é encaminhada para um SGBD em algum, possivelmente diferente, o nó a ser executado. Veremos na Seção 14.5.4 como esse modelo simples pode ser estendido para lidar comprocessamento de consulta paralelo, usando vários nós para processar uma única consulta.

Como em um SGBD paralelo, o middleware de cluster de banco de dados tem várias camadas de software: balanceador de carga de transação, o Replication Manager, processador de consulta e gerente faulttolerance. O balanceador de carga transação desencadeia a execução da transação com o melhor de nós, usando informações de carregamento obtido a partir de sondas de nós. O "melhor" nó é definido como aquele com carga mais leve transação. O balanceador de carga transação também garante que cada execução da transação obedece as propriedades ACID, e, em seguida, sinaliza para o SGBD para confirmar ou anular a transação. O gestor de replicação gere o acesso a dados replicados e assegura consistência forte de modo a que as operações que atualizam dados replicados são executados na mesma ordem em série em cada nó. O processador de consultas explora tanto paralelismo inter-e intra-consulta.Com inter-consulta paralelismo, o processador de consulta encaminha cada consulta submetida a um nó e, após a conclusão da consulta, envia os resultados para o aplicativo cliente. Paralelismo intra-consulta é mais envolvido. À medida que os SGBDs caixa-preta não são clusters, eles não podem interagir uns com os outros, a fim de processar a mesma consulta. Então, é até o processador de consultas para controlar a execução da consulta, a composição resultado final e balanceamento de carga. Finalmente, o gerente de tolerância a falhas fornece on-line e recuperação de failover.

14.5.2 replicaçãoTal como no SGBDs distribuídos, a replicação pode ser usado para melhorar o desempenho e disponibilidade. Em um cluster de banco de dados, o sistema de interconexão e comunicação rápida pode ser explorado para apoiar uma cópia serializability, proporcionando escalabilidade (para obter um desempenho com um grande número de nós) e autonomia (para explorar blackbox DBMS). Ao contrário de um sistema distribuído, um cluster fornece um ambiente estável, com evolução pouco da topologia (por exemplo, como um resultado de nós adicionados ou falhas de ligação de comunicação). Assim, é mais fácil para suportar um sistema de comunicação grupo [Chockler et al., 2001] que gere uma comunicação fiável entre grupos de nós. Primitivas de comunicação do grupo pode ser usado com técnicas de replicação ou ansiosos ou lenta, como um meio para alcançar a disseminação da informação atómica (isto é, em vez do 2PC caros). O protocolo NODO (ver Capítulo 13) é um representante do protocolo

ansiosos que pode ser usado em um cluster de banco de dados. Apresentamos agora um outro protocolo para a replicação que é preguiçoso e fornece suporte para um copy-seriação e escalabilidade.

Protocolo de replicação preventiva

Replicação preventiva é um protocolo para a replicação preguiçosa preguiçoso distribuído em um cluster de banco de dados [Pacitti et al, 2003;. Coulon et al, 2005;. Pacitti et al, 2006.]. Também preserva a autonomia DBMS. Em vez de usar multicast ordenada total, como em protocolos ansiosas, tais como NODO, ele usa FIFO multicast fiável que é mais simples e mais eficiente. O princípio é o seguinte. Cada T transacção de entrada para o sistema tem um ts timestamp cronológica (T) = C, e é multicast para todos os outros nós, onde há uma cópia. Em cada nó, um atraso de tempo é introduzido antes de iniciar a execução de T. Este atraso corresponde ao limite superior do tempo necessário para multicast uma mensagem(Um sistema síncrono com a computação delimitada e tempo de transmissão é assumido). A questão crítica é o cálculo preciso dos limites superiores para as mensagens (ou seja,atrasar). Em um sistema de agrupamento, o limite superior pode ser calculado com bastante precisão. Quando o atraso expira, todas as transações que tenham cometido antes de C são garantidos para ser recebido e executado antes de T, seguindo a ordem timestamp (ou seja, a ordem total). Assim, esta abordagem evita conflitos e reforça a consistência forte em clusters de banco de dados. Apresentando os tempos de demora também tem sido explorada em vários protocolos de replicação preguiçosos centralizados para sistemas distribuídos [Pacitti et al, 1999;. Pacitti e Simon, 2000;. Pacitti et al, 2006].

Nós apresentamos o algoritmo de refresco básica para atualização de cópias, assumindo a replicação completa, pela simplicidade. O sistema de comunicação é assumido para fornecer FIFO multicast [Pacitti et al., 2003]. Max é o limite superior do tempo necessário para uma mensagem de multicast a partir de um nó i para qualquer j outro nó. É essencial para ter um valor de Max que não é mais de estimado. O cálculo de resorts Max com a teoria de programação [Pinedo, 2001] e tem em conta vários parâmetros, tais como a rede global de confiança em si, as características das mensagens de multicast e os fracassos a ser tolerado. Cada nó tem um relógio local. Para equidade, relógios são assumidos para ter uma deriva e para ser e-sincronizado, ou seja, a diferença entre quaisquer dois relógios correctos não é maior que e (conhecido como o precisão). Inconsistências podem surgir sempre que as ordens de série de duas operações em dois nós não são iguais. Por isso, devem ser executados na mesma ordem em série em quaisquer dois nós. Assim, ordenação FIFO global não é suficiente para garantir a correção do algoritmo refresco. Cada transacção está associada com um cronológica timestamp valor C. O princípio do refresco preventiva algoritmo é apresentar uma seqüência de transações na mesma ordem cronológica em cada nó. Antes de submeter uma transação no nó i, ele verifica se existe alguma transação mais velha rota para o nó i. Para conseguir isso, o tempo de apresentação de uma nova transação no nó i está atrasada por Max e. Assim, a primeira vez que uma transação é submetida é C e Max (doravante chamado de tempo de entrega).

Sempre que uma transação Ti está a ser desencadeada em algum nó i, i nó multicast Ti a todos os nós 1, 2, ..., n, incluindo a si próprio. Uma vez que Ti é recebido em algum outro nó j (i pode ser igual a j), é colocado na fila pendente, a fim FIFO no que diz respeito ao nó desencadeamento i. Portanto, em cada nó i, existe um conjunto de filas, q1; q2; ...; qn, chamado filas pendentes, cada um dos quais corresponde a um nó e é usado pelo algoritmo refresco para executar ordem cronológica com respeito à prazos de entrega. Figura 14,22 mostra parte dos componentes necessários para executar o algoritmo.A reciclagem lê operações a partir do topo das filas pendentes e executa ordem cronológica com respeito aos tempos de entrega. Uma vez que uma transacção é ordenada, em seguida, a reciclagem escreve-lo para a fila de execução, a fim FIFO, um após o outro. Finalmente o Libertador mantém a verificação da topo da fila de execução para iniciar a execução transacção, um após o outro, no DBMS local.

Exemplo 14.7. Vamos ilustrar o algoritmo. Suponha que temos dois nós i e j, mestres da cópia R. Assim no nó i, há duas filas de pendentes: qi e qj correspondentes a nós mestre i e j. T1 e T2 são duas transações que atualizam R em nós i e j, respectivamente. Vamos supor que Max = 10 e E = 1. Assim, no nó i, temos a seguinte seqüência de execução:

   No tempo de 10: T2 chega com uma ts timestamp (T2) = 5. Assim, qi = [T2 (5)], q(j) = [] e T2 é escolhido pelo Refresher ser a próxima operação para executar no tempo de entrega 16 (= 5 +10+ 1), eo tempo é definido como expirar no momento 16.

   Em tempo de 12: T1 chega do nó j com um timestamp TS (T1) = 3; assim qi = [T2 (5)], qj = [T1 (3)]. T1 é escolhido pelo Refresher ser a próxima operação para executar no tempo de entrega 14 (= 3 +10+ 1), eo tempo é reajustado para expirar no tempo 14.

Em tempo de 14: o tempo limite expirar eo Refresher escreve T1 na fila de execução. Assim, qi = [T2 (5)], q (j) = []. T2 é seleccionada para ser a transacção seguinte toperform em tempo de entrega 16 (= 5 +10+ 1).

Em tempo de 16: o tempo limite expirar. O Refresher escreve T2 na fila de execução. Então, qi = [], q(j) = [].

Embora as transações sejam recebidos na ordem errada em relação aos seus timestamps (T2, em seguida, T1), elas são escritas na fila de execução na ordem cronológica de acordo com seus timestamps (T1, então T2). Assim, a ordem total é aplicado mesmo que as mensagens não são enviadas de forma total.

O protocolo de replicação inicial preventiva tem duas limitações. Primeiro, ela pressupõe que bancos de dados são totalmente replicado em todos os nós do cluster e, portanto, se propaga cada transação para cada nó do cluster. Isto faz com que o algoritmo inadequados para apoiar grandes bancos de dados. Em segundo lugar, tem limitações de desempenho vez que as operações são realizadas uma após a outra, e deve suportar espera atrasos antes de iniciar. Assim, refresco é um gargalo potencial, em particular, no caso de cargas de trabalho em rajadas, onde as taxas de entrada de transacções são elevados, por vezes.

A primeira limitação pode ser abordada, fornecendo suporte para replicação parcial [Coulon et al., 2005]. Com a replicação parcial, alguns dos nós alvo pode não ser capaz de realizar uma transação T porque não mantenha todas as cópias necessárias para realizar a ler conjunto de T. No entanto, a gravação conjunto de T, o que corresponde à sua transação de actualização, deve ser ordenada usando o valor de T timestamp, a fim de assegurar a consistência. Então T está prevista, como de costume, mas não apresentados para execução. Em vez disso, os nós alvo envolvidos esperar para a recepção do conjunto de gravação correspondente. Em seguida, a origem nó i, quando o compromisso de T for detectado, o conjunto de gravação correspondente é produzido e nó i multicasts-la para os nós de destino. Aquando da recepção da gravação fixado a um nó de destino j, o conteúdo de T (ainda à espera) é substituído com o conteúdo do conjunto de gravação de entrada e T pode ser executado.

A segunda limitação é dirigida por um algoritmo de refresco que (potencialmente) elimina o tempo de atraso [Pacitti et al., 2006]. Em um cluster (que é normalmente rápida e confiável), as mensagens são muitas vezes naturalmente ordenadas cronologicamente [Pedone e Schiper, 1998]. Apenas algumas mensagens podem ser recebidas em uma ordem que é diferente da ordem de envio. Com base nesta propriedade, o algoritmo pode ser melhorado através da apresentação de uma transacção para a execução, logo que é recebido, evitando assim o atraso antes de submeter as transacções. Para garantir a consistência forte, a ordem de confirmação das operações está programado de tal maneira que uma transacção pode ser comprometida apenas após Max + e. Quando uma transação T é recebido fora de ordem, todas as transações mais jovens deve ser abortada e re-apresentados de acordo com sua ordem de timestamp correta com relação a T. Portanto, todas as transações são cometidos em sua ordem de timestamp. Para melhorar o tempo resposta em cargas de trabalho em rajadas, as transações podem ser acionados simultaneamente. Utilização a propriedade de isolamento do DBMS subjacente, cada nó pode garantir que cada transacção vê um banco de dados consistente em todos os momentos. Para manter a consistência forte em todos os nós, as transações são confirmadas na mesma ordem em que são submetidos e escrito para a fila de execução. Assim, a ordem total é sempre cumprida. No entanto, sem acesso ao controlador de concorrência DBMS (por razões de autonomia), um não podemos garantir que duas transações simultâneas conflitantes obter um bloqueio na mesma ordem em dois diferentes nós.

Assim, as operações em conflito não são acionados simultaneamente. Detectando que duas transações são conflitantes exige a análise de código como para determinar a classe de conflito no protocolo NODO. A validação do protocolo de replicação preventiva através de experimentos com o benchmark TPC-C acima de um cluster de 64 nodos executando o PostgreSQL DBMS têm mostrado excelente scale-up e speed-up [Pacitti et al., 2006].

14.5.3 O balanceamento de cargaEm um cluster de banco de dados, replicação oferece bom balanceamento de carga de replicação opportunities.With ansioso ou preventiva, balanceamento de carga de consulta é fácil de alcançar. Uma vez que todas as cópias são coerentes entre si, qualquer nó que armazena uma cópia dos dados transacionado, por exemplo, o menor nó carregado, pode ser escolhido em tempo de execução de uma estratégia de balanceamento de carga convencional. Equilíbrio de carga de transação é também fácil, no caso de replicação distribuído lazy uma vez que todos os nós mestre precisa eventualmente executar uma transacção. No entanto, o custo total da execução da transação em todos os nós podem ser elevados. Ao relaxar, consistência de replicação preguiçosos podem melhor reduzir o custo de execução da transação e, portanto, aumentar o desempenho de ambas as consultas e transações. Assim, dependendo dos requisitos de consistência / desempenho, a replicação ansioso e preguiçoso são úteis nos conjuntos de dados.

Modelos de consistência relaxados têm sido propostos para controlar divergência réplica com base em requisitos do utilizador. Os requisitos do usuário sobre a consistência desejada pode ser expresso quer pelos programadores, por exemplo, dentro de instruções SQL [Guo et al., 2004] ou dos administradores de banco de dados, por exemplo, usando as regras de acesso [Ganc ¸ arski et al., 2002]. Na maioria das abordagens, a consistência reduz a frescura: transações de atualização são globalmente serializado sobre os diferentes nós do cluster, de modo que sempre que uma consulta é enviada para um determinado nó, ele lê um estado consistente do banco de dados. Consistência global é obtida por garantir que as transações conflitantes são executadas em cada nó na mesma ordem relativa. No entanto, o estado consistente pode não ser o mais recente, uma vez que as transações podem ser executado em outros nós. A frescura de dados de um nó reflecte a diferença entre o estado do banco de dados do nó e do estado que teria se todas as operações de funcionamento já tinha sido aplicado para esse nó. No entanto, a frescura não é fácil de definir, em particular para os estados de banco de dados perfeitamente frescos. Assim, o conceito oposto do staleness, é muitas vezes utilizado, uma vez que é sempre definido (por exemplo, igual a 0 para os estados de base de dados perfeitamente frescos). O staleness de uma cópia relação pode então ser capturada pela quantidade de mudança que tem sido feito para as outras cópias, tal como medido pelo número de tuplas actualizados [Pape et al., 2004].

Exemplo 14.8. Vamos ilustrar como a replicação distribuída preguiçoso pode introduzir staleness, e seu impacto sobre as respostas da consulta. Considere a seguinte consulta Q:

SELECT PNOFROM ASGWHERE SUM(DUR) > 200GROUP BY PNO

Vamos supor que ASG relação é replicada nos nós i e j, ambas as cópias com um ranço de 0 no tempo t0. Suponha que, para o grupo de tuplas onde PNO = "P1", que temos SUM (DUR) = 180. Considere que, em T0 +1, nó i, j, respectivamente nó, comete uma transação que insere uma tupla para PNO = "P1" com DUR = 12, respectivamente DUR = 18. Assim, o staleness de ambos iej é 1. Agora, em T0 +2, execução Q em qualquer i ou j não recuperar "P1", já que para o grupo de tuplas onde PNO = "P1", temos SUM (DUR) = 192 e 198 no i em j. A razão é que as duas cópias, embora consistentes, são obsoletos. No entanto, após a reconciliação, por exemplo, em t0 3, temos SUM (DUR) = 210 em ambos os nós e execução de Q seria recuperar "P1". Assim, a precisão da resposta de Q depende da quantidade de envelhecer cópia do nó é.

Com frescor relaxante, balanceamento de carga é mais complexa porque o custo de reconciliação cópia para cumprir os requisitos definidos pelo usuário frescura deve ser considerado quando roteamento transações e consultas para os nós do cluster. R ¨ ohm et al. [2002b] propõem uma solução simples para o frescor-aware consulta de roteamento em clusters de banco de dados. Usando técnicas singlemaster replicação (ou seja, as transações são sempre encaminhadas para o nó mestre), as consultas são encaminhadas para o nó menos carregado que é fresco o bastante. Se nenhum nó é fresco o suficiente, a consulta simplesmente espera.

Ganc ¸ arski et al. [2007] propõem uma solução mais geral para a frescura-aware roteamento. Ele funciona com a replicação distribuída preguiçoso que produz os maiores oportunidades para balanceamento de carga transação. Resumimos esta solução. Um roteador transação gera para cada operação de entrada ou de consultar um plano de execução com base em requisitos dos utilizadores

frescura obtidos a partir do diretório compartilhado. Em seguida, ele aciona a execução com os melhores nodos, utilizando de tempo de execução de informação sobre a carga nodos '. Quando necessário, ele também desencadeia operações de atualização, a fim de fazer alguns nós mais fresco para a execução de transações subseqüentes ou consultas.

O roteador operação leva em conta as exigências de frescura de consultas a nível relação para melhorar o balanceamento de carga. Ele usa funções de custo que leva em conta não só a carga do cluster em termos de transações concorrentes e consultas, mas também o tempo estimado para atualizar réplicas para o nível exigido por consultas recebidas. O roteador transação utiliza dois baseados nos custos estratégias de roteamento, cada um bem adequada às necessidades de aplicação diferentes. A primeira estratégia, chamada de custo baseado apenas (CB), não faz nenhuma suposição sobre a carga de trabalho e avalia o custo de sincronização para respeitar a staleness aceito por consultas e transações. CB simplesmente avalia, para cada nó, o custo do nó a refrescante (se necessário) para satisfazer as exigências de frescura, bem como o custo da execução da operação propriamente dito. Em seguida, ele escolhe o nó que minimiza o custo. A segunda estratégia favorece transações de atualização para lidar com cargas de trabalho OLTP. É uma variante do CB com tempo de resposta limitada (BRT), que atribui dinamicamente nós para processamento de transações e os nós de processamento de consulta. Ele usa um parâmetro, Tmax, que representa os usuários de tempo máximo de resposta pode aceitar para transações de atualização. Ele se dedica como nós do cluster que forem necessárias para garantir que as atualizações são executados em menos de Tmax, e utiliza os nós restantes para o processamento de consultas. A validação desta abordagem, usando a implementação e emulação de até 128 nós com o benchmark TPC-C, mostra que a escala excelente up podem ser obtidas [Ganc ¸ arski et al., 2007].

Outras abordagens têm sido propostas para balanceamento de carga em clusters de banco de dados. A abordagem em [Mil'an-Franco et al., 2004] ajusta a alterações na carga apresentada para as réplicas diferentes e com o tipo de carga de trabalho. Ele combina balanceamento de carga com feedback orientados ajustes do número de transações simultâneas. A abordagem é mostrada para proporcionar alto rendimento, boa escalabilidade, e tempos de resposta baixos para mudar cargas e cargas de trabalho com pouca sobrecarga.

14.5.4 Processamento de ConsultaEm um cluster de banco de dados, o processamento de consulta paralelo pode ser usado com sucesso para produzir um alto desempenho. Inter-consulta paralelismo (ou transações inter) é naturalmente obtida como resultado de balanceamento de carga e replicação, como discutido na seção anterior.Tal paralelismo é principalmente útil para aumentar a thoughput de transacção aplicações orientadas e, em certa medida, reduzir o tempo de resposta de transacções e consultas. Para aplicações de OLAP que normalmente utilizam consultas ad-hoc, que acessam grandes quantidades de dados, paralelismo intra-consulta é essencial para reduzir ainda mais o tempo de resposta. Paralelismo intra-consulta consiste em processar a mesma consulta em partições diferentes das relações envolvidas na consulta.

Há duas soluções alternativas para as relações de particionamento em um cluster de banco de dados: físico e virtual. Particionamento físico define partições relação, essencialmente como fragmentos horizontais, e os aloca os nós do cluster, possivelmente com a replicação.Este ressembles fragmentação e design alocação em bancos de dados distribuídos (ver Capítulo 3), exceto que o objetivo é aumentar o paralelismo intra-consulta, e não localidade de referência. Assim, dependendo da consulta e tamanhos de relação, o grau de separação deve ser muito mais fina. Particionamento físico em clusters de banco de dados para apoio à decisão é dirigida por São ¨ ohr et al. [2000], utilizando partições de grãos pequenos.Sob a distribuição de dados uniforme, esta solução é mostrado para se obter o paralelismo intra-consulta boa e superar inter-consulta paralelismo. No entanto, o particionamento físico é estática e, portanto, muito sensível a dados de condições de inclinação ea variação dos padrões de consulta que pode exigir reparticionamento periódica.

Particionamento Virtual evita os problemas de particionamento físico estático usando uma abordagem dinâmica e replicação completa (cada relação é replicado em cada nó). Em sua forma mais simples, que chamamos de particionamento virtuais simples (SVP), partições virtuaissão dinamicamente produzidos para cada consulta e paralelismo intra-consulta é obtido através do envio de sub-consultas a diferentes partições virtuais [Akal et al., 2002]. Para produzir os subconsultas diferentes, a base de dados do processador de consulta aglomerado adiciona predicados para a consulta de entrada, a fim de restringir o acesso a um subconjunto de uma relação, isto é, uma partição virtual. Pode também fazer alguma reescrita para se decompor a consulta em subconsultas equivalentes seguido por uma consulta composição. Em seguida, cada DBMS que recebe uma consulta sub-é forçado para processar um subconjunto diferente de itens de dados. Finalmente, o particionadaresultado precisa ser combinadas por uma consulta de agregação.

Exemplo 14.9. Vamos ilustrar SVP com a seguinte consulta Q:

SELECT PNO, AVG(DUR)FROM ASGWHERE SUM(DUR) > 200GROUP BY PNO

Uma subconsulta genérico em uma partição virtual é obtida pela adição à cláusula Q, onde o predicado "e PNO> = P1 e PNO <P2". Por ligação [P1, P2] para n intervalos subseqüentes de valores PNO, obtemos subconsultas n, cada um para um nó diferente em uma partição diferente virtual de ASG. Assim, o grau de paralelismo intra-consulta é n. Além disso, o "AVG (DUR)" operação deve ser reescrito como "SUM (DUR), COUNT (DUR)" na subconsulta. Finalmente, para obter o resultado correto para "AVG (DUR)", a consulta a composição deve executar "SUM (DUR) / SUM (COUNT (DUR))" sobre os resultados parciais n.

O desempenho da execução de cada subconsulta depende pesadamente sobre os métodos de acesso disponíveis no atributo de particionamento (PNO). Neste exemplo, um índice clusterizado na PNO seria melhor. Assim, é importante para o processador de consulta para conhecer os métodos de acesso disponíveis para decidir, de acordo com a consulta, que o particionamento atribuir a usar.

SVP permite uma grande flexibilidade para a alocação nó durante o processamento da consulta, visto que qualquer nó pode ser escolhida para a execução de uma subconsulta. No entanto, nem todos os tipos de consultas podem beneficiar da SVP e ser paralelizado. Akal et al. [2002] propõem uma classificação de consultas OLAP tais que as consultas da mesma classe têm propriedades semelhantes paralelização. Esta classificação depende de como as maiores relações, chamadas tabelas de fatos (por exemplo, ordens e LineItems) em uma aplicação OLAP típicas, são acessados. A justificativa é que tal divisão virtual de tais relações produz paralelismo intraoperator muito. Três classes principais são identificadas:

1. Consultas sem subconsultas que acessam uma tabela de fatos.2. Consultas com uma subconsulta que são equivalentes a uma consulta da classe 1.3. Quaisquer outras consultas.

Consultas da classe 2 precisa ser reescrita em consultas da classe 1, a fim de aplicar SVP, enquanto consultas da classe 3 não podem beneficiar da SVP.

SVP tem algumas limitações. Em primeiro lugar, determinar as melhores atributos de particionamento virtuais e intervalos de valores pode ser difícil, uma vez assumindo distribuição uniforme valor não é realista. Segundo, alguns SGBDs realizar varredura de toda a tabela de acesso indexado ao recuperar as tuplas de grandes intervalos de valores. Isso reduz os benefícios de acesso ao disco paralelo uma vez que um nó pode incidentalmente ler uma relação inteira para acessar uma partição virtual. Isso faz com que SVP dependente dos recursos de consulta subjacentes DBMS. Em terceiro lugar, como uma consulta não pode ser modificado externamente enquanto está a ser executado, o equilíbrio de carga é difícil de conseguir e depende da compartimentação inicial.

De grão fino particionamento endereços virtuais estas limitações, usando um grande número de sub-consultas em vez de um per DBMS [Lima et al., 2004a]. Trabalhando com o menor sub-consultas evita varredura completa de tabela e faz o processamento de consultas menos vulnerável a idiossincrasias DBMS. No entanto, esta abordagem deve estimar o tamanho das partições, usando estatísticas de banco de dados e estimativas de consulta em tempo de processamento. Na prática, estas estimativas são difíceis de obter com caixa-preta SGBDs.Adaptive particionamento virtual (AVP) resolve este problema dinamicamente o tamanho das partições de ajuste, assim, sem a necessidade de estas estimativas [Lima et al., 2004b]. AVP é executado de forma independente em cada nó de cluster participantes, evitando inter-nó de comunicação (por determinação do tamanho da partição). Inicialmente, cada nó recebe um intervalo de valores de trabalhar. Estes intervalos são determinados exactamente como para SVP. Em seguida, cada nó executa as seguintes etapas:

1. Começar com um tamanho de partição muito pequena começando com o primeiro valor do intervalo recebido.2. Executa uma sub-consulta com esse intervalo.3. Aumente o tamanho da partição e executar o correspondente sub-consulta, enquanto o aumento no tempo de execução é proporcionalmente menor do que o aumento no tamanho da partição.4. Parar de aumentar. Um tamanho estável foi encontrado.5. Se houver degradação de desempenho, ou seja, houve execuções consecutivo piores, diminuir o tamanho e vá para o Passo 2.

Começando com um tamanho de partição muito pequena evita scans tabela completas no início do processo. Isso também evita ter que saber o limite após o qual o DBMS não usa índices clusterizados e começa a executar varreduras de tabela cheia. Quando aumenta o tamanho de partição, o tempo de execução de consulta é monitorizada permitindo a determinação do ponto depois do qual as etapas de processamento de consulta de dados que são de tamanho independente não influenciar o tempo de execução muito total de consulta. Por exemplo, se a duplicação do tamanho da partição produz um tempo de execução que é duas vezes a anterior, isto significa que um tal ponto foi encontrado. Assim, o algoritmo pára o aumento do tamanho. O desempenho do sistema pode deteriorar-se devido a acidentes de DBMS de cache de dados ou aumento carga total do sistema. Pode acontecer que o tamanho a ser utilizado é muito grande e tem beneficiado de anteriorcache de acessos de dados. Neste caso, pode ser melhor para reduzir o tamanho de partição. Isso é precisamente o que faz o passo 6. Dá uma chance de voltar e inspecionar tamanhos menores de partição. Por outro lado, se a deterioração do desempenho foi devido a um aumento casual e temporária de carga do sistema ou erros de cache de dados, mantendo um tamanho de partição pequeno pode levar a um desempenho pobre. Para evitar tal situação, o algoritmo volta para o passo 2 e reinicia tamanhos crescentes.

AVP e outras variantes de particionamento virtual tem várias vantagens: flexibilidade para a atribuição do nó, alta disponibilidade, porque de replicação completa, e as oportunidades para balanceamento de carga dinâmico. Mas replicação completa pode levar ao alto custo na utilização do disco. Para suportar a replicação parcial, soluções híbridas têm sido propostos para combinar particionamento físico e virtual. O design híbrido por Rohm et al. [2000] usa física particionamento para as relações maiores e mais importantes e totalmente replica as pequenas mesas. Assim, intra-consulta paralelismo pode ser conseguida com os requisitos de menor espaço de disco. A solução híbrida devido à Furtado et al. [2005, 2006] combina AVP com o particionamento físico. Ele resolve o problema do uso do disco, mantendo as vantagens de AVP, ou seja, evitar varredura completa da tabela e balanceamento dinâmico de carga.

14.5.5 A tolerância a falhasNas seções anteriores, o foco tem sido sobre como obter uma performance, consistência e escalabilidade quando o sistema não falha. Nesta seção, discutimos o que acontece no advento de falhas. Há várias questões levantadas pelos fracassos. O primeiro é como manter a consistência apesar das falhas. Segundo, para operações em aberto, há a questão de como executar failover. Em terceiro lugar, quando uma réplica não é reintroduzida (recuperação a seguir), ou uma réplica fresca é introduzida no sistema, o estado actual da base de dados tem de ser recuperado. A principal preocupação é como lidar com falhas. Para começar, as falhas precisam ser detectado. Em abordagens de comunicação em grupo baseadas, detecção de falhas é fornecido pelo grupo de comunicação subjacente (tipicamente baseados em algum tipo de mecanismo de pulsação). Mudanças de associação são notificados como eventos1. Ao comparar a nova associação com a anterior, torna-se possível saber quais réplicas falharam. Grupo de comunicação também garante que todas as réplicas conectados compartilham a noção mesma filiação. Para abordagens que não são baseados em grupo de detecção de falha de comunicação podem ser transferidos para a camada de comunicação subjacente (por exemplo, TCP / IP), ou implementado como um componente adicional da lógica de replicação. No entanto, algum protocolo de acordo é necessário para garantir que todas as réplicas conectados compartilham a noção mesma inscrição de que as réplicas estão operacionais e que não são. Caso contrário, as incoerências podem surgir.

Falhas também deve ser detectado no lado do cliente pela API cliente. Os clientes geralmente se conectam através de TCP / IP e pode suspeitar de nós fracassados através de conexões quebradas. Após uma falha réplica, a API cliente deve descobrir uma nova réplica, restabelecer uma nova conexão a ela, e, no caso mais simples, retransmitir a última transação pendente para a réplica apenas ligado. Desde retransmissões são necessários, transacções duplicadas podem ser entregues. Isto requer uma operação de detecção duplicado e mecanismo de remoção. Na maioria dos casos, é suficiente para ter um identificador de cliente único, e um identificador de transacção única por cliente. O último é incrementado para cada nova transação apresentada. Assim, o cluster pode saber se uma transação cliente já foi processado e, nesse caso, descartá-lo.

Uma vez que uma falha réplica foi detectada, várias ações devem ser tomadas no cluster de banco de

dados. Estas acções são parte do processo de failover, que devem reorientar as operações a partir de um nó que falhou para outro nó de réplica, de uma maneira que é tão transparente quanto possível para os clientes. Failover altamente dependente ou não a réplica não foi um mestre. Se uma réplica não-master falhar, nenhuma ação precisa ser tomada no lado cluster. Os clientes com operações em aberto conectar a um nó nova réplica e reenviar as últimas transações. No entanto, a questão interessante é que a definição de consistência é fornecido. Lembre-se do ponto 13.1, que, em um replicado banco de dados, serializability uma cópia-pode ser violada, como resultado de serialização transacções em diferentes nós na ordem inversa. Devido à failover, as operações podem também ser tratados de modo a que uma cópia-serializability é comprometida.

Na maioria das abordagens de replicação, failover é tratado por abortar todas as operações em curso para evitar estas situações. No entanto, esta forma de falhas de manipulação tem um impacto sobre os clientes que devem reenviar a transação abortada. Como os clientes geralmente não têm capacidades transacionais para desfazer os resultados de uma interação conversacional, isto pode ser muito complexo. O conceito de transacções altamente disponíveis torna falhas totalmente transparente aos clientes para que eles não observam abortos transações devido a falhas [Perez-Sorrosal et al., 2006]. Tem sido aplicada ao protocolo de replicação NODO (ver Capítulo 13) como se segue. O conjunto de gravação e a resposta para todas as transações de atualização são multicast para as outras réplicas antes de atender o cliente. Assim, qualquer outra réplica pode assumir a qualquer momento em uma interação transacional.

As ações a serem tomadas no caso de uma falha réplica master estão mais envolvidos do que para o caso de não-master. Primeiro, um novo mestre deve ser designado para assumir a master falhou. A nomeação de um novo mestre deve ser acordado todos os réplicas do cluster. No grupo baseado em replicação, graças à notificação de alteração de filiação, é o suficiente para aplicar uma função determinística sobre a nova composição para atribuir mestres (todos os nós recebem exatamente a mesma lista de nós e conectado). Por exemplo, o protocolo NODO trata falhas desta maneira. Ao nomear um novo mestre, é necessário cuidar da coerência.

Outro aspecto essencial da tolerância a falhas é a recuperação após a falha. Alta disponibilidade tem duas faces. Uma delas é a tolerar falhas e continuar a proporcionar o acesso a dados consistentes apesar das falhas. No entanto, as falhas de diminuir o grau de redundância no sistema, a disponibilidade assim degradantes e desempenho. Por isso, é necessário reintroduzir réplicas falhadas ou fresco no sistema para manter ou melhorar a disponibilidade e desempenho. A principal dificuldade é que as réplicas têm estado e uma réplica não pode ter perdido as atualizações ao mesmo tempo que estava para baixo. Assim, uma réplica em recuperação não precisa receber as atualizações perdidas antes de ser capaz de iniciar o processamento de novas transações. A solução é parar de processamento de transações. Assim, um estado quiescente é directamente atingido que pode ser transferido por qualquer uma das réplicas de trabalho para a recuperação de uma. Uma vez que a réplica recuperar recebeu todas as atualizações perdidas, processamento de transações pode retomar todas as réplicas e pode processar novas ransações. No entanto, este protocolo de recuperação offline dói disponibilidade, o que contraria o objetivo inicial de replicação. Portanto, se de alta disponibilidade e desempenho devem ser fornecidos, a única opção é para executar a recuperação online [Kemme et al, 2001;. Jim'enez-Peris et al, 2002.].

14,6 ConclusãoSistemas de banco de dados paralelos esforçar-se para explorar arquiteturas de multiprocessadores usando soluções softwareoriented para gerenciamento de dados. Suas promessas são de alta performance highavailability, e extensibilidade com uma relação custo / desempenho bom. Além disso, paralelismo é a única solução viável para suportar bancos de dados muito grandes dentro de um único sistema.

Sistemas de banco de dados paralelos podem ser apoiada por várias arquiteturas paralelas entre memória partilhada, disco, compartilhou nada e arquiteturas híbridas. Cada arquitetura tem suas vantagens e limitações em termos de performance, extensibilidade, disponibilidade e. Para pequenas configurações (por exemplo, menos de 20 processadores), memória compartilhada, pode fornecer o melhor desempenho por causa do melhor balanceamento de carga. Arquiteturas de disco compartilhado e nada compartilhado superar memória compartilhada em termos de extensibilidade. Alguns anos atrás,

compartilhou nada era a única escolha para sistemas high-end. No entanto, os progressos recentes nas tecnologias de conectividade, tais como disco SAN fazer um disco compartilhado, uma alternativa viável e com a principal vantagem de simplificar a administração de dados. Híbrido arquiteturas, como NUMA e cluster pode combinar a eficiência e simplicidade de memória compartilhada ea extensibilidade e custo de qualquer disco compartilhado ou nada compartilhado.Em particular, eles podem usar memória compartilhada nós com excelente performance / custo. Ambos NUMA e cluster pode escalar até grandes configurações (centenas de nós). A principal vantagem do NUMA sobre um cluster é o modelo (memória compartilhada) de programação simples que facilita o projeto de banco de dados e administração. No entanto, usando nós de PC padrão e interconexões, os clusters de proporcionar um melhor conjunto custo / desempenho e, usando compartilhada nada, pode escalar até configurações muito grandes (milhares de nós).

Paralelas técnicas de gerenciamento de dados estender técnicas de banco de dados distribuídos, a fim de obter alto desempenho, alta disponibilidade e extensibilidade. Essencialmente, as soluções para gerenciamento de transações, ou seja, controle de concorrência distribuído, confiabilidade, atomicidade, e replicação pode ser reutilizado. No entanto, as questões críticas para tais arquiteturas são dados colocação, execução de consulta paralela, processamento paralelo de dados, otimização de consulta paralela e balanceamento de carga. As soluções para esses problemas são mais envolvidos do que em DBMS distribuída porque o número de nós pode ser muito maior. Além disso, técnicas de gestão de dados paralelos utilizar diferentes hipóteses, tais como interconexão rápido e nós homogêneos que oferecem mais oportunidades de otimização.

Um cluster de banco de dados é um importante tipo de sistema de banco de dados paralelo que usa blackbox DBMS em cada nó. Muitas pesquisas têm se dedicado a tirar o máximo proveito do ambiente de cluster estável, a fim de melhorar o desempenho e disponibilidade, explorando a replicação de dados. Os principais resultados desta pesquisa são novas técnicas de replicação, balanceamento de carga, processamento de consultas, e tolerância a falhas.

Exercícios

Problema 14,1 (*). Considere a organização servidor centralizado com vários servidores de aplicação que acessam um servidor de banco de dados. Suponha também que cada servidor de aplicativos armazena um subconjunto do diretório de dados que está totalmente armazenada no servidor de banco de dados. Suponhamos também que os diretórios de dados locais em servidores de aplicativos diferentes não são necessariamente disjuntos. Quais são as implicações sobre o gerenciamento de dados de diretório e de processamento de consulta para o servidor de banco de dados se os diretórios de dados locais podem ser atualizadas pelos servidores de aplicação, em vez do servidor de banco de dados?

Problema 14,2 (**). Propor uma arquitetura para um servidor de banco de dados paralelo de memória compartilhada e fornecer uma comparação qualitativa com o nada-compartilhado arquitetura com base no desempenho esperado, a complexidade do software (na colocação, em particular de dados e processamento de consultas), extensibilidade e disponibilidade.

Problema 14.3. Especifique o hash paralelo algoritmo de junção para o paralelo arquitetura de servidor de banco de dados sharedmemory proposta no Exercício 14.2.

Problema 14,4 (*). Explicar os problemas associados com o cluster e particionamento completo em um sistema de banco de dados compartilhado nada paralelo. Propor soluções e compará-los.

Problema 14.5. Propor um algoritmo semijoin paralelo para um sistema de banco de dados compartilhado nada paralelo. Como deve ser o paralelo algoritmos de junção ser estendido para explorar este algoritmo semijoin?

Problem 14.6. Consider the following SQL query:

SELECT ENAME, DURFROM EMP, ASG, PROJWHERE EMP.ENO=ASG.ENOAND ASG.PNO=PROJ.PNOAND RESP="Manager"AND PNAME="Instrumentation"

Give four possible operator trees: right-deep, left-deep, zigzag and bushy. For each one, discuss the opportunities for parallelism.

Problema 14.7. Considere uma maneira nove join (dez relações devem ser unidas) calcular o número de possíveis direita profundas, árvores de profundidade à esquerda e espessa, assumindo que cada relação pode ser juntado com mais ninguém. O que você conclui sobre otimização paralela?

Problema 14,8 (**). Propor uma estratégia de posicionamento de dados para uma arquitetura de cluster que maximiza o paralelismo intra-nó (intra-operador paralelismo dentro de uma memória compartilhadanó).

Problema 14,9 (**). Como deve ser o modelo de execução DP apresentado na Seção 14.4.4 ser alterado para lidar com a inter-consulta paralelismo?

Problema 14.10 (**). Considere-se um multi-usuário do sistema de banco de dados centralizado. Descreva a principal mudança para permitir inter-consulta paralelismo do desenvolvedor do sistema de banco de dadose pontos de vista do administrador. Quais são as implicações para o usuário final em termos de interface e desempenho?

Problema 14,11 (**). Mesma pergunta para paralelismo intra-consulta em uma arquitetura de memória compartilhada ou para uma arquitetura shared-nothing.

Problema 14,12 (*). Considere a arquitetura de cluster de banco de dados na Figura 14,21. Assumindo que cada nó de cluster pode aceitar transações de entrada, precisa fazer caixa middleware DBcluster descrevendo as camadas de software diferentes, e seus componentes e as relações em termos de dados e fluxo de controle. Que tipo de informação precisa ser compartilhada entre os nós do cluster? como?

Problema 14,13 (**). Discutir as questões de tolerância a falhas para o protocolo de replicação preventiva (ver secção 14.5.2).

Problema 14,14 (**). Compare o protocolo de replicação preventiva com o protocolo de replicação NODO (ver Capítulo 13), no contexto de um sistema de cluster em termos de: configurações de replicação suportados, requisitos de rede, consistência, desempenho, tolerância a falhas.

Problema 14.15 (*). Vamos considerar um cluster de banco de dados para uma loja de aplicativos online. O banco de dados é acessado simultaneamente por transações de atualização de curta duração (por exemplo, pedidos de produtos) e longas consultas somente leitura de apoio à decisão (por exemplo, análise de ações). Discutir como a replicação do banco de dados com o controle de frescura pode ser útil para melhorar o tempo de resposta das consultas de apoio de decisão. Qual pode ser o impacto na carga transação?

Problema 14.16 (**). Considere duas relações R (A, B, C, D, E) e S (A, F, G, H). Suponha que há um índice agrupado em um atributo para cada relação. Assumindo um cluster de base de dados com a replicação completa, para cada um dos seguintes consultas, determinar se Partioning Virtual pode ser usado para obter intra-consulta paralelismo e, em caso afirmativo, escrever a subconsulta correspondente ea consulta composição final resultado.

(a) SELECT B, COUNT(C)FROM RGROUP BY B

(b) SELECT C, SUM(D), AVG(E)FROM R

WHERE B=:v1GROUP BY C

(c) SELECT B, SUM(E)FROM R, SWHERE R.A=S.AGROUP BY BHAVING COUNT(*) > 50

(d) SELECT B, MAX(D)FROM R, SWHERE C = (SELECT SUM(G) FROM S WHERE S.A=R.A)GROUP BY B

(e) SELECT B, MIN(E)FROM RWHERE D > (SELECT MAX(H) FROM S WHERE G >= :v1)GROUP BY B