processamento paralelo de consultas...
TRANSCRIPT
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
PROCESSAMENTO PARALELO DE CONSULTAS SOBRE FRAGMENTOS
VIRTUAIS DE DOCUMENTOS XML
Carla Amaral de Sant’ Anna Rodrigues
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
Vanessa Braganholo Murta
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.)
PROCESSAMENTO PARALELO DE CONSULTAS SOBRE FRAGMENTOS
VIRTUAIS DE DOCUMENTOS XML
Carla Amaral de Sant’ Anna Rodrigues
Dezembro/2011
Orientadores: Marta Lima de Queirós Mattoso
Vanessa Braganholo Murta
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
Carla Amaral de Sant’ Anna Rodrigues
December/2011
Advisors: Marta Lima de Queirós Mattoso
Vanessa Braganholo Murta
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>
(a) Árvore XML. (b) Documento XML.
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>
(a) Árvore XML. (b) Documento XML.
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
FROM cliente cli, pedido ped
WHERE ped.cliente_id = cli.cliente_id
AND ped.qtde_parc_rest > 0
AND ped.pedido_id >= 1 and ped.pedido_id <500001
Q2: SELECT cli.nome, cli.e_mail,
ped.preco_total, ped.qtde_parc_restantes
FROM cliente cli, pedido ped
WHERE ped.cliente_id = cli.cliente_id
AND ped.qtde_parc_rest > 0
AND ped.pedido_id >= 500001 and ped.pedido_id <1000 001
Q3: SELECT cli.nome, cli.e_mail,
ped.preco_total, ped.qtde_parc_restantes
FROM cliente cli, pedido ped
WHERE ped.cliente_id = cli.cliente_id
AND ped.qtde_parc_rest > 0
AND ped.pedido_id >= 1000001 and ped.pedido_id <150 0001
Q4: SELECT cli.nome, cli.e_mail,
ped.preco_total, ped.qtde_parc_restantes
FROM cliente cli, pedido ped
WHERE ped.cliente_id = cli.cliente_id
AND ped.qtde_parc_rest > 0
AND ped.pedido_id >= 1500001 and ped.pedido_id <200 0001
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
WHERE DATEDIFF(year, data_nascimento, getdate ()) > 26
AND (cpf LIKE ‘6%’ OR cpf LIKE ‘7%’)
29
Q5: SELECT nome, e_mail
FROM cliente
WHERE DATEDIFF(year, data_nascimento, getdate ()) > 26
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:field xpath="@id"/>
</xs:key>
</xs:element>
<xs:element name="parcelasPedidos" type="TparcelasPedidos">
<xs:key name="parcelaId">
<xs:selector xpath="parcelaPedido"/>
<xs:field xpath="@id"/>
</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="id" type="xs:integer" use="required"/>
<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:attribute name="id" 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>
<data_nasc>1984-08-29</data_nasc>
<e_mail>[email protected]</e_mail>
</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 id="25406" clienteRef="20354">
<preco_total>81.60</preco_total>
<qtde_parcelas>3</qtde_parcelas>
<parc_rest>3</parc_rest>
<data_comp>2010-09-22</data_comp>
</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>
<parcelaPedido id="152002" pedidoRef="120">
<data_venc>2010-10-15</data_venc>
<valor_parcela>75.00</valor_parcela>
<mes_referencia>10/2010</mes_referencia>
<situacao_parc>aguard. pagto</situacao_parc>
</parcelaPedido>
<parcelaPedido id="167807" pedidoRef="25406">
<data_venc>2010-09-30</data_venc>
<valor_parcela>27.20</valor_parcela>
<mes_referencia>09/2010</mes_referencia>
<situacao_parc>inadimplente</situacao_parc>
</parcelaPedido>
<parcelaPedido id="167808" pedidoRef="25406">
<data_venc>2010-10-30</data_venc>
<valor_parcela>27.20</valor_parcela>
<mes_referencia>10/2010</mes_referencia>
<situacao_parc>aguard.pagto</situacao_parc>
</parcelaPedido>
<parcelaPedido id="167809" pedidoRef="25406">
<data_venc>2010-11-30</data_venc>
<valor_parcela>27.20</valor_parcela>
<mes_referencia>11/2010</mes_referencia>
<situacao_parc>aguard. pagto</situacao_parc>
</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>
<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>
<data_nasc>1984-08-29</data_nasc>
<e_mail>[email protected]</e_mail>
</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>
... </pedidos>
<parcelasPedidos>
<parcelaPedido id="167809" pedidoRef="25406">
<data_venc>2010-11-30</data_venc>
<valor_parcela>27.20</valor_parcela>
<mes_referencia>11/2010</mes_referencia>
<situacao_parc>aguard. pagto</situacao_parc>
</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]
where ends-with($cli/e_mail, '@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$cli/e_mail}
</cliente>}
</results>
(a) Fragmento correspondente ao intervalo [1; 50001[.
<results> {
for $cli in doc('compraEletronica.xml')// cliente [position() >= 50001
and position() < 100001]
where ends-with($cli/e_mail, '@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$cli/e_mail}
</cliente>}
</results>
(b) Fragmento correspondente ao intervalo [50001; 100001[.
<results> {
for $cli in doc('compraEletronica.xml')// cliente[position() >= 100001
and position() < 150001]
where ends-with($cli/e_mail, '@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$cli/e_mail}
</cliente>}
</results>
(c) Fragmento correspondente ao intervalo [100001; 150001[.
<results> {
for $cli in doc('compraEletronica.xml')// cliente[position() >= 150001
and position() < 200001]
where ends-with($cli/e_mail, '@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$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
where $ped/@clienteRef = $cli/@id
and $par/@pedidoRef = $ped/@id
and $ped/parc_rest > 0
and $par/situacao = 'aguard. pagto'
return
<cliente> {$cli/nome}
{$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
where $ped/@clienteRef = $cli/@id
and $par/@pedidoRef = $ped/@id
and $ped/parc_rest > 0
and $par/situacao = 'aguard. pagto'
return
<cliente> {$cli/nome}
{$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
[position() >= 1 and position() <
150001]
/compraEletronica/parcelasPedidos
/ parcelaPedido[position() >= 1 and
position() < 250001]
/compraEletronica/clientes/ cliente
[position() >= 100001 and position() <
200001]
/compraEletronica/pedidos/ pedido
[position() >= 1 and position() <
150001]
/compraEletronica/parcelasPedidos
/ parcelaPedido[position() >= 1 and
position() < 250001]
(a) Fragmento para a 1ª combinação. (e) Fragmento p ara a 5ª combinação.
/compraEletronica/clientes/ cliente
[position() >= 1 and position() <
100001]
/compraEletronica/pedidos/ pedido
[position() >= 1 and position() <
150001]
/compraEletronica/parcelasPedidos/
parcelaPedido[position() >= 250001 and
position() < 500001]
/compraEletronica/clientes/ cliente
[position() >= 100001 and position() <
200001]
/compraEletronica/pedidos/ pedido
[position() >= 1 and position() <
150001]
/compraEletronica/parcelasPedidos
/ parcelaPedido[position() >= 250001 and
position() < 500001]
(b) Fragmento para a 2ª combinação. (f) Fragmento p ara a 6ª combinação.
/compraEletronica/clientes/ cliente
[position() >= 1 and position() <
100001]
/compraEletronica/pedidos/ pedido
[position() >= 150001 and position() <
300001]
/compraEletronica/parcelasPedidos
/ parcelaPedido[position() >= 1 and
position() < 250001]
/compraEletronica /clientes/cliente
[position() >= 100001 and position() <
200001]
/compraEletronica/pedidos/pedido
[position() >= 150001 and position() <
300001]
/compraEletronica/parcelasPedidos
/parcelaPedido [position() >= 1 and
position() < 250001]
(c) Fragmento para a 3ª combinação. (g) Fragmento p ara a 7ª combinação.
/compraEletronica/clientes/ cliente
[position() >= 1 and position() <
100001]
/compraEletronica/pedidos/ pedido
[position() >= 150001 and position() <
300001]
/compraEletronica/parcelasPedidos
/ parcelaPedido [position() >= 250001 and
position() < 500001]
/compraEletronica/clientes/ cliente
[position() >= 100001 and position() <
200001]
/compraEletronica/pedidos/ pedido
[position() >= 150001 and position() <
300001]
/compraEletronica/parcelasPedidos
/ parcelaPedido[position() >= 250001 and
position() < 500001]
(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
where ends-with($cli/e_mail, '@cos.ufrj.br')
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
position() < 100001]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$cli/e_mail}
</cliente>}
</results>
<results> {
for $cli in collection('compras')
// cliente[position() >= 100001 and
position() < 200001]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$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
let $d2:= doc('compra2.xml',
'compras')//cliente
let $d3:= doc('compra3.xml',
'compras')//cliente
let $d4:= doc('compra4.xml',
'compras')//cliente
for $d in ($d1 | $d2 | $d3 | $d4)
// cliente[position >= 1 and
position < 100001]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$cli/e_mail}
</cliente>}
</results>
<results> {
let $d1:= doc('compra1.xml',
'compras')//cliente
let $d2:= doc('compra2.xml',
'compras')//cliente
let $d3:= doc('compra3.xml',
'compras')//cliente
let $d4:= doc('compra4.xml',
'compras')//cliente
for $d in ($d1 | $d2 | $d3 | $d4)
// cliente[position >= 100001 and
position < 200001]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$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
where ends-with($cli/e_mail, '@cos.ufrj.br')
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]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$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]
where ends-with($cli/e_mail,
'@cos.ufrj.br')
return
<cliente> {$cli/nome}
{$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
1 2 4 8 16 32Número de processadores
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
1 2 4 8 16 32Número de processadores
Tem
po to
tal (
%)
C1 C9
Tempo Médio (Consulta - baixo custo)
0
20
40
60
80
100
1 2 4 8 16 32Número de processadores
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
1 2 4 8 16 32Número de processadores
Tem
po to
tal(%
)
C13 C14 C15
Tempo Médio (Consultas - baixo custo)
0
20
40
60
80
100
1 2 4 8 16 32Número de processadores
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado
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
Tempo de Composição do resultado