PROCESSAMENTO PARALELO DE CONSULTAS...

PROCESSAMENTO PARALELO DE CONSULTAS SOBRE FRAGMENTOS

VIRTUAIS DE DOCUMENTOS XML

Carla Amaral de Sant’ Anna Rodrigues

Dissertação de Mestrado apresentada ao

Programa de Pós-graduação em Engenharia de

Sistemas e Computação, COPPE, da

Universidade Federal do Rio de Janeiro, como

parte dos requisitos necessários à obtenção do

título de Mestre em Engenharia de Sistemas e

Computação.

Orientador(es): Marta Lima de Queirós Mattoso

Vanessa Braganholo Murta

Rio de Janeiro

Dezembro de 2011




DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO

LUIZ DE COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA

(COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS

REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM

CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.

Examinada por:

________________________________________________

Profª. Marta Lima de Queirós Mattoso, D.Sc.

________________________________________________

Profª. Vanessa Braganholo Murta, D.Sc.

________________________________________________

Prof. Alexandre de Assis Bento Lima, D.Sc.

________________________________________________

Profª. Mirella Moura Moro, Ph.D.

RIO DE JANEIRO, RJ – BRASIL

DEZEMBRO DE 2011

iii

Rodrigues, Carla Amaral de Sant’ Anna

Processamento paralelo de consultas sobre fragmentos

virtuais de documentos XML / Carla Amaral de Sant’ Anna

Rodrigues. – Rio de Janeiro: UFRJ/COPPE, 2011.

XII, 105 p.: il.; 29,7 cm.

Orientador(es): Marta Lima de Queirós Mattoso


Dissertação (mestrado) – UFRJ/ COPPE/ Programa

de Engenharia de Sistemas e Computação, 2011.

Referências Bibliográficas: p. 84-88.

1. Processamento paralelo e distribuído de consultas

ad-hoc. 2. Fragmentação virtual de dados. 3. Bases de

dados XML. I. Mattoso, Marta Lima de Queirós et al. II.

Universidade Federal do Rio de Janeiro, COPPE,

Programa de Engenharia de Sistemas e Computação. III.

Título.

iv

A Deus, por estar sempre ao meu lado.

v

AGRADECIMENTOS

Agradeço a Deus por estar sempre ao meu lado, por me ajudar a chegar até

aqui. Por dar-me forças para prosseguir, principalmente, quando achei que não era

possível. Obrigada Senhor, pois sem Tua ajuda eu jamais teria conseguido.

Aos meus pais, Sônia Amaral e Carlos Rodrigues, meus sinceros

agradecimentos por sempre acreditarem em mim e por me apoiarem nos momentos

mais difíceis. Embora não estejamos juntos, obrigada por suas orações, pelas

palavras de incentivo, pela preocupação contínua e por compreenderem a minha

ausência em prol dos estudos.

À Ana Luiza Ribeiro, com quem tenho convivido nos últimos três anos, meus

sinceros agradecimentos pelo apoio e incentivo constantes e, principalmente, pela

tamanha paciência e compreensão diante do meu estresse em vésperas de prova,

apresentações de trabalho e submissão de artigos. Obrigada pela companhia, por me

ouvir nos momentos de grande preocupação e por seus conselhos, que sempre me

ajudaram a manter a calma e seguir adiante.

À Vanessa Carla Felipe Gonçalves, minha companheira e amiga de todas as

horas, obrigada pelo apoio e incentivo, e por estar sempre presente nos momentos

mais difíceis. Sou muita grata a Deus por sua amizade. Você me ajudou a seguir em

frente. Sua perseverança é um exemplo para mim.

Obrigada Daniel de Oliveira e Eduardo Ogasawara por compartilharem seus

conhecimentos comigo e por todo o aprendizado que obtive com vocês ao longo

destes anos.

Ao Jonas Dias, obrigada por toda ajuda para que eu pudesse realizar a

validação experimental de minha dissertação. Obrigada pela paciência ao me explicar

sobre as configurações e funcionamento do cluster e por toda a atenção ao responder

minhas duvidas por e-mail. Muito obrigada, Jonas! Sem sua ajuda eu não teria

conseguido.

Às professoras Marta Mattoso e Vanessa Braganholo, meus sinceros

agradecimentos pela excelente orientação. Obrigada por me guiarem nesta jornada e

por estarem sempre presentes. O apoio e a ajuda de vocês foram imprescindíveis para

que eu chegasse até aqui. São professoras como vocês que fazem a diferença e

transformam as nossas vidas.

vi

Ao professor Alexandre de Assis, obrigada pela ajuda nos momentos de dúvida

e pelas idéias e sugestões de melhoria que auxiliaram no desenvolvimento desta

dissertação.

À professora Mirella Moura, obrigada por aceitar o convite para participar da

banca. É uma honra tê-la como integrante.

Ao professor Flávio R. C. Sousa, meus sinceros agradecimentos por toda

atenção e ajuda que me destes ao responder minhas dúvidas por e-mail. Sua ajuda foi

muito importante para a conclusão desta dissertação. Tudo o que posso dizer é: Muito

obrigada!

À professora Jonice de Oliveira, obrigada pelo constante apoio, incentivo e

amizade.

Aos amigos de jornada e companheiros de disciplina: Júlia Ferreira de Almeida,

Rodrigo Mesquita, Gizelle Gaspar, Hugo Cesar de Castro e Arlindo Neto, obrigada

pelo apoio e companheirismo.

Aos amigos do trabalho, da equipe Coppetec e da Marinha: Egídio Gomes,

Jorge Luíz de Oliveira, Felipe Leite, José Luíz Garcia Villar, Carlos Alberto Meirelles e

Sérgio Barros, obrigada pelo apoio e companheirismo durante estes últimos anos.

Aos meus vizinhos Sueli e Wilson, obrigada por toda a ajuda que me deram

desde o dia em que me mudei até os dias de hoje. Agradeço a Deus por ter vizinhos

tão solícitos e amigos como vocês.

À COPPE, obrigada por me permitir estudar nesta instituição exemplar e por

propiciar um ensino de excelente qualidade. A CAPES, obrigada por permitir a

conclusão dos meus estudos, auxiliando-me com o financiamento necessário para

custear minhas despesas e meus estudos. Ao NACAD, obrigada por permitir a

realização dos testes necessários para a validação da solução proposta nesta

dissertação.

Por fim, porém, não menos importante, obrigada a todos que fizeram parte da

minha jornada na COPPE. À Ana Paula Rabelo, Patrícia Leal, Cláudia Prata, Mara

Prata, Josefina Solange Silva Santos, Sonia Regina Galliano, Maria Mercedes e

Gutierrez, meu Muito Obrigada!

vii

Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos

necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)




Dezembro/2011

Orientadores: Marta Lima de Queirós Mattoso


Programa: Engenharia de Sistema e Computação

A era interativa da internet implicou o aumento no volume de transações e

informações sobre produtos, clientes, parceiros e fornecedores. A interoperabilidade e

a facilidade de integração providas pela XML (eXtensible Markup Language)

promoveram o aumento substancial de dados expressos nesta linguagem.

Considerando o aumento da concorrência e as práticas de fidelização de clientes, a

análise informacional de dados XML tornou-se necessária para auxiliar no processo de

tomada de decisão. No entanto, o crescimento dos bancos de dados XML implicou a

busca por soluções que propiciassem melhor desempenho ao processar consultas

XML analíticas. Em geral, técnicas de fragmentação física são aplicadas sobre a base

de dados para prover o processamento paralelo das consultas, visando a diminuir o

tempo total de resposta. Considerando um cenário típico de sistemas de suporte à

decisão, onde as consultas são ad-hoc, a fragmentação física de dados não pode ser

aplicada, uma vez que esta técnica analisa as consultas de entrada mais frequentes

para definir o projeto de fragmentação. Desta maneira, adotamos uma solução

independente do conhecimento prévio das consultas de entrada: a fragmentação

virtual de dados. Esta técnica realiza a fragmentação dinâmica da base de dados, por

meio da reescrita da consulta de entrada, onde a quantidade e o tamanho dos

fragmentos virtuais são definidos em tempo de execução. Tal estratégia tem sido

aplicada apenas no modelo relacional. Esta dissertação apresenta uma adaptação da

fragmentação virtual de dados para o modelo XML. Nossa avaliação experimental

mostra ganhos de desempenho de até 90%.

viii

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the

requirements for the degree of Master of Science (M.Sc.)

PARALLEL QUERY PROCESSING OVER VIRTUAL PARTITIONS OF XML

DOCUMENTS


December/2011

Advisors: Marta Lima de Queirós Mattoso


Department: Computer and Systems Engineering

The interactive internet era has caused a significant increase in the volume of

data about products, customers, partners, suppliers and transactions to manipulate

such data. The interoperability and easy integration provided by XML (eXtensible

Markup Language) promoted a substantial increase in data expressed in this language.

Considering the increased competition and customer retention practices, informational

analysis of XML data has become necessary to assist in any decision-making process.

However, the growth of XML databases resulted in the search for solutions to improve

the performance of analytical XML queries. In general, physical fragmentation

techniques are applied to the database to provide parallel query processing in order to

reduce the total query response time. Considering a typical scenario of decision

support systems, where queries are ad-hoc, physical fragmentation techniques cannot

be applied, since it analyzes the more frequent input queries to define the

fragmentation design. Thus, we adopt a solution that does not depend on prior

knowledge of the input queries: the virtual partitioning. This technique performs the

dynamic partitioning of the database, through query rewriting, where the number and

size of the virtual fragments are defined at runtime. This strategy has been applied only

in the relational model. This dissertation presents an adaptation of the virtual

partitioning to the XML model. Our experimental evaluation shows performance gains

of up to 90%.

ix

ÍNDICE DO TEXTO

1 Introdução ........................................ ................................................................... 1

1.1 Motivação ....................................................................................................... 1 1.2 Objetivos ........................................................................................................ 5 1.3 Organização dos Capítulos ............................................................................. 6

2 Processamento paralelo e distribuído de consultas . ....................................... 8

2.1 Fragmentação física de dados no modelo relacional ...................................... 8 2.2 Fragmentação física de dados no modelo XML ............................................ 10 2.3 Replicação e alocação de dados .................................................................. 14 2.4 Processamento de consultas sobre bancos de dados XML distribuídos ....... 16 2.5 Processamento adaptativo e distribuição dinâmica de carga ........................ 17 2.6 Considerações finais .................................................................................... 18

3 Processamento eficiente de consulta analíticas ad-h oc ................................ 20

3.1 Transações OLTP e consultas OLAP ........................................................... 20 3.2 Agrupamentos de banco de dados e processamento paralelo de consultas . 21 3.3 Fragmentação virtual de dados..................................................................... 22

3.3.1 Fragmentação virtual ............................................................................. 23 3.3.2 Problemas da fragmentação virtual na escolha de atributos de fragmentação do tipo string ................................................................................. 27 3.3.3 Fragmentação virtual adaptativa ............................................................ 30 3.3.4 Fragmentação virtual híbrida ................................................................. 31

3.4 Soluções de alto desempenho baseadas na fragmentação virtual de dados 32 3.4.1 PowerDB ............................................................................................... 33 3.4.2 Pargres .................................................................................................. 33 3.4.3 Aplicação do paralelismo intra-consulta ao algoritmo BLAST ................ 33 3.4.4 SmaQSS ............................................................................................... 34

3.5 Considerações finais .................................................................................... 34 4 Metodologia para a aplicação da fragmentação virtua l sobre bancos de dados XML.............................................................................................................................. 37

4.1 Exemplo de bases de dados XML ................................................................ 37 4.2 Fragmentação virtual sobre bancos de dados XML ...................................... 41

4.2.1 Consultas a bases de dados SD ............................................................ 44 4.2.2 Consultas a bases de dados MD ........................................................... 53

4.3 Composição dos resultados .......................................................................... 57 4.4 Considerações Finais ................................................................................... 58

5 Partix-VP – fragmentação virtual em XML............ ............................................... 60

5.1 Adaptação da fragmentação virtual de dados ao modelo XML ..................... 60 5.2 Processamento paralelo de consultas em agrupamentos de banco de dados .. .................................................................................................................................. 61 5.3 Consolidação dos resultados ........................................................................ 63 5.4 Armazenamento de dados em SGBDX nativos ............................................ 65 5.5 Comunicação paralela e distribuída entre os nós do agrupamento ............... 68 5.6 Considerações Finais ................................................................................... 69

6 Validação Experimental ............................ ........................................................ 71

6.1 Configuração do ambiente ............................................................................ 71 6.2 Consultas XML e bases de dados ................................................................ 72 6.3 Análise dos Resultados ................................................................................ 75 6.4 Considerações Finais ................................................................................... 79

x

7 Conclusões e Trabalhos Futuros .................... .................................................... 81

7.1 Considerações Finais ................................................................................... 81 7.2 Trabalhos Futuros......................................................................................... 83

8 Referências Bibliográficas ........................ ....................................................... 84

9 Anexo I - Consultas XQuery utilizadas nos experimen tos ............................. 89

10 Anexo II – Tempo de processamento das consultas ... ................................... 94

11 Anexo III – Proporção entre os tempos de execução e composição dos resultados ........................................ ......................................................................... 96

xi

ÍNDICE DE FIGURAS

Figura 3.1: Atributos e relacionamentos das relações do cenário apresentado. .......... 25 Figura 3.2: Fragmentação virtual adaptativa no agrupamento de banco de dados. .... 31 Figura 4.1: Declaração de restrições xs:key e xs:keyref em um esquema XML. ......... 38 Figura 4.2: Definição dos tipos TClientes e TPedidos. ................................................ 39 Figura 4.3: Definição do tipo TParcelasPedidos. ......................................................... 40 Figura 4.4: Documento XML válido contendo as informações dos clientes e dos pedidos. ...................................................................................................................... 40 Figura 4.5: Informações das parcelas relacionadas aos pedidos dos clientes............. 41 Figura 4.6: Retorno da função XPath position(). ......................................................... 42 Figura 4.7: Consulta XQuery de entrada. .................................................................... 45 Figura 4.8: Consulta XQuery envolvendo uma operação de junção. ........................... 46 Figura 4.9: Fragmentos virtuais gerados após aplicar a FV. ....................................... 47 Figura 4.10: Consulta XQuery envolvendo duas operações de junção. ...................... 49 Figura 4.11: Fragmento virtual correspondente ao intervalo [100001; 200001[. .......... 51 Figura 4.12: Combinações após aplicar a FV sobre uma consulta com operações de junção. ........................................................................................................................ 52 Figura 4.13: Consulta a uma coleção de documentos. ................................................ 53 Figura 4.14: Fragmentos virtuais gerados para a consulta sobre uma coleção de documentos. ............................................................................................................... 54 Figura 4.15: Fragmentos virtuais gerados sobre a consulta intermediária. .................. 55 Figura 5.1: Visão geral da arquitetura para a FV no agrupamento de banco de dados. ................................................................................................................................... 62 Figura 5.2: Consulta envolvendo uma operação de ordenação. ................................. 64 Figura 5.3: Fragmentos virtuais gerados para a consulta com ordenação. ................. 64 Figura 5.4: Consulta XQuery para obter o resultado final ordenado. ........................... 65 Figura 6.1: Arquivo para a submissão de tarefas ao agrupamento. ............................ 71 Figura 6.2: Esquema da base de dados do dblp. ........................................................ 73 Figura 6.3: Esquema da base de dados do benchmark Xmark. .................................. 74 Figura 6.4: Resultados obtidos nos experimentos com consultas de alto custo e médio custo. .......................................................................................................................... 76 Figura 6.5: Resultados obtidos nos experimentos com consultas de baixo custo. ...... 78 Figura 6.6: Resultados obtidos nos experimentos com consultas a bases de dados MD. ............................................................................................................................. 79

xii

ÍNDICE DE TABELAS

Tabela 6.1: Características das bases de dados utilizadas nos experimentos. ........... 73 Tabela 6.2: Definição das consultas utilizadas nos experimentos. .............................. 75 Tabela 6.3: Tempo médio de processamento (ms). .................................................... 76

1

1 Introdução

1.1 Motivação Em meados da década de 90, evoluções tecnológicas proporcionaram

mudanças consideráveis, resultando na era interativa da internet, na qual surgiu o

comércio eletrônico. Como consequência, as organizações tiveram de se adaptar ao

novo cenário para gerenciar um número elevado de transações e informações. Além

disso, a análise informacional sobre parceiros, fornecedores e, principalmente clientes,

tornou-se necessária para auxiliar no processo de tomada de decisão. Esta análise

informacional permitiu às organizações realizarem previsões, estabelecerem planos de

contingência e definir estratégias de fidelização de clientes.

Com o decorrer dos anos, houve um aumento considerável no volume de dados

que, por sua vez, dificultava a análise das informações. Além disso, estes dados

poderiam estar armazenados de forma distribuída e segundo diferentes

representações, tais como em planilhas, em arquivos texto, e/ou em bancos de dados.

Posteriormente, com o crescimento do volume de dados na Web e com a necessidade

de integrar e de analisar dados semi-estruturados, a linguagem XML (eXtensible

Markup Language, ou Linguagem Extensível de Marcação) (BRAY et al., 2008) passou

a ser utilizada como linguagem padrão de representação e manipulação de dados em

diversas áreas de negócio.

O aumento substancial de dados no formato XML, tais como informações de

compras eletrônicas, bibliotecas digitais e avaliações de usuários sobre produtos e

serviços, implicou a busca por técnicas que permitissem tratá-los como bancos de

dados, sobre as quais consultas pudessem ser realizadas. Inicialmente, técnicas de

mapeamento entre o modelo semi-estruturado e o modelo relacional foram utilizadas a

fim de transformar a estrutura lógica em árvore para a estrutura plana (ou tabular) do

modelo relacional (ATAY et al., 2007; DEUTSCH et al., 1999; FLORESCU, DANIELA

et al., 1999). Posteriormente, surgiram os Sistemas de Gerência de Banco de Dados

Relacionais (SGBDR) com suporte a consultas XML e ao armazenamento de

documentos XML como atributos de uma relação (tabela), tais como SQL Server1,

Oracle2, DB23, entre outros. No entanto, o conceito de bancos de dados XML culminou

1 http://msdn.microsoft.com/en-us/library/ms345117(v=sql.90).aspx 2 http://technet.oracle.com/tech/xml/info/htdocs/relational/index.htmn#ID795i 3 http://www-4.ibm.com/software/data/db2/extenders/xmlext.htmli

2

com o surgimento de Sistemas de Gerência de Banco de Dados XML (SGBDX)

nativos (JAGADISH et al., 2002), os quais proveem o armazenamento e a recuperação

de dados em seu formato original, pois os dados são persistidos em disco segundo

uma estrutura lógica em árvore ou grafo.

Ao longo dos anos, surgiram diversos SGBDX, tais como Tamino (SCHÖNING,

2001), Timber (JAGADISH et al., 2002), Natix (FIEBIG et al., 2002), eXist (MEIER,

2003), Sedna (FOMICHEV et al., 2006) e X-Hive4. Porém, apesar das evoluções dos

SGBDX através de sofisticados mecanismos de indexação e de buscas full-text, o

aumento considerável do volume de dados nas organizações e a natureza distribuída

de muitos desses dados implicou a necessidade de desenvolver técnicas que

propiciassem mais desempenho em consultas sobre uma base de dados XML

extensa, como o processamento de consultas distribuídas (KOSSMANN, 2000).

Uma das formas de realizar o processamento paralelo de consultas é utilizar

técnicas de fragmentação física de dados e alocação de documentos XML para

distribuir a base. A fragmentação física da base de dados caracteriza-se pela divisão

do documento original em documentos XML menores, denominados fragmentos, por

meio de operações de seleção e projeção. Para isso, é necessário definir um projeto

de fragmentação que consiste da análise das consultas mais frequentes e dos

respectivos predicados de seleção, a fim de escolher o tipo de fragmentação mais

adequado e aplicar as operações de seleção ou projeção sobre os documentos. Após

a etapa de fragmentação, cada fragmento gerado é alocado em um ou mais nós da

rede.

Trabalhos relacionados consideram a execução de consultas a bases XML

distribuídas sob a arquitetura de um mediador (FIGUEIREDO et al., 2010; KURITA et

al., 2007; MOREIRA; MACHADO, 2007; MOREIRA et al., 2011). No trabalho de

Figueiredo et al. (2010), técnicas de fragmentação física propostas por Andrade et al.

(2006) são aplicadas a documentos XML, gerando fragmentos que são,

posteriormente, alocados a diferentes nós de uma rede sobre os quais são executadas

as sub-consultas geradas a partir da consulta original. Técnicas de fragmentação

sobre documentos XML também são utilizadas em (GERTZ; BREMER, 2003; KIDO et

al., 2006; KLING et al., 2011; MA; SCHEWE, 2003; WALDVOGEL et al., 2008). Em

geral, a maioria das propostas aloca os fragmentos em nós da rede segundo uma

abordagem sem replicação, isto é, cada fragmento é armazenado em um, e somente

um nó da rede, pois não existem réplicas (cópias) dos fragmentos distribuídas entre os

4 www.x-hive.com

3

nós. No entanto, existem propostas na literatura que armazenam réplicas em outros

nós (MOREIRA et al., 2011), tendo em vista a maior tolerância a falhas.

Embora vários estudos indiquem a fragmentação física como a estratégia a ser

adotada para se obter mais desempenho em consultas XML com paralelismo, esta é

uma solução com restrições. A fragmentação física requer o conhecimento prévio das

informações que são consultadas frequentemente, de forma a produzir fragmentos de

acordo com os predicados das consultas, como implementado em (MAHBOUBI;

DARMONT, 2009). No entanto, se este conhecimento não existir ou se houver

alteração ou adição de consultas com novos predicados, um novo projeto de

fragmentação deve ser realizado para adaptar-se ao novo cenário. Esse é o caso

clássico dos sistemas de apoio à decisão, caracterizado por consultas analíticas ad-

hoc. Consultas analíticas caracterizam-se pelo processamento de um grande volume

de dados e, em geral, utilizam operações de agregação sobre estes dados, o que

demanda um longo tempo de processamento. Quanto à natureza ad-hoc, não se sabe

a priori o tipo de análise que será realizado e, portanto, não se sabe quais consultas

serão executadas. O benchmark TPC-H (TPC, 2011) deixa isso bem claro em sua

especificação que caracteriza as consultas analíticas. Assim, novos grupos de

consultas poderiam ser penalizadas pela fragmentação inadequada. A alternativa seria

a criação de novos projetos de fragmentação, seguidos da alocação dos novos

fragmentos, o que tornaria o processo dispendioso. Além disso, a variação do número

de nós (falha ou entrada de nós na rede) e o desbalanceamento de carga podem

exigir a realocação dos fragmentos. Por estes motivos, a fragmentação física não se

mostra como uma solução adequada para dar suporte a consultas analíticas ad-hoc no

ambiente distribuído.

Para auxiliar no processamento de consultas XML analíticas, surgiram propostas

de aplicações conhecidas como XML-OLAP. Aplicações deste tipo assemelham-se

aos armazéns de dados do modelo relacional. No entanto, os dados armazenados são

representados por documentos XML e não por relações (tabelas). A estrutura das

aplicações XML-OLAP é bastante complexa se comparada à estrutura dos armazéns

de dados no modelo relacional, uma vez que a tabela de fato e as tabelas de

dimensões podem ser hierárquicas. Assim, estas tabelas precisam ser definidas de

forma a manter os relacionamentos e a semântica inerentes à linguagem XML. Em

(WIWATWATTANA et al., 2007; ZHANG et al., 2005) são apresentadas soluções que

permitem a criação de cubos OLAP sobre documentos XML. Os cubos são compostos

por duas ou mais dimensões, que por sua vez, representam uma visão do negócio, tal

como tempo, região, produto, entre outros. Assim, o usuário pode efetuar a análise

4

que julgar mais adequada para auxiliar no processo de tomada de decisão.Em

(WIWATWATTANA et al., 2007; ZHANG et al., 2005) árvores de padrões são

utilizadas para prover a especificação de cubos OLAP sobre os dados XML. No que se

refere à avaliação de desempenho de consultas analíticas sobre armazéns de dados

XML, em (MAHBOUBI; DARMONT, 2010) é apresentado o XWeb, um benchmark

XML composto por um conjunto de vinte consultas XML analíticas, na sua maioria com

funções de agregação, que são características deste tipo de ambiente. As consultas

providas por este benchmark foram geradas com base no benchmark TPC-H e se

adequam às características de aplicações XML-OLAP.

Desta forma, considerando as características das consultas submetidas a

aplicações XML-OLAP e a ausência de soluções voltadas para a melhoria de

desempenho destas consultas, surgiu a motivação para esta dissertação: prover uma

solução de alto desempenho para consultas XML analíticas ad-hoc.

Analisando as limitações da fragmentação física, identificamos a fragmentação

virtual (FV) (AKAL et al., 2002) como uma proposta de solução atraente, até então

adotada apenas para bancos de dados relacionais. A fragmentação virtual consiste da

fragmentação dinâmica da base de dados, a qual gera os fragmentos virtuais por meio

da reescrita da consulta original através da adição de novos predicados de seleção,

segundo o atributo escolhido para a fragmentação (MATTOSO, 2009a). Deste modo,

cada fragmento gerado corresponde a um determinado intervalo de valores do atributo

selecionado. Na abordagem de Akal et al. (2002), a fragmentação virtual é adotada em

um ambiente de agrupamento (cluster) de banco de dados que se caracteriza como

um agrupamento de computadores no qual cada nó executa um sistema de gerência

de banco de dados independente (MATTOSO, 2009b). Em Akal et al. (2002), a base

de dados completa é armazenada em cada um dos nós, de maneira que qualquer nó

pode ser escolhido para executar uma das sub-consultas geradas.

No que se refere à fragmentação virtual, não existem trabalhos na literatura que

adotem esta técnica no modelo XML. Tendo em vista a necessidade de soluções de

alto desempenho para consultas XML analíticas ad-hoc e a proposta de fragmentação

virtual como uma técnica promissora, surgiu a motivação para esta dissertação. Assim,

apresentamos o Partix-VP, que consiste de uma adaptação da fragmentação virtual ao

cenário de consultas XML distribuídas em agrupamentos de banco de dados. Essa

adaptação da fragmentação virtual no modelo relacional para o modelo XML não é

trivial, pois as definições de fragmentos relacionais se baseiam no atributo chave das

relações para definir os fragmentos. Esse conceito nem sempre está presente em

XML. Portanto, a escolha do atributo para a determinação dos intervalos dos

5

fragmentos é um desafio no modelo XML. A composição final dos resultados também

se torna mais complexa devido à sofisticação da linguagem XML quanto à

especificação da estrutura do documento de resposta.

1.2 Objetivos Esta dissertação tem como objetivo contribuir com uma solução para o

processamento de consultas XML analíticas ad-hoc sobre bancos de dados XML

distribuídos. Para isso, propomos uma solução de paralelismo intra-consulta

(MATTOSO, 2009b) sobre agrupamentos de banco de dados que consiste da

execução da mesma consulta em diferentes nós sobre sub-conjuntos dos dados.

Nossa abordagem se baseia na fragmentação virtual de dados, a qual foi adaptada ao

modelo XML e aos SGBDX nativos. Na fragmentação virtual, o paralelismo intra-

consulta é realizado através da geração de sub-consultas com predicados de seleção

distintos que caracterizam diferentes faixas de valores da consulta original. As faixas

de valores caracterizam os sub-conjuntos dos dados globais da consulta original. A

solução proposta contempla os dois tipos de bases de dados XML: Único Documento

(Single Document - SD) e Múltiplos Documentos (Multiple Documents - MD) (YAO et

al., 2003). Na abordagem SD, a base de dados contém um único documento XML

bastante extenso. Já a abordagem MD consiste de uma base de dados que possui

múltiplos documentos, normalmente, de tamanhos menores. Em geral, documentos

semanticamente relacionados são armazenados em uma mesma coleção. As coleções

no modelo XML assemelham-se aos diretórios em um sistema de arquivos e podem

conter apenas documentos ou sub-coleções.

A metodologia proposta nesta dissertação permite a escolha dinâmica do

atributo de fragmentação; a reescrita da consulta original para a geração das sub-

consultas, que proporciona a fragmentação virtual em tempo de execução; a execução

das sub-consultas no ambiente distribuído e a consolidação dos resultados. A etapa

de composição do resultado final é realizada por um único nó do agrupamento, o qual

é denominado “nó de controle”. O nó de controle é semelhante a qualquer outro nó do

agrupamento. No entanto, além de processar consultas XML, ele é o único

responsável pela consolidação dos resultados. O SGBDX Sedna (FOMICHEV et al.,

2006) foi utilizado para o armazenamento e a recuperação de dados XML.

A fim de analisar a efetividade de nossa solução, realizamos experimentos em

um ambiente de agrupamento de banco de dados, considerando bases de dados XML

SD e MD. Consultas XML de alto, médio e baixo custo foram formuladas para

avaliarmos diferentes cenários. Cada uma das consultas foi executada no ambiente

6

centralizado e teve seu tempo de processamento coletado. Em seguida, cada consulta

foi submetida à fragmentação virtual e, posteriormente processada no agrupamento de

banco de dados. Por fim, os tempos de processamento obtidos nos ambientes

centralizado e distribuído foram comparados a fim de identificar o potencial dos

ganhos em desempenho.

1.3 Organização dos Capítulos Os capítulos que compõem esta dissertação estão organizados como segue.

No Capítulo 2, descrevemos os aspectos relacionados ao processamento

paralelo e distribuído de consultas XML segundo a técnica de fragmentação física de

dados, uma vez que esta abordagem é adotada em grande parte das soluções

existentes na literatura. Nesse capítulo, discutimos os assuntos relacionados ao

projeto de distribuição de dados, assim como a replicação e alocação de dados.

No Capítulo 3, apresentamos os conceitos inerentes ao ambiente de

agrupamento de banco de dados, aos paralelismos inter e intra-consulta e à

fragmentação virtual, a fim de prover embasamento teórico para a compreensão da

solução proposta nesta dissertação. Além disso, uma revisão bibliográfica a respeito

das soluções de alto desempenho que adotam a fragmentação virtual no modelo

relacional é apresentada, uma vez que esta técnica é o foco desta dissertação.

Nossa proposta de solução é apresentada no Capítulo 4, onde especificamos a

metodologia utilizada e descrevemos a estratégia adotada para implantar a

fragmentação virtual em bancos de dados XML distribuídos. Os conceitos inerentes a

restrições de unicidade em bases de dados XML e os exemplos utilizados para

explicar a nossa solução são descritos neste capítulo. O algoritmo de decomposição

da consulta original em fragmentos virtuais é apresentado com exemplos ilustrativos a

fim de prover ao leitor melhor entendimento sobre a estratégia utilizada.

No Capítulo 5, apresentamos os detalhes de implementação do Partix-VP e

indicamos a arquitetura utilizada e os SGBDX analisados, assim como as respectivas

características e os critérios utilizados para a escolha do SGBDX mais adequado.

Neste capítulo, também apresentamos a solução utilizada para prover a comunicação

paralela e distribuída entre os nós do agrupamento de banco de dados.

O Capítulo 6 é dedicado à validação experimental, onde apresentamos a base

de dados e as consultas XML utilizadas nos experimentos. Neste capítulo definimos os

critérios de avaliação dos resultados, tais como o tamanho do documento a ser

consultado; a cardinalidade do atributo de fragmentação; o tamanho do documento de

7

resposta e as características da consulta de entrada. De acordo com estes critérios,

apresentamos os resultados obtidos e a análise realizada, comparando os tempos de

processamento observados nos ambientes centralizado e distribuído.

Por último, as conclusões são apresentadas no Capítulo 7, onde mencionamos

as considerações finais e as contribuições desta dissertação, e indicamos as questões

em aberto e os trabalhos futuros.

8

2 Processamento paralelo e distribuído de consultas

Considerando o alto custo de consultas analíticas, as quais demandam longo

tempo de processamento, uma vez que acessam um grande volume de dados,

surgiram propostas de soluções baseadas em técnicas de processamento paralelo

que consistem da decomposição da consulta em múltiplas sub-consultas que são

processadas por diferentes nós da rede (FURTADO et al., 2005; LIMA et al., 2009;

PAES et al., 2008; RÖHM et al., 2000). Para isso, é necessária a definição de um

projeto de distribuição de dados que suporte a divisão das relações (no modelo

relacional) ou dos documentos XML (no modelo XML) da base de dados em unidades

menores e as distribua entre os nós da rede. O projeto de distribuição é constituído

pelas técnicas de fragmentação, de replicação e de alocação dos dados.

A fragmentação física dos dados é responsável pela divisão da base de dados,

através do particionamento das relações ou dos documentos XML segundo as

consultas de entrada, gerando partes disjuntas, o que denominamos de fragmentos.

Os tipos de fragmentação são definidos na Seção 2.1 e 2.2 para os modelos relacional

e XML, respectivamente. A fragmentação física é sucedida pela replicação de dados

que, por sua vez, caracteriza-se pela definição do número de réplicas para cada

fragmento gerado e pode se enquadrar em uma dentre três abordagens distintas: a

replicação total, a replicação parcial ou a abordagem sem replicação, cujos conceitos

são explicados na Seção 2.3. Nessa seção também apresentamos as técnicas para

alocação de dados, que consiste em armazenar os fragmentos e suas réplicas nos nós

da rede, de forma a alcançar a melhor eficiência possível. Uma revisão bibliográfica a

respeito das soluções de alto desempenho no modelo XML é apresentada nas Seções

2.4 e 2.5. Por último, apresentamos nossas considerações finais na Seção 2.6.

2.1 Fragmentação física de dados no modelo relacion al A fragmentação física de dados consiste em dividir a base de dados em

unidades lógicas chamadas de fragmentos. Para isso, é necessário executar um

projeto de fragmentação (ÖZSU; VALDURIEZ, 2011), antes de iniciá-la de fato.

Durante o projeto de fragmentação, as consultas mais frequentes são analisadas a fim

de identificar as relações a serem fragmentadas. Também são identificados o tipo de

fragmentação mais adequado e os atributos sobre os quais a fragmentação será

aplicada, denominados atributos de fragmentação. Existem três tipos de técnicas para

9

a fragmentação física de dados: a fragmentação horizontal, a fragmentação vertical e

a fragmentação híbrida.

Fragmentação horizontal . Os fragmentos são gerados a partir da aplicação de

operações de seleção sobre a relação desejada. A fragmentação horizontal subdivide-

se em fragmentação horizontal primária (FHP) e fragmentação horizontal derivada

(FHD). Na FHP, operações de seleção são aplicadas sobre a relação original, o que

gera fragmentos que contêm todos os atributos (colunas) da relação original e um

número limitado de tuplas (linhas) que correspondem aos registros que satisfazem aos

predicados mintermos, resultantes da combinação de predicados simples como

veremos a seguir.

Segundo a técnica proposta por Özsu e Valduriez (2011), o primeiro passo da

FHP é analisar os predicados de seleção mais frequentes que aparecem nas

consultas submetidas pelos usuários, denominados predicados simples. Em seguida,

identificamos as relações às quais os atributos desses predicados pertencem, a fim de

criarmos uma lista que relacione os predicados simples às suas respectivas relações.

Posteriormente, o tipo de fragmentação horizontal é definido, sabendo-se que a FHP é

indicada para relações que contêm as chaves primárias, enquanto a FHD deve ser

aplicada a relações que contêm as chaves estrangeiras. Na FHP, após o agrupamento

dos predicados simples por relação, os predicados combinados, chamados de

predicados mintermos, são gerados através da combinação “booleana” dos predicados

simples. Em seguida, as contradições e redundâncias são eliminadas analisando as

implicações lógicas dos predicados. Os predicados mintermos resultantes

caracterizam os fragmentos (primários) a serem distribuídos.

A FHD é aplicada sobre relações que possuem chaves estrangeiras, as quais

referenciam relações já fragmentadas horizontalmente. As relações que contêm

chaves estrangeiras são denominadas relações membro, enquanto as relações que

contêm apenas chaves primárias são chamadas de relações dono. Na FHD, os

fragmentos são gerados através de operações de semi-junção, considerando a chave

estrangeira da relação membro e a chave primária dos fragmentos primários gerados.

A FHD resulta em fragmentos (derivados) que contêm todas as tuplas da relação

membro cuja chave estrangeira aparece como chave primária no fragmento primário

envolvido. Note que a quantidade de fragmentos gerados na FHD é igual à quantidade

de fragmentos primários gerados na fase anterior.

Fragmentação vertical. Na fragmentação vertical, os fragmentos são gerados

através da aplicação de operações de projeção sobre uma determinada relação, de

10

forma a agrupar os atributos da relação original segundo o grau de afinidade entre

eles. Os grupos formados constituem os fragmentos verticais. É importante ressaltar

que a chave primária da relação original é o único atributo que deve estar contido em

todos os fragmentos gerados para possibilitar a reconstrução da relação, isto é, a

obtenção da relação original não fragmentada. A fragmentação vertical é mais

complexa se comparada à fragmentação horizontal, pois o número de combinações

possíveis é proporcional ao número de atributos das relações. Para que a

fragmentação vertical seja eficiente, é necessário analisar os atributos utilizados nas

projeções e nos predicados de seleção das consultas, a fim de identificar aqueles que

são acessados em conjunto em cada consulta. Em seguida, analisamos a frequência

com que cada consulta é processada para identificar os atributos que aparecem

simultaneamente nestas consultas. Os atributos com maior afinidade são agrupados

em um mesmo fragmento.

Fragmentação Híbrida. A fragmentação híbrida é caracterizada como uma

combinação das estratégias anteriores, onde os fragmentos são obtidos através de

seleções (quando houver fragmentação horizontal primária) ou semi-junções (quando

houver fragmentação horizontal derivada), seguidas de projeções, ou vice-versa.

Após a fragmentação, devemos validá-la através da verificação de corretude

segundo os princípios da completude, da disjunção e da reconstrução indicados por

(ÖZSU; VALDURIEZ, 2011). Considerando o modelo relacional, a fragmentação física

de uma relação é completa quando todas as tuplas (na fragmentação horizontal) ou

atributos (na fragmentação vertical) da relação original estão contidos nos fragmentos

gerados. A completude assegura que os fragmentos não excluem dados, de maneira

que a execução de uma determinada consulta na base não fragmentada e na base

distribuída gera a mesma resposta. Para que a fragmentação seja disjunta, cada

tupla/atributo da relação original deve pertencer a um, e somente um fragmento. A

reconstrução consiste da aplicação de operações de união sobre os fragmentos

horizontais e operações de junção sobre os fragmentos verticais, a fim de se obter a

relação original da base não fragmentada.

2.2 Fragmentação física de dados no modelo XML A fragmentação física sobre bases de dados XML pode ser do tipo horizontal,

vertical ou híbrida. Técnicas de fragmentação física já foram definidas na literatura

(ANDRADE et al., 2006; GERTZ; BREMER, 2003; MA; SCHEWE, 2003). No entanto,

apenas Andrade et al. (2006), apresenta uma definição completa, a qual abrange

fragmentos horizontais, verticais e híbridos. Além disso, este é o único trabalho que

11

define regras de corretude para a fragmentação física em bases de dados XML, e

utiliza uma álgebra XML (PAPARIZOS; LAKSHMANAN, 2004) para isso. Em

(ANDRADE et al., 2006), um fragmento XML é definido como o resultado da aplicação

de operações da álgebra sobre uma coleção SD ou MD. A seguir, apresentamos as

definições para cada um dos tipos de fragmentação.

Fragmentação Horizontal. A fragmentação horizontal visa agrupar os dados

que são frequentemente acessados por uma determinada consulta XML. Como

exemplo, considere a árvore (a) e o documento XML (b) apresentados na Figura 2.1.

<dblp>

<periodicos>

<periodico>

<autores>

<autor>Carla Rodrigues</autor>

<autor>Vanessa Braganholo</autor>

<autor>Marta Mattoso</autor>

</autores>

<titulo>XML virtual partitioning</titulo>

<ano>2011</ano>

</periodico>

<periodico>...</periodico>

...

</periodicos>

</dblp>

(a) Árvore XML. (b) Documento XML.

Figura 2.1: Árvore e documentos XML de exemplo para a fragmentação horizontal.

Um fragmento horizontal F é obtido a partir da aplicação de uma operação de

seleção σ (PAPARIZOS; LAKSHMANAN, 2004) sobre uma coleção homogênea C,

como descrito a seguir.

Fh_periodicos := Cdblp, σ/dblp/periodicos/ano >=2005

No exemplo descrito acima, o fragmento horizontal Fh_periodicos é definido

sobre a coleção Cdblp e conterá somente os documentos de dblp que satisfazem ao

predicado de seleção /dblp/periodicos/ano >=2005.

Note que na fragmentação horizontal, operações de seleção são aplicadas sobre

uma coleção de documentos, o que gera fragmentos correspondentes aos

documentos XML que satisfazem ao predicado de seleção utilizado. Bases de dados

do tipo SD não podem sofrer este tipo de fragmentação, pois a fragmentação

horizontal é definida sobre um conjunto de árvores, o que exige uma coleção de

múltiplos documentos.

12

Fragmentação Vertical. A fragmentação vertical tem como objetivo agrupar os

elementos que são acessados simultaneamente por uma determinada consulta XML.

O esquema da coleção original é dividido em vários esquemas menores, de forma que

cada fragmento gerado possui um sub-conjunto dos elementos da estrutura de dados

original. Como consequência, os esquemas que definem cada fragmento são

diferentes entre si. Como exemplo, considere a árvore (a) e o documento XML (b)

apresentados na Figura 2.2

<redeSocial>

<paises>

<Australia>...</Australia>

<Brasil>...</Brasil>

...

</paises>

<categorias>

<categoria>...</categoria>

...

</categorias>

</redeSocial>


Figura 2.2: Árvore e documentos XML de exemplo para a fragmentação vertical.

Um fragmento vertical V é obtido a partir da aplicação de uma operação de

projeção ΠΡΓ (PAPARIZOS; LAKSHMANAN, 2004) sobre uma coleção C, onde P

indica a expressão de caminho do elemento a ser projetado e Γ representa um conjunto

de expressões de caminho a serem podados de P, como exibido a seguir.

FV_redeSocial := CredeSocial, Π/redeSocial, { /redeSocial/paises, /redeSocial/categorias }

Neste exemplo, o fragmento vertical FV_redeSocial é definido sobre a coleção

CredeSocial e conterá todas as sub-árvores do elemento redeSocial, exceto as sub-

árvores /redeSocial/paises e /redeSocial/categorias.

Observe que o elemento a ser a raiz do fragmento deve possuir cardinalidade

igual a um. Desta maneira, podemos assegurar que os documentos gerados a partir

da poda das sub-árvores são documentos bem-formados. Caso contrário, seria

necessário criar novos elementos XML para assumirem o papel de nó raiz nos

fragmentos.

Fragmentação Híbrida. A fragmentação híbrida consiste da aplicação da

fragmentação horizontal seguida da fragmentação vertical ou vice-versa. Este é o

único tipo de fragmentação que possibilita que uma base de dados SD seja

fragmentada horizontalmente. Para isso, devemos aplicar a fragmentação vertical

13

sobre o documento XML original e, em seguida, aplicar a fragmentação horizontal

sobre os fragmentos verticais gerados. Como exemplo, considere a árvore (a) e o

documento XML (b) apresentados na Figura 2.3.

<processoSeletivo>

<candidatos>

<candidato>

<nome>Ana Ribeiro</nome>

<idade>24</idade>

<escolaridade>Superior Completo

</escolaridade>

</candidato>

<candidato>

<nome>Vanessa Gonçalves</nome>

<idade>27</idade>

<escolaridade>Mestrado Completo

</escolaridade>

</candidato>

...

</candidatos>

</processoSeletivo>


Figura 2.3: Árvore e documentos XML de exemplo para a fragmentação híbrida.

A seguir, exibimos um exemplo de fragmentação híbrida sobre uma coleção.

FY_candidatos := Cselecao, Π/processoSeletivo/candidatos,{ } • σ//candidato/escolaridade=”Superior Completo”

No exemplo descrito, o fragmento híbrido FY_candidatos é definido sobre a

coleção Cselecao. Inicialmente, é feita a projeção do elemento

/processoSeletivo/candidatos sem poda de sub-árvores deste elemento, o que gera os

fragmentos verticais. Posteriormente, a seleção é aplicada sobre o conjunto de

fragmentos verticais, a fim de selecionar somente os elementos que satisfazem ao

predicado //candidato/escolaridade=”Superior Completo”. É importante ressaltar que

candidato é sub-elemento de candidatos no documento XML original.

Para assegurar a corretude do projeto de fragmentação sobre bases de dados

XML, os fragmentos devem ser completos e disjuntos, assim como no modelo

relacional. Além disso, a aplicação de operações de união/junção sobre os fragmentos

gerados deve resultar na coleção/documento original (reconstrução). Uma coleção que

foi submetida à fragmentação horizontal pode ser reconstruída a partir da união de

seus fragmentos. Para documentos fragmentados verticalmente, operações de junção

são executadas sobre os fragmentos para realizar a reconstrução do documento

original. Para a fragmentação híbrida, a reconstrução deve ser realizada por etapas,

14

aplicando as operações de união sobre os fragmentos horizontais, seguidas de

operações de junção sobre os fragmentos verticais ou vice-versa.

Fragmentar um documento XML extenso garante que cada nó processará um

subconjunto de dados do documento original. Porém, uma vez que consultas

distribuídas geram transferência de resultados intermediários, o desempenho pode ser

afetado pelos custos com comunicação e composição do resultado final. A vazão e o

tempo de resposta das consultas são diretamente afetados pela distribuição dos dados

entre os fragmentos gerados. Para alcançar melhor desempenho é necessário

concentrar os dados que atendem aos predicados de cada consulta em bases de

dados locais ou próximas do nó que submeteu a consulta, de forma a diminuir custos

com comunicação, resultante do acesso remoto.

Além disso, devemos analisar o custo com a reconstrução da

coleção/documento a partir de seus fragmentos. Este custo pode ser muito elevado se

for necessário acessar um número grande de fragmentos para processar a consulta.

Por último, a falta de flexibilidade de escolha dos nós, em cenários sem replicação,

limita o ganho de desempenho, uma vez que um nó que contém um fragmento que

atende a várias consultas pode ficar sobrecarregado, resultando em

desbalanceamento de carga. Na próxima seção, discutimos os aspectos inerentes à

replicação e à alocação de dados.

2.3 Replicação e alocação de dados A fragmentação física é seguida pela fase de alocação dos dados, na qual os

fragmentos são armazenados em diferentes nós da rede. Antes da alocação

propriamente dita, o projetista deve definir o tipo de replicação a ser utilizado. Se cada

fragmento é armazenado em um único nó da rede, dizemos que não há replicação de

dados, caso contrário, a replicação pode ser total ou parcial. A replicação total consiste

em armazenar réplicas de todos os fragmentos em todos os nós da rede, resultando

no máximo de disponibilidade e flexibilidade (ÖZSU; VALDURIEZ, 2011). No entanto,

a viabilidade desta técnica depende do tamanho da base de dados e da capacidade

de armazenamento de cada nó. Na replicação parcial, todos ou parte dos fragmentos

são replicados em alguns nós da rede, mas não em todos.

Existem características importantes que devemos analisar no momento da

alocação, tais como os tamanhos dos fragmentos, o número e o tipo de acesso (local

ou remoto), os nós mais utilizados, a capacidade de armazenamento dos nós da rede

e a largura de banda (ÖZSU; VALDURIEZ, 2011). É importante ressaltar que a

replicação de dados, se comparada à abordagem sem replicação, provê a

15

continuidade do processamento paralelo da consulta ainda que um dos nós apresente

falha, pois réplicas podem ser acessadas em outros nós. Além disso, a replicação é

aconselhada nos casos em que múltiplas consultas proveem de localizações

geográficas diferentes e muito distantes, diminuindo os custos com transmissão de

dados, uma vez que se pode optar pelo acesso a réplicas mais próximas.

Após a definição do tipo de replicação a ser adotada, os fragmentos e as

respectivas réplicas devem ser alocados em nós da rede. Encontrar uma solução

ótima para a alocação de dados em bancos de dados distribuídos é um problema NP-

Difícil, o que torna inviável a especificação e análise de todas as possibilidades de

armazenamento de fragmentos em uma rede de computadores. Desta maneira, os

trabalhos encontrados na literatura baseiam-se em métodos heurísticos (HUANG;

CHEN, 2001; WILDEMBERG et al., 2003) que proveem soluções eficientes e

aproximadas da solução ótima, porém, não garantem que a melhor solução seja

encontrada.

Em Shepherd et al. (1995), a alocação de dados é dividida em duas fases:

agrupamento de fragmentos e análise de custo. Na primeira fase, os fragmentos são

agrupados segundo o grau de afinidade entre eles, isto é, os grupos são formados por

fragmentos que tendem a ser acessados juntos, em um determinado número de

consultas. Na segunda fase, a técnica “dividir para conquistar” é utilizada para a

alocação dos dados, onde os grupos de fragmentos da primeira fase são divididos,

visando a encontrar o ponto de partição mais eficiente. Nesta fase, os grupos são

alocados em nós da rede e os custos com comunicação e transmissão são analisados

a fim de encontrar a alocação mais eficiente, dentre os casos possíveis, segundo a

capacidade de armazenamento de cada nó.

Em outras propostas (HUANG; CHEN, 2001; WILDEMBERG et al., 2003), a

alocação de dados é realizada em três fases: (i) alocação de réplicas dos fragmentos

em nós que executem ao menos uma operação de leitura/atualização sobre estes

fragmentos; (ii) diminuição progressiva do número de réplicas alocadas durante a

primeira fase, através da análise dos custos adicionais com operações de leitura

gerados pela retirada da réplica, assim como, do benefício alcançado pela redução de

operações de atualização e; (iii) alocação dos fragmentos que não são acessados por

nenhuma transação (WILDEMBERG et al., 2003), ou são acessados somente por

transações de atualização (HUANG; CHEN, 2001), a fim de garantir que todo

fragmento seja alocado em, no mínimo, um nó.

16

Apesar das particularidades de cada abordagem, em geral, é aconselhável

armazenar réplicas dos fragmentos nos próprios nós que executam consultas

relacionadas a estes fragmentos, de modo a evitar o acesso remoto e maiores custos

com comunicação e transmissão de dados. No entanto, um número elevado de

réplicas pode resultar em queda de desempenho e aumento do custo com operações

de atualização que, por sua vez, devem respeitar a propriedade de consistência dos

dados.

2.4 Processamento de consultas sobre bancos de dado s XML distribuídos Grande parte das soluções encontradas para processamento de consultas sobre

bancos de dados XML distribuídos baseiam-se na fragmentação física dos dados

(FIGUEIREDO et al., 2010; GERTZ; BREMER, 2003; KIDO et al., 2006; KLING et al.,

2011; KURITA et al., 2007; MA; SCHEWE, 2003; MOREIRA et al., 2011;

WILDEMBERG et al., 2003).

Em (FIGUEIREDO et al., 2010) é apresentada uma metodologia para prover o

processamento paralelo e distribuído de consultas XML através da fragmentação física

da base de dados. Neste trabalho, o sistema desenvolvido funciona como um

middleware entre a aplicação cliente e os SGBDX nativos distribuídos. O sistema

provê o processamento de consultas XML distribuídas, especificadas na linguagem

XQuery (BOAG et al., 2010), através de uma arquitetura baseada em um nó mediador.

Este nó é responsável pela decomposição da consulta original em sub-consultas, pela

localização dos nós que contêm os fragmentos que contribuem para o resultado, e

pela composição do resultado final proveniente dos resultados parciais recebidos. O

sistema proposto realiza a conversão da consulta XQuery para a representação

algébrica TLC (Tree Logical Class) (PAPARIZOS; LAKSHMANAN, 2004) equivalente,

a fim de auxiliar no processo de localização, redução e eliminação (prunning) dos

fragmentos. Em seguida, técnicas de otimização são utilizadas para encontrar o

melhor plano de execução, de acordo com uma função de custo previamente definida.

Após a otimização, a representação algébrica TLC é convertida novamente para a

linguagem XQuery, originando a sub-consulta que será distribuída para o nó

apropriado. Para isso, o mediador acessa um catálogo que armazena informações,

tais como: especificação dos fragmentos através dos predicados que os definem;

relacionamentos dos fragmentos com os respectivos documentos originais; endereços

dos nós remotos e indicação dos fragmentos que eles armazenam, e dados

estatísticos que auxiliam na busca pelo plano de execução de menor custo durante a

fase de otimização. Esta dissertação apresenta as adaptações realizadas no sistema

17

desenvolvido por Figueiredo et al. (2010) para permitir a decomposição da consulta

original e o processamento paralelo das sub-consultas através da fragmentação virtual

de dados, ao invés da fragmentação física de dados.

A arquitetura baseada em um nó mediador também é adotada em outros

trabalhos. Em Moreira et al. (2011) uma solução para consultas XML distribuídas

baseada em um nó mediador é apresentada. Além de consultas XML, esta solução

também oferece suporte a operações de atualização na base de dados, por meio de

um mecanismo de controle de concorrência distribuído, denominado DTX, o qual

permite gerenciar as transações e manter a consistência dos dados. Tanto a

replicação parcial quanto a replicação total de dados são adotadas neste trabalho a

fim de avaliar os ganhos de desempenho em ambas as abordagens.

Além da fragmentação física de dados, outras soluções têm sido indicadas para

obter mais desempenho no processamento de consultas XML, tais como as técnicas

de processamento adaptativo de consultas e a técnica de distribuição dinâmica dos

dados, como explicado na próxima seção.

2.5 Processamento adaptativo e distribuição dinâmic a de carga O processamento adaptativo de consultas (AQP – Adaptive Query Processsing)

é uma técnica utilizada para detectar e corrigir erros de otimização e, tem sido

aplicada a consultas que demandam longo tempo de processamento. Essa técnica

considera estatísticas do banco de dados, tais como a cardinalidade das relações

originais, os fatores de seletividade das operações, a alocação de memória exigida, a

cardinalidade dos resultados intermediários e os tempos de execução parciais, para

monitorar o processamento das consultas e modificar os planos de execução quando

for necessário (BABU; BIZARRO, 2005). Para isso, o plano de execução é dividido em

segmentos, o que evita a abordagem tradicional plan-first execute-next, na qual o

plano de execução escolhido é utilizado até que a respectiva consulta tenha sido

processada por completo. Assim, as etapas de execução, monitoramento e otimização

são realizadas de forma alternada, possibilitando re-otimizações durante o

processamento da consulta corrente.

Considerando as propostas que adotam esse tipo de solução para o

processamento de dados XML podemos citar as abordagens de IVES et al. (2000) e

NAUGHTON et al. (2001) que implementam os sistemas de integração de dados

Tukwila e Niagara, respectivamente. No Tukwila, o plano de execução é dividido em

segmentos que são processados e têm o seu desempenho monitorado. Assim, o

18

Tukwila compara o desempenho estimado ao desempenho obtido e, caso a diferença

atinja um valor previamente estipulado (threshold), a re-otimização é aplicada aos

segmentos restantes, utilizando os resultados de desempenho observados na etapa

anterior. O Tukwila também provê a visualização de resultados parciais durante a

execução dos segmentos, e adota técnicas que permitem processar expressões XPath

(CLARK; DEROSE, 1999) sobre dados de entrada à medida que eles chegam, o que

evita a espera pelo pacote de dados completo e o seu armazenamento local, antes de

iniciar o processamento. Do mesmo modo, o Niagara também provê o envio de

resultados parciais ao usuário, assim como é capaz de processar qualquer dado

disponível na entrada a qualquer momento, durante a execução do segmento corrente.

Uma restrição importante dessa estratégia é que esta técnica não garante

eficiência máxima no processamento das consultas, pois não é possível assegurar que

a varredura sequencial de dados não é realizada ao processar um determinado plano

de execução. Além disso, os índices previamente definidos podem, inclusive, não ser

utilizados durante o processamento, o que limita as melhorias no desempenho das

consultas como um todo.

No que se refere à distribuição dinâmica de carga, esta técnica é definida como

o ato de fragmentar a base de dados XML dinamicamente, isto é, enquanto as

consultas estiverem sendo processadas, a fim de redistribuir os novos fragmentos aos

nós da rede que estão menos sobrecarregados, o que contribui para o balanceamento

de carga (AMAGASA et al., 2009). Outra proposta de balanceamento de carga pode

ser encontrada em (KURITA et al., 2007), a qual possui um mecanismo que permite

monitorar o tempo de processamento dos nós em um agrupamento de banco de

dados. Este mecanismo é utilizado para identificar os nós que possuem o menor e o

maior tempo de processamento, os quais chamaremos de NMenorT e NMaiorT,

respectivamente. Em seguida, identifica-se o fragmento armazenado em NMenorT que

apresenta o menor tempo de processamento e o fragmento alocado a NMaiorT que

possui o maior tempo de processamento. Por último, é realizada a troca desses

fragmentos entre ambos os nós. A realocação de fragmentos atinge apenas o nó mais

sobrecarregado e o menos sobrecarregado a cada fase de monitoramento, de forma

que outros nós podem apresentar indícios de sobrecarga e continuar a processar

grandes quantidades de dados, sem que nenhuma intervenção seja feita.

2.6 Considerações finais Grande parte das soluções existentes na literatura adota a fragmentação física

de dados para obter melhor desempenho em consultas a bases de dados XML. No

19

entanto, vimos que esta técnica apresenta restrições, uma vez que é necessário

conhecer o conjunto de consultas de entrada para realizar a fragmentação. Assim,

cada mudança no conjunto de consultas de entrada exige um novo projeto de

fragmentação, a fim de adaptar o ambiente para atender ao novo conjunto de

consultas. Logo, esta estratégia é inadequada para os casos em que não se conhece

a priori as consultas a serem submetidas pelo usuário. Além disso, problemas

relacionados ao desbalanceamento de carga exigem a re-alocação dos fragmentos

físicos gerados. Por estes motivos, a abordagem proposta nesta dissertação visa a

prover uma solução independente do conhecimento prévio das consultas de entrada, a

fim de evitar a re-adaptação do ambiente e atender a consultas analíticas ad-hoc.

No que se refere à replicação e alocação de dados, a abordagem sem

replicação é a única que não provê tolerância a falhas e, por isso, deve ser evitada,

uma vez que cada fragmento é armazenado em um, e somente um, nó da rede.

Assim, se o nó, que contém o fragmento, apresentar falhas, o processamento da

consulta não pode ser concluído. A replicação total ou parcial de dados são as

abordagens mais indicadas. A replicação total provê maior tolerância a falhas, no

entanto, é necessário analisar a capacidade de armazenamento dos nós e o tamanho

da base de dados, uma vez que esta abordagem pode não ser adequada para bases

de dados muito extensas. A replicação parcial, por sua vez, exige um algoritmo bem

definido para estabelecer quais fragmentos devem ser replicados e, em quais nós

devem ser armazenados. Vimos que não existem estratégias que assegurem que a

solução ótima seja encontrada, uma vez que não é possível analisar todas as

possibilidades de alocação dos fragmentos nos nós da rede.

No próximo capítulo, discutimos os fundamentos teóricos pertinentes à solução

apresentada nesta dissertação e apresentamos uma técnica de fragmentação de

dados, denominada fragmentação virtual, que reduz consideravelmente a

complexidade do problema de alocação, pois reduz o espaço de busca, já que não

realiza a alocação de fragmentos, mas sim da base de dados completa. Além disso,

discutimos algumas das soluções existentes que adotam este tipo de técnica no

modelo relacional, uma vez que não há indícios da utilização dessa estratégia no

modelo XML, a fim de fornecer ao leitor o embasamento teórico necessário para a

compreensão da solução proposta nesta dissertação.

20

3 Processamento eficiente de consulta analíticas ad -hoc

Assim como a maior parte das soluções existentes na literatura, esta dissertação

propõe o processamento paralelo e distribuído de consultas, com foco em consultas

analíticas ad-hoc. Este capítulo visa a prover embasamento teórico para que os

conceitos e técnicas utilizados nesta dissertação possam ser compreendidos. Na

Seção 3.1 descrevemos os conceitos de transações OLTP e consultas OLAP. Na

Seção 3.2, apresentamos o conceito de agrupamento (cluster) de banco de dados e

de paralelismos inter e intra-consulta. Na Seção 3.3, apresentamos os conceitos

inerentes à fragmentação virtual de dados e as diferentes variações deste tipo de

técnica existentes na literatura. Propostas de solução baseadas na fragmentação

virtual são discutidas na Seção 3.4. Por último, na Seção 3.5, apresentamos nossas

considerações finais sobre as soluções de alto desempenho para consultas analíticas

ad-hoc.

3.1 Transações OLTP e consultas OLAP A maioria das organizações controla suas atividades operacionais através da

utilização de sistemas de informação que proveem uma interface entre a aplicação e o

banco de dados, o que permite ao usuário inserir, atualizar e excluir dados de forma

transparente. O acesso e a manutenção destes dados são realizados por sistemas de

gerência de banco de dados que processam transações submetidas simultaneamente

por diferentes usuários e aplicações. Uma transação é uma sequência de operações

executadas no banco de dados como uma única unidade lógica de trabalho, e sua

integridade depende de quatro propriedades, conhecidas como ACID (Atomicidade,

Consistência, Isolamento, Durabilidade) (ELMASRI; NAVATHE, 2006). Transações do

tipo OLTP (On-Line Transaction Processing) são bastante comuns em sistemas de

informação e caracterizam-se por baixo tempo de processamento, pois executam

operações rotineiras para o funcionamento da organização, tais como o

processamento de pedidos, o cadastro de funcionários, o cadastro/cancelamento de

reservas, o depósito/saque feito pelo correntista, entre outros.

Em geral, devido ao acesso concorrente por parte de diversos usuários, as

empresas lidam com um número elevado de transações diárias. No entanto, na

maioria das vezes, as transações OLTP não constituem fatores críticos para o

desempenho, pois processam pequenas quantidades de dados. Por outro lado,

sistemas de apoio à tomada de decisão acessam bases de dados extensas que

21

armazenam dados provenientes de diferentes sistemas transacionais, ao longo de um

determinado período, a fim de que se possa realizar a previsão de eventos futuros

através da análise de dados históricos. Esta análise é realizada por meio de consultas

OLAP (On-Line Analytical Processing) que envolvem um grande volume de dados e,

por isso, caracterizam-se por um longo tempo de processamento e por sua

imprevisibilidade, já que as consultas são definidas de acordo com o interesse do

usuário. Por este motivo, consultas OLAP têm sido alvo de estudos na área de banco

de dados distribuídos, na qual grande parte das soluções encontradas se baseia no

processamento paralelo das consultas em agrupamentos de banco de dados, visando

à diminuição do tempo de resposta.

3.2 Agrupamentos de banco de dados e processamento paralelo de consultas Atualmente, agrupamentos de banco de dados (MATTOSO, 2009b) têm sido

bastante utilizados como solução para alcançar mais desempenho em consultas que

envolvem grandes massas de dados. Um agrupamento de banco de dados é

caracterizado como um conjunto de computadores, interligados por uma rede local de

alta velocidade, que executam sistemas de gerência de banco de dados

independentes. Cada computador possui memória e processadores locais, e uma

camada intermediária (middleware), localizada entre o sistema de banco de dados e a

aplicação, é utilizada para interceptar a consulta original proveniente da aplicação

cliente, dividi-la em sub-consultas e coordenar a distribuição das sub-consultas

geradas e a execução paralela nos nós do agrupamento. A principal característica

dessa solução é a possibilidade de utilizar SGBDs sequenciais nos nós do

agrupamento como componentes “caixa-preta”, isto é, sem alterações em seu código

fonte, provendo o paralelismo de modo externo e independente do SGBD local. Além

disso, o poder de processamento e de armazenamento dos computadores atuais, o

suporte ao paralelismo oferecido por diferentes plataformas e softwares existentes e a

queda no custo dos computadores pessoais tornaram tal abordagem atrativa e de fácil

expansão.

Um agrupamento de banco de dados é composto por vários nós de

processamento e um nó de administração. Os nós de processamento são

responsáveis por executar as tarefas que lhes são designadas. O nó de administração,

por sua vez, funciona como interface entre a aplicação cliente e os nós de

processamento, cuja função é submeter tarefas da aplicação para os nós de

processamento, o que caracteriza a abordagem mestre/escravo (GIERSCH et al.,

2004). Em geral, cada nó do agrupamento acessa o disco rígido local para execução

22

das tarefas. Porém, existem agrupamentos de banco de dados cujos nós não

possuem disco rígido (diskless nodes) e, por isso, adota-se uma abordagem de

acesso compartilhado, por meio de uma unidade central de armazenamento que pode

ser acessada por todos os nós do agrupamento. O ganho de desempenho em

agrupamentos de bancos de dados pode ser obtido segundo duas abordagens

distintas: o paralelismo inter-consulta e o paralelismo intra-consulta.

Paralelismo inter-consulta. O paralelismo inter-consulta consiste em executar

simultaneamente diversas consultas de baixo custo, cada uma em um nó diferente do

agrupamento (MATTOSO, 2009b). Esta abordagem é aconselhável para atender a

transações OLTP, uma vez que inúmeras consultas de baixo custo, as quais

apresentam pequeno tempo de execução, são submetidas simultaneamente. Ao

processá-las em paralelo, o tempo total de resposta das consultas diminui, o que

aumenta a vazão do sistema.

Paralelismo intra-consulta. O paralelismo intra-consulta consiste da divisão de

uma mesma consulta em múltiplas partes, a fim de que sejam processadas em

paralelo. Este tipo de paralelismo pode ser aplicado segundo duas abordagens

distintas: (i) executar em paralelo diferentes operações da mesma consulta sobre um

mesmo conjunto de dados ou (ii) executar em paralelo a mesma operação, porém,

sobre diferentes conjuntos de dados. Os fundamentos desta dissertação baseiam-se

no conceito inerente à segunda abordagem, a qual se caracteriza pela execução

paralela da mesma consulta em diferentes nós, utilizando sub-consultas que

abrangem partes diferentes da relação (tabela) envolvida (MATTOSO, 2009b). Desta

forma, cada nó executa a mesma operação, porém, sobre diferentes faixas de valores

das relações envolvidas na consulta. Consultas OLAP demandam a varredura de uma

grande massa de dados e, por apresentarem longo tempo de processamento, são

candidatas ao paralelismo intra-consulta.

Na literatura, existem diversas soluções que implementam o paralelismo intra-

consulta para obter melhor desempenho no ambiente de consultas OLAP. Esse tipo de

paralelismo vem sendo implementado por meio da utilização de uma técnica bastante

promissora, porém, ainda restrita ao modelo relacional: a fragmentação virtual de

dados.

3.3 Fragmentação virtual de dados Na Seção 3.2, vimos que as consultas OLAP são candidatas ao paralelismo

intra-consulta, visando à diminuição do tempo de processamento através da execução

paralela da mesma consulta em diferentes nós de uma rede, utilizando sub-consultas

23

que abrangem partes diferentes da relação envolvida. A fragmentação virtual (FV) é

uma técnica utilizada em bancos de dados distribuídos que implementa o paralelismo

intra-consulta através da reescrita da consulta original (MATTOSO, 2009a), o que gera

diversas sub-consultas que são processadas pelos diferentes nós da rede.

A reescrita da consulta original é feita através da adição de predicados de

seleção sobre um determinado atributo na consulta original. O predicado de seleção é

uma condição, isto é, um conjunto de expressões lógicas que devem ser satisfeitas

para que uma determinada tupla seja inserida no resultado. O atributo sobre o qual

essa condição deve ser verificada é denominado atributo de fragmentação virtual

(AFV). Para assegurar a eficiência da FV, é aconselhável que o AFV possua um índice

agrupado (clustered) ordenado, a fim de reduzir o número de acessos a páginas de

disco, o que diminui o número de operações de leitura/escrita e favorece o ganho de

desempenho. Em alguns SGBDs, tais como o SQL Server5 e o MySQL6, as chaves

primárias das relações são automaticamente criadas como índices agrupados

ordenados, exceto nos casos em que a tabela envolvida já possui um índice agrupado

ou o usuário declara a chave primária como um índice não agrupado, por meio da

instrução nonclustered. Por este motivo, atributos que compõem as chaves primárias

das relações são, em geral, escolhidos como os atributos de fragmentação virtual.

Na literatura podemos encontrar três abordagens distintas baseadas na

fragmentação virtual: a fragmentação virtual, que gera fragmentos de tamanhos iguais

para cada nó da rede; a fragmentação virtual adaptativa, que provê a geração de

pequenos fragmentos, não necessariamente do mesmo tamanho, e torna possível a

redistribuição dinâmica de carga; e a fragmentação virtual híbrida, que consiste de

uma solução híbrida, caracterizada pela combinação da fragmentação virtual

adaptativa com a fragmentação física de dados. As seções a seguir explicam as

abordagens mencionadas de forma mais detalhada.

3.3.1 Fragmentação virtual A eficiência da fragmentação virtual em agrupamentos de banco de dados pode

ser observada em trabalhos anteriores voltados para bancos de dados relacionais. Em

Akal et al. (2002), a técnica de fragmentação virtual adotada subdivide a consulta

original em fragmentos virtuais de mesmo tamanho, considerando o intervalo de

valores utilizado pelo AFV e o número de nós a serem alocados. Considerando um

número fixo de nós, o tamanho do intervalo dos valores atribuídos ao AFV define o

5 http://msdn.microsoft.com/en-us/library/ms186342.aspx 6 http://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.html

24

tamanho dos fragmentos. Desta forma, quanto maior o intervalo de valores utilizados

pelo AFV, maior o tamanho dos fragmentos gerados, o que pode resultar em grandes

fragmentos virtuais e prejudicar o ganho de desempenho. Isto se deve ao fato de que

o acesso às tuplas do banco de dados pode ser feito sem a utilização dos índices, se

um determinado número limite de tuplas for ultrapassado (LIMA et al., 2010).

A FV assume que o atributo de fragmentação virtual escolhido possui

distribuição uniforme. Um atributo possui distribuição uniforme se cada um dos valores

atribuídos a ele está uniformemente distribuído na relação, isto é, os valores deste

atributo ocorrem com frequências semelhantes. No mundo real, os atributos de uma

relação dificilmente possuem distribuição uniforme. Por este motivo, ao adotar a FV, o

desempenho pode ser prejudicado pelo desbalanceamento de carga, uma vez que

determinados nós podem ficar sobrecarregados com fragmentos virtuais que acessam

um número elevado de tuplas se comparado a outros fragmentos definidos por

diferentes intervalos, que podem conter um número reduzido de tuplas. Quando os

valores dos atributos não se encontram distribuídos uniformemente entre as tuplas de

uma relação dizemos que há distorção de dados. Para solucionar os problemas de

desbalanceamento de carga e de subutilização de índices durante o processamento

das consultas, o que ocorre quando há grandes fragmentos virtuais, surgiu a

fragmentação virtual adaptativa, cuja técnica será detalhada na Seção 3.3.3.

Segundo a estratégia da FV, para definir os predicados de seleção a serem

adicionados, precisamos das seguintes informações: o nome do AFV selecionado; a

relação à qual este atributo pertence; os valores deste atributo existentes na relação

envolvida; e o número de nós requeridos para o processamento das sub-consultas. As

sub-consultas são resultantes da adição de predicados de seleção, de acordo com o

atributo de fragmentação virtual selecionado, e o número de nós requisitados no

agrupamento. Desta forma, são gerados diferentes fragmentos virtuais com faixas de

valores de mesmo tamanho para cada nó, onde cada fragmento corresponde a uma

faixa de valor da relação referenciada na consulta original. Assim, ao receber as sub-

consultas definidas pelos fragmentos virtuais, cada nó percorre apenas uma parte da

relação e, em seguida, envia os resultados obtidos para o nó mediador para que seja

feita a composição do resultado final.

Como exemplo, considere o seguinte cenário: uma organização disponibiliza a

venda de seus produtos através do comércio eletrônico e necessita contatar os

clientes com parcelas em atraso, considerando que existem produtos que permitem o

pagamento parcelado. Sistemas informacionais são utilizados para controlar

operações rotineiras, tais como o controle de vendas, o controle de estoque e o

25

controle financeiro, responsável pelo acompanhamento do pagamento das parcelas.

Suponha que o setor responsável realiza a análise dos dados de pagamento

mensalmente, de modo que a organização pode identificar os clientes com parcelas

em aberto para contatá-los e efetuar a cobrança. Considere que as maiores relações

do banco de dados são as relações cliente, pedido e parcela_pedido, que armazenam,

respectivamente, os dados de clientes, de pedidos dos clientes e das parcelas

referentes à compra realizada. Os principais atributos e relacionamentos entre as

relações mencionadas neste exemplo são ilustrados na Figura 3.1, onde os atributos

que compõem as chaves primárias são apresentados acima das linhas horizontais

contidas nos retângulos, os quais representam as três relações mencionadas. As

chaves estrangeiras são identificadas pelos caracteres (FK).

Figura 3.1: Atributos e relacionamentos das relações do cenário apresentado.

Suponha que a relação pedido contém, atualmente, 2.000.000 de tuplas, das

quais 400.000 tuplas correspondem a entidades que possuem alguma parcela a

pagar, isto é, a quantidade de parcelas restantes é maior que zero. A chave primária

de pedido possui um índice agrupado ordenado e é composta pelo atributo pedido_id.

O atributo situacao_parcela pode assumir os valores “aguardando pagamento”, “paga”

e “inadimplente”. Assuma também que desejamos obter o nome e o e-mail dos

clientes que possuem alguma parcela a pagar, assim como a especificação do preço

total e da quantidade de parcelas restantes. Para isso, formulamos uma consulta Q

que deve ser processada por quatro nós de um agrupamento: N1, N2, N3 e N4, que

possuem réplicas completas da base de dados.

Q: SELECT cli.nome, cli.e_mail, ped.preco_total, ped. qtde_parc_rest

FROM cliente cli, pedido ped

WHERE ped.cliente_id = cli.cliente_id

AND ped.qtde_parc_rest > 0

Considere que, visando à diminuição do tempo de resposta devido ao elevado

número de tuplas da relação pedido, utilizaremos a técnica da fragmentação virtual

para o processamento da consulta Q e que pedido_id é o atributo de fragmentação

virtual selecionado para esta relação. Analisando o cenário apresentado, observamos

26

que os valores do atributo de fragmentação pertencem ao intervalo [1, 2.000.000], de

forma que a fragmentação virtual gera quatro fragmentos (um para cada nó do

agrupamento) com faixas de valores distintas, identificados pelas sub-consultas Q1,

Q2, Q3 e Q4. Cada sub-consulta gerada é semelhante à consulta original, acrescida de

um novo predicado de seleção que indica as faixas de valores, referentes ao atributo

de fragmentação pedido_id, que serão processadas por cada nó. Sabendo que

pedido_id possui um como o valor mínimo e 2.000.000 como o valor máximo, cada um

dos quatro fragmentos virtuais possui tamanho igual a 500.000, cujos intervalos estão

especificados abaixo.

Q1: SELECT cli.nome, cli.e_mail,

ped.preco_total, ped.qtde_parc_restantes




AND ped.pedido_id >= 1 and ped.pedido_id <500001






AND ped.pedido_id >= 500001 and ped.pedido_id <1000 001













Após a geração das sub-consultas, estas são submetidas a cada um dos quatro

nós reservados, de maneira que cada nó processa apenas ¼ do número total de

tuplas, aumentando a vazão e diminuindo o tempo de resposta através do

processamento paralelo. No entanto, a geração de fragmentos virtuais de mesmo

tamanho não garante que cada nó recebe a mesma carga de trabalho. Considerando

27

o cenário apresentado, suponha que alguns pedidos foram cancelados e operações de

exclusão foram executadas sobre tuplas da relação pedido, resultando em uma

distribuição não uniforme entre os valores do atributo pedido_id. Após estas

alterações, assuma que os intervalos [500001, 1000001[ e [1500001, 2000001[

passaram a conter um número maior de tuplas se comparados aos outros dois

intervalos. Desta forma, assumindo que os nós N1, N2, N3 e N4, recebem as consultas

Q1, Q2, Q3 e Q4, respectivamente, observamos que ocorre o desbalanceamento de

carga, visto que os nós N2 e N4 processam um número maior de tuplas se comparados

aos nós N1 e N3, devido à distorção de dados. Visando a eliminar as limitações da FV,

surgiu a proposta da FVA que provê a geração de pequenos fragmentos e torna

possível a redistribuição dinâmica de carga, cuja discussão é apresentada na Seção

3.3.3.

Além do desbalanceamento de carga, a FV possui limitações no que se refere ao

tipo do atributo de fragmentação escolhido. Atributos de fragmentação virtual que

assumem valores inteiros facilitam a definição dos fragmentos virtuais, uma vez que a

definição dos intervalos é automática, simples e intuitiva. Por outro lado, atributos de

fragmentação do tipo string dificultam a geração dos fragmentos virtuais, uma vez que

nem sempre é possível identificar quais caracteres representam o início e o fim dos

intervalos. Na próxima seção, discutimos os problemas relacionados à FV quando os

atributos de fragmentação virtual assumem valores do tipo string.

3.3.2 Problemas da fragmentação virtual na escolha de atributos de fragmentação do tipo string

Segundo a técnica utilizada na FV, a definição dos intervalos depende do

atributo de fragmentação selecionado. Em SGBDs relacionais, esta escolha é

facilitada pela existência dos atributos que compõem a chave primária das relações,

uma vez que estes atributos, na maior parte dos casos, são índices agrupados e

ordenados, o que evita a varredura sequencial dos dados durante o processamento.

No entanto, não podemos assumir que as chaves primárias de todas as relações de

um banco de dados assumem valores inteiros. Como exemplo, consideremos as

mesmas relações e relacionamentos apresentados anteriormente na Figura 3.1.

Consideremos que a consulta de entrada Q deve retornar os nomes e os e-mails de

todos os clientes que possuem idade maior que 26 anos. A seguir, apresentamos a

consulta Q, a qual calcula as idades dos clientes através das funções getdate() e

datediff(). A função datediff() possui três parâmetros: (i) o tipo do retorno, o qual pode

assumir os valores day, month ou year, uma vez que indicam dia, mês e ano,

28

respectivamente; (ii) a data inicial; e (iii) a data final. A função getdate(), por sua vez,

não possui parâmetros e sempre retorna a data corrente, isto é, a data atual.

Q: SELECT nome, e_mail

FROM cliente

WHERE DATEDIFF(year, data_nascimento, getdate ()) > 26

Como vimos na Seção 3.3.1, a fragmentação virtual utiliza um método bastante

simples, pois consiste da adição de novos predicados de seleção à consulta original,

considerando o atributo de fragmentação escolhido. No exemplo descrito acima,

consideremos a abordagem de Akal et al. (2002) e suponhamos que o esquema da

Figura 3.1 sofreu as seguintes alterações: exclusão da chave primária cliente_id e

definição do atributo CPF como a nova chave primária da relação cliente. É importante

ressaltar que o atributo CPF está declarado como char(11), o que representa uma

string que contém exatamente onze caracteres. Suponhamos também que o elemento

CPF, o qual compõe a chave primária da relação cliente, é selecionado como o

atributo de fragmentação. Além disso, consideremos que o usuário deseja reservar

cinco nós do agrupamento de banco de dados para processar os fragmentos, o que

indica que os valores possíveis para o atributo cpf devem ser divididos em cinco

intervalos disjuntos.

Sabemos que o cpf é composto por onze dígitos e que cada dígito pode assumir

qualquer valor entre zero e nove, o que resulta em dez possibilidades para cada dígito.

Uma possível maneira de criar os intervalos, pode ser através da análise do primeiro

dígito do cpf. Assim, a FV divide as dez possibilidades de valores que o primeiro dígito

pode assumir por cinco, uma vez que cinco nós do agrupamento serão alocados, o

que gera intervalos de tamanho dois, como especificado a seguir: (i) [0-1] cpfs cujo

primeiro dígito assume o valor zero ou o valor um; (ii) [2-3] cpfs cujo primeiro dígito

assume o valor dois ou o valor três; (iii) [4-5] cpfs cujo primeiro dígito assume o valor

quatro ou o valor cinco; (iv) [6-7] cpfs cujo primeiro dígito assume o valor seis ou o

valor sete; e (v) [8-9] cpfs cujo primeiro dígito assume o valor oito ou o valor nove.

Esses intervalos geram os predicados de seleção que são adicionados à consulta

original, o que resulta em cinco fragmentos virtuais. As consultas Q4 e Q5 apresentam

os fragmentos virtuais correspondentes ao quarto e quinto intervalos, respectivamente.

Q4: SELECT nome, e_mail

FROM cliente


AND (cpf LIKE ‘6%’ OR cpf LIKE ‘7%’)

29

Q5: SELECT nome, e_mail

FROM cliente


AND (cpf LIKE ‘8%’ OR cpf LIKE ‘9%’)

O operador LIKE usa os caracteres coringas _ ou %. O caracter _ (sublinhado)

indica que apenas um caracter pode ocupar aquela posição, seja ele qual for. O

caracter % (porcentagem) representa uma cadeia de caracteres de tamanho N, onde

N pode assumir qualquer valor maior ou igual a zero.

Após a geração dos fragmentos, estes são submetidos e processados em

paralelo pelos nós do agrupamento. Note que, durante o processamento, pode ocorrer

desbalanceamento de carga, uma vez que os diferentes fragmentos virtuais podem

implicar a varredura de diferentes quantidades de tuplas por parte dos nós. Para

melhor entendimento, consideremos que a relação cliente possui muitos clientes com

cpfs que se iniciam pelos dígitos com o valor um ou sete, porém poucos clientes com

cpfs que se iniciam pelos dígitos que assumem os demais valores. Desta maneira, os

dois nós que processam os intervalos [0-1] e [6-7] possuem maiores cargas de

trabalho se comparados aos outros três nós que processam os demais intervalos. Este

problema é uma limitação da FV, uma vez que a distribuição dos dados referentes ao

atributo de fragmentação é imprevisível. No entanto, este problema parece ser mais

grave nos casos em que a chave escolhida como o atributo de fragmentação virtual

não é um número inteiro, uma vez que atributos chave do tipo inteiro tendem a

assumir uma distribuição mais uniforme se comparados a atributos chave do tipo

string.

Além do desbalanceamento de carga ser mais severo em atributos de

fragmentação virtual do tipo string, este tipo de atributo também torna mais complexa a

definição dos intervalos. Para melhor compreensão, consideremos o mesmo exemplo

utilizado anteriormente, no entanto, suponhamos que o usuário deseja gerar dezesseis

fragmentos virtuais, ao invés de apenas cinco. Neste caso, não podemos analisar

somente o primeiro dígito do cpf, uma vez que existem somente dez possibilidades

para este. A análise do segundo dígito do cpf é necessária para a geração dos

intervalos, o que poderia gerar os seguintes fragmentos: (i) [00-15] cpfs cujos dois

primeiros dígitos estão entre os valores 00 e 15; (ii) [16-22] cpfs cujos dois primeiros

dígitos estão entre os valores 16 e 22; (iii) [23-37] cpfs cujos dois primeiros dígitos

estão entre 23 e 37 e, assim sucessivamente, até que os dezesseis intervalos tenham

sido gerados. Note que, neste caso, não há um algoritmo bem definido para a geração

dos intervalos, uma vez que não é possível estabelecer uma regra de divisão para os

30

dois primeiros dígitos dos cpfs entre os dezesseis intervalos. Assim, a ausência de um

algoritmo bem definido torna inviável a aplicação da FV em casos como o

exemplificado acima.

Nesta seção, vimos que a FV apresenta limitações no que se refere à escolha de

atributos de fragmentação virtual do tipo string. É importante ressaltar que atributos de

fragmentação do tipo inteiro também podem seguir uma distribuição não-uniforme dos

dados, visto que operações de inserção e exclusão de registros podem ser executadas

sobre qualquer relação do banco de dados, o que também poderia resultar em

desbalanceamento de carga. Porém, este desbalanceamento seria mais brando se

comparado aos casos em que o atributo de fragmentação assume valores do tipo

string. Visando a eliminar as limitações da FV, no que se refere ao desbalanceamento

de carga, surgiu a proposta da fragmentação virtual adaptativa que provê a geração de

pequenos fragmentos e torna possível a redistribuição dinâmica de carga.

3.3.3 Fragmentação virtual adaptativa A fragmentação virtual adaptativa (FVA) (LIMA et al., 2010) possui semelhanças

com a FV. No entanto, possui duas fases adicionais que permitem controlar o tamanho

dos fragmentos e a carga de trabalho dos nós. A FVA é composta por quatro fases: (i)

fragmentação virtual inicial; (ii) ajuste dos tamanhos dos fragmentos; (iii) redistribuição

dinâmica de carga; e (iv) encerramento. A fragmentação virtual inicial consiste da

geração dos fragmentos virtuais iniciais de mesmo tamanho, considerando o intervalo

de valores do AFV, como ocorre na FV, e da distribuição destes fragmentos para cada

nó do agrupamento. Em seguida, as sub-consultas são processadas pelos nós e o

tamanho de cada fragmento é ajustado de acordo com o monitoramento do tempo de

execução das sub-consultas definidas pelos fragmentos virtuais. Nesta fase, o

fragmento virtual inicial recebido por cada nó é dividido em partes menores, as quais

chamaremos de fragmentos secundários. Inicia-se com um tamanho muito pequeno e

este vai sendo aumentado gradativamente a cada execução, até que o aumento no

tempo de execução com o novo fragmento não seja proporcionalmente menor que o

tempo de execução da sub-consulta no fragmento anterior. Quando isso ocorrer, um

tamanho estável foi encontrado. A Figura 3.2 mostra a fase de ajuste dos tamanhos

dos fragmentos, adotada na fragmentação virtual adaptativa.

31

Nó mediador submete fragmento original (FV)

Nó deprocessamento

inicia a FVA

Especificaintervalo

inicial

Monitoratempo deexecução

Verifica limite do

fragmento original

É o limite final do intervalo

original?Sim

Não

Finalizaprocesso da FVA

Verifica deterioração de desempenho

Houve deterioração?

Sim

Não

Diminui tamanho dofragmento

Verifica aumento dotempo de execução

É proporcionalmente menorque o tempo anterior?

Não

Sim

Aumentatamanho dofragmento

Mantém o tamanho do fragmento

Processa fragmento

virtual atual

Figura 3.2: Fragmentação virtual adaptativa no agrupamento de banco de dados.

A etapa de redistribuição busca evitar o desbalanceamento de carga, pois

permite que um nó do agrupamento distribua alguns de seus fragmentos secundários

a nós vizinhos que já tenham concluído seu trabalho e estejam disponíveis. Por último,

a fase de encerramento é executada pelo nó mediador que verifica se todas as sub-

consultas foram processadas, solicitando o encerramento das atividades por parte dos

demais nós e realizando a composição do resultado final. Com a redistribuição de

carga, a FVA apresentou aceleração super-linear ou linear na maior parte das

consultas de aplicações OLAP, fornecidas pelo benchmark TPC-H, que foram

utilizadas no experimento realizado por Lima et al. (2010).

3.3.4 Fragmentação virtual híbrida Além das propostas que adotam apenas a fragmentação virtual, encontramos na

literatura uma solução que adota a FV e a fragmentação física dos dados de forma

combinada, visando potencializar os benefícios de ambas as abordagens. Em (LIMA et

al., 2009), esta abordagem híbrida é adotada em um ambiente de armazém de dados,

o qual é utilizado para processar consultas OLAP. Nesse trabalho, a fragmentação

32

virtual híbrida é implementada da seguinte maneira: a fragmentação física dos dados é

aplicada sobre as tabelas de fatos. Os fragmentos gerados são replicados

parcialmente, em oposição à abordagem tradicional sem replicação de dados, a qual

aloca cada fragmento a um único nó do agrupamento. Por outro lado, as tabelas de

dimensões são replicadas em todos os nós, oferecendo maior flexibilidade de escolha

dos nós para a execução das sub-consultas. A FVA é utilizada para prover o

paralelismo intra-consulta e realizar a redistribuição dinâmica de carga. Assim, a

combinação de ambas as técnicas de fragmentação, tanto a física quanto a virtual,

minimiza a utilização de espaço em disco, pois não utiliza a replicação total da base de

dados, mas apenas de alguns dos fragmentos físicos gerados, e mantém a

flexibilidade e o balanceamento de carga característicos da FVA.

Nesta seção, apresentamos três estratégias distintas para obter mais

desempenho em consultas OLAP, segundo a estratégia da fragmentação virtual.

Segundo Mattoso (2009a), a fragmentação virtual mostra-se como uma solução

promissora para a implementação do paralelismo intra-consulta em agrupamento de

banco de dados, pois independe do tipo da consulta a ser realizada, já que não é

possível prever a consulta a ser executada em ambientes de suporte à decisão,

caracterizados por consultas analíticas ad-hoc. Além disso, a FV provê maior

flexibilidade na escolha dos nós para execução das sub-consultas, uma vez que esta

técnica adota a replicação da base de dados, seja esta a replicação parcial ou a

replicação total.

Na próxima seção, apresentamos algumas dentre as propostas de solução

existentes na literatura que adotam a fragmentação virtual de dados. As soluções

discutidas a seguir buscam obter melhor desempenho em consultas de alto custo

sobre bancos de dados relacionais.

3.4 Soluções de alto desempenho baseadas na fragmen tação virtual de dados Na literatura, existem diversas soluções para a otimização do desempenho de

consultas em agrupamentos de bancos de dados. No modelo relacional, destacamos

quatro propostas de solução que adotam a fragmentação virtual de dados: o PowerDB

(AKAL et al., 2002) que se baseia na fragmentação virtual; o Pargres (MATTOSO et

al., 2005) que utiliza a fragmentação virtual adaptativa; uma proposta de fragmentação

virtual para a paralelização do algoritmo BLAST (SOUSA et al., 2008) segundo a

fragmentação virtual adaptativa; e, por último, o SmaQSS (FURTADO et al., 2005),

que adota a técnica da fragmentação virtual híbrida.

33

3.4.1 PowerDB O PowerDB é uma camada intermediária entre a aplicação cliente e os SGBDs

no agrupamento de banco de dados que provê o processamento paralelo de consultas

através da fragmentação virtual de dados. Na proposta de Akal et al. (2002), o

PowerDB provê o paralelismo intra-consulta através da fragmentação virtual com

replicação total da base de dados. Porém, esta proposta apresenta limitações no que

tange ao balanceamento de carga e à distorção dos dados, pois assume que os

valores do atributo de fragmentação seguem uma distribuição uniforme.

Considerando a proposta de Röhm et al. (2000), o PowerDB é utilizado em um

ambiente de armazém de dados, segundo a técnica da fragmentação híbrida, na qual

as tabelas de fatos são fragmentadas fisicamente e os fragmentos gerados são

alocados a diferentes nós do agrupamento. As tabelas de dimensões, por sua vez, são

replicadas em todos os nós do agrupamento. Esta abordagem provê melhor

aproveitamento da capacidade de armazenamento dos nós, visto que a replicação

total de dados pode ser inviável nos casos em que a base de dados é muito extensa.

Apesar de estar relacionada ao PowerDB, esta abordagem é anterior à de Akal et al.

(2002) e não adota a fragmentação virtual de dados, uma vez que as tabelas são

fragmentadas fisicamente.

3.4.2 Pargres O Pargres (MATTOSO et al., 2005) é um software livre desenvolvido como um

middleware entre a aplicação e os SGBDs instalados nos nós do agrupamento, para

auxiliar no processamento paralelo de consultas de aplicações OLAP. O Pargres

implementa o paralelismo intra-consulta utilizando a técnica da fragmentação virtual

adaptativa com replicação total de dados. Além do paralelismo intra-consulta, o

Pargres também implementa o paralelismo inter-consulta e permite atualizações na

base de dados. Para isso, o nó coordenador verifica a necessidade de se combinar o

paralelismo inter ao intra-consulta, de acordo com a consulta submetida, e possui um

escalonador responsável por estabelecer a ordem das operações e por bloquear todas

as operações no agrupamento no momento em que uma atualização é iniciada.

3.4.3 Aplicação do paralelismo intra-consulta ao al goritmo BLAST

Em (SOUSA et al., 2008), encontramos uma solução baseada no conceito da

FVA, porém, aplicada à área de bioinformática, através da paralelização do algoritmo

BLAST (Basic Local Alignment Search Tool). O BLAST pertence à família de

algoritmos utilizados na biologia molecular para realizar a comparação entre

34

sequências biológicas e operações de alinhamento (COSTA, 2002). Este algoritmo

caracteriza-se pela análise de uma grande massa de dados e por um número elevado

de operações de comparação entre diferentes sequências, o que resulta em um longo

tempo de processamento. Na proposta de Sousa et al. (2008), técnicas baseadas na

fragmentação virtual adaptativa são utilizadas para prover a execução paralela e

distribuída do algoritmo BLAST. A base de dados é totalmente replicada nos nós do

agrupamento. Além da replicação total da base de dados, a fragmentação física é

aplicada sobre esta mesma base de dados, o que gera fragmentos físicos nos nós

envolvidos. Cada nó do agrupamento recebe uma tarefa distinta, a qual consiste em

realizar a comparação e o alinhamento sobre uma dada sequência biológica, através

da consulta aos fragmentos físicos gerados. A distribuição das tarefas é baseada na

abordagem mestre/escravo, onde um nó (nó mestre) distribui as tarefas aos nós

responsáveis pelo processamento (nós escravos). Após o término da execução da

tarefa, cada nó verifica se há tarefas disponíveis, o que provê o balanceamento de

carga, uma vez que os nós processam novas tarefas, à medida que concluem as

tarefas correntes. Por último, após o término da execução de todas as tarefas, o nó

mestre compõe o resultado final através da união dos resultados parciais obtidos.

3.4.4 SmaQSS O SmaQSS é uma proposta de solução que une a FVA à fragmentação física

de dados, a fim de se obter o paralelismo intra-consulta e evitar a replicação total da

base de dados, o que pode ser inviável devido a limitações de capacidade de

armazenamento dos nós e ao tamanho da base de dados. Em (FURTADO et al.,

2005), a fragmentação virtual híbrida é utilizada no contexto de armazém de dados,

onde as tabelas de fatos, por apresentarem grandes volumes de dados, são

fragmentadas fisicamente, enquanto as tabelas menores, isto é, as tabelas de

dimensões, são replicadas em todos os nós da rede. O atributo de fragmentação

virtual a ser utilizado para geração dos fragmentos virtuais é o mesmo atributo

utilizado na fragmentação física das tabelas de fatos. No que se refere à flexibilidade

de escolha dos nós durante o processamento das consultas e, consequentemente, ao

balanceamento de carga, o SmaQSS adota a replicação parcial dos fragmentos das

tabelas de fatos através do armazenamento de réplicas em nós que são adjacentes ao

nó que contém a cópia primária do fragmento físico gerado.

3.5 Considerações finais Entre as propostas de solução para o processamento de consultas analíticas ad-

hoc, a fragmentação virtual tem sido a abordagem mais adotada, pois provê maior

35

flexibilidade se comparada à fragmentação física dos dados e evita a adaptação do

ambiente, através de um novo projeto de distribuição de dados, para atender a um

novo conjunto de consultas. Além disso, a FV oferece um mecanismo simples para a

geração de sub-consultas a partir da consulta original, pois utiliza apenas a adição de

novos predicados de seleção de acordo com o atributo de fragmentação escolhido,

com as faixas de valores que ele pode assumir e com o número de nós de

processamento a ser reservado. No que se refere ao ambiente escolhido,

agrupamentos de banco de dados têm sido uma solução frequentemente adotada,

pois oferecem escalabilidade e tolerância a falhas, garantindo a disponibilidade do

serviço em caso de falha de um nó de processamento.

Embora a FV apresente melhorias no ganho de desempenho de consultas que

demandam longo tempo de processamento, vimos que esta abordagem pode

ocasionar a subutilização de índices durante o processamento das consultas e o

desbalanceamento de carga entre os nós do agrupamento, pois assume que as tuplas

das relações seguem uma distribuição uniforme, o que, em geral, não ocorre na

realidade. As soluções que utilizam a replicação total da base de dados apresentam

maior custo se comparadas às soluções baseadas na replicação parcial. Isso acontece

pois, dependendo do tamanho da base de dados, o custo de armazenamento de todas

as réplicas pode ser inviável. No entanto, considerando a flexibilidade e a

disponibilidade dos nós, a replicação total é a abordagem que provê o maior benefício.

Isto se deve ao fato de que em caso de falha de um nó, uma réplica da base de dados

pode ser acessada em qualquer outro nó da rede para prosseguir com a execução da

consulta corrente. Assim, analisando esta relação custo/benefício das soluções de alto

desempenho que adotam a fragmentação virtual, e as propostas para o

processamento de consultas XML em um ambiente distribuído mencionadas na Seção

2.4, esta dissertação propõe a adaptação da FV (AKAL et al., 2002) ao modelo XML

com replicação total da base de dados. A arquitetura distribuída sob o controle de um

nó mediador (FIGUEIREDO et al., 2010) é utilizada para prover a validação das

consultas de entrada, a geração das sub-consultas e a composição do resultado final.

Nosso objetivo é avaliar os benefícios da fragmentação virtual e, posteriormente,

investigar a abordagem adaptativa.

Vimos que, em geral, a fragmentação virtual de dados utiliza a chave primária da

relação envolvida como o atributo de fragmentação. Assim, a adaptação da FV ao

modelo XML não é trivial, uma vez que o conceito de chave nem sempre está presente

em bancos de dados XML. Apesar de ser possível a definição de chaves no modelo

semi-estruturado, por meio da instrução key em esquemas XML (FALLSITE;

36

WALMSLEY, 2004), não podemos garantir que todos os documentos XML do banco

de dados contemplem este tipo de restrição. No próximo capítulo, apresentamos a

nossa proposta de solução e descrevemos os conceitos relacionados à estrutura de

documentos XML e a restrições de unicidade em esquemas XML.

37

4 Metodologia para a aplicação da fragmentação virt ual sobre bancos de dados XML

No Capítulo 3, vimos que a fragmentação virtual tem se mostrado como a

técnica mais adequada para consultas analíticas ad-hoc. Apesar de essa técnica ter

sido adotada em diversas soluções sobre SGBDs relacionais, não encontramos

propostas na literatura que indiquem iniciativas de se aplicar esta solução ao ambiente

de consultas XML distribuídas. Nesta dissertação, adaptamos a fragmentação virtual

para o modelo XML com o objetivo de obter melhor desempenho em consultas

analíticas XML ad-hoc. A adaptação desta técnica para o modelo XML não é trivial,

devido à estrutura dos documentos XML e ao conceito de chave, que nem sempre

está definido sobre todos os documentos do banco de dados.

Na Seção 4.1 discutimos aspectos relacionados à estrutura de esquemas XML e

definimos o exemplo que será utilizado neste capítulo. Na Seção 4.2, apresentamos a

nossa estratégia para a geração dos fragmentos virtuais sobre bases de dados XML.

Os aspectos relacionados à composição dos resultados são detalhados na Seção 4.3.

Por último, na Seção 4.4 apresentamos as considerações finais sobre a fragmentação

virtual no modelo XML.

4.1 Exemplo de bases de dados XML Nesta seção, discutimos as características de bases de dados XML e definimos

a estrutura do documento XML que será utilizado em todos os exemplos contidos

neste capítulo. Com o objetivo de auxiliar o leitor na compreensão dos exemplos,

apresentamos os conceitos relacionados a elementos e atributos chave, e a esquemas

XML.

Considerando bancos de dados relacionais, vimos que, em geral, os atributos

que compõem as chaves primárias das relações são escolhidos como atributos de

fragmentação. Os bancos de dados XML, por sua vez, podem conter documentos que

não possuem atributos chave definidos. No entanto, apesar de não ser obrigatório,

documentos XML podem conter restrições de unicidade declaradas em seu esquema,

previamente definido pelo usuário. Elementos e atributos identificadores podem ser

declarados em um esquema XML (FALLSITE; WALMSLEY, 2004) através do tipo ID, o

qual estabelece que o valor do elemento ou atributo que tem este tipo deve ser único

em todo o documento XML. Embora o tipo ID possa ser utilizado, sua utilidade prática

em documentos XML maiores é bastante reduzida, pois nestes casos, a probabilidade

de elementos ou atributos distintos, porém do mesmo tipo ID, assumirem o mesmo

38

valor é alta, o que infringe a unicidade estabelecida. Considerando esta limitação, é

desejável que o usuário possa estabelecer a unicidade dos valores dentro de um

determinado escopo, o que é possível com a declaração de restrições xs:unique ou

xs:key de XML Schema (FALLSITE; WALMSLEY, 2004).

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="compraEletronica" type="TcompraEletronica">

<xs:keyref name="pedidoRef" refer="pedidoId">

<xs:selector xpath="parcelasPedidos/parcelaPedido"/>

<xs:field xpath="@pedidoRef"/>

</xs:keyref>

<xs:keyref name="clienteRef" refer="clienteId">

<xs:selector xpath="pedidos/pedido"/>

<xs:field xpath="@clienteRef"/>

</xs:keyref>

</xs:element>

<xs:complexType name="TcompraEletronica">

<xs:sequence>

<xs:element name="clientes" type="TClientes">

<xs:key name="clienteId">

<xs:selector xpath="cliente"/>

<xs:field xpath="@id"/>

</xs:key>

</xs:element>

<xs:element name="pedidos" type="TPedidos">

<xs:key name="pedidoId">

<xs:selector xpath="pedido"/>


</xs:key>

</xs:element>

<xs:element name="parcelasPedidos" type="TparcelasPedidos">

<xs:key name="parcelaId">

<xs:selector xpath="parcelaPedido"/>


</xs:key>

</xs:element>

</xs:sequence>

</xs:complexType>

...

</xs:schema>

Figura 4.1: Declaração de restrições xs:key e xs:keyref em um esquema XML.

As restrições xs:unique e xs:key são compostas pelos sub-elementos selector e

field que indicam, respectivamente, os elementos a serem verificados e o elemento ou

atributo que deve ter valor único dentro do escopo definido. Apesar da similaridade

semântica entre ambas as restrições, apenas elementos declarados como xs:key

podem ser referenciados por xs:keyref. A Figura 4.1 apresenta um exemplo de

esquema XML que declara os tipos xs:key e xs:keyref para elementos/atributos de um

documento XML, cuja especificação está indicada em negrito.

39

No esquema indicado, o elemento compraEletronica possui duas restrições

xs:keyref que referenciam pedidoId e clienteId que, por sua vez, estão declarados

como restrições xs:key para que a referência seja válida. O elemento

compraEletronica é do tipo TCompraEletronica que, por sua vez, possui os sub-

elementos clientes, pedidos e parcelasPedidos que fornecem informações a respeito

de clientes, pedidos e parcelas referentes aos pedidos realizados, respectivamente.

Cada elemento cliente, pedido e parcelaPedido é identificado por seu atributo id, cujo

valor deve ser único dentro do escopo de compraEletronica, devido à restrição xs:key

declarada. Consideremos que os clientes possuem identificadores únicos e são

descritos por informações pessoais, os pedidos descrevem os dados da compra e as

parcelas dos pedidos especificam informações dos pagamentos. A Figura 4.2

apresenta a definição dos sub-elementos TCliente e TPedido que contêm os atributos

chave e de referência, os quais estão especificados em negrito. A Figura 4.3

apresenta a definição do elemento TParcelasPedidos.

<xs:complexType name="TClientes">

<xs:sequence>

<xs:element name="cliente" type="TCliente" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="TPedidos">

<xs:sequence>

<xs:element name="pedido" type="TPedido" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="TCliente">

<xs:sequence>

<xs:element name="cpf" type="xs:string"/>

<xs:element name="nome" type="xs:string"/>

<xs:element name="data_nasc" type="xs:string"/>

<xs:element name="e_mail" type="xs:string"/>

</xs:sequence>

<xs:attribute name="id" type="xs:integer" use="required"/>

</xs:complexType>

<xs:complexType name="TPedido">

<xs:sequence>

<xs:element name="preco_total" type="xs:double"/>

<xs:element name="qtde_parc" type="xs:integer"/>

<xs:element name="parc_rest" type="xs:integer"/>

<xs:element name="data_comp" type="xs:date"/>

</xs:sequence>


<xs:attribute name="clienteRef" type="xs:integer" use="required"/>

</xs:complexType>

Figura 4.2: Definição dos tipos TClientes e TPedidos.

40

<xs:complexType name="TParcelasPedidos">

<xs:sequence>

<xs:element name="parcelaPedido" type="TParcelaPedido" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="TParcelaPedido">

<xs:sequence>

<xs:element name="data_venc" type="xs:date"/>

<xs:element name="valor_parcela" type="xs:double"/>

<xs:element name="mes_referencia" type="xs:string"/>

<xs:element name="situacao_parc" type="xs:string"/>

</xs:sequence>

<xs:attribute name="pedidoRef" type="xs:integer" use="required"/>


</xs:complexType>

Figura 4.3: Definição do tipo TParcelasPedidos.

Apresentamos na Figura 4.4 um documento XML válido segundo o esquema

descrito. Note que o atributo clienteRef referencia as chaves dos elementos cliente

(atributo id).

<?xml version="1.0" encoding="UTF-8"?>

<compraEletronica>

<clientes>

<cliente id="1081">

<cpf>616.227.381-44</cpf>

<nome>Vanessa Carla Felipe Gonçalves</nome>

<data_nasc>1984-04-25</data_nasc>

<e_mail>[email protected]</e_mail>

</cliente>

<cliente id="20354">

<cpf>036.091.012-29</cpf>

<nome>Carla Amaral de S Rodrigues</nome>



</cliente> ... </clientes>

<pedidos>

<pedido id="120" clienteRef="1081">

<preco_total>150.00</preco_total>

<qtde_parcelas>2</qtde_parcelas>

<parc_rest>1</parc_rest>

<data_comp>2010-09-12</data_comp>

</pedido>






</pedido> ... </pedidos>

<parcelaPedidos> ... </parcelaPedidos>

</compraEletronica>

Figura 4.4: Documento XML válido contendo as informações dos clientes e dos pedidos.

Da mesma forma que os pedidos armazenam referências para os clientes, os

elementos parcelaPedido armazenam referências para os respectivos pedidos, como

mostra a Figura 4.5.

41

<compraEletronica> ...

<parcelasPedidos>

<parcelaPedido id="152001" pedidoRef="120">

<data_venc>2010-09-15</data_venc>

<valor_parcela>75.00</valor_parcela>

<mes_referencia>09/2010</mes_referencia>

<situacao_parc>paga</situacao_parc>

</parcelaPedido>





<situacao_parc>aguard. pagto</situacao_parc>

</parcelaPedido>





<situacao_parc>inadimplente</situacao_parc>

</parcelaPedido>





<situacao_parc>aguard.pagto</situacao_parc>

</parcelaPedido>






</parcelaPedido>

...

</parcelasPedidos>

</compraEletronica>

Figura 4.5: Informações das parcelas relacionadas aos pedidos dos clientes.

Apesar de ser possível definir restrições que assegurem a unicidade de

elementos/atributos em documentos XML, nem sempre eles são utilizados por

documentos encontrados em bancos de dados reais. Este é um obstáculo que deve

ser superado pela abordagem proposta nesta dissertação, a qual apresenta uma

solução de alto desempenho baseada na FV para bases de dados XML.

4.2 Fragmentação virtual sobre bancos de dados XML A adaptação da fragmentação virtual ao modelo XML não é trivial, visto que a

estrutura dos dados semi-estruturados torna a geração dos fragmentos virtuais mais

complexa. Vimos, anteriormente, que a ausência de atributos chave em documentos

XML e a escolha de atributos de fragmentação do tipo string podem inviabilizar a

aplicação da FV no contexto de bancos de dados XML distribuídos. Em bancos de

dados relacionais, atributos que compõem a chave primária das relações são

escolhidos para determinar os intervalos dos fragmentos virtuais. Já em bancos de

dados XML, os documentos são compostos por elementos e atributos, e, apesar de

ser possível definir restrições de unicidade, como detalhamos na Seção 4.1, nem

todos os esquemas XML especificam uma chave para os documentos que seguem

aquele esquema. Desta forma, a escolha de atributos de fragmentação não pode ser

realizada de forma simples se comparada à estratégia adotada para bancos de dados

relacionais. Do mesmo modo, a identificação do intervalo de valores que os

elementos/atributos podem assumir também não é trivial, principalmente quando se

trata de elementos/atributos do tipo string.

42

Considerando o modelo XML distribuído, os principais desafios são: a seleção do

atributo de fragmentação, a decomposição da consulta original em sub-consultas, de

acordo com o atributo de fragmentação escolhido, e a composição do resultado final.

Visando a eliminar essas limitações da FV, nossa proposta de solução se baseia em

uma estratégia independente de atributos chave e do tipo do atributo de fragmentação

virtual. Para isso, a estratégia adotada para a geração dos fragmentos virtuais se

baseia na posição dos elementos no documento XML, o que pode ser obtido através

da função position() (MALHOTRA et al., 2010). Essa função retorna a posição do

elemento corrente em um dado documento XML. As posições dos elementos são

utilizadas para criar os predicados de seleção correspondentes aos diferentes

fragmentos virtuais, como mostra o exemplo na Figura 4.6

<compraEletronica>

<clientes>

<cliente id="1081">

<cpf>616.227.381-44</cpf>

<nome>Vanessa Carla Felipe Gonçalves</nome>



</cliente>

<cliente id="20354">

<cpf>036.091.012-29</cpf>

<nome>Carla Amaral de S Rodrigues</nome>



</cliente>

... </clientes>

<pedidos>






</pedido>

... </pedidos>

<parcelasPedidos>






</parcelaPedido>

...</parcelasPedidos>

</compraEletronica>

cliente[position()=1]

cliente[position()=2]

pedido[position()=1]

parcelaPedido[position()=1]

Figura 4.6: Retorno da função XPath position().

O primeiro passo da FV é a escolha do atributo de fragmentação virtual. Nossa

estratégia para identificar um candidato a atributo de fragmentação se baseia em um

43

relacionamento 1:N. Isto significa que o AFV é um elemento XML contido na consulta

de entrada, o qual aparece N vezes no documento XML envolvido. Além disso, o AFV

possui um elemento pai que aparece uma única vez no documento. Esta estratégia

permite a seleção automática do atributo de fragmentação virtual, cuja definição é

apresentada a seguir.

Definição 4.1 (atributo de fragmentação virtual no modelo XML) Dada uma

consulta XQuery Q que contém um conjunto de cláusulas for/let {F1, F2, ..., Fn}, e os

caminhos XPath especificados nestas cláusulas, um atributo de fragmentação virtual,

denominado Afv, é um elemento ou atributo contido em um destes caminhos XPath,

onde Afv apresenta cardinalidade c, c > 1, no documento XML envolvido, e possui um

elemento pai, cuja cardinalidade, neste mesmo documento, assume o valor um.

Após a escolha do AFV, os fragmentos virtuais são gerados de acordo com a

cardinalidade do AFV e com o número de nós do agrupamento reservados para o

processamento das sub-consultas. Para isso, dividimos a cardinalidade do AFV pelo

número de nós alocados, a fim de gerar intervalos com faixas de valores disjuntas,

porém, de tamanhos iguais para cada nó de processamento. Os predicados de

seleção são gerados por meio da utilização da função position(), a qual é adicionada

como um filtro de uma expressão XPath. Este filtro define os elementos XML a serem

processados por cada nó do agrupamento. Assim, dado um AFV e a quantidade de

nós reservados para o processamento das sub-consultas, a geração de fragmentos

virtuais pode ser definida como segue.

Definição 4.2 (geração de fragmentos virtuais no mo delo XML) Dada uma

consulta XQuery Q, um atributo de fragmentação Afv com cardinalidade c, onde c > 1,

e um conjunto de N nós a serem alocados para o processamento dos fragmentos, o

tamanho dos intervalos, denominado Tin, se dá pela divisão de c por N, e o processo

de geração de fragmentos virtuais resulta em predicados de seleção na forma

Afv[position() >= n1 and position() < n2], onde n2-n1 é igual a Tin.

A aplicação da FV sobre consultas sem operações de junção relacionadas a

bases de dados SD envolve os seguintes passos: (i) a validação da consulta original;

(ii) a seleção do atributo de fragmentação virtual segundo a Definição 4.1; e (iii) a

geração dos fragmentos virtuais de acordo com a Definição 4.2. Por outro lado,

consultas com operações de junção envolvem a consulta ao documento armazenado

na base de dados, a fim de verificar a cardinalidade dos elementos envolvidos em

ambos os lados da junção. Esta consulta à base de dados é necessária para permitir a

44

seleção de um, e somente um, atributo de fragmentação, uma vez que cada cláusula

for resulta em um candidato a atributo de fragmentação diferente.

Em nosso exemplo, o elemento cliente pode estar associado a N elementos

pedido, uma vez que cada cliente pode ter vários pedidos. Assim, cliente é o elemento

primário, o qual é referenciado por pedido que, por sua vez, é o elemento secundário.

Em consultas com uma única junção, somente o elemento primário pode ser

selecionado como o AFV. O elemento primário possui menor cardinalidade se

comparado ao elemento secundário. Desta forma, analisamos os caminhos XPath de

ambos os lados da junção. O caminho XPath que apresentar a menor cardinalidade se

refere ao elemento primário e, por isso, indica o único caminho XPath a ser analisado

no processo de seleção do atributo de fragmentação. Porém, se a consulta de entrada

possuir mais de uma operação de junção, isto é, vários elementos primários

envolvidos, somente o elemento primário que apresentar a menor cardinalidade será

selecionado como o AFV.

Consultas a bases de dados MD são mais complexas se comparadas a

consultas a bases SD, uma vez que os documentos de uma coleção são processados

individualmente. Desta maneira, se a estratégia de geração de fragmentos virtuais for

aplicada diretamente sobre a consulta de entrada, isso pode causar

desbalanceamento de carga. Para eliminar este problema, as consultas de entrada

sobre bases de dados MD são reformuladas, a fim de gerar uma consulta

intermediária sobre a qual a FV é aplicada. A consulta intermediária contém a união

dos documentos contidos na coleção original, o que permite o processamento de um

documento completo que contém a coleção como um todo. Além disso, a

cardinalidade usada na geração dos fragmentos é a soma das cardinalidades do AFV,

considerando a coleção como um todo.

Na próxima seção, voltamos a discutir os conceitos aqui apresentados, porém,

de forma mais detalhada. As Seções 4.2.1 e 4.2.2 apresentam a estratégia utilizada

para a geração de fragmentos virtuais sobre consultas a bases de dados SD e bases

de dados MD, respectivamente. Para melhor compreensão, a estratégia utilizada e os

passos do algoritmo adotado são apresentados com exemplos ilustrativos,

considerando consultas XML especificadas na linguagem XQuery.

4.2.1 Consultas a bases de dados SD Consultas a bases de dados SD são formuladas com a cláusula doc(). Para

aplicar a FV sobre este tipo de consulta, analisamos a consulta de entrada para

45

selecionar o atributo de fragmentação virtual, identificamos os intervalos e, por último,

geramos os fragmentos virtuais de acordo com os respectivos predicados de seleção.

Nosso algoritmo para aplicar a FV recebe dois parâmetros de entrada: (i) a

consulta XQuery que o usuário deseja processar, e (ii) um número inteiro que indica a

quantidade de fragmentos virtuais que deve ser gerada, a qual corresponde ao

número de nós do agrupamento que o usuário deseja reservar para o processamento

dos fragmentos.

Como exemplo, consideremos o esquema apresentado nas Figuras 4.1, 4.2 e

4.3 e a consulta XQuery apresentada na Figura 4.7, a qual acessa o documento

compraEletronica.xml e retorna os nomes e os e-mails de todos os clientes cujos e-

mails terminam com a string @cos.ufrj.br. Suponhamos também que o usuário deseja

gerar quatro fragmentos virtuais para a consulta de entrada.

<results> {

for $cli in doc('compraEletronica.xml')//cliente

where ends-with($cli/e_mail, '@cos.ufrj.br')

return

<cliente> {$cli/nome}

{$cli/e_mail}

</cliente>

} </results>

Figura 4.7: Consulta XQuery de entrada.

Dada a consulta XQuery e o esquema XML do documento envolvido, a seleção

do atributo de fragmentação virtual consiste em encontrar um relacionamento 1:N

entre os elementos XML. O primeiro passo é a obtenção dos caminhos XPath contidos

em cláusulas for/let da consulta de entrada. Em nosso exemplo, há somente o

caminho XPath //cliente. Por se tratar de um caminho que utiliza o operador “//”, o

algoritmo realiza uma consulta à base de dados para obter o caminho completo até o

elemento cliente, o que retorna o caminho compraEletronica/clientes/cliente. Em

seguida, verificamos a cardinalidade do elemento pai clientes e do elemento filho

cliente, a fim de analisar se há um relacionamento 1:N entre eles. No exemplo

apresentado, o elemento clientes aparece somente uma vez no documento

compraEletronica.xml, enquanto o elemento cliente aparece N vezes, onde N > 1, o

que satisfaz a condição necessária para ser um elemento candidato a atributo de

fragmentação virtual. Como não há outros candidatos a AFV, uma vez que a consulta

de entrada não possui operações de junção, o elemento cliente é escolhido como o

atributo de fragmentação virtual.

46

Após a escolha do AFV, é necessário definir o tamanho dos fragmentos a serem

gerados, assim como o início e o fim destes intervalos. Visto que o elemento cliente é

o AFV, o algoritmo realiza uma consulta à base de dados, a fim de obter a

cardinalidade do AFV. Considerando que este atributo possui cardinalidade 200.000 e

quatro fragmentos virtuais devem ser gerados, o tamanho dos intervalos é resultante

da divisão de 200.000 por quatro, o que retorna o valor 50.000. Desta maneira, o

algoritmo gera os seguintes intervalos: (i) [1; 50001[, que define os elementos cliente

cuja posição varia de 1 a 50.000; (ii) [50001; 100001[ que representa os elementos

cliente cuja posição varia de 50.001 a 100.000; (iii) [100001; 150001[ que indica os

elementos cliente cuja posição varia de 100.001 a 150.000; e (iv) [150001; 200001[

que indica os elementos cliente cuja posição varia de 150.001 a 200.000. Observe que

os intervalos definidos incluem somente um dos extremos, uma vez que o fim dos

intervalos é aberto.

Por último, os predicados de seleção correspondentes a cada um dos intervalos

são adicionados como filtros de expressões XPath na consulta de entrada, o que gera

os fragmentos virtuais. A Figura 4.9 exibe os quatro fragmentos virtuais gerados.

Consultas que envolvem operações de junção necessitam de uma fase adicional

que envolve a consulta à base de dados. O objetivo é verificar o caminho XPath que

contém o elemento primário de menor cardinalidade. Para melhor compreensão,

consideremos uma consulta XQuery que envolve uma operação de junção como

apresentada na Figura 4.8.

<results> {

for $cli in

doc('compraEletronica.xml')/compraEletronica/client es/cliente

for $ped in

doc('compraEletronica.xml')/compraEletronica/pedido s/pedido

where $ped/@clienteRef = $cli/@id

and $ped/parc_rest > 0

return

<cliente>

{$cli/nome}

{$ped/parc_rest}

</cliente>

} </results>

Figura 4.8: Consulta XQuery envolvendo uma operação de junção.

47

<results> {

for $cli in doc('compraEletronica.xml')// cliente [position() >= 1

and position() < 50001]


return


{$cli/e_mail}

</cliente>}

</results>

(a) Fragmento correspondente ao intervalo [1; 50001[.

<results> {

for $cli in doc('compraEletronica.xml')// cliente [position() >= 50001



return


{$cli/e_mail}

</cliente>}

</results>

(b) Fragmento correspondente ao intervalo [50001; 100001[.

<results> {

for $cli in doc('compraEletronica.xml')// cliente[position() >= 100001



return


{$cli/e_mail}

</cliente>}

</results>

(c) Fragmento correspondente ao intervalo [100001; 150001[.

<results> {

for $cli in doc('compraEletronica.xml')// cliente[position() >= 150001



return


{$cli/e_mail}

</cliente>}

</results>

(d) Fragmento correspondente ao intervalo [150001; 200001[.

Figura 4.9: Fragmentos virtuais gerados após aplicar a FV.

48

A consulta apresentada na Figura 4.8 possui duas cláusulas for, as quais são

utilizadas para construir uma operação de junção, através da expressão where

$ped/@clienteRef = $cli/@id. Essa expressão indica os caminhos XPath que precisam

ser analisados, a fim de identificar qual lado da junção corresponde ao elemento

primário e ao elemento secundário. Para isso, obtemos as variáveis $cli e $ped

envolvidas na junção. Em seguida, substituímos as variáveis por seus caminhos

XPath, o que resulta nos caminhos compraEletronica/clientes/cliente e

compraEletronica/pedidos/pedido, respectivamente. Por fim, realizamos uma consulta

sobre o documento compraEletronica.xml, a fim de obter as cardinalidades dos

caminhos XPath compraEletronica/clientes/cliente e compraEletronica/pedidos/pedido.

No cenário descrito, um cliente pode ter vários pedidos e, por isso, a cardinalidade do

elemento cliente é menor que a cardinalidade do elemento pedido. Logo, cliente é o

elemento primário e o algoritmo de seleção do atributo de fragmentação analisa

somente o caminho XPath indicado pela variável $cli. Note que não é necessário que

o documento XML possua um esquema XML associado com as definições das chaves

primárias e de referência. A verificação da cardinalidade dos elementos envolvidos na

junção é suficiente para indicar qual deles se refere ao elemento primário. Isto se deve

ao fato de que os elementos primários possuem menor cardinalidade se comparados

aos elementos secundários.

No exemplo apresentado, há somente uma operação de junção. No entanto, as

consultas de entrada podem conter inúmeras operações de junção, uma vez que as

consultas são ad-hoc e, por isso, não é possível prever a quantidade de operações de

junção que a consulta de entrada irá conter. A estratégia para analisar consultas com

mais de uma operação de junção é bastante semelhante à explicitada anteriormente,

uma vez que os caminhos XPath definidos em ambos os lados das expressões de

junção também devem ser consultados na base de dados. A diferença está no fato de

que existirá mais de um caminho XPath que contém um elemento primário. A

cardinalidade desses caminhos deve ser analisada para identificar qual destes deve

ser utilizado para a seleção do atributo de fragmentação. O caminho que apresentar a

menor cardinalidade é o escolhido. Como exemplo, consideremos a consulta XQuery

apresentada na Figura 4.10, a qual contém duas operações de junção.

No exemplo descrito, identificamos duas expressões que caracterizam as

junções: $ped/@clienteRef=$cli/@id e $par/@pedidoRef=$ped/@id. Em seguida, os

valores das variáveis $ped, $cli e $par são substituídos, a fim de identificar os quatro

caminhos XPath utilizados por ambos os lados das junções. O lado esquerdo da

primeira junção está relacionado à variável $ped, a qual é representada pelo caminho

49

XPath compraEletronica/pedidos/pedido, e o lado direito está relacionado à variável

$cli, cujo caminho XPath é compraEletronica/clientes/cliente. Assim, verificamos a

cardinalidade de compraEletronica/pedidos/pedido e compraEletronica/clientes/cliente

no documento compraEletronica.xml, a fim de identificar o caminho XPath com a

menor cardinalidade. Neste caso, a cardinalidade de cliente é menor que a

cardinalidade de pedido, uma vez que cada cliente pode ter vários pedidos. Assim,

concluímos que cliente é o elemento primário na primeira expressão de junção. Iremos

supor que a cardinalidade de cliente assume o valor C1. Posteriormente, analisamos o

lado esquerdo da segunda junção, o qual contém a variável $par. Essa variável está

representada pelo caminho XPath compraEletronica/parcelasPedido/parcelaPedido, o

qual é utilizado na consulta à base de dados para obtenção da cardinalidade. Em

seguida, analisamos o lado direito da segunda junção, que contém a variável $ped,

representada pelo caminho XPath por compraEletronica/pedidos/pedido. Uma vez que

um pedido pode ter inúmeras parcelas, o elemento pedido possui menor cardinalidade

que o elemento parcelaPedido e, por isso, representa o elemento primário na segunda

expressão de junção. Iremos supor que a cardinalidade do elemento pedido assume o

valor C2. Assim, os elementos cliente e pedido representam os elementos primários

envolvidos nas junções. Por último, comparamos ambas as cardinalidades, a fim de

definir o caminho XPath a ser utilizado para a seleção do atributo de fragmentação. Se

C1<C2, o caminho compraEletronica/clientes/cliente relacionado à C1 é o escolhido,

caso contrário, o caminho compraEletronica/pedidos/pedido é selecionado.

<results> {

for $cli in doc('compraEletronica.xml')/compraEletr onica/clientes/cliente

for $ped in doc('compraEletronica.xml')/compraEletr onica/pedidos/pedido

for $par in

doc('compraEletronica.xml')/compraEletronica/parcel asPedido/parcelaPedido


and $par/@pedidoRef = $ped/@id


and $par/situacao = 'aguard. pagto'

return


{$par/data_venc}

{$par/valor_parcela}

{$par/mes_referencia}

</cliente>

} </results>

Figura 4.10: Consulta XQuery envolvendo duas operações de junção.

50

Após a definição do caminho a ser analisado, o algoritmo 4.1, que realiza a

seleção do atributo de fragmentação e a geração dos fragmentos virtuais pode ser

inicializado.

Algoritmo 4.1: Procedimento para a geração de fragmentos virtuais. 1: procedure FragmentacaoVirtual(Xquery, NumeroNos) 2: if XQuery contém expressões collection then 3: XQuery <- obtemQueryReformulada(XQuery); 4: end if 5: numeroJuncoes <- obtemNumeroJuncoes(XQuery); 6: XQueryTmp <- XQuery; 7: if numeroJuncoes = 0 then 8: XPath <- obtemXPathEmExpressoesForLet (XQuery); 9: else 10: juncao <- obtemExpressaoJuncao (XQueryTmp); 11: XqueryTmp <- removeExpressaoJuncaoObtida (XQueryTmp); 12: chave <- obtemElementoChave(juncao); 13: cardinalidadeAnterior <- obtemCardinalidade(chave); 14: XPathLadoEsquerdo <- obtemLadoEsquerdoJuncao(juncao); 15: XPathLadoDireito <- obtemLadoDireitoJuncao(juncao); 16: if XPathLadoEsquerdo contém a chave then 17: XPath <- obtemXPathExpressaoFor(XPathLadoEsquerdo, XQuery); 18: else 19: XPath <- obtemXPathExpressaoFor(XPathLadoDireito, XQuery); 20: end if 21: loop 22: if XQueryTmp contém junções then 23: juncao <- obtemExpressaoJuncao(XQueryTmp); 24: XQueryTmp <- removeExpressaoJuncaoObtida(XQueryTmp); 25: chave <- obtemElementoChave(juncao); 26: cardinalidadeAtual <- obtemCardinalidade(chave); 27: XPathLadoEsquerdo <- obtemLadoEsquerdoJuncao(juncao); 28: XPathLadoDireito <- obtemLadoDireitoJuncao(juncao); 29: if cardinalidadeAtual < cardinalidadeAnterior then 30: if XPathLadoEsquerdo contém a chave then 31: XPath <- obtemXPathExpressaoFor(XPathLadoEsquerdo, XQuery); 32: else 33: XPath <- obtemXPathExpressaoFor(XPathLadoDireito, XQuery); 34: end if 35: end if 36: else saidaLoop(); 37: end if 38: end loop 39: end if

40: if XPath é um caminho incompleto then 41: caminhoCompleto <- obtemCaminhoCompleto (XPath); 42: else 43: caminhoCompleto <- XPath; 44: end if 45: elementoPai <- obtemElementoRaiz(caminhoCompleto); 46: caminhoCompleto <- removeElementoRaiz(caminhoCompleto); 47: cardinalidadeElemPai <- 1; 48: atributoFragmentacao <- indefinido; 49: cardinalidadeFinal <- 0; 50: loop 51: if caminhoCompleto contém elementos XML then 52: elementoFilho <- obtemElementoRaiz(caminhoCompleto); 53: caminhoCompleto<- removeElementoRaiz(caminhoCompleto); 54: cardinalidadeElemFilho <- obtemCardinalidade(elementoFilho); 55: if cardinalidadeElemFilho > 1 then 56: if cardinalidadeElemPai = 1 then 57: atributoFragmentacao <- elementoFilho; 58: cardinalidadeFinal <- cardinalidadeElemFilho; 59: saidaLoop(); 60: end if 61: else 62: cardinalidadeElemPai <- cardinalidadeElemFilho; 63: elementoPai <- elementoFilho;

64: end if 65: else saidaLoop(); 66: end if 67: end loop 68: if atributoFragmentacao difere de indefinido then 69: intervalos <- gera_intervalos(atributoFragmentacao, cardinalidadeFinal, numeroNos); 70: adicionaPredicadosSelecao(intervalos, XQuery); 71: else 72: notificaUsuarioFVNaoPodeSerAplicada (); 73: end if 74: end procedure

Dada a consulta XQuery apresentada na Figura 4.10 e o esquema XML descrito

nas Figuras 4.1, 4.2 e 4.3, analisamos o relacionamento entre os elementos existentes

no caminho XPath selecionado. No exemplo acima, consideremos que a cardinalidade

C1 é menor que C2 e, por isso, o caminho XPath compraEletronica/clientes/cliente é

selecionado. Assim, o algoritmo percorre os elementos do caminho XPath indicado, da

raiz compraEletronica em direção à folha cliente, a fim de verificar as respectivas

cardinalidades. Assim que o algoritmo encontra um elemento X que possui

cardinalidade c (c>1) e cujo elemento pai Y possui cardinalidade um, o elemento X é

selecionado como o atributo de fragmentação.

51

No exemplo dado, o elemento cliente possui cardinalidade 200.000 e seus

ancestrais possuem cardinalidade um, de forma que cliente é selecionado como o

atributo de fragmentação virtual. Suponhamos que o usuário deseja gerar apenas dois

fragmentos virtuais, de modo que o tamanho do intervalo é resultante da divisão de

200.000 por dois, o que gera o valor 100.000. Assim, a FV gera os seguintes

intervalos: (i) [1; 100001[; e (ii) [100001; 200001[. Portanto, a FV gera dois predicados

de seleção distintos para cada um dos intervalos. A Figura 4.11 apresenta o fragmento

virtual correspondente ao segundo intervalo, cujo predicado de seleção está

especificado em negrito.

A solução especificada anteriormente visa a assegurar que o algoritmo sempre

seleciona um, e somente um, atributo de fragmentação, o que garante a geração de

tantos fragmentos virtuais quanto o número de fragmentos definido pelo usuário como

parâmetro de entrada. A definição de vários atributos de fragmentação geraria um

número de fragmentos virtuais maior que o desejado.

Para melhor compreensão, consideremos que mais de um atributo de

fragmentação possa ser selecionado. No exemplo anterior, consideremos que há três

relacionamentos 1:N, resultando em três atributos de fragmentação, cujas distribuições

são especificadas como se segue: (i) cliente, atributo de fragmentação com

cardinalidade igual a 200.000, referente à primeira cláusula for; (ii) pedido, atributo de

fragmentação com cardinalidade igual a 300.000, referente à segunda cláusula for; e

(iii) parcelaPedido, atributo de fragmentação com cardinalidade 500.000, referente à

terceira cláusula for. Suponhamos que o usuário deseja gerar dois fragmentos virtuais.

<results> {

for $cli in doc('compraEletronica.xml')/compraEletr onica/clientes/ cliente

[position() >= 100001 and position < 200001]

for $ped in

doc('compraEletronica.xml')/compraEletronica/pedido s/pedido

for $par in

doc('compraEletronica.xml')/compraEletronica/parcel asPedido/parcelaPedido


and $par/@pedidoRef = $ped/@id


and $par/situacao = 'aguard. pagto'

return


{$par/data_venc}

{$par/valor_parcela}

{$par/mes_referencia}

</cliente> } </results>

Figura 4.11: Fragmento virtual correspondente ao intervalo [100001; 200001[.

52

Assim, a cardinalidade de cada atributo de fragmentação é dividida por dois, a fim de

definir o início e o fim dos intervalos.

/compraEletronica/clientes/ cliente

[position() >= 1 and position() <

100001]

/compraEletronica/pedidos/ pedido


150001]

/compraEletronica/parcelasPedidos

/ parcelaPedido[position() >= 1 and

position() < 250001]



200001]



150001]




(a) Fragmento para a 1ª combinação. (e) Fragmento p ara a 5ª combinação.



100001]



150001]

/compraEletronica/parcelasPedidos/

parcelaPedido[position() >= 250001 and




200001]



150001]




(b) Fragmento para a 2ª combinação. (f) Fragmento p ara a 6ª combinação.



100001]



300001]




/compraEletronica /clientes/cliente


200001]

/compraEletronica/pedidos/pedido


300001]


/parcelaPedido [position() >= 1 and


(c) Fragmento para a 3ª combinação. (g) Fragmento p ara a 7ª combinação.



100001]



300001]


/ parcelaPedido [position() >= 250001 and




200001]



300001]




(d) Fragmento para a 4ª combinação. (h) Fragmento p ara a 8ª combinação.

Figura 4.12: Combinações após aplicar a FV sobre uma consulta com operações de junção.

53

Como cada atributo de fragmentação gera dois fragmentos virtuais, no total,

teremos oito fragmentos virtuais, cujos predicados de seleção são apresentados na

Figura 4.12. Note que são consideradas todas as combinações possíveis entre os

intervalos gerados, de modo que os oito fragmentos virtuais são resultantes da

multiplicação de dois fragmentos * (duas operações de junção + 1). Para evitar este

problema, nossa solução restringe o número de atributos de fragmentação a um, e

somente um, a fim de selecionar somente um elemento XML da consulta de entrada.

Isto se deve ao fato de que o número de fragmentos gerados após aplicar a FV sobre

a consulta de entrada deve ser igual ao número previamente definido e passado como

parâmetro de entrada pelo usuário.

A estratégia definida anteriormente para a geração dos fragmentos virtuais pode

ser aplicada somente a consultas de entrada sobre bases de dados SD, isto é,

consultas que contêm cláusulas doc(). Para consultas a bases de dados MD, as quais

utilizam a cláusula collection(), é necessário criar uma consulta intermediária antes de

aplicar a FV. A técnica utilizada para atender consultas desse tipo é especificada na

seção a seguir.

4.2.2 Consultas a bases de dados MD Consultas a bases de dados MD são formuladas com a cláusula collection(),

uma vez que se deseja acessar uma coleção com múltiplos documentos. Consultas

desse tipo podem causar um severo desbalanceamento de carga se a estratégia para

a geração dos fragmentos for aplicada diretamente sobre a consulta de entrada. Para

melhor compreensão, consideremos uma coleção denominada compras, a qual possui

quatro documentos: compra1.xml, compra2.xml, compra3.xml e compra4.xml. Além

disso, consideremos que cada documento dessa coleção segue o esquema

apresentado nas Figuras 4.1, 4.2 e 4.3. Suponhamos que o usuário deseja gerar dois

fragmentos virtuais sobre uma consulta de entrada semelhante à consulta Q,

apresentada na Figura 4.7, porém, ao invés de utilizar a cláusula doc(), utiliza a

cláusula collection(). A consulta Q é apresentada na Figura 4.13.

Results> {

for $cli in collection('compras')//cliente


return

<cliente>

{$cli/nome}

{$cli/e_mail}

</cliente>}

</results>

Figura 4.13: Consulta a uma coleção de documentos.

54

No exemplo descrito, o elemento cliente é escolhido como o atributo de

fragmentação virtual. Consideremos ainda a seguinte distribuição do elemento cliente

entre os documentos XML armazenados na coleção: (i) compra1.xml contém 50.000

elementos cliente; (ii) compra2.xml contém 80.000 elementos cliente; (iii) compra3.xml

contém 60.000 elementos cliente; e (iv) compra4.xml contém 10.000 elementos

cliente. Analisando as cardinalidades mencionadas, vimos que a cardinalidade total do

elemento cliente, considerando a coleção como um todo é igual a 200.000. Assim,

utilizando a técnica para a geração dos intervalos, temos os seguintes resultados: (i)

[1; 100001[ e (ii) [100001; 200001[. Os fragmentos virtuais gerados são apresentados

na Figura 4.14.

Após a geração dos fragmentos virtuais, consideremos que dois nós do

agrupamento, N1 e N2, processam o primeiro e o segundo fragmento, respectivamente.

Neste caso, o processamento causa um severo desbalanceamento de carga, uma vez

que os documentos XML da coleção são processados individualmente. O nó N1

processa todos os elementos cliente dos quatro documentos, enquanto o nó N2 não

processa elemento algum. Isto se deve ao fato de que os documentos individuais não

contêm elementos cliente em posições maiores que 80.000. Note que, inclusive o

documento compra4.xml, o qual possui a maior quantidade de elementos cliente, não

tem elementos processados pelo nó N2, uma vez que este nó processa somente

elementos cujas posições assumem valores maiores que 100.000.

<results> {

for $cli in collection('compras')

// cliente[position() >= 1 and


where ends-with($cli/e_mail,

'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

<results> {

for $cli in collection('compras')

// cliente[position() >= 100001 and



'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

(a) Fragmento para o intervalo [1; 100001[. (b) Fragmento para o intervalo [100001;

200001[.

Figura 4.14: Fragmentos virtuais gerados para a consulta sobre uma coleção de documentos.

Visando a eliminar este problema, nossa solução provê a reescrita da consulta

original para gerar uma consulta intermediária, a qual contém a união de todos os

documentos armazenados na coleção envolvida. Esta estratégia permite que, durante

o processamento, o banco de dados considere os elementos da coleção como um

todo, e não os elementos dos documentos individuais. A geração da consulta

55

intermediária consiste da execução dos seguintes passos: (i) consulta à base de

dados para obter a identificação de todos os documentos XML armazenados na

coleção envolvida; (ii) criação de uma cláusula let para cada documento XML

retornado no passo anterior; (iii) união dos documentos XML expressos nas cláusulas

let, e (iv) reescrita da consulta original para incluir a união dos documentos XML.

Considerando o exemplo apresentado, seriam geradas quatro cláusulas let, uma

para cada um dos quatro documentos XML armazenados na coleção compras. Após a

geração das cláusulas let, realizamos a união dos documentos através do operador de

união “|” (pipe). Por fim, a consulta de entrada é reescrita para incluir a união dos

documentos, o que gera a consulta intermediária. Assim, a FV é aplicada sobre a

consulta intermediária, e não sobre a consulta original, a fim de gerar os fragmentos

virtuais de maneira adequada e evitar o problema de desbalanceamento de carga

discutido anteriormente. A Figura 4.15 apresenta os fragmentos virtuais gerados sobre

a consulta intermediária.

<results> {

let $d1:= doc('compra1.xml',

'compras')//cliente


'compras')//cliente


'compras')//cliente


'compras')//cliente

for $d in ($d1 | $d2 | $d3 | $d4)

// cliente[position >= 1 and

position < 100001]


'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

<results> {


'compras')//cliente


'compras')//cliente


'compras')//cliente


'compras')//cliente

for $d in ($d1 | $d2 | $d3 | $d4)

// cliente[position >= 100001 and

position < 200001]


'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

(a) Fragmento para o intervalo [1; 15001[. (b) Fragmento para o intervalo [15001; 30001[.

Figura 4.15: Fragmentos virtuais gerados sobre a consulta intermediária.

O processamento dos fragmentos virtuais gerados não acarreta o

desbalanceamento de carga, uma vez que a união dos fragmentos resulta em um

documento XML intermediário que contém todos os elementos cliente, isto é, 200.000

56

elementos. Desta forma, ao distribuir ambos os fragmentos para dois nós distintos,

ambos os nós processarão a mesma quantidade de elementos.

É importante observar, no entanto, que o desbalanceamento de carga ainda

assim pode ocorrer, uma vez que a consulta de entrada contém um predicado de

seleção que limita os resultados aos elementos cliente que possuem e-mails que

terminam com a string @cos.ufrj.br. No entanto, este tipo de desbalanceamento de

carga é inerente à distribuição não-uniforme dos dados, e não às faixas de valores que

caracterizam os fragmentos virtuais. A solução para este tipo de desbalanceamento de

carga está fora do escopo desta dissertação, uma vez que a FV não trata este

problema. No entanto, como trabalhos futuros, pretendemos implementar a

abordagem da fragmentação virtual adaptativa para o modelo XML, a fim de eliminar

esta limitação e tornar possível a distribuição dinâmica de carga.

Como vimos, a fragmentação virtual proposta nesta dissertação atende aos

diferentes tipos de consultas XML. Nossa solução abrange bases de dados do tipo SD

e MD, além de assegurar a correta decomposição das consultas para os casos em

que existem operações de junção. O algoritmo adotado inclui os seguintes passos: (i)

a leitura dos parâmetros de entrada que definem a consulta XQuery e o número de

nós do agrupamento a serem alocados, que por sua vez, definem o número de

fragmentos virtuais a serem gerados; (ii) a validação da consulta XQuery de entrada;

(iii) a verificação do tipo da consulta, uma vez que pode estar relacionada a bases de

dados SD ou MD; (iv) a reformulação da consulta de entrada, nos casos em que se

refere a uma base de dados MD; (v) a seleção de um, e somente um, atributo de

fragmentação virtual; (vi) a geração dos predicados de seleção, que identificam os

fragmentos virtuais, através da utilização da função position() sobre as faixas de

valores do atributo de fragmentação virtual; (vii) o processamento paralelo dos

fragmentos virtuais em um agrupamento de banco de dados; e (viii) a composição do

resultado final. A metodologia proposta em (FIGUEIREDO et al., 2010) é utilizada para

a execução dos últimos dois passos mencionados.

Nossa solução independe do tipo do atributo de fragmentação escolhido e pode

ser aplicada sobre a consulta XQuery de entrada, ainda que não existam atributos

chave previamente definidos sobre os documentos XML armazenados no banco de

dados. É importante ressaltar que, ao contrário da proposta da FV para o modelo

relacional, nossa proposta não se baseia na escolha de chaves primárias como

atributos de fragmentação. A condição necessária para a escolha do atributo de

fragmentação é a existência de um relacionamento 1:N entre os elementos XML

presentes nos documentos do banco de dados.

57

Nesta seção, discutimos os problemas encontrados ao processar consultas

sobre bases de dados MD e consultas que envolvem operações de junção. Além

disso, apresentamos as soluções encontradas para atender às particularidades desses

tipos de consulta. Na próxima seção, abordamos os aspectos relacionados à

composição dos resultados, considerando consultas de entrada que possuem

operações de ordenação e agregação. A estratégia para consolidar os resultados é

apresentada a fim de garantir que o resultado final obtido seja igual ao resultado final

que seria retornado ao processar a mesma consulta na base centralizada.

4.3 Composição dos resultados A composição do resultado final no modelo XML possui maior complexidade se

comparado ao modelo relacional, pois a estrutura do documento de resposta é

definida pela consulta XQuery formulada pelo usuário e o resultado final deve respeitar

os relacionamentos de hierarquia entre os elementos. No modelo relacional, não há

esta preocupação, pois se conhece a priori a estrutura da resposta que independe de

relacionamentos hierárquicos, já que a composição do resultado final baseia-se

apenas em operações de união de tuplas. Considerando as características deste novo

cenário, adaptações foram realizadas para que a fragmentação virtual fosse ajustada à

estrutura do modelo XML.

No modelo relacional, em geral, a estratégia adotada para a composição dos

resultados baseia-se em armazenar os resultados parciais em uma tabela temporária.

Por fim, operações de união, agregação e ordenação são executadas sobre a tabela

temporária a fim de compor o resultado final.

No modelo XML, utilizamos uma estratégia semelhante, baseada na criação de

uma coleção temporária destinada ao armazenamento do documento XML

intermediário, o qual contém a união dos resultados parciais. Em nossa proposta, o

resultado obtido por cada nó de processamento resulta na criação de um documento

XML, no qual a resposta é armazenada. Cada documento XML que contém um

resultado parcial é armazenado na coleção temporária de sua respectiva instância do

SGBDX. Em seguida, os resultados parciais são consolidados gerando um documento

XML de resposta. Este pode ser o documento de resposta definitivo, caso não existam

operações de agregação ou ordenação na consulta de entrada, ou pode ser um

documento intermediário, caso existam estes tipos de operações. Neste último caso, o

documento intermediário é armazenado em uma coleção temporária de uma única

instância do SGBDX. Por fim, uma consulta expressa na linguagem XQuery, a qual

58

possui a operação de agregação e/ou ordenação, é processada sobre essa coleção

temporária para compor o resultado final.

Uma característica importante do modelo XML que deve ser analisada na

composição do resultado final se refere à preservação da ordem dos elementos, isto é,

os elementos presentes no documento XML de resposta devem seguir a mesma

ordem em que se encontravam no documento original (exceto quando uma cláusula

order by está presente na consulta), o que é assegurado pela solução adotada nesta

dissertação.

4.4 Considerações Finais Neste capítulo, apresentamos a nossa solução e as dificuldades inerentes à

adaptação da fragmentação virtual ao modelo XML. No Capítulo 3, vimos que a

escolha de atributos de fragmentação do tipo string inviabiliza a definição eficaz dos

intervalos. Este problema pode ocorrer tanto no modelo relacional quanto no modelo

XML, no entanto, parece ser mais grave no modelo XML, uma vez que neste modelo

as chaves são, na maioria das vezes, indicadas por um conjunto de caracteres,

enquanto as chaves no modelo relacional tendem a assumir valores inteiros. Além

disso, no modelo relacional, os atributos que compõem as chaves primárias das

relações são, em geral, selecionados como atributos de fragmentação. No entanto, no

modelo XML, não podemos garantir que todos os documentos XML do banco de

dados possuem atributos/elementos chave definidos em seus esquemas, o que

tornaria inviável a aplicação da FV.

Para eliminar estas limitações da FV, adotamos uma estratégia eficaz de seleção

do atributo de fragmentação, a qual independe da existência de chaves nos

documentos XML armazenados nos bancos de dados. A escolha do atributo de

fragmentação é automática e depende, exclusivamente, da existência de

relacionamentos 1:N entre os elementos XML presentes nos documentos. Além disso,

a estratégia adotada garante que um, e somente um, atributo de fragmentação é

selecionado, a fim de assegurar que o número de fragmentos virtuais gerados é igual

ao número requerido pelo usuário.

A solução adotada nesta dissertação atende a consultas XML a bases de dados

SD e bases de dados MD. Vimos que é necessária a criação de uma consulta

intermediária para atender a este segundo tipo de consulta. Além disso, consultas que

envolvem operações de agregação ou ordenação exigem um processamento final do

documento intermediário, a fim de obter o documento de resposta definitivo. Para

59

assegurar o paralelismo de entrada e de saída, cada nó do agrupamento acessa uma

instância diferente do SGBDX, a fim de evitar filas de espera resultantes de conexões

concorrentes à mesma instância do banco de dados.

No próximo capítulo, apresentamos uma visão geral da arquitetura utilizada,

ressaltando as adaptações realizadas para prover a comunicação paralela e

distribuída no agrupamento de banco de dados, segundo uma arquitetura de disco

compartilhado. Neste capítulo, também discutimos os aspectos relacionados a alguns

dentre os SGBDX mais utilizados e mencionamos os critérios utilizados na avaliação

de cada um deles para a escolha do SGBDX mais adequado.

60

5 Partix-VP – fragmentação virtual em XML

Neste capítulo, apresentamos os aspectos inerentes à implementação de nossa

solução: o Partix-VP. Esta solução provê a fragmentação virtual sobre bases de dados

XML sob a arquitetura de agrupamentos de banco de dados. Na Seção 5.1

descrevemos a metodologia utilizada nesta dissertação e apresentamos as

adaptações realizadas para permitir a fragmentação virtual das bases de dados,

considerando o cenário de consultas XML ad-hoc. Na Seção 5.2, exibimos a

arquitetura paralela utilizada que conta com modelo de memória de disco

compartilhado. A estratégia adotada para a consolidação dos resultados é

apresentada na Seção 5.3. A Seção 5.4 apresenta alguns dentre os SGBDX nativos

mais conhecidos, mantendo o foco nos SGBDX eXist e Sedna, por serem de código

aberto, possuírem uma estrutura simples e exigirem pouco espaço em disco. Nesta

seção também indicamos o SGBDX selecionado para a validação experimental de

nossa solução. Por último, a Seção 5.5 menciona a API (Application Programming

Interface) utilizada para atender às características do ambiente de agrupamento de

banco de dados, provendo comunicação paralela e distribuída entre os nós da rede.

5.1 Adaptação da fragmentação virtual de dados ao m odelo XML A metodologia proposta por Figueiredo et al. (2010) foi utilizada nesta

dissertação, a qual provê o processamento paralelo de consultas XML distribuídas

através de técnicas de fragmentação física de dados. Assim, diversas adaptações

foram necessárias para que a metodologia mencionada pudesse atender às consultas

ad-hoc XML de nosso cenário. Desta forma, a implementação de Figueiredo et al.

(2010) foi modificada, a fim de implantar a técnica da fragmentação virtual de dados,

ao invés da fragmentação física.

Dentre as principais adaptações, podemos destacar: a identificação do tipo da

consulta de entrada (a bases SD ou MD); a seleção do atributo de fragmentação

virtual; a definição dos intervalos sobre o atributo de fragmentação selecionado; a

geração dos predicados de seleção que caracterizam os fragmentos virtuais; e a

adição destes predicados através da reescrita da consulta de entrada. A aplicação

desenvolvida permite a geração dos fragmentos virtuais, os quais são, posteriormente,

processados em paralelo em um ambiente de agrupamento de banco de dados.

61

A aplicação gera os fragmentos virtuais de forma automática e dinâmica, sem

que seja necessário o conhecimento dos algoritmos e configurações internas

envolvidos. Os únicos parâmetros de entrada a serem especificados pelo usuário são:

uma consulta XQuery válida e um número inteiro que indique a quantidade de nós do

agrupamento a serem alocados para o processamento da consulta. No que se refere

aos resultados, nossa solução garante que o resultado obtido ao processar os

fragmentos virtuais gerados no agrupamento de banco de dados é igual ao resultado

obtido ao processar a consulta original na base de dados centralizada.

A fragmentação virtual é executada pela aplicação na máquina cliente,

responsável por receber a consulta XQuery do usuário e efetuar a decomposição

desta em subintervalos de mesmo tamanho, considerando o número de nós a ser

alocado. Dada uma consulta XQuery, as sub-consultas são geradas com intervalos de

valores independentes, considerando o atributo de fragmentação escolhido. Em

seguida, essas sub-consultas são submetidas aos nós do agrupamento de banco de

dados, os quais processam os seus fragmentos virtuais e armazenam os resultados

parciais em suas respectivas instâncias do SGBDX. Ao término do processamento de

todos os fragmentos virtuais, o nó coordenador realiza a composição do resultado

final. O nó coordenador é semelhante a qualquer outro nó do agrupamento e processa

seus próprios fragmentos virtuais. No entanto, ele é o único responsável pela

composição do resultado final. Na próxima seção, é apresentada uma visão geral da

arquitetura utilizada na implementação.

5.2 Processamento paralelo de consultas em agrupame ntos de banco de dados Como a maior parte das soluções baseadas na fragmentação virtual, nossa

solução segue a abordagem de agrupamento de banco de dados, porém, utilizando a

arquitetura de disco compartilhado. Esta área de acesso compartilhado pode ser

acessada por qualquer nó do agrupamento. Para prover paralelismo de entrada e de

saída, criamos uma instância do SGBDX para cada nó do agrupamento. Cada nó

acessa uma instância diferente para processar o seu fragmento virtual, tanto para

realizar operações de leitura quanto para realizar operações de escrita, o que evita

quedas no desempenho causadas por conexões concorrentes ao mesmo SGBDX. As

instâncias armazenam cópias da mesma base de dados, de forma que os nós

acessam o mesmo conjunto de coleções/documentos XML.

O agrupamento de banco de dados que utilizamos consiste de um conjunto de

nós de processamento que possuem processadores (oito processadores por nó) e

62

memória. Porém, não possuem disco rígido (diskless nodes). Por isso, cada instância

do banco de dados deve ser acessada por meio da arquitetura de disco compartilhado.

A Figura 5.1 exibe a arquitetura utilizada, cujo disco compartilhado armazena todas as

instâncias do banco de dados que devem ser acessadas pelos nós do agrupamento, a

fim de processar os fragmentos virtuais gerados pela aplicação na máquina cliente.

Máquina cliente

Fragmentação Virtual

Fv1 Fv2 Fv3 Fvn

Agrupamento de Banco de Dados

Nó de Administração (Np0)

Fv1 Fv2 Fv3 Fvn

Np0 Np1 Np2 Npn-1

...

Rp0

Fvn-1

Np3

Fvn-1

...

Rp1 Rp2 Rp3 Rpn-1

Sg0 Sg1 Sg2 Sg3 Sg4

Np0

Disco compartilhado

QtdeNós

Figura 5.1: Visão geral da arquitetura para a FV no agrupamento de banco de dados.

Na etapa inicial, a FV é realizada pela aplicação na máquina cliente, a qual

recebe a consulta XQuery e a quantidade de nós a serem alocados como parâmetros

de entrada. Os fragmentos virtuais com faixas de valores de tamanhos iguais são

gerados com base nos parâmetros de entrada. Em seguida, os fragmentos virtuais

gerados, indicados por Fv1, Fv2, Fv3, ..., Fvn-1 e Fvn são submetidos ao agrupamento. O

nó de administração, isto é, o nó coordenador (Np0), obtém os fragmentos virtuais e os

distribui aos nós de processamento, indicados por Np1, Np2, Np3, ..., e Npn-1 que, por

sua vez, acessam instâncias independentes para processar seus respectivos

fragmentos virtuais. Note que o nó coordenador também participa desta etapa de

processamento. Os resultados parciais gerados por cada nó estão representados por

Rp0, Rp1, Rp2, Rp3, ..., e Rpn-1, respectivamente, os quais são armazenados nos

63

SGBDX independentes, indicados por Sg0, Sg1, Sg2, Sg3, ..., e Sgn-1. Por fim, o nó

coordenador compõe o resultado final.

Na próxima seção, discutimos os detalhes de implementação relacionados à

composição do resultado final.

5.3 Consolidação dos resultados A consolidação dos resultados de consultas que não envolvem operações de

agregação ou ordenação é bastante simples, uma vez que não é necessário processar

nenhuma operação sobre o documento final, o qual contém o conjunto de dados

completo. Cada nó do agrupamento de banco de dados acessa uma instância distinta

do SGBDX para processar o seu fragmento virtual. Cada resultado parcial gerado é

armazenado em sua respectiva instância da base de dados. Para compor o resultado

final, um dos nós do agrupamento, o nó de controle, obtém os resultados parciais de

cada instância e gera um documento final com o resultado completo. É importante

ressaltar que o nó de controle obtém os resultados parciais na ordem em que os

fragmentos foram gerados, isto é, da menor faixa de valores dos intervalos para a

maior faixa de valores. Desta forma, os elementos XML que são retornados no

documento final de resposta seguem a mesma ordem em que apareciam no

documento/coleção original, armazenado na base de dados.

Por outro lado, consultas que envolvem operações de ordenação ou agregação

exigem um processo de composição de resultado com uma fase adicional. Após a

obtenção de todos os resultados parciais e consolidação dos mesmos em um único

documento de resposta, armazenamos este documento de resposta intermediário em

uma coleção temporária, denominada tmpResultadosParciais, a qual é criada em uma

instância do SGBDX. Em seguida, a operação final de agregação ou ordenação é

processada sobre este documento intermediário para obtenção do resultado final

definitivo. É importante ressaltar que esse documento intermediário, armazenado na

coleção, possui um elemento denominado partialResult como o elemento raiz, o qual é

utilizado na consulta final. Os fragmentos virtuais que contêm esses tipos de

operações (agregação ou ordenação) são precedidos com um cabeçalho que

especifica a função de agregação ou ordenação a ser processada para compor o

resultado final definitivo. Como exemplo, consideremos a mesma consulta utilizada em

exemplos anteriores, porém, com uma operação de ordenação, como apresentado na

Figura 5.2.

64

<results> {

for $cli in doc('compraEletronica.xml')//cliente


order by $cli/nome ascending

return <cliente> {$cli/nome}

{$cli/e_mail}

</cliente>} </results>

Figura 5.2: Consulta envolvendo uma operação de ordenação.

Suponhamos que o usuário deseja gerar dois fragmentos virtuais e

consideremos que o elemento cliente, cuja cardinalidade é igual a 200.000, é o

atributo de fragmentação virtual selecionado. Assim, a FV gera os fragmentos virtuais

apresentados na Figura 5.3.

<ORDERBY>$cli/nome</ORDERBY>

<ORDERBYTYPE>ascending</ORDERBYTYPE>

<AGRFUNC></AGRFUNC>

<results> {

for $cli in

doc('compraEletronica.xml')// cliente

[position() >= 1 and position()

< 100001]


'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

<ORDERBY>$cli/nome</ORDERBY>

<ORDERBYTYPE>ascending</ORDERBYTYPE>

<AGRFUNC></AGRFUNC>

<results> {

for $cli in

doc('compraEletronica.xml')// cliente

[position() >= 100001 and position()

< 200001]


'@cos.ufrj.br')

return


{$cli/e_mail}

</cliente>}

</results>

(a) Fragmento para o intervalo [1; 100001[. (b) Fragmento para o intervalo [100001; 200001[.

Figura 5.3: Fragmentos virtuais gerados para a consulta com ordenação.

No momento do processamento do fragmento virtual, o cabeçalho que define as

operações finais de ordenação/agregação é desconsiderado, o que resulta apenas no

processamento da consulta XQuery. No entanto, após a consolidação dos resultados

parciais em um único documento XML, o qual é armazenado na coleção temporária,

os elementos do cabeçalho são considerados para prover o resultado final. Para isso,

criamos um elemento denominado <ORDERBY>, o qual indica o elemento sobre o

qual a ordenação deve ser realizada. Observe que a variável $cli se refere ao

elemento <cliente> presente no resultado, sobre o qual a ordenação será aplicada. O

elemento <ORDERBYTYPE>, por sua vez, indica o tipo da ordenação, a qual pode ser

crescente (ascending) ou decrescente (descending). Por fim, o elemento <AGRFUNC>

indica o tipo da função de agregação e o elemento sobre o qual esta função deve ser

processada. A consulta de exemplo não possui operações de agregação, por isso,

este elemento está vazio. Considerando estas informações, é possível executar uma

65

operação final de agregação ou ordenação sobre o conjunto completo de dados,

retornados nos resultados parciais. A Figura 5.4 indica a consulta utilizada para obter o

resultado final ordenado.

<results> {

for $ret in collection('tmpResultadosParciais')/p artialResult

let $elm := $ret/results/element()

order by $ret/results/cliente/nome ascending

return $elm

} </results>

Figura 5.4: Consulta XQuery para obter o resultado final ordenado.

A consulta apresentada retorna todos os sub-elementos do elemento results, o

que é indicado pelo caminho XPath $ret/results/element(). Além disso, o resultado é

ordenado de forma crescente de acordo com os nomes dos clientes, o que é indicado

pela cláusula order by $ret/results/cliente/nome ascending. Desta maneira, nossa

solução assegura a composição correta do resultado final, atendendo tanto a

consultas simples, quanto a consultas mais complexas que envolvem operações de

agregação e/ou ordenação.

Na próxima seção, discutimos os aspectos relacionados aos SGBDX nativos

mais conhecidos e destacamos aquele que foi selecionado para a implementação e

avaliação de nossa solução.

5.4 Armazenamento de dados em SGBDX nativos Atualmente, existem vários SGBDX nativos para o armazenamento e a consulta

à base de dados XML, tais como Timber (JAGADISH et al., 2002), Tamino

(SCHÖNING, 2001), Natix (FIEBIG et al., 2002), X-Hive (X-HIVE, 2007), eXist (MEIER,

2003) e Sedna (FOMICHEV et al., 2006).

O Timber (JAGADISH et al., 2002) utiliza a álgebra TAX para processar as

consultas que, ao serem recebidas, são transformadas em uma árvore de operadores

algébricos que são, posteriormente, mapeados para os operadores físicos. Além de

operações de consulta, o Timber permite atualização dos documentos, através de uma

extensão da linguagem XQuery. No Timber, o plano de execução é dividido em

segmentos e um otimizador é utilizado para prover mais desempenho no

processamento da consulta, através de estimativas de custo que permitem avaliar o

custo das operações.

O Tamino (SCHÖNING, 2001) é um SGBDX proprietário que oferece suporte a

transações concorrentes e possui uma camada de interface para a web. Ele aceita a

linguagem de consulta XQuery e provê a utilização de índices. Os documentos XML

66

são agrupados em coleções, e operações padrões tais como seleção, projeção, junção

e ordenação são permitidas, além da definição de funções por parte do usuário.

O Natix (FIEBIG et al., 2002) também é um sistema proprietário, cuja estrutura

em árvore é gerenciada através de um mecanismo que divide o documento XML em

níveis de registro que são semelhantes às páginas de dados em SGBDs relacionais.

Deste modo, cada registro armazena uma parte diferente do documento. Dentre as

funcionalidades do Natix, podemos destacar o acesso eficiente aos dados, através da

utilização de índices, a recuperação de metadados e o gerenciamento de transações

que garantem as propriedades ACID (Atomicidade, Consistência, Isolamento,

Durabilidade) (ELMASRI; NAVATHE, 2006) e auxiliam na recuperação de falhas.

O X-Hive (X-HIVE, 2007), por sua vez, é um SGBDX comercial que adota o

modelo cliente-servidor e suporta as linguagens de consulta XQuery, XUpdate e DOM.

Também provê a utilização de índices sobre nomes de elementos, nomes de atributos

e seus respectivos valores. O X-Hive utiliza um modelo de controle de concorrência

que bloqueia todo o documento, resultando em um baixo desempenho.

O eXist (MEIER, 2003) é um SGBDX que permite processar consultas

complexas através da linguagem XQuery, validar os documentos XML antes de

armazená-los na base, configurar índices e utilizar acesso simultâneo por meio de

operações thread-safe concorrentes de múltiplos usuários. Além disso, trata-se de um

software gratuito de código aberto. O eXist pode ser acessado como uma aplicação

Web ou por meio de bibliotecas Java, quando utilizado em aplicações Desktop. Como

aplicação Web, o eXist pode ser acessado remotamente, através da especificação de

caminho na url do navegador web. Por outro lado, como aplicação Desktop, o eXist

deve ser instalado no disco rígido da máquina cliente e pode ser acessado por outras

aplicações, através da utilização de interfaces, isto é, bibliotecas Java. A versão atual

do eXist inclui vários tipos de índices, dentre os quais destacamos: structural indexes

que se relacionam diretamente à estrutura do XML, pois indexam os nomes dos

elementos/atributos dos documentos, e range indexes que mapeiam os valores dos

elementos/atributos aos seus respectivos tipos definidos no esquema XML, isto é, ao

processar uma consulta sobre um elemento do tipo xs:double, o SGBD tenta realizar a

conversão do valor especificado na consulta para o tipo xs:double. Os elementos que

não podem ser convertidos são ignorados. Os índices mencionados podem ser

aplicados a valores do tipo xs:string, xs:integer, xs:double, xs:float, xs:boolean and

xs:dateTime.

67

O SGBDX Sedna (FOMICHEV et al., 2006) se assemelha a um banco de dados

relacional, pois permite a criação de várias bases de dados que, por sua vez, podem

conter coleções e documentos. Ele permite a atribuição de permissões e privilégios

para cada tipo de usuário/grupo, o que resulta em maior segurança no que se refere

ao acesso à base de dados. O Sedna ocupa pouco espaço em disco e pode ser

acessado via interface de administração (CARNEIRO FILHO et al., 2007), tal como os

SGBDs relacionais, ou via linha de comando, utilizando-se dos comandos previamente

definidos em sua DDL (Data Definition Language) e DML (Data Manipulation

Language). A DDL define os comandos de criação e alteração de estrutura, os quais

são responsáveis pelo armazenamento dos dados. Podemos citar como exemplo os

comandos create collection e drop collection, os quais criam e excluem uma coleção

de documentos XML, respectivamente. A DML, por sua vez, contém comandos que

manipulam dados, tais como seleção, inserção, atualização e exclusão. No Sedna, os

comandos de inserção e exclusão de documentos são especificados por load e drop

document, respectivamente. O comando de seleção nem sempre está inserido no

contexto da DML, pois alguns estudiosos (ISHIKAWA et al., 1999; DEUTSCH et al.,

1999) incluem este comando em outra categoria: a DQL (Data Query Language).

O Sedna oferece suporte à otimização de consultas, à recuperação de falhas e

a transações concorrentes com um mecanismo eficiente que não bloqueia o

documento para transações de leitura, o que favorece o ganho de desempenho. No

Sedna, metadados podem ser recuperados através de consultas XQuery, tais como os

índices definidos, os nomes de cada documento pertencente a uma coleção, o número

total de nós em um determinado documento e a frequência com que um elemento

aparece em um dado documento. Além disso, informações de operações executadas

e erros ocorridos são armazenados em um arquivo de log que pode ser visualizado a

qualquer momento pelo usuário.

O Sedna pode ser acessado através de linguagens de programação, por meio

da utilização de APIs nas linguagens Java, C e Scheme, que possuem métodos

similares à API JDBC. Consultas, através da linguagem XQuery, e atualizações, por

meio de uma extensão da XQuery, são suportadas pelo Sedna, além de funções,

triggers e variáveis globais. O armazenamento de esquemas também é permitido, o

que favorece a validação dos documentos no momento de sua inclusão na base.

Quanto ao controle de concorrência, este se baseia no bloqueio de dados sobre um

conjunto de nós e pode ser do tipo bloqueio exclusivo ou bloqueio compartilhado

(PLESHACHKOV, 2006). No que se refere ao acesso eficiente aos dados, o Sedna

provê a manipulação de índices que são armazenados em uma estrutura de árvore B

68

e podem ser definidos sobre o conteúdo de elementos ou sobre os valores de

atributos. Índices full-text também são implementados pelo Sedna, o que permite

realizar consultas mais complexas. Apesar disso, a versão atual do sistema não utiliza

os índices existentes de forma automática durante o processamento das consultas.

Para isso, o usuário deve utilizar as funções index-scan, index-scan-between e ftindex-

scan para assegurar a utilização dos índices. A função position(), a qual caracteriza a

posição de um dado elemento em um documento XML, parece ser a única que utiliza

índice automaticamente durante o processamento das consultas XML.

Dentre os SGBDX nativos mencionados, selecionamos o Sedna para a

implementação e avaliação de nossa solução, por se tratar de um sistema gratuito e

de código aberto, cujo acesso independe de servidores Web e pode ser feito por

aplicações Desktop, utilizando-se de métodos providos por APIs nas linguagens de

programação mencionadas. Além disso, o fato de ocupar pouco espaço em disco

(apenas 245 MB) torna o Sedna um SGBDX leve, pois não exige grandes capacidades

de armazenamento para sua instalação. O sistema de recuperação de falhas e o

controle de acesso, através da concessão de privilégios aos usuários, faz com que o

Sedna apresente mais segurança e robustez se comparado aos demais SGBDX

estudados. Além disso, a possibilidade de criar várias bases de dados provê maior

flexibilidade, organização e, consequentemente, facilidade para gerenciar as coleções

e os documentos armazenados.

Após definir a arquitetura e o SGBDX a ser utilizado, fez-se necessário se

preocupar com um aspecto essencial para a eficácia de nossa solução: a

comunicação paralela e distribuída entre os nós do agrupamento.

5.5 Comunicação paralela e distribuída entre os nós do agrupamento A adaptação do sistema implementado em Figueiredo et al. (2010) ao ambiente

de agrupamento exigiu a adoção de uma linguagem que ofereça suporte à

comunicação paralela e distribuída. A MPI (Message Passing Interface) é um padrão

amplamente utilizado para a comunicação paralela. No entanto, oferece suporte

somente às linguagens Fortran, C e C++. Com o surgimento da linguagem Java,

surgiram as bibliotecas MPJ (CARPENTER et al., 2000), PJMPI (TONG et al., 2000),

JMPI (MORIN et al., 2002), MPJava7 (SCHEPKE, 2005) e MPJExpress (SHAFI et al.,

2010) que permitem aos desenvolvedores utilizarem MPI em Java, através da

utilização de métodos que possibilitam a comunicação ponto-a-ponto e a comunicação

7 http://www.inf.ufrgs.br/~cschepke/mestrado/ArtigoMpiJava.pdf

69

coletiva, tais como mensagens multicast (direcionadas a grupos de nós) e mensagens

broadcast (enviadas para todos os nós da rede). Considerando a eficiência, o grau de

dificuldade para o aprendizado e o suporte à execução de aplicações paralelas em

agrupamentos ou computadores pessoais/notebooks que possuam mais de um

processador ou memória compartilhada, concluímos que a biblioteca MPJExpress

seria a opção mais adequada.

Para a comunicação ponto-a-ponto, o MPJExpress oferece os métodos

MPI_Send e MPI_Recv. O MPISend(end, num, tipo, dest, idmsg, com) é responsável

pelo envio de mensagens, cujos parâmetros indicam, respectivamente: o endereço de

memória onde a mensagem começa, o número de itens contidos na mensagem, o tipo

do item enviado (int, float, double), o identificador do processo (processador) que

receberá a mensagem, o identificador da mensagem e o comunicador que, por sua

vez, representa o grupo ou o contexto ao qual o processo pertence. O método

MPI_Recv(end, num, tipo, orig, idmsg, com, status) sinaliza o recebimento da

mensagem, cujos parâmetros são semelhantes aos do método anterior, exceto pelo

parâmetro orig que indica o processo que enviou a mensagem e o status que permite

identificar a ocorrência de erros. Deste modo, utilizamos a biblioteca MPJExpress para

prover o processamento paralelo e distribuído dos fragmentos virtuais no agrupamento

de banco de dados.

5.6 Considerações Finais Nesta dissertação, realizamos adaptações na metodologia proposta por

Figueiredo et al. (2010), a fim de prover o processamento paralelo de consultas,

através da técnica da fragmentação virtual de dados. As alterações na implementação

incluem o algoritmo completo para a geração dos fragmentos virtuais, por meio da

reescrita da consulta de entrada, o que é realizado em tempo de execução. A

fragmentação virtual de dados é realizada na aplicação instalada na máquina cliente.

No Capítulo 4, vimos que a fragmentação virtual de dados depende da

existência de um relacionamento 1:N entre os elementos do documento XML

envolvido. Isso requer que sejam realizadas consultas aos documentos XML, a fim de

verificar a cardinalidade dos elementos. A obtenção das cardinalidades pode ser

realizada por meio de consultas XQuery contendo a instrução count(), ou via acesso

direto ao catálogo do sistema do SGBDX, assumindo que o SGBDX escolhido possui

um catálogo com este tipo de informação. Nesta dissertação, as cardinalidades são

obtidas através da execução de consultas XQuery sobre a base de dados, uma vez

que o catálogo do sistema, provido pelo SGBDX Sedna, não contém todas as

70

informações das quais necessitamos. Porém, se outro SGBDX for adotado, cujo

catálogo forneça todas as informações de cardinalidade necessárias, o acesso direto a

este catálogo pode ser realizado, evitando assim consultas XQuery desnecessárias e,

consequentemente, diminuindo o tempo total de resposta das consultas de entrada.

No que se refere ao processamento paralelo, adotamos o ambiente de

agrupamento de cluster de banco de dados, com replicação total da base de dados, a

fim de prover maior tolerância a falhas. Neste ambiente, cada nó é responsável por

processar seu respectivo fragmento e a consolidação dos resultados é realizada pelo

nó de controle, que é um dos nós envolvidos no processamento.

Para comprovar a efetividade de nossa proposta, executamos um conjunto de

consultas XML em um agrupamento de banco de dados real, segundo a técnica da

fragmentação virtual de dados. No total, dezoito consultas distintas, tanto em bases de

dados SD como MD, foram utilizadas na validação experimental, a fim de comparar os

tempos de processamento no ambiente centralizado e no ambiente distribuído. No

próximo capítulo, descrevemos as características do agrupamento de banco de dados

utilizado, discutimos os aspectos inerentes às bases de dados utilizadas, e

apresentamos os resultados obtidos. Uma análise apurada dos resultados é

apresentada, indicando os ganhos de desempenho alcançados, de acordo com o

número de processadores/nós envolvidos no processamento dos fragmentos virtuais

gerados.

71

6 Validação Experimental

Neste capítulo, apresentamos os resultados obtidos ao aplicar a técnica da FV a

consultas XML. Na Seção 6.1 discutimos a configuração do ambiente para a execução

dos experimentos. A Seção 6.2 apresenta as características das bases de dados e os

grupos de consultas analisados. Os resultados obtidos são apresentados na Seção

6.3. Por último, a Seção 6.4 apresenta as considerações finais sobre os ganhos de

desempenho observados.

6.1 Configuração do ambiente O agrupamento de banco de dados utilizado é um SGI Altix ICE 8200 com 64

CPUs 2.66 GHz Quad Core Intel Xeon 5355 com 1GB de memória RAM por núcleo de

processamento, executando o sistema operacional Linux. A execução de tarefas no

agrupamento é gerenciada por um escalonador de tarefas (jobs), também conhecido

como PBS (Portable Batch System), cuja principal função é alocar tarefas aos nós do

agrupamento que estiverem disponíveis. O middleware Hydra (OGASAWARA et al.,

2009) foi utilizado para prover o paralelismo através da alocação das tarefas aos nós.

Para isso, é necessário configurar o arquivo responsável pela submissão de tarefas, o

qual é apresentado na Figura 6.1.

#PBS -l nodes=4:ppn=8

#PBS -l walltime=00:30:00

#PBS -S /bin/bash

#PBS -N frgVrt1Nd1ThRd1Dl2s

#PBS -j oe

#PBS -V

#PBS -m ae

#PBS -M [email protected]

# change directory

cd ${PBS_O_WORKDIR}

echo Java Job: ${PBS_JOBID}

with java

sort ${PBS_NODEFILE} | uniq > ~/tmp/${PBS_JOBID}

~/teste_copy/exp/hydra.pbs ~/tmp/${PBS_JOBID} 32 "${PBS_JOBID}.conf"

Figura 6.1: Arquivo para a submissão de tarefas ao agrupamento.

Os principais parâmetros deste arquivo são: (i) PBS -l nodes, o qual indica a

quantidade de nós de processamento requeridos; (ii) PBS -l ppn, o qual indica o

número de processadores a serem alocados para cada nó, uma vez que cada nó

possui oito processadores; (iii) PBS -l walltime, que define o tempo total permitido para

a execução da tarefa, no formato hh:mm:ss; (v) PBS –N, que indica o nome do arquivo

72

de saída com informações de erro e de log, (vi) PBS –M, que indica o e-mail para o

recebimento de informações relacionadas aos nós alocados e aos recursos utilizados

pelas tarefas; e (iv) total de processadores, indicado pelo número que antecede a

instrução "${PBS_JOBID}.conf". Note que, no exemplo dado, o total de processadores

assume o valor 32, uma vez que foram requisitados os oito processadores de quatro

nós do agrupamento.

Como mencionado no Capítulo 5, os experimentos foram realizados em um

agrupamento de banco de dados que possui uma área de acesso compartilhado, uma

vez que os nós não possuem disco rígido. Assim, fez-se necessário a instalação de

instâncias do SGBDX Sedna na área de acesso compartilhado para que os nós

pudessem acessar bancos de dados independentes. Na próxima seção, apresentamos

as bases de dados utilizadas e os tipos de consultas analisadas durante a execução

dos experimentos.

6.2 Consultas XML e bases de dados Os experimentos realizados contemplam dois tipos de consultas: consultas a

bases de dados SD, as quais utilizam cláusulas doc(), e consultas a bases de dados

MD, as quais utilizam cláusulas collection(). As consultas XML utilizadas estão

especificadas na linguagem XQuery e foram agrupadas por custo, isto é, por tempo de

processamento no ambiente centralizado. Assim, analisamos três diferentes grupos de

consultas: (i) consultas de baixo custo, cujo tempo de processamento varia entre zero

e dez segundos; (ii) consultas de médio custo, cujo tempo de processamento varia

entre dez e 100 segundos; e (iii) consultas de alto custo, cujo tempo de

processamento é maior que 100 segundos. A definição destes grupos tem como

objetivo principal facilitar a visualização das consultas que se beneficiam da

fragmentação virtual e as que não se beneficiam. Para isso, formulamos consultas

simples, as quais referenciam somente um caminho XPath de um documento/coleção

XML, e consultas complexas, as quais contemplam operações de junção, de

agregação e de ordenação. As consultas XML utilizadas nos experimentos estão

definidas no Anexo I.

As consultas foram executadas sobre bases de dados XML, obtidas da base do

dblp8 e do benchmark XMark (SCHMIDT et al., 2002), cujos esquemas são

apresentados na Figura 6.2 e na Figura 6.3, respectivamente. É importante ressaltar

que cada uma das 32 instâncias do SGBDX contém uma cópia da mesma base de

dados.

8 http://www.informatik.uni-trier.de/~ley/db/

73

title

keykey

mdate

key

title

mdate

key

mdate

author

crossref

publisher

booktitle

croosref

dblp

masterthesis phdthesis inproceedingsproceedings incollectionwww bookarticle

author

year

url

pages

ee

cdrom

cite

number

note

editor

number

month

volume

journal

ee

url

cdrom

cite

note

editor

booktitle

mdatemdate

key

author

year

title

pages

month

author

year

title

pages

booktitle

url

crossref

publisher

ee

cdrom

cite

isbn

chapter

mdate

editor

title

booktitle

publisher

year

isbn

url

author

cdrom

cite

ee

series

volume

month

pages

author

title

pages

school

year

ee

series

number

publisher

volume

isbn

url

month

mdate

key

title

year

school

url

key

mdate

key

editor

booktitle

publisher

series

volume

isbn

year

ee

url

author

address

number

crossref

note

month

cite

journal

Figura 6.2: Esquema da base de dados do dblp.

Para executar os experimentos em bases de dados SD, armazenamos dois

documentos XML extensos no SGBDX escolhido. Por outro lado, para os

experimentos em bases de dados MD, criamos três coleções distintas, as quais

abrangem somente algumas sub-árvores dos esquemas XML originais apresentados

anteriormente. A Tabela 6.1 mostra as características das bases de dados utilizadas.

Tabela 6.1: Características das bases de dados utilizadas nos experimentos.

Tipo Nome do documento ou coleção Sub-árvores Tamanho da base

SD dblp.xml Todas 127,00 Mb

SD XmlDataBaseXmark.xml Todas 111,13 Mb

MD Papers dblp/article 13,00 Mb

MD samericaItens site/samerica/itens/item 8,36 Mb

MD asiaItens site/asia/itens/item 8,96 Mb

74

open_auction

site

regions categories open_auctionspeople closed_auctionscatgraph

{samerica, namerica, asiaaustralia, europe, africa}

category edge person closed_auction

item

id

name

description

from

to

id

name

emailaddress

phone

homepage

creditcard

profile

watches

address

id

initial

reserve

bidder

current

itemref

seller

annotation

quantity

type

interval

privacy

seller

buyer

itemref

price

date

quantity

type

annotation

id

location

quantity

name

payment

description

shipping

incategory

mailbox

featured

category

income

interest

education

business

gender

age

watch

open_auction

street

city

country

province

zipcode

person

item

person

person

item

itens

Figura 6.3: Esquema da base de dados do benchmark Xmark.

A execução dos experimentos depende de três parâmetros de entrada: os

fragmentos virtuais que caracterizam as consultas XQuery a serem processadas, o

número de nós a serem alocados, e o número de processadores por nó que será

utilizado. Os fragmentos virtuais gerados pela FV são armazenados na área de acesso

compartilhado. Assim, ao submeter uma tarefa ao agrupamento, o escalonador verifica

a quantidade de nós/processadores requeridos, identifica os recursos disponíveis e

aloca as tarefas aos nós apropriados. Os nós/processadores obtêm seus respectivos

fragmentos virtuais e acessam instâncias independentes do SGBDX para processá-

los. Por fim, um dos nós do agrupamento, o nó de controle, consolida os resultados.

Na próxima seção, apresentamos os resultados obtidos ao aplicar a FV sobre

bases de dados XML. Os desempenhos foram analisados tanto no ambiente

centralizado quanto no distribuído, a fim de prover meios para a comparação dos

benefícios/impactos observados.

75

6.3 Análise dos Resultados Os resultados obtidos são provenientes da execução de um grupo de consultas

XQuery no agrupamento de banco de dados, segundo números distintos de

processadores. Cada experimento pode ser definido como um par (consulta XQuery,

número de processadores), onde o número de processadores pode assumir os valores

um, dois, quatro, oito, dezesseis e trinta e dois. Para calcular o tempo médio total,

executamos cada experimento por onze vezes consecutivas, descartamos a primeira

execução, e obtivemos a média dos tempos considerando as dez execuções

restantes. A análise dos resultados foi realizada com base nos ganhos de

desempenho obtidos em cada experimento e nas características das consultas de

entrada. Dentre as principais características, podemos destacar: (i) o tipo da base de

dados (SD ou MD), (ii) o número de operações de junção envolvidas na consulta, (iii) a

cardinalidade da operação de junção, (iv) a existência de operações de agregação, (v)

a existência de operações de ordenação, (vi) a cardinalidade do atributo de

fragmentação virtual (Card.AF), (vii) o tamanho do documento a ser processado

(DocProc) e (viii) o tamanho do documento de resposta (DocResp). A Tabela 6.2 exibe

as características de cada consulta utilizada nos experimentos.

Tabela 6.2: Definição das consultas utilizadas nos experimentos. . Consulta Tipo #Join Crd.Join Agr. Ord. Card.AF DocProc DocResp

C1 SD 0 0 Não Sim 212273 127000 Kb 22340 Kb C2 SD 0 0 Não Não 212273 127000 Kb 48424,11 Kb C3 SD 1 25500000 Não Sim 25500 111130 Kb 37371,40 Kb C4 SD 0 0 Sim Não 212273 127000 Kb 27500 Kb C5 SD 1 51000000 Sim Não 25500 111130 Kb 99,12 Kb C6 SD 1 25500000 Não Não 25500 111130 Kb 80,26 Kb C7 SD 0 0 Não Sim 111609 127000 Kb 23,77 Kb C8 SD 0 0 Sim Não 25500 111130 Kb 2870 Kb C9 SD 0 0 Não Não 25500 111130 Kb 7200 Kb C10 SD 0 0 Sim Sim 25500 111130 Kb 1090 Kb C11 SD 1 5362500 Não Não 9750 111130 Kb 3,42 Kb C12 SD 0 0 Sim Não 12000 111130 Kb 15450 Kb C13 MD 0 0 Sim Não 28433 13000 Kb 8519 Kb C14 MD 1 764400 Não Não 76 8360 Kb 16650 Kb C15 MD 1 787875 Não Não 76 8960 Kb 19973 Kb C16 MD 0 0 Sim Não 10505 13000 Kb 3650 Kb C17 MD 0 0 Sim Não 28433 8960 Kb 4190 Kb C18 MD 0 0 Sim Não 10192 8360 Kb 3030 Kb

Como vimos na Seção 6.2, três grupos de consultas foram analisados: baixo

custo (exibidas na Tabela 6.2 na cor branco), médio custo (exibidas na Tabela 6.2 na

cor cinza claro) e alto custo (exibidas na Tabela 6.2 na cor cinza escuro). A Tabela 6.3

apresenta os tempos médios de processamento obtidos em cada um dos

experimentos. É importante ressaltar que o tempo médio de processamento é igual à

76

soma do tempo de geração dos fragmentos com o tempo de execução dos fragmentos

virtuais e o tempo de composição do resultado final.

Tabela 6.3: Tempo médio de processamento (ms).

Consulta 1 proc. 2 proc. 4 proc. 8 proc. 16 proc. 32 proc.

C1 9427,30 8040,00 6086,70 4708,70 4281,50 2689,20

C2 104157,70 65859,10 35541,30 23281,40 15800,40 10187,00

C3 370972,50 263112,80 136695,30 80305,70 53235,90 28299,60

C4 11743,60 10908,40 7598,50 5986,00 5802,00 2899,60

C5 419864,40 259151,40 125096,50 72767,80 37443,00 18514,20

C6 169319,50 85602,20 46202,30 43560,80 32851,50 27404,00

C7 4341,70 2532,40 2549,60 2643,10 2628,90 1958,20

C8 6434,60 4088,60 2539,80 3163,90 2224,60 2265,40

C9 9351,10 6571,70 4515,20 4056,40 3493,20 2181,30

C10 4936,10 3039,20 2782,20 2705,90 1723,00 1943,20

C11 23481,20 12251,20 7659,10 5333,20 5638,60 2265,40

C12 14078,10 9466,10 6235,40 5235,70 4756,30 2951,90

C13 13671,90 7166,20 5498,10 5262,10 3591,90 2539,90

C14 67778,50 27924,80 16629,60 10692,50 6312,20 4811,90

C15 48592,00 26379,80 18834,40 12442,00 8138,00 6007,50

C16 2728,20 1536,70 764,40 523,90 358,90 301,60

C17 4209,50 2265,50 1729,00 1124,80 633,20 361,70

C18 2818,80 1559,20 949,40 456,30 396,60 299,00

Para melhor visualização dos ganhos de desempenho, obtivemos os tempos de

processamento das consultas no ambiente centralizado e no ambiente distribuído, a

fim de permitir a comparação adequada. Nos gráficos, os tempos de processamento

obtidos no ambiente centralizado estão representados como 100%, enquanto os

tempos obtidos no ambiente distribuído estão representados pela respectiva

porcentagem em relação ao tempo no ambiente centralizado. A Figura 6.4 exibe os

ganhos de desempenho obtidos ao processar as consultas (a) de alto custo e (b) de

médio custo.

Tempo Médio (Consulta - alto custo)

0

20

40

60

80

100

1 2 4 8 16 32Número de processadores

Tem

po to

tal (

%)

C2 C3 C5 C6

Tempo Médio (Consulta - médio custo)

0

20

40

60

80

100


Tem

po to

tal (

%)

C4 C11 C12

(a) Desempenho das consultas C2, C3, C5, C6. (b) Desempenho das consultas C4, C11 e C12.

Figura 6.4: Resultados obtidos nos experimentos com consultas de alto custo e médio custo.

77

Observamos que as consultas C3 e C5 apresentaram os melhores ganhos de

desempenho se comparadas às demais consultas. Isto se deve ao fato de que as

consultas C3 e C5 possuem operações de junção, cuja cardinalidade é bastante alta, o

que requer o processamento de uma grande massa de dados. Além disso, a consulta

C3 possui uma operação de ordenação e C5 possui uma operação de agregação, o

que caracteriza ambas as consultas como sendo de alto custo. Desta forma, o

processamento paralelo dos fragmentos virtuais resulta no aumento da vazão e na

diminuição do tempo total de resposta. Note que a cardinalidade do atributo de

fragmentação (apresentada na Tabela 6.2) é a mesma para ambas as consultas. No

entanto, o melhor desempenho foi obtido por C5, uma vez que o respectivo documento

de resposta possui tamanho reduzido, o que diminui o tempo necessário para a

composição do resultado final. Por outro lado, C3 sofre impactos com a consolidação

dos resultados, uma vez que o documento de resposta gerado é bastante extenso.

As consultas C2 e C6 também são consultas de alto custo, uma vez que C6

possui uma operação de junção, e o atributo de fragmentação virtual relacionado à C2

possui cardinalidade alta. Estas consultas também apresentaram consideráveis

ganhos de desempenho, visto que o processamento paralelo contribui para a

diminuição do tempo total de resposta. Observe que a consulta C6 apresenta maior

custo se comparada à consulta C2 (apresentado na Tabela 6.3), e por isso, obteve

melhor desempenho, quando processada em até quatro processadores. Porém, de

oito a 32 processadores, os ganhos de desempenho de C2 tornaram-se melhores. É

importante ressaltar que as consultas C2, C3 e C5 não sofrem impactos com a

distribuição não uniforme de dados, uma vez que estas consultas não contêm

predicados de seleção que restringem os dados retornados. Assim, cada nó processa

a mesma quantidade de dados. Por isso, estas três consultas apresentaram os

maiores ganhos de desempenho dentre todas as consultas analisadas.

No que se refere às consultas de médio custo, C11 obteve o melhor

desempenho, uma vez que seu tempo de composição dos resultados é reduzido se

comparado aos tempos de composição demandado pelas consultas C4 e C12, visto

que estas geram documentos de resposta maiores. Por este motivo, as consultas C4 e

C12 são afetadas pelos custos com comunicação e transferência de resultados

parciais.

Considerando as consultas de baixo custo (C1, C7, C8, C9 e C10) apresentadas

na Figura 6.5, apenas C1 e C9 apresentaram ganhos consecutivos de desempenho

até 32 processadores, uma vez que são as mais custosas dentre as consultas deste

grupo, como mostrado na Tabela 6.3. Note que C1 possui uma operação de

78

ordenação e um atributo de fragmentação virtual cuja cardinalidade é bastante alta.

Por outro lado, C7, C8 e C10 apresentaram oscilações no tempo médio de

processamento durante os experimentos. A consulta C10 apresentou melhorias no

desempenho até dezesseis processadores, enquanto C7 e C8 apresentaram ganhos

de desempenho até quatro processadores apenas. Consultas como estas sofrem

impactos com a técnica da fragmentação virtual, uma vez que os custos com

comunicação e transferência de dados são maiores que os benefícios obtidos com o

processamento paralelo dos fragmentos virtuais. A Figura 6.5 apresenta os

desempenhos das consultas de baixo custo.

Tempo Médio (Consulta - baixo custo)

0

20

40

60

80

100


Tem

po to

tal (

%)

C1 C9

Tempo Médio (Consulta - baixo custo)

0

20

40

60

80

100


Tem

po to

tal (

%)

C7 C8 C10

(a) Desempenho das consultas C1 e C9. (b) Desempenho das consultas C7, C8 e C10.

Figura 6.5: Resultados obtidos nos experimentos com consultas de baixo custo.

No que se refere às consultas a bases de dados MD, observamos ganhos

consecutivos de desempenho nas consultas C13, C14 e C15 até 32 processadores.

As consultas C14 e C15 não contêm predicados de seleção e, por isso, os dados

processados nestas consultas estão distribuídos uniformemente. Além disso, estas

consultas são mais custosas que C13 e, por este motivo, apresentaram os maiores

ganhos de desempenho. As três consultas são de médio custo e não apresentaram

perdas significativas de desempenho relacionadas à transferência de resultados

parciais, visto que os documentos de resposta gerados possuem tamanho reduzido.

As consultas C16, C17 e C18 são consultas de baixo custo e obtiveram ganhos de

desempenho da ordem de 90%, ou seja, o tempo de resposta ao processá-las com 32

processadores é 90% menor se comparado ao tempo de resposta ao processá-las no

ambiente centralizado. A Figura 6.6 apresenta os desempenhos das consultas (a) de

médio custo e (b) de baixo custo, processadas sobre bases de dados MD.

79

Tempo Médio (Consultas - médio custo)

0

20

40

60

80

100


Tem

po to

tal(%

)

C13 C14 C15

Tempo Médio (Consultas - baixo custo)

0

20

40

60

80

100


Tem

po to

tal (

%)

C16 C17 C18

(a) Desempenho das consultas C13, C14 e C15. (a) Desempenho das consultas C16, C17 e C18.

Figura 6.6: Resultados obtidos nos experimentos com consultas a bases de dados MD.

6.4 Considerações Finais A validação experimental teve como objetivo avaliar a eficiência da fragmentação

virtual sobre bases de dados XML. Os resultados obtidos mostram que a FV é uma

solução apropriada para melhorar o desempenho de consultas no modelo XML. Como

esperado, consultas que demandam o processamento de grandes massas de dados

são beneficiadas pela FV, uma vez que a paralelização do processamento diminui o

tempo total de resposta. Além disso, vimos que consultas sobre elementos XML que

possuem distribuição uniforme apresentaram melhor desempenho, uma vez que

permitem o processamento de cargas de trabalho iguais para todos os nós.

Em geral, as consultas de médio custo apresentaram ganhos de desempenho

significativos. Porém, o desempenho de consultas que geram documentos de resposta

extensos é afetado por custos com comunicação e transferência de dados, visto que o

nó de controle precisa acessar diversas instâncias do SGBDX para obter os resultados

parciais e compor o resultado final. Deste modo, quanto maior o documento de

resposta, maior o impacto no desempenho. A proporção entre os tempos de execução

e composição dos resultados é apresentada no Anexo III.

Por outro lado, consultas de baixo custo não são beneficiadas pela FV, visto que

os custos com comunicação entre os nós envolvidos e a transferência de resultados

parciais são maiores que os ganhos de desempenho resultantes do processamento

paralelo. Assim, aplicar a FV sobre este tipo de consulta pode não ser a melhor

estratégia.

80

Embora algumas consultas não tenham apresentado ganhos de desempenho

contínuos, todas as consultas analisadas apresentaram melhor desempenho com a

técnica da FV se comparado ao desempenho no ambiente centralizado. Os

experimentos mostraram que a maior parte das consultas analisadas apresentou

consideráveis quedas no tempo de resposta. Comparando os tempos médios obtidos

nos ambientes centralizado e distribuído, observamos que o processamento de

algumas consultas tornou-se até 22 vezes mais rápido no ambiente distribuído. O

Anexo II apresenta os ganhos de desempenho obtidos em cada uma das dezoito

consultas utilizadas nos experimentos.

Consultas que possuem predicados de seleção, cujos dados não apresentam

distribuição uniforme, parecem ser afetadas, uma vez que os predicados de seleção

restringem os dados a serem retornados, o que causa desbalanceamento de carga.

Isto se deve ao fato de que alguns nós processam grandes massas de dados,

enquanto outros não processam dado algum, ou processam uma pequena massa de

dados, uma vez que o intervalo de dados referente ao seu fragmento virtual não

satisfaz ao predicado de seleção da consulta envolvida. A abordagem da

fragmentação virtual adaptativa (LIMA et al., 2010) parece ser a melhor estratégia para

eliminar este problema. Como trabalhos futuros, pretendemos adaptar a técnica da

FVA ao modelo XML.

81

7 Conclusões e Trabalhos Futuros

7.1 Considerações Finais O aumento considerável de dados no formato XML e a natureza distribuída de

muitos desses dados implicou a necessidade de desenvolver técnicas que

propiciassem mais desempenho em consultas sobre uma base de dados XML

extensa, considerando o ambiente distribuído. Os trabalhos do estado da arte na

literatura adotam a fragmentação física dos dados como solução deste problema

(FIGUEIREDO et al., 2010; GERTZ; BREMER, 2003; KLING et al., 2011; KURITA et

al., 2007; MA; SCHEWE, 2003; MOREIRA et al., 2011; WILDEMBERG et al., 2003).

Não há trabalhos que utilizem a fragmentação virtual em XML. No entanto, o projeto

de fragmentação física requer o conhecimento prévio das consultas de entrada, o que

torna esta solução inadequada para sistemas de apoio à decisão, onde as consultas

submetidas são sabidamente ad-hoc. Logo, a cada mudança no conjunto de consultas

de entrada, seria necessário um novo projeto de fragmentação física para se adaptar

ao novo cenário, o que tornaria o processo dispendioso.

Considerando a necessidade de soluções de alto desempenho para consultas

XML, as limitações da fragmentação física de dados, no que tange ao cenário de

consultas XML ad-hoc, e a abordagem promissora da fragmentação virtual, até então,

adotada apenas em banco de dados relacionais, surgiu a motivação para este

trabalho: adaptar a fragmentação virtual ao modelo XML. Nossa solução visa a

eliminar o custo com projetos de fragmentação física e garantir maior disponibilidade

de acesso à base de dados, tendo em vista os problemas encontrados nas

abordagens que adotam a fragmentação física sem replicação de dados. Além disso,

nossa solução se baseia na fragmentação virtual dinâmica dos documentos XML, o

que é realizado em tempo de execução e, por isso, não exige o conhecimento prévio

do conjunto de consultas de entrada, podendo se adaptar a cada consulta.

Considerando o custo e a capacidade de expansão de agrupamentos de banco de

dados, adotamos este tipo de ambiente para validar a efetividade de nossa solução.

Em oposição ao modelo relacional, nossa solução independe da existência de

chaves nos documentos XML, uma vez que, no mundo real, a base de dados pode

conter documentos XML cujas chaves não foram definidas pelo usuário em esquemas

XML. Assim, nossa estratégia permite que a escolha do atributo de fragmentação

virtual seja feita de forma automática. A única condição necessária é a existência de

relacionamentos 1:N entre os elementos XML existentes no documento a ser

82

processado. O relacionamento 1:N existe na maioria dos documentos XML, uma vez

que todo documento XML, possui um elemento raiz que, por sua vez, possui diversos

sub-elementos. Deste modo, sempre existe um relacionamento 1:N entre os sub-

elementos e o elemento raiz. Se este relacionamento não existir indica que o

documento XML possui um único elemento (o elemento raiz) ou, todos os sub-

elementos do elemento raiz possuem cardinalidade igual a um. Em casos como estes,

a fragmentação virtual não pode ser aplicada, uma vez que geraria um único

fragmento virtual de tamanho um, o que é desnecessário. A fragmentação virtual é

indicada para processar vários elementos em um documento XML e não se aplica aos

casos em que o processamento da consulta se limita a um único elemento XML, visto

que tal processamento pode ser realizado no ambiente centralizado sem impactos no

desempenho. Vimos também que a estratégia adotada contempla bases de dados do

tipo SD e MD, utilizando soluções distintas para atender às particularidades de ambas

as bases.

Após a seleção do atributo de fragmentação, os fragmentos virtuais são gerados

por meio da reescrita da consulta original, cujos intervalos são delimitados pelo uso da

função XPath position(). Os fragmentos virtuais gerados são processados por nós do

agrupamento, cujos resultados são consolidados pelo nó de controle.

Os experimentos realizados mostram que a FV é uma solução adequada para

obter mais desempenho em consultas XML no ambiente distribuído. Em nossa

avaliação, analisamos consultas de baixo, médio e alto custo, a fim de avaliar o

comportamento de diferentes tipos de consultas ao serem submetidas à técnica da FV.

Embora algumas consultas de médio custo tenham apresentado quedas no

desempenho por gerarem documentos de resposta muito extensos, os resultados

mostram que consultas de médio e alto custo se beneficiam da FV. Por outro lado,

consultas de baixo custo são afetadas pelos custos com comunicação entre os nós

envolvidos e transferência de resultados parciais. Consultas como estas apresentam

maiores prejuízos que benefícios quando processadas em paralelo, conforme

esperado. Apesar disso, o tempo de resposta de todas as consultas analisadas foi

menor no ambiente distribuído e, algumas destas apresentaram tempo de resposta até

22 vezes menor com a FV se comparado ao tempo obtido no ambiente centralizado.

Durante a elaboração deste trabalho, obtivemos a publicação de um artigo no

Journal of Information and Data Management (RODRIGUES et al., 2011), cuja

apresentação foi realizada no Simpósio Brasileiro de Banco de Dados.

83

7.2 Trabalhos Futuros Impactos causados pela distribuição não uniforme dos dados ainda são um

problema em aberto. Os resultados obtidos mostram que consultas cujos fragmentos

virtuais seguem uma distribuição uniforme apresentaram melhor desempenho se

comparadas às consultas cujos fragmentos apresentam distorção de dados. Isto se

deve ao fato de que a distorção de dados acarreta desbalanceamento de carga entre

os nós envolvidos no processamento dos fragmentos. Visando a eliminar esta

limitação, pretendemos adotar a técnica da fragmentação virtual adaptativa (LIMA et

al., 2010) no modelo XML, a fim de permitir a distribuição dinâmica de carga.

As consultas utilizadas nos experimentos apresentam nenhuma ou somente uma

operação de junção, visto que, ao executar consultas com um número maior de

junções, o SGBDX apresentava sinais de parada o que impedia a obtenção do

documento de resposta e dos tempos de processamento gastos. Acreditamos que

este problema pode estar relacionado à quantidade de memória disponível na

máquina onde os experimentos foram realizados e ao tamanho do documento de

entrada a ser processado. No entanto, pretendemos investigar este problema e

realizar experimentos com um número maior de junções a fim de validar a efetividade

da FV em consultas de custo extremamente elevado.

No que se refere à gramática suportada por nossa solução, a mesma não

contempla quantificadores, tais como “some”, “every”, “satisfies”, expressões

condicionais (“if”, “then”, “else”) e operadores matemáticos de adição e multiplicação.

Assim, pretendemos incluir tais expressões e operadores no escopo da gramática

XQuery, para que estas sejam aceitas nas consultas de entrada especificadas pelo

usuário.

Considerando os experimentos realizados em bases de dados MD, os resultados

obtidos são apenas resultados preliminares. Como trabalhos futuros, pretendemos

executar experimentos sobre coleções de dados maiores, utilizando consultas com um

maior nível de complexidade, a fim de identificar possíveis gargalos, ainda não

identificados nos experimentos preliminares.

Os experimentos realizados mostram a eficácia da FV no modelo XML. Porém, a

análise de consultas analíticas XML e um número maior de experimentos devem ser

realizados para comprovar a efetividade de nossa solução para uma variedade maior

de consultas, evitando assim, problemas não previstos durante a análise dos

resultados aqui apresentados.

84

8 Referências Bibliográficas

AKAL, F.; BÖHM, K.; SCHEK, H.-J. OLAP Query Evaluation in a Database Cluster: A Performance Study on Intra-Query Parallelism . East European Conference on Advances in Databases and Information Systems. Anais ... London, UK: p. 218-231, 2002.

AMAGASA, T.; KITAGAWA, H.; MACHDI, I. XML data partitioning schemes for parallel holistic twig joins. International Journal of Web Information Systems , v. 5, n. 2, p. 151-194, 2009.

ANDRADE, A.; RUBERG, G.; BAIÃO, F.; BRAGANHOLO, V.; MATTOSO, M. Efficiently Processing XML Queries over Fragmented Repositories with PartiX . International Workshop on Database Technologies for Handling XML Information on the Web (DATAX). Anais ... Munich, Germany: p. 150-163, 2006.

ATAY, M.; CHEBOTKO, A.; LIU, D.; LU, S.; FOTOUHI, F. Efficient schema-based XML-to-Relational data mapping. Information Systems , v. 32, n. 3, p. 458-476, 2007.

BABU, S.; BIZARRO, P. Adaptive Query Processing in the Looking Glass . Conference on Innovative Data Systems Research (CIDR). Asilomar, CA, USA: p. 238-249, 2005.

BOAG, S.; CHAMBERLIN, D.; FERNANDEZ, M. F.; FLORESCU, D.; ROBIE, J.; SIMÉON, J. XQuery 1.0: An XML Query Language . Disponível em: <www.w3.org/TR/xquery>. Acesso em: 9 jun. 2011.

BRAY, T.; PAOLI, J.; SPERBERG, M.; MALER, E.; YERGEAU, F. Extensible Markup Language (XML) 1.0 (Fifth Edition) . Disponível em: <http://www.w3.org/TR/REC-xml/>. Acesso em: 3 nov. 2011.

CARNEIRO FILHO, H. J. A.; MOREIRA, L. O.; SOUSA, F. R. C. Sedna Admin . Disponível em: <http://sednaadmin.great.ufc.br>. Acesso em: 3 nov. 2011.

CARPENTER, B.; GETOV, V.; JUDD, G.; SKJELLUM, A.; FOX, G. MPJ: MPI-like message passing for Java. Concurrency: Practice and Experience , v. 12, n. 11, p. 1019-1038, 2000.

CLARK, J.; DEROSE, S. XML Path Language (XPath) Version 1.0 . Disponível em: <http://www.w3.org/TR/1999/REC-xpath-19991116/>. Acesso em: 18 nov. 2010.

COSTA, R. L. C. Alocação de Dados e Distribuição de Carga para Exec ução Paralela da Estratégia BLAST de Comparação de Seqüências . Rio de Janeiro, Brasil: Pontifícia Universidade Católica (PUC-RJ), 2002.

DEUTSCH, A.; FERNANDEZ, M.; SUCIU, D. Storing semistructured data with STORED. SIGMOD. Anais ... Philadelphia, Pennsylvania: p. 431-442, 1999.

DEUTSCH, A.; LEVY, A.; FERNANDEZ, M.; MAIER, D. Querying XML data. IEEE DATA ENGINEERING BULLETIN , v. 22, n. 3, p. 10-18, 1999.

ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems . 5. ed. Addison Wesley, 2006.

85

FALLSITE, D.; WALMSLEY, P. XML Schema Part 0: Primer Second Edition . Disponível em: <http://www.w3.org/TR/xmlschema-0/>. Acesso em: 3 nov. 2011.

FIEBIG, T.; HELMER, S.; KANNE, C.-C.; MOERKOTTE, G.; NEUMANN, J.; SCHIELE, R.; WESTMANN, T. Anatomy of a native XML base management system. The VLDB Journal , v. 11, n. 4, p. 292-314, 2002.

FIGUEIREDO, G.; BRAGANHOLO, V.; MATTOSO, M. Processing Queries over Distributed XML Databases. Journal of Information and Data Management , v. 1, n. 3, p. 455-470, 2010.

FLORESCU, D.; LEVY, A.; MANOLESCU, I.; SUCIU, D. Query optimization in the presence of limited access patterns. SIGMOD Rec., v. 28, p. 311–322, 1999.

FOMICHEV, A.; GRINEV, M.; KUZNETSOV, S. Sedna: A Native XML DBMS . International Conference on Current Trends in Theory and Practice of Computer Science (SOFSEM). Anais ... Merin, Czech Republic: p. 272-281, 2006.

FURTADO, C.; LIMA, A.; PACITTI, E.; VALDURIEZ, P.; MATTOSO, M. Physical and virtual partitioning in OLAP database clusters . International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD). Anais ... Washington, DC, USA: p. 143-150, 2005

GERTZ, M.; BREMER, J.-M. Distributed XML Repositories: Top-down Design and Transparent Query Processing . Technical Report, 2003.

GIERSCH, A.; ROBERT, Y.; VIVIEN, F. Scheduling tasks sharing files on heterogeneous master-slave platforms . Euromicro Conference on Parallel, Distributed and Network-Based Processing. Anais ... Lugano, Switzerland: p. 364-371, 2004.

HUANG, Y.-F; CHEN, J.-H. Fragment Allocation in Distributed Database Design. Journal of Information Science and Engineering , v. 17, p. 491-506, 2001.

ISHIKAWA, H.; KUBOTA, K.; KANEMASA, Y.; NOGUCHI, Y. The design of a query language for XML data . International Workshop on Database and Expert Systems Applications (DEXA). Anais ... Florence, Italy: p. 919-922, 1999.

IVES, Z. G.; LEVY, A. Y.; WELD, D. S.; FLORESCU, D.; FRIEDMAN, M. Adaptive Query Processing for Internet Applications. Bulletin of the Technical Committee on Data Engineering , v. 23, n. 2, p. 19-26, 2000.

JAGADISH, H. V.; AL-KHALIFA, S.; CHAPMAN, A.; LAKSHMANAN, L. V. S.; NIERMAN, A.; PAPARIZOS, S.; PATEL, J. M.; SRIVASTAVA, D.; WIWATWATTANA, N. TIMBER: A native XML database. The VLDB Journal , v. 11, n. 4, p. 274-291, 2002.

KIDO, K.; AMAGASA, T.; KITAGAWA, H. Processing XPath Queries in PC-Clusters Using XML Data Partitioning . International Conference on Data Engineering Workshops. Anais ... Atlanta, GA, USA: p. 114-119, 2006.

KLING, P.; OZSU, M. T.; DAUDJEE, K. Generating efficient execution plans for vertically partitioned XML databases. PVLDB , v. (to appear), 2011.

86

KOSSMANN, D. The state of the art in distributed query processing. ACM COMPUTING SURVEYS, v. 32, n. 4, p. 422-469, 2000.

KURITA, H.; HATANO, K.; MIYAZAKI, J.; UEMURA, S. Efficient Query Processing for Large XML Data in Distributed Environments . International Conference on Advanced Information Networking and Applications (AINA). Anais ... Niagara Falls, Canada: p. 317-322, 2007.

LIMA, A. A.; FURTADO, C.; VALDURIEZ, P.; MATTOSO, M. Parallel OLAP query processing in database clusters with data replication. Distributed and Parallel Databases , v. 25, n. 1-2, p. 97–123, 2009.

LIMA, A.; MATTOSO, M.; VALDURIEZ, P. Adaptive Virtual Partitioning for OLAP Query Processing in a Database Cluster. Journal of Information and Data Management , v. 1, n. 1, p. 75-88, 2010.

MA, H.; SCHEWE, D. Fragmentation of XML Documents . Simpósio Brasileiro de Banco de Dados (SBBD). Anais ... Manaus, AM, Brasil: p. 200-214, 2003.

MAHBOUBI, H.; DARMONT, J. Enhancing XML data warehouse query performance by fragmentation . ACM symposium on Applied Computing. Anais ... Honolulu, Hawaii: p. 1555-1562, 2009.

MAHBOUBI, H.; DARMONT, J. XWeB: the XML warehouse benchmark . TPC Technology Conference on Performance Evaluation, Measurement and Characterization of Complex Systems. Anais ... Singapore: p. 185-203, 2010.

MALHOTRA, A.; MELTON, J.; WALSH, N.; KAY, M. XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition) . Disponível em: <http://www.w3.org/TR/2010/REC-xpath-functions-20101214/>. Acesso em: 3 nov. 2011.

MATTOSO, M. Virtual Partitioning. Encyclopedia of database systems . L. Liu, M. T. Özsu, 2009a. p. 3340-3341.

MATTOSO, M. Database Clusters. Encyclopedia of database systems . L. Liu, M. T. Özsu, 2009b. p. 700-704.

MATTOSO, M.; SILVA, G. Z.; LIMA, A. A. B.; BAIÃO, F. A.; BRAGANHOLO, V. P.; AVELEDA, A.; MIRANDA, B.; ALMENTERO, B. K.; COSTA, M. N. ParGRES: Middleware para Processamento Paralelo de Consultas OLAP em Clusters de Banco de Dados . Simpósio Brasileiro de Banco de Dados (SBBD). Anais ... Uberlândia, MG, Brasil: p. 19-24, 2005.

MEIER, W. eXist: An Open Source Native XML Database. Web, Web-Services, and Database Systems , v. LNCS 2593, p. 169—183, 2003.

MICROSOFT. Creating clustered Indexes . Disponível em: <http://msdn.microsoft.com/en-us/library/ms186342.aspx>. Acesso em: 3 nov. 2011.

MOREIRA, L. O.; MACHADO, J. C. Um Mecanismo para Transações Distribuídas com Suporte a Dados XML . Simpósio Brasileiro de Banco de Dados. Anais ... João Pessoa, PB - Brazil: p. 37-42, 2007.

87

MOREIRA, L. O.; SOUSA, F. R. C.; MACHADO, J. C. A distributed concurrency control mechanism for XML data. Journal of Computer and System Sciences , v. 77, n. 6, p. 1009-1022, 2011.

MORIN, S.; KOREN, I.; KRISHNA, C. M. JMPI: implementing the message passing standard in Java . Parallel and Distributed Processing Symposium. Anais ... Washington, DC, USA: p. 118-123, 2002.

NAUGHTON, J.; DEWITT, D.; MAIER, D.; ABOULNAGA, A.; CHEN, J.; GALANIS, L.; KANG, J.; KRISHNAMURTHY, R.; LUO, Q.; PRAKASH, N.; RAMAMURTHY, R.; SHANMUGASUNDARAM, J.; TIAN, F.; TUFTE, K.; VIGLAS S. The Niagara Internet Query System. IEEE DATA ENGINEERING BULLETIN , v. 24, p. 27-33, 2001.

OGASAWARA, E.; OLIVEIRA, D.; CHIRIGATI, F.; BARBOSA, C. E.; ELIAS, R.; BRAGANHOLO, V.; COUTINHO, A.; MATTOSO, M.; Exploring many task computing in scientific workflows . Workshop on Many-Task Computing on Grids and Supercomputers. Anais ... Portland, Oregon: p. 1-10, 2009.

ÖZSU, M. T.; VALDURIEZ, P. Principles of Distributed Database Systems . 3. ed. New York: Springer, 2011.

PAES, M.; LIMA, A. A. B.; VALDURIEZ, P.; MATTOSO, M. High-Performance Query Processing of a Real-World OLAP Database with ParGR ES. High Performance Computing for Computational Science (VECPAR). Anais ... Toulouse, France: p. 188-200, 2008.

PAPARIZOS, S.; LAKSHMANAN, L. V. S. Tree Logical Classes for Efficient Evaluation of XQuery . SIGMOD International Conference on Management of Data. Anais ... Paris, France: p. 71-82, 2004.

PLESHACHKOV, P. Transaction Management in XML Database Management Systems . Doctoral Thesis. Moscow, Russia: Institute for System Programming of Russian Academy of Sciences, 2006.

RODRIGUES, C.; BRAGANHOLO, V.; MATTOSO, M. Virtual Partitioning ad-hoc Queries over Distributed XML Databases. Journal of Information and Data Management , v. 2, n. 3, p. 495-510, 2011.

RÖHM, U.; BÖHM, K.; SCHEK, H.-J. OLAP Query Routing and Physical Design in a Database Cluster . Conference on Extending Database Technology: Advances in Database Technology (EDBT). Anais ... London, UK: p. 254-268, 2000.

SCHMIDT, A.; WAAS, F.; KERSTEN, M. L.; CAREY, M. J.; MANOLESCU, I.; BUSSE, R. XMark: A Benchmark for XML Data Management . International Conference on Very Large Data Bases (VLDB). Anais ... Hong Kong, China: p. 974-985, 2002.

SCHÖNING, H. Tamino - A DBMS designed for XML . International Conference on Data Engineering. Anais ... Heidelberg, Germany: p. 149-154, 2001.

SHAFI, A.; CARPENTER, B.; BAKER, M.; TABOADA, G. L. MPJExpress: A Implementation of MPI in Java . Disponível em: <http://mpj-express.org/docs/guides/windowsguide.pdf>. Acesso em: 13 dez. 2010.

88

SHEPHERD, J.; HARANGSRI, B.; CHEN, H. L.; NGU, A. A Two-Phase Approach to Data Allocation in Distributed Databases . Database Systems for Advanced Applications (DASFAA). Anais ... Singapore: p. 380-387, 1995.

SOUSA, D. X.; LIFSCHITZ, S.; VALDURIEZ, P. BLAST Distributed Execution on Partitioned Databases with Primary Fragments . High Performance Computing for Computational Science (VECPAR). Anais ... Toulouse, France: p. 544-554, 2008.

TONG, W.; YE, H.; YAO, W. PJMPI: pure Java implementation of MPI . Conference/Exhibition on High Performance Computing in the Asia-Pacific Region. Anais ... Beijing, China: p. 533-535, 2000.

TPC. TPC-H - Homepage . Disponível em: <http://www.tpc.org/tpch/>. Acesso em: 28 mar. 2011.

WALDVOGEL, M.; KRAMIS, M.; GRAF, S. Distributing XML with Focus on Parallel Evaluation . Databases, Information Systems and Peer-to-Peer Computing (DBISP2P). Anais ... Auckland, New Zealand: p. 55-67, 2008.

WILDEMBERG, M.; PAULA, M.; BAIÃO, F.; MATTOSO, M. Alocação de dados em Bancos de Dados Distribuídos . Simpósio Brasileiro de Banco de Dados (SBBD). Anais ... Manaus, AM, Brasil: p. 215-228, 2003.

WIWATWATTANA, N.; JAGADISH, H. V.; LAKSHMANAN, L. V. .; SRIVASTAVA, D. X^ 3: A Cube Operator for XML OLAP . IEEE International Conference on Data Engineering. Anais ... Istanbul, Turkey: p. 916-925, 2007.

YAO, B. B.; ÖZSU, M. T.; KEENLEYSIDE, J. XBench - A Family of Benchmarks for XML DBMSs . Efficiency and Effectiveness of XML Tools and Techniques and Data Integration over the Web-Revised Papers. Anais ... London, UK: p. 162-164, 2003.

ZHANG, J.; WANG, W.; LIU, H.; ZHANG, S. X-warehouse: Building Query Pattern-driven Data . International conference on World Wide Web. Anais ... New York, NY, USA: p. 896–897, 2005.

89

9 Anexo I - Consultas XQuery utilizadas nos experim entos Consulta C1 <results>

{ for $c in doc('dblp.xml')/dblp/inproceedings where $c/year >1984 and $c/year <=2007 return <inproceeding> {$c/title} </inproceeding> } </results>

Consulta C2 <results> { for $c in doc('dblp.xml')/dblp/inproceedings return <inproceeding> {$c/title} </inproceeding> } </results>

Consulta C3 <results> { for $it in doc('xmlDataBaseXmark.xml')/site/regions/samerica/item for $pe in doc('xmlDataBaseXmark.xml')/site/people/person where $pe/profile/interest/@category = $it/incategory/@category return <people> {$pe} </people> } </results>

Consulta C4 <results> { for $inp in doc('dblp.xml')/dblp/inproceedings where count($inp/author) = 1 return <inproceeding_one_author> {$inp} </inproceeding_one_author> } </results>

90

Consulta C5 <results> { for $it in doc('xmlDataBaseXmark.xml')/site/regions/asia/item for $pe in doc('xmlDataBaseXmark.xml')/site/people/person where $pe/profile/interest/@category = $it/incategory/@category return <people> {$pe} </people> } </results>

Consulta C6 <results> { for $it in doc('xmlDataBaseXmark.xml')/site/regions/samerica/item for $pe in doc('xmlDataBaseXmark.xml')/site/people/person where $pe/profile/interest/@category = $it/incategory/@category and $it/incategory/@category = "category251" and $pe/profile/education = "Graduate School" return <people> {$pe} </people> } </results>

Consulta C7 <results> { for $art in doc('dblp.xml')/dblp/article where count($art/author) >=2 and $art/year >= 2000 return <publication> {$art} </publication> } </results>

Consulta C8 <results> { for $pe in doc('xmlDataBaseXmark.xml')/site/people/person let $int := $pe/profile/interest where $pe/profile/business = "Yes" and count($int) > 1 order by $pe/name return <people> {$pe} </people> } </results>

91

Consulta C9 <results> { for $p in doc('xmlDataBaseXmark.xml')/site/people/person where $p/profile/@income > 10000 return <people> {$p} </people> } </results>

Consulta C10 <results> { for $p in doc('xmlDataBaseXmark.xml')/site/people/person let $e := $p/homepage where count($e) = 0 return <people_without_homepage> {$p/name} </people_without_homepage> } </results>

Consulta C11 <results> { for $it in doc('xmlDataBaseXmark.xml')/site/regions/africa/item for $co in doc('xmlDataBaseXmark.xml')/site/closed_auctions/closed_auction where $co/itemref/@item = $it/@id and $it/payment = "Cash" return <itens> {$co/price} {$co/date} {$co/quantity} {$co/type} {$it/payment} {$it/location} {$it/from} {$it/to} </itens> } </results>

Consulta C12 <results> { for $op in doc('xmlDataBaseXmark.xml')/site/open_auctions/open_auction let $bd := $op/bidder where count($op/bidder) > 5 return <open_auctions_with_more_than_5_bidders> <auction> {$op} </auction> <qty_bidder> {count($op/bidder)} </qty_bidder> </open_auctions_with_more_than_5_bidders> } </results>

92

Consulta C13 <results>

{ for $art in collection('papers')/dblp/article where count($art/author) >=2 and $art/year >= 2000 return <publication> {$art} </publication> } </results>

Consulta C14 <results> { for $it in collection('samericaItens')/orders/itens/item for $pe in collection('samericaItens')/orders/people/person where $pe/profile/interest/@category = $it/incategory/@category return <people> {$pe} </people> } </results>

Consulta C15 <results> { for $it in collection('asiaItens')/orders/itens/item for $pe in collection('asiaItens')/orders/people/person where $pe/profile/interest/@category = $it/incategory/@category return <people> {$pe} </people> } </results>

Consulta 16 <results>{ for $pe in collection('asiaItens')/orders/people/person let $wt := $pe//watch where count($wt) > 1 return <people>{$pe}</people> }</results>

Consulta C17 <results>{ for $at in collection('papers')/dblp/article where count($at/author) > 2 return <article> {$at/title} {$at/author} {$at/year} {$at/journal} {$at/number} {$at/pages} <qtde_authors>{count($at/author)}</qtde_authors> </article> }</results>

93

Consulta C18 <results>{

for $pe in collection('samericaItens')/orders/people/person let $wt := $pe//watch where count($wt) > 1 return <people> {$pe/name} {$pe/emailaddress} {$pe/address} {$pe/profile} {$pe/watches} </people> }</results>

94

10 Anexo II – Tempo de processamento das consultas

Tempo de processamento total

0 20 40 60 80 100

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo total (%)

1 processador 2 processadores 4 processadores

8 processadores 16 processadores 32 processadores

95

Tempo de processamento total

0 20 40 60 80 100

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12C

onsu

ltas

Tempo total (%)

1 processador 2 processadores 4 processadores

8 processadores 16 processadores 32 processadores

96

11 Anexo III – Proporção entre os tempos de execuçã o e composição dos resultados

Proporção dos tempos de execução e composição (dois processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo de Execução

Tempo de Composição do resultado

97

Proporção dos tempos de execução e composição (dois processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12

Con

sulta

s

Tempo de Execução


98

Proporção dos tempos de execução e composição (quatro processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo de Execução


99

Proporção dos tempos de execução e composição (quatro processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12

Con

sulta

s

Tempo de Execução


100

Proporção dos tempos de execução e composição (oito processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo de Execução


101

Proporção dos tempos de execução e composição (oito processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12

Con

sulta

s

Tempo de Execução


102

Proporção dos tempos de execução e composição (dezesseis processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo de Execução


103

Proporção dos tempos de execução e composição (dezesseis processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12

Con

sulta

s

Tempo de Execução


104

Proporção dos tempos de execução e composição (32 processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C13

Consulta C14

Consulta C15

Consulta C16

Consulta C17

Consulta C18

Con

sulta

s

Tempo de Execução


105

Proporção dos tempos de execução e composição (32 processadores)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Consulta C1

Consulta C2

Consulta C3

Consulta C4

Consulta C5

Consulta C6

Consulta C7

Consulta C8

Consulta C9

Consulta C10

Consulta C11

Consulta C12

Con

sulta

s

Tempo de Execução


PROCESSAMENTO PARALELO DE CONSULTAS...

Documents

Transcript of PROCESSAMENTO PARALELO DE CONSULTAS...