Rodrigo Costa Mateus

Transcrição

1 Pós-Graduação em Ciência da Computação CSB-INDEX: Um Índice Espacial para Data Warehouses Geográficos na Nuvem Por Rodrigo Costa Mateus Dissertação de Mestrado Universidade Federal de Pernambuco RECIFE, SETEMBRO/2013

2 UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RODRIGO COSTA MATEUS CSB-INDEX: Um Índice Espacial para Data Warehouse Geográficos na Nuvem ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO. ORIENTADOR(A): Valéria Cesário Times, PhD RECIFE, SETEMBRO/2013

3 Dissertação de Mestrado apresentada por Rodrigo Costa Mateus à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título CSB-INDEX: Um Índice Espacial para Data Warehouses Geográficos na Nuvem orientada pela Profa. Valéria Cesário Times e aprovada pela Banca Examinadora formada pelos professores: Profa. Ana Carolina Brandão Salgado Centro de Informática / UFPE Profa. Cristina Dutra de Aguiar Ciferri Departamento de Ciências da Computação/ USP Profa. Valéria Cesário Times Centro de Informática / UFPE Visto e permitida a impressão. Recife, 5 de setembro de Prof. Edna Natividade da Silva Barros Coordenador da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

4 Catalogação na fonte Bibliotecária Monick Raquel Silvestre da Silva, CRB Mateus, Rodrigo Costa CSB-Index: um índice espacial para data warehouses geográficos na nuvem / Rodrigo Costa Mateus. - Recife: O Autor, f., il., fig., tab. Orientadora: Valéria Cesário Times. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, Inclui referências. 1. Banco de dados. 2. Processamento multidimensional. 3. Data warehouse I. Times, Valéria Cesário (orientadora). II. Título CDD (23. ed.) MEI

5 Aos meus pais, João Mateus (In memorian) e Dauricy Mateus iii

6 AGRADECIMENTOS Serei eternamente grato aos meus pais por tudo. Jamais esquecerei todo o esforço realizado pelo meu pai para garantir a mim, e aos meus irmãos, alegrias momentâneas e, mais do que isso, um caráter honesto e um futuro digno. Sempre dedicado à família, lutou sem reclamar para nos proteger e nos criar. Ao meu pai que tanto fez por mim, meu muito obrigado. Agradeço a minha melhor amiga, minha mãe. Ela que sempre esteve ao meu lado, que sempre torceu por mim, que vibrou com minhas conquistas e que me apoiou após meus fracassos. Sou grato ainda por suas posições firmes que modelaram meu caráter, me mostraram o caminho e por todo seu imenso carinho e amor, a mim dedicados. Aos meus irmãos, que sempre torceram por mim e me apoiaram. Aos meus irmãos, meus agradecimentos. Sou muito grato aos professores do Centro de Informática da Universidade Federal de Pernambuco por terem me transmitido um pouco de seus conhecimentos, especialmente a Professora Valéria Times. Ela, símbolo de paixão pelo trabalho, meu muito obrigado pela atenção, pela paciência, pela tolerância, pelas oportunidades, pelos merecidos puxões de orelha, pelas palavras amigas nos momentos mais difíceis e pela amizade. Agradeço também aos colegas de pós-graduação em especial a Maria Carolina, Andresson Firmino, Vinícius Monteiro e Claudivan Lopes. Obrigado pelas oportunidades que foram possíveis compartilhar conhecimentos, por estarem sempre disponíveis para me ajudar, me ensinar, me aconselhar, me corrigir e por proporcionar bons momentos. Aos meus amigos, pessoas especiais que sempre estiveram ao meu lado, sempre me apoiaram e me compreenderam. A todos, meu sincero e profundo MUITO OBRIGADO! iv

7 RESUMO Plataformas de computação em nuvem proveem escalabilidade, elasticidade e tolerância a falhas aos sistemas computacionais. Além disso, elas foram projetadas para lidar com grande volume de dados utilizando recursos computacionais quase ilimitados. Data Warehouse Geográfico (DWG) se tornou uma das principais tecnologias de suporte à decisão, pois promove a integração do Data Warehouse convencionais, das ferramentas On-Line Analytical Processing e dos Sistemas de Informações Geográficas. Por esse motivo, um DWG viabiliza a análise no contexto espacial aliada à execução de consultas multidimensionais envolvendo grande volume de dados. A combinação da computação em nuvem e dos DWG traz consigo o desafio de prover análises de dados espaciais em um ambiente distribuído. Além disso, há a preocupação com o desempenho no processamento de consultas, que utilizam janelas de consultas espaciais ad-hoc e realizam várias junções entre as tabelas de dimensões e de fatos. Embora existam eficientes mecanismos para aumentar o desempenho do processamento de consultas em DWG, como as estruturas de indexação, elas se tornam impróprias aos DWG mantidos em nuvem porque estes mecanismos não lidam com a recuperação de dados em ambientes distribuídos. Nesta dissertação, propõe-se um novo índice para DWG mantidos em nuvem chamado CSB-Index (Cloud Spatial- Bitmap Index). O CSB-Index se baseia no SB-Index e permite a recuperação de dados mantidos em um ambiente distribuído, pois mantém em sua estrutura referências aos bancos de dados que compõe o DWG. Além disso, ele introduz o uso do Índice Bitmap de Junção aos DWG armazenados em nuvem, evitando o processamento das custosas operações de junção estrela. A viabilidade do CSB-Index foi comprovada por meio de testes experimentais de desempenho e escalabilidade. Comparações entre diferentes métodos de acesso indicaram que o CSB-Index diminuiu significativamente o tempo de resposta do processamento de consultas roll-up e drilldown relacionadas aos predicados espaciais intersecta, está contido e contém, possibilitando redução no tempo de processamento destas consultas de 58,2% até 99,65%. Também foi verificado que a escalabilidade dos dados e do número de máquinas que armazenam o DWG não afetam negativamente o desempenho do CSB-Index. Por fim, este trabalho também investigou o impacto do uso das federações no processamento das consultas SOLAP e comprovou que está técnica possibilita maior desempenho ao processamento destas consultas. Palavras-chave: Data warehouse geográfico, Indexação, Computação em nuvem v

8 ABSTRACT Cloud computing platforms provide scalability, elasticity and fault tolerance to computer systems. In addition, they have been designed to handle large volumes of data by using almost unlimited computational resources. Geographic Data Warehouse (GDW) has become a key technology for decision support because it promotes the integration among conventional Data Warehouses, On-Line Analytical Processing tools and Geographic Information Systems. For this reason, a GDW allows analysis to be done in a spatial context and the execution of multidimensional queries involving large volumes of data. The combination of cloud computing and GDW brings the challenge of providing spatial data analyzes in a distributed environment. Furthermore, there is the concern with the performance of query processing, which use ad-hoc spatial queries windows and perform multiple joins between the dimension tables and fact tables. Although there are efficient mechanisms to increase the performance of query processing in GDW, such as indexing structures, they became inappropriate to GDW stored in cloud platforms because these mechanisms do not deal with the data retrieval of distributed environments. In this dissertation, a new index for a GDW stored in a cloud is proposed and is called CSB-Index (Cloud Spatial-Bitmap Index). The CSB-Index is based on SB-Index and allows the retrieval of data kept in a distributed environment because it stores in its data structure references to databases that compose the GDW. In addition, it adds the use of the Join Bitmap Index to GDW stored in a cloud, by avoiding the processing of costly star joins operations. The viability of the CSB-Index has been proven by the execution of performance and scalability experimental tests. Comparisons among different access methods have indicated that the CSB-Index has significantly decreased the response time of queries processing involving roll-up and drill-down operations and related to the spatial predicates intersects, within and contains. Our results indicated that the CSB- Index provided a reduction ranging from 58.2% to 99.65% in time processing of these queries. It was also verified that the data scalability and the number of machines that store the GDW do not affect negatively the CSB-Index performance. Finally, this study has also investigated the impact of the use of federations in the SOLAP queries processing and has shown that this use improves the processing performance of these queries. Keywords: Geographic data warehouse, Indexing, Cloud computing vi

9 vii LISTA DE FIGURAS Figura 2.1: Arquitetura de data warehousing (SIQUEIRA, 2009a) Figura 2.2: Cubo de dados multidimensional que representa uma aplicação de varejo (SIQUEIRA, 2009) Figura 2.3: Esquema estrela que representa a aplicação de varejo adaptado de (SIQUEIRA, 2009) Figura 2.4: Esquema floco-de-neve para o exemplo do varejo Figura 2.5: Exemplo da abstração MBR Figura 2.6: Etapas do processamento de consultas espaciais. Imagem adaptada de (CIFERRI, 2002b) Figura 2.7: Exemplo de uma R-Tree, onde seus objetos espaciais estão envolvidos pelos seus respectivos MBR (CIFERRI, 2002) Figura 2.8: Estrutura simplificada da R-Tree apresentada na Figura 2.7 (CIFERRI, 2002) Figura 2.9: Ambiente de computação em nuvem (BUYYA; BROBERG; GOSCINSKI, 2011).17 Figura 2.10: Definições de computação em nuvem segundo o NSIT. Imagem traduzida de (SOSINSKY, 2011) Figura 2.11: Classificações dos DaaS baseada nas tecnologias utilizadas. Imagem adaptada de (SOUSA et al., 2010) Figura 2.12: (a) esquema lógico do TPC-H (TRANSACTION PROCESSING PERFORMANCE COUNCIL, 2013). (b) esquema lógico do SSB (O NEIL; O NEIL; CHEN, 2005) Figura 2.13: Esquemas do Spadawan Benchmark adaptado de (SIQUEIRA et al., 2010) Figura 3.1: Exemplo de índice de projeção (SIQUEIRA, 2009) Figura 3.2: Exemplo de um Índice Bitmap de Junção (IBJ) sobre o esquema do Spadawan Benchmark Figura 3.3: Comparação entre índice de bitmap codificado por igualdade (b), codificado por faixa (c) e os valores a projeção do atributo A (a) Figura 3.4: Exemplo de índice bitmap com empacotamento. Imagem traduzida de (STOCKINGER; WU, 2006) Figura 3.5: Um exemplo de compressão de uma sequência de 5456 bits segundo a estratégia WAH. Imagem traduzida de (STOCKINGER; WU, 2006) Figura 3.6: Um IBJ criado a partir do FastBit (SIQUEIRA, 2009) Figura 3.7: DWG com uma dimensão espacial Local e a ar-tree correspondente. Imagem adaptada de (SIQUEIRA, 2009) Figura 3.8: ar-tree com agregação de quantidade utilizando as funções SUM e MAX. Adaptado de (SIQUEIRA, 2009) Figura 3.9: ar-tree com dimensão espacial (local) e uma descritiva (TipoVeiculo). Fonte (SIQUEIRA, 2009) Figura 3.10: ar-tree com suporte a mais de uma dimensão Figura 3.11: Dimensão espacial City, a tabela de dimensão Supplier e a tabela de fatos Lineorder (SIQUEIRA et al., 2011) Figura 3.12: A estrutura do SB-Index acompanhado do IBJ criado utilizando FastBit. Traduzida de (SIQUEIRA et al., 2011) Figura 3.13: Processo de construção do SB-Index (SIQUEIRA, 2009) Figura 3.14: Processamento de consultas do SB-Index Figura 3.15: Arquitetura do EMINC Figura 4.1: Estrutura de dados do CSB-Index e o Índice IBJ criado pelo FastBit Figura 4.2: Arquitetura do CSB-Index Figura 4.3: Etapas da construção do CSB-Index Figura 4.4: Algoritmo para construção do CSB-Index

10 Figura 4.5: Processamento de consultas utilizando o CSB-Index Figura 4.6: Algoritmo de processamento de consultas usando o CSB-Index Figura 5.1: Esquemas GHSSB e o RBF-GHSSB Figura 5.2: Esquema de DWG adaptado do GHSSB, no qual uma federação sobre o ano do pedido foi criada Figura 5.3: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo Figura 5.4: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo Figura 5.5: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo Figura 5.6: Exemplos de janelas de consultas para os diferentes níveis de granularidade Figura 5.7: Tela do aplicativo para realizar consultas paralelas distribuídas sobre o Azure SQL Database Figura 5.8: Algoritmo para busca paralela em uma federação Figura 5.9: Gráfico que compara os tempos de processamentos da consulta Tipo 3 ( contém ) nos RBF-GHSSB com fator de escala 1 e Figura 5.10: Gráfico que compara os diferentes métodos de acesso com base no tempo de resposta das consultas SOLAP do Tipo 1 sobre um DWG gerado a partir do fator de escala 5 do SSB viii

11 ix LISTA DE TABELAS Tabela 5.1: Número de tuplas presentes em cada tabela federada para o esquema RBF-GHSSB do DWG gerado a partir do fator de escala Tabela 5.2: Número de tuplas presentes em cada tabela federada para o esquema DBF-GHSSB de DWG gerado a partir do fator de escala Tabela 5.3: Frações do extent cobertas por cada JC para os níveis de granularidade Tabela 5.4: Custo de geração do IBJ pelo FastBit Tabela 5.5: Custo de criação do CSB-Index para o fator de escala Tabela 5.6: Custo de criação do CSB-Index para o fator de escala Tabela 5.7: Tempo de processamento obtido pela execução de operações de roll-up da consulta do Tipo 1 utilizando CSB-Index em um DWG gerado com esquema RBF-GHSSB utilizando o fator de escala Tabela 5.8: Medidas coletadas no processamento de consultas do Tipo 1 utilizando os métodos de busca sequencial na tabela (C1), o índice espacial do Azure SQL Database (C2) e o CSB- Index (C3). A coluna redução é calculada com base no ganho de tempo do CSB-Index com o melhor tempo obtido entre C1 e C Tabela 5.9: Tempo de processamento obtido pela execução de operações de roll-up da consulta do Tipo 2 sobre o RBS-GHSSB utilizando o CSB-Index e fator de escala Tabela 5.10: Medidas coletadas no processamento de consultas do Tipo 2 utilizando os métodos de busca sequencial na tabela (C1), o índice espacial do Azure SQL Database (C2) e o CSB- Index (C3). A coluna redução é calculada com base no ganho de tempo do CSB-Index com o melhor tempo obtido entre C1 e C Tabela 5.11: Frações do extent utilizado na consulta do Tipo 2 para garantir maior abrangência da JC Tabela 5.12: Tempo de processamento obtido pela execução de operações de roll-up da consulta do Tipo 2 sobre o RBS-GHSSB utilizando o CSB-Index e fator de escala 5 usando janelas de consultas mais abrangentes Tabela 5.13: Medidas coletadas no processamento de consultas do Tipo 2, usando JC mais abrangentes, e utilizando os métodos de busca sequencial na tabela (C1), o índice espacial do Azure SQL Database (C2) e o CSB-Index (C3). A coluna redução é calculada com base no ganho de tempo do CSB-Index com o melhor tempo obtido entre C1 e C Tabela 5.14: Tempo de processamento obtido pela execução de operações de roll-up da consulta do Tipo 3 utilizando o CSB-Index Tabela 5.15: Medidas coletadas no processamento de consultas do Tipo 3 utilizando os métodos de busca sequencial na tabela (C1), o índice espacial do Azure SQL Database (C2) e o CSB- Index (C3). A coluna redução é calculada com base no ganho de tempo do CSB-Index com o melhor tempo obtido entre C1 e C Tabela 5.16: Resultados obtidos pela execução da consulta do Tipo 1 ( intersecta ) para diferentes configurações de federações em um mesmo DWG Tabela 5.17: Resultados obtidos pela execução da consulta do Tipo 2 ( está contido ) para diferentes configurações de federações em um mesmo DWG Tabela 5.18: Resultados obtidos pela execução da consulta do Tipo 3 ( contém ) para diferentes configurações de federações em um mesmo DWG Tabela 5.19: Comparação entre o tempo de processamento de consultas do Tipo 1 ( intersecta ) utilizando as configurações C2 e C3 sobre RBF-GHSSB com fator de escala 1 e Tabela 5.20: Comparação entre o tempo de processamento de consultas do Tipo 2 ( está contido ) utilizando as configurações C2 e C3 sobre RBF-GHSSB com fator de escala 1 e Tabela 5.21: Comparação entre o tempo de processamento de consultas do Tipo 3 ( contém ) utilizando as configurações C2 e C3 sobre RBF-GHSSB com fator de escala 1 e

12 Tabela 5.22: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 1 ( intersecta ) sobre o DBF-GHSSB Tabela 5.23: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 2 ( está contido ) sobre o DBF-GHSSB Tabela 5.24: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 3 ( contém ) Sobre o DBF-GHSSB Tabela 5.25: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 1 ( intersecta ) sobre o RBF-GHSSB Tabela 5.26: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 2 ( está contido ) sobre o RBF-GHSSB Tabela 5.27: Métricas que representam o tempo de resposta do processamento de consultas do Tipo 3 ( contém ) sobre o RBF-GHSSB x

13 SUMÁRIO 1. INTRODUÇÃO Contextualização Motivação Objetivos e Contribuições Estrutura do Documento FUNDAMENTAÇÃO TEÓRICA Introdução Sistemas de Suporte à Decisão DW e OLAP Sistemas de informação geográfica DWG e SOLAP Estruturas de Indexação R-Tree Computação em Nuvem Características Essenciais Modelos de Implantação Modelos de Serviços DaaS: Banco de dados como um Serviço Benchmarks para avaliação de desempenho Benchmark para DW Spadawan Benchmark: benchmark para DWG Benchmark para Computação em Nuvem Conclusão TRABALHOS CORRELATOS Introdução Índice de Projeção Índices Bitmap Codificação Empacotamento Compressão FastBit Índices para DWG ar-tree SB-INDEX EMINC xi

14 3.7 Conclusão CSB-INDEX Introdução Estrutura de Dados do CSB-Index Arquitetura do Ambiente na Nuvem Usando o CSB-Index Construção do Índice CSB-Index Processamento de Consulta Conclusão TESTES EXPERIMENTAIS Introdução Projeto de Experimento Configuração do Ambiente de Teste Bases de Dados RBF-GHSSB DBF-GHSSB Carga de Trabalho Processador de Consultas em Paralelo Resultados da Viabilidade do CSB-Index Configuração dos Testes de Desempenho Custo de Construção do CSB-Index Processamento de Consultas SOLAP Investigação da Escalabilidade de Banco de Dados Análise da Escalabilidade dos Dados Análise do Uso de Federações no Processamento de Consultas SOLAP DBF-GHSSB RBF-GHSSB Conclusão CONCLUSÃO Introdução Considerações Finais Trabalhos Futuros Criação de um Índice Bitmap de Junção para Nuvem Benchmark para DWG em nuvem Algoritmo de Otimização para Definição de Federações Prover Suporte às Hierarquias Ad-hoc REFERÊNCIAS xii

15 1.1 Contextualização Em um mercado cada vez mais globalizado e competitivo, a capacidade de responder com agilidade e eficácia às mudanças no ambiente de negócios pode ser um diferencial para as empresas. A necessidade de responder prontamente às variações impostas por estas atividades é imprescindível para sobressair-se em relação aos principais concorrentes. Para isto, mecanismos para armazenar e manipular dados apropriadamente têm sido propostos na literatura de BD. Armazenar estes dados corretamente e recuperá-los eficientemente permite às companhias: adquirir um conhecimento sobre sua estrutura interna, prever tendências no mercado e obter suporte no processo de tomada de decisões, e então, ficar em uma situação favorável diante de seus competidores. Estes mecanismos que permitem o uso estratégico de informações estão se tornando ferramentas computacionais indispensáveis para as organizações e são chamados de Sistemas de Suporte à Decisão (SSD) ou sistemas analíticos. Um exemplo de sistema de suporte à decisão que permite o armazenamento, a recuperação e a visualização de dados georreferenciados são os Sistemas de Informações Geográficos (SIG) (CÂMARA et al., 1996). SIG são sistemas projetados para capturar, armazenar, manipular, analisar e gerenciar dados espaciais. Estes sistemas possibilitam a realização de análises para a definição do melhor local para construção de uma dada corporação, a especificação de melhores rotas e a realização de estudos de simulação com base na manipulação de dados espaciais, dentre outras análises. Embora fosse evidente a popularização das ferramentas SSD, o cenário observado nas corporações não era favorável ao seu uso, pois o crescente aumento no número de dados (não integrados) foi visto como um obstáculo à necessidade de obtenção de baixo tempo de resposta das consultas analíticas. Constatou-se, então, que o ambiente operacional deveria ser separado do ambiente decisório, isolando os dados e as transações do dia-a-dia das consultas analíticas que proveem apoio à tomada de decisão (INMON, 2002). Como resultado da separação destes ambientes, várias tecnologias foram desenvolvidas pela indústria de TI para a manipulação dos dados. Dentre estas tecnologias, destacam-se o Data Warehouse (DW) (INMON, 2002; 1

16 KIMBALL; ROSS, 2002) e as ferramentas OLAP (On-Line Analytical Processing) (CHAUDHURI; DAYAL, 1997). O DW pode ser definido como uma base de dados para suporte à decisão que armazena dados orientados a assuntos, integrados, variante no tempo e não volátil. Sistemas de gerenciamento de DW tornaram-se, portanto, parte fundamental do ambiente decisório no qual consultas analíticas e multidimensionais são submetidas por meio de ferramentas OLAP para prover o suporte à decisão. Para facilitar o entendimento sobre o comportamento dos dados de uma organização, as ferramentas OLAP recuperam dados do DW para serem visualizados em diferentes perspectivas e com diferentes níveis de detalhes (CHAUDHURI; DAYAL, 1997; OLAP COUNCIL, 1999). No decorrer da década de 90, paralelamente à popularização do DW e das ferramentas OLAP, em função do surgimento de novos meios de armazenamento de dados digitais, difundiramse as aplicações que fazem uso de dados geográficos, motivando assim, a criação de sistemas de bancos de dados geográficos. Eles armazenam tipos de dados complexos que representam a localização e a geometria de um dado objeto. Concomitante com o desenvolvimento destes sistemas de bancos de dados espaciais, os Sistemas de Informações Geográficas tornaram-se populares e foram empregados no suporte à decisão principalmente por causa do surgimento de interfaces mais amigáveis e da redução de custos relativos à aquisição destes sistemas. SIG são sistemas específicos para auxiliar na tomada de decisão sobre o espaço geográfico e permitem a aquisição, manipulação, visualização e análise de objetos espaciais. Durante o final da última década, observou-se a introdução de dados espaciais nos DW (STEFANOVIC; KOPERSKI, 2000) para aumentar o universo de consultas analíticas e a produtividade na tomada de decisão. No entanto, estes sistemas de DW convencionais não fornecem mecanismos adequados para representação, indexação e manipulação de dados espaciais. Por isso, surgiram diversas propostas na literatura de BD visando integrar a capacidade de armazenamento e o processamento de ferramentas do tipo OLAP e SIG (BIMONTE; TCHOUNIKINE; MIQUEL, 2005, 2006; BIMONTE et al., 2006; DAMIANI; SPACCAPIETRA, 2009; ESCRIBANO et al., 2007; MALINOWSKI; ZIMÁNYI, 2004, 2006; MALINOWSKI, 2009; POURABBAS, 2003; RICCI et al., 2001; RIVEST et al., 2005; SCOTCH; PARMANTO, [s.d.]). Este novo tipo de ferramenta tem sido referenciado como SOLAP (Spatial OLAP) e beneficia a elaboração de estratégias para possibilitar o entendimento sobre o comportamento dos dados de uma organização ampliando os tipos de consultas possíveis e fazendo uso de um DW Geográfico (DWG). DWG são DW tradicionais com atributos espaciais que são usados para armazenar geometrias de objetos espaciais e definir tabelas de dimensões espaciais, medidas espaciais, hierarquias espaciais e membros espaciais (RUIZ; TIMES, 2009). Um DW pode ser representado logicamente por um esquema estrela (Star Schema) (KIMBALL; ROSS, 2002), o qual é composto por uma única tabela de fatos que referencia várias outras tabelas chamadas de dimensões. O DWG diferencia-se do DW por apresentar pelo menos 2

17 uma tabela de dimensão ou uma medida composta por dados geométricos (e.g. um conjunto de coordenadas vetoriais que determina a localização e a forma de uma dada região) (BIMONTE; TCHOUNIKINE; MIQUEL, 2005; FIDALGO et al., 2004; MALINOWSKI; ZIMÁNYI, 2004; MALINOWSKI, 2009; SAMPAIO; DE SOUSA; BAPTISTA, 2006; STEFANOVIC; KOPERSKI, 2000). As consultas realizadas sobre este esquema exigem, em seu processamento, a realização de custosas operações de junções e agregações envolvendo a recuperação de uma grande quantidade de tuplas. Em um DWG, soma-se o cômputo do processamento de atributos espaciais ao custo da consulta (GAEDE; GÜNTHER, 1998). Assim, é evidente o desafio de pesquisas existentes para obter um baixo tempo de resposta às consultas SOLAP feitas sobre o DWG, para a criação de mecanismos que auxiliem na redução do custo das operações de junções entre volumosas tabelas de fatos e tabelas de dimensão espacial, e para realização de operações de agregação e avaliação dos predicados espaciais em consultas multidimensionais. Existem diversas abordagens para aumentar o desempenho do processamento de consultas em DW e DWG. Entre elas, pode-se citar o uso de visões materializadas (GOLFARELLI; MANIEZZO; RIZZI, 2004; HARINARAYAN; RAJARAMAN; ULLMAN, 1996; RAO et al., 2003), o uso de estruturas de indexação (O NEIL; GRAEFE, 1995; SARAWAGI, 1997; SIQUEIRA, 2009), a fragmentação horizontal ou vertical de dados (CIFERRI, 2002a; GOLFARELLI; MAIO; RIZZI, 2000), frameworks para modelagem de dados (FIDALGO et al., 2004; MATEUS et al., 2010), ou o uso de diversos processadores visando à realização do processamento paralelo (DATTA; THOMAS, 1998; FURTADO, 2004). Paralelamente ao desenvolvimento de novas tecnologias de SSD, um novo paradigma de computação tem se popularizado desde o final da última década: a computação em nuvem (SOSINSKY, 2011; SOUSA et al., 2010). Na computação em nuvem, empresas contratam recursos computacionais como um serviço de centros de dados, também denominados de provedores, e pagam apenas pela demanda utilizada. A alocação dos recursos ocorre dinamicamente de acordo com a carga de trabalho processada. Esta característica cria a percepção de que os recursos computacionais disponíveis são virtualmente infinitos. A grande capacidade de armazenamento e processamento de dados aliada à alta-disponibilidade presentes nesta arquitetura motivaram o desenvolvimento de novas tecnologias de armazenamento de dados. Os provedores oferecem estas soluções de armazenamento de dados como um serviço, o qual ficou conhecido como banco de dados como um serviço (DaaS, do inglês Database-as-a-Service) (CURINO et al., 2011). No DaaS, usuários mantêm e consultam dados por meio de uma infraestrutura de comunicação ou através da própria Internet. Aos provedores cabem a manutenção e gerenciamento da infraestrutura, garantindo a qualidade do serviço contratado. Estes sistemas de armazenamento de dados são construídos sobre um pool de recursos computacionais, o qual é provido por centenas ou milhares de máquinas. A complexidade desta arquitetura originou novas técnicas para o correto armazenamento e recuperação de dados (CURINO et al., 2011; DECANDIA et al., 2007; 3

18 GHEMAWAT; GOBIOFF; LEUNG, 2003; HADOOP, 2012). O armazenamento de dados em nuvem difere dos SGBD construídos sobre uma infraestrutura convencional, porque propiciam grande escalabilidade, elasticidade e tolerância a falhas, além de serem projetados para trabalhar com grandes volumes de dados. Estes aspectos são desejados em SSD, por isso a computação em nuvem tem sido foco de pesquisas para o armazenamento e processamento de dados analíticos (ABADI, 2009; BREZANY et al., 2011). É sabido, entretanto, que o armazenamento sobre diversas máquinas com capacidade heterogêneas traz consigo grandes desafios quanto ao processamento de consultas analíticas distribuídas. Por isso, é preciso repensar as atuais estruturas de indexação para prover melhor desempenho ao ambiente decisório quando mantidos em nuvem. O trabalho de pesquisa descrito nesta dissertação propõe a criação de uma estrutura de indexação para DWG que estão mantidos em nuvem. Este índice deve ser capaz de explorar a elasticidade e a escalabilidade dos DWG mantidos em nuvem e oferecer bom desempenho às consultas SOLAP. 1.2 Motivação A crescente popularização dos serviços baseados em computação em nuvem tem despertado o interesse da comunidade de banco de dados. Novos mecanismos e estruturas para o armazenamento e recuperação de dados têm sido propostos, ficando conhecidos como DaaS. O armazenamento de dados em nuvem traz consigo grandes desafios como: (i) segurança dos dados; (ii) manutenção de informações consistentes; (iii) provisão de alta disponibilidade; e (iv) baixo tempo de resposta para manipulação dos dados. Abadi, em (ABADI, 2009), realizou um estudo analítico sobre as características dos DaaS com o intuito de identificar qual o ambiente (analítico ou transacional) que melhor se adequa ao contexto de computação em nuvem, onde o processamento e armazenamento de dados é distribuído entre diversas máquinas. Neste estudo, foi constatado que sistemas analíticos, como os DW e DWG, são mais adequados ao contexto de nuvem devido à natureza dos seus dados e da sua carga de trabalho. Os DWG, assim como os DW, armazenam grande volume de dados e realizam custosas operações de junções e agregações, por isso é importante o uso de estruturas de indexação para auxiliar o processamento das consultas. Na literatura de BD, existem diversas abordagens para a indexação de atributos geográficos e multidimensionais, porém não se tem conhecimento de estruturas de indexação para DWG que sejam capazes de explorar as vantagens proporcionadas pela infraestrutura de nuvem, tais como, o processamento distribuído, a escalabilidade e a elasticidade. 1.3 Objetivos e Contribuições Neste trabalho de pesquisa é proposto o Cloud Spatial Bitmap Index, ou CSB-INDEX, para a indexação de DWG em nuvem. O CSB-INDEX é uma extensão do SB-INDEX, trabalho proposto 4

19 em (SIQUEIRA, 2009). CSB-Index foi projetado para a realização de operações de drill-down e roll-up em DWG mantidos na nuvem onde a elasticidade horizontal foi aplicada para ganhos de performance de consultas SOLAP. A validação da viabilidade do CSB-INDEX foi realizada por meio de testes experimentais utilizando o Windows Azure SQL Database e um bechmark para avaliação de desempenho de sistemas de DWG mantidos em uma infraestrutura convencional. Os testes avaliaram o tempo de resposta das consultas e o número de acesso a disco para o processamento das consultas SOLAP. Os resultados foram comparados com o processamento de consultas auxiliadas por métodos de acessos a dados disponíveis nos SGBDs, e também foi considerado o processamento paralelo dos dados nos diversos sites que compõem o DWG. Para a análise do processamento paralelo de consultas foi desenvolvida também um aplicativo para execução de consultas de modo paralelo. Este aplicativo realiza buscas de dados em todos os bancos de dados que compõem um DWG. Além disso, ele realiza a agregação dos dados obtidos em cada BD. Além da proposta do CSB-Index, este trabalho tem por objetivo realizar uma análise investigativa que visa identificar os efeitos do uso de federações (i.e., fragmentação horizontal de um banco de dados armazenado em nuvem) sobre o tempo de processamento de consultas SOLAP em um DWG. É importante destacar que o uso de federações possibilita maior escalabilidade e elasticidade permitindo maior desempenho no processamento de consultas. 1.4 Estrutura do Documento Além do capítulo de introdução, o presente trabalho está estruturado da seguinte maneira: O Capítulo 2 resume os fundamentos e conceitos teóricos sobre Computação em Nuvem, e descreve as principais tecnologias de SSD (DW/OLAP, SIG e DWG/SOLAP) e algumas estruturas de indexação as quais são indispensáveis para a compreensão do índice proposto neste documento. O Capítulo 3, por sua vez, expõe os trabalhos correlatos ao objeto de pesquisa desta dissertação. No Capítulo 4 é proposto o CSB-INDEX, capaz de explorar os benefícios da elasticidade da nuvem. O Capítulo 5 apresenta os resultados dos experimentos realizados. Por fim, o Capítulo 6 conclui o estudo aqui detalhado e apresenta algumas sugestões para realização de trabalhos futuros. 5

20 2.1 Introdução O objetivo principal desse capítulo é fornecer ao leitor, os principais conceitos das áreas de pesquisa relacionadas ao estudo realizado para facilitar o entendimento do problema abordado neste trabalho. A fim de atingir tal objetivo, na Seção 2.2, os conceitos básicos sobre sistemas de suporte a decisão (SSD) como DW, OLAP, SIG, DWG e SOLAP são descritos. A Seção 2.3, discorre sobre estruturas de indexação as quais constituem importantes mecanismos para auxiliar na recuperação de dados em sistemas de bancos de dados. Na Seção 2.4, as principais características sobre a tecnologia de Computação em Nuvem são apresentadas. A Seção 2.5 discorre sobre benchmarks importantes métodos para avaliação de desempenho de sistemas. Por fim, na Seção 2.6 são apresentadas as considerações finais. 2.2 Sistemas de Suporte à Decisão Os conceitos básicos sobre os sistemas de suporte à decisão necessários ao entendimento deste trabalho são descritos nesta seção. Na Seção 2.3.1, os sistemas de DW e as ferramentas OLAP que são amplamente utilizados para tomada de decisões estratégicas, são detalhados. Na Seção 2.3.2, os SIG são abordados e por fim, a Seção destaca os DWG e as ferramentas SOLAP que constituem o foco desta dissertação DW e OLAP O nível operacional abrange um conjunto de aplicações OLTP (On-Line Transaction Processing) cujo objetivo é automatizar as tarefas que retratam o dia-a-dia de uma instituição, como, por exemplo, o cadastro de clientes, os registros de compras, a produção de uma peça, entre outras atividades. Nele, as operações realizadas são predominantemente simples, repetitivas, bem conhecidas, atômicas e isoladas. Estas são realizadas em grande frequência e de forma concorrente, porém acessam poucos registros por vez, executando modificações, remoções, inclusões, além de consultas normalmente por meio da verificação e indexação de chaves-primárias. Como as operações ocorrem concomitantemente, a consistência de dados e tolerância a falhas são requisitos desejados. O projeto de banco de dados do ambiente operacional demanda um esforço voltado para otimização de transações e consultas (CHAUDHURI; DAYAL, 1997; ELMASRI; NAVATHE, 2005; INMON, 2002; KIMBALL; ROSS, 2002; RIZZI, 2006). As atividades relacionadas com o suporte à decisão, por sua vez, são desempenhadas por aplicações OLAP (On-Line Analytical Processing). Estas aplicações caracterizam-se por 6

21 realizarem complexas consultas, quando comparadas às realizadas no ambiente OLTP, que podem acessar milhões de registros por vez, e realizam diversas varreduras sobre os dados e custosas operações de junções e agregações. Outra característica de OLAP é que suas consultas incidem principalmente sobre dados históricos, sumarizados, consolidados e não variantes no tempo. Portanto, objetiva-se maximizar o desempenho de consultas, ao invés do desempenho de transações (CHAUDHURI; DAYAL, 1997; ELMASRI; NAVATHE, 2005; INMON, 2002; KIMBALL; ROSS, 2002; RIZZI, 2006). Segundo descrito anteriormente, os requisitos de dados e processamento do ambiente operacional divergem dos requisitos impostos pelas ferramentas que provêm suporte à decisão. Por isso, foi proposta a criação de uma nova base de dados projetada para manter os dados destinados aos sistemas de suporte à decisão. Esta base de dados ficou conhecida como Data Warehouse (DW) (INMON, 2002). O DW é uma volumosa base de dados responsável pelo armazenamento de dados orientados a assuntos, históricos, não voláteis, integrados e sumarizados, além de proporcionar rapidez e eficiência às consultas analíticas. Estas consultas são submetidas diretamente ao DW, dispensando o acesso aos provedores de dados originais (ADZIC; FIORE; SISTO, 2007; CHAUDHURI; DAYAL, 1997; INMON, 2002; KIMBALL; CASERTA, 2004; KIMBALL; ROSS, 2002; RIZZI, 2006). A Figura 2.1 ilustra a arquitetura de data warehousing na qual o DW assume um papel de destaque. Figura 2.1: Arquitetura de data warehousing (SIQUEIRA, 2009a). As fontes de dados extraídos para o ambiente de DW podem ser gerenciadas por SGBD relacionais, orientados a objetos, objeto-relacionais, e sistemas legados ou até mesmo serem representadas por bases de conhecimento, planilhas e arquivos de dados, dentre outros formatos de dados. Contudo, por serem oriundos de fontes heterogêneas, estes dados precisam ser tratados e integrados (ADZIC; FIORE; SISTO, 2007; KIMBALL; CASERTA, 2004). Os metadados mantêm as informações necessárias para a configuração do DW, como por 7

22 exemplo, descrição das fontes de dados, definição do esquema do DW, e especificação de dimensões e hierarquias. Além disso, são responsáveis por controlar a versão dos dados históricos armazenados no DW (CHAUDHURI; DAYAL, 1997; WU; BUCHMANN, 1997). Um Data Mart (DM) tanto pode ser visto como um protótipo para a construção do DW como um todo (KIMBALL; ROSS, 2002), como uma solução local voltada para uma unidade departamental, cujo escopo de aplicação é reduzido se comparado ao escopo do DW (INMON, 2002). Data Mart é um repositório de dados, tal qual um DW, porém apresenta um subconjunto de dados multidimensionais destinados a um departamento específico ou atividade de negócio de interesse. Os servidores OLAP (PENTAHO CORPORATION, 2013) atuam como uma camada intermediária entre o DW e os componentes de análise e consultas analíticas. Por meio deles, os usuários responsáveis por elaborar estratégias submetem consultas ao DW, as quais permitem observar o negócio sobre diferentes perspectivas. Estes servidores são compostos por um middleware que oferece suporte a consultas multidimensionais. Consultas analíticas são submetidas aos servidores OLAP, que efetuam o mapeamento para o SQL correspondente. Por realizar este mapeamento, o servidor OLAP consegue tirar proveito das funcionalidades de consultas dos SGBD. Os componentes de análise e consulta viabilizam as consultas analíticas aos usuários de forma transparente, portanto o usuário não precisa saber onde os dados estão fisicamente armazenados. Conceitualmente, o esquema multidimensional de dados permite que ferramentas OLAP manipulem os dados como se estes pertencessem a um hipercubo n-dimensional, exemplificado na Figura 2.2. Um cubo é formado por um conjunto de medidas agregadas e estruturado de acordo com um conjunto de dimensões. Dentro de um cubo, possíveis agregações de medidas são resultantes da combinação dos membros das dimensões (RIVEST et al., 2005). Cada dimensão do cubo representa um tema de interesse ao qual o negócio está inserido. Uma dimensão é formada por um conjunto de atributos e de hierarquias. Cada hierarquia possui vários níveis. Uma dimensão contém membros que são os valores dos seus atributos ou níveis, e como mostrado na Figura 2.2 Jan04, DVD e New York são exemplos de membros das dimensões Data, Item e Fornecedor, respectivamente. Os valores das medidas relativas aos membros de um nível (e.g., Computador e Impressora ) podem ser agrupados para compor valores de membros do nível acima (e.g., Informática ), e desta forma, fica evidente a possibilidade de existência de um relacionamento hierárquico entre os atributos de uma dimensão. As dimensões no DW convencional podem ser classificadas em: temporal (representam o histórico de ocorrência dos fatos), convencionais (possuem apenas atributos descritivos) ou geográficas (são representados por objetos espaciais). Cada célula ilustrada no cubo representa um fato. Cada fato é descrito por um conjunto de valores numéricos (as medidas) e contextualizado pelos membros das dimensões. A medida 8

23 depende de um conjunto de dimensões, as quais determinam o contexto no qual ela está inserida. Estas medidas podem ser obtidas por meio de fórmulas e dependem do nível de agregação dos dados. Por exemplo, o número de computadores vendidos, no estado de Nova Iorque, em janeiro de 2004 foi de unidades pode ser considerado um fato. Figura 2.2: Cubo de dados multidimensional que representa uma aplicação de varejo (SIQUEIRA, 2009). Ainda com relação aos servidores OLAP, estes podem ser implantados em três abordagens distintas: relacional OLAP (ROLAP), multidimensional OLAP (MOLAP) e uma abordagem híbrida, também conhecida por (HOLAP) (PENTAHO CORPORATION, 2013). Em nossos experimentos foi utilizado um servidor ROLAP, logo um esquema relacional é necessário para representação do modelo multidimensional. Existem dois esquemas principais para a representação lógica de dados dimensionais: o esquema estrela e o floco-de-neves. O primeiro deles está exemplificado na Figura 2.3 e é o mais utilizado para representar logicamente um modelo de dados dimensional. De acordo com este esquema estrela, o banco de dados é constituído por uma única tabela de fatos e uma tabela para cada dimensão. Cada tupla na tabela de fatos mantém um relacionamento para cada dimensão por meio de chaves-estrangeiras, além de atributos que representam as medidas. Cada dimensão é descrita por um conjunto de colunas que correspondem aos seus atributos. Porém, este esquema não provê uma representação explícita de hierarquia de atributos (KIMBALL; ROSS, 2002). O esquema flocos-de-neve é um refinamento do esquema estrela, de modo que o relacionamento hierárquico dos atributos está explicitamente representado pela normalização das dimensões conforme mostra a Figura 2.4. Embora este modelo possua a vantagem em relação à manutenção das tabelas de dimensões, o esquema estrela é preferível ao flocos-de-neve por sua estrutura não normalizada que é mais eficiente por requerer menos operações de junções (KIMBALL; ROSS, 2002). 9

24 Figura 2.3: Esquema estrela que representa a aplicação de varejo adaptado de (SIQUEIRA, 2009). Figura 2.4: Esquema floco-de-neve para o exemplo do varejo. O cliente OLAP permite aos usuários finais, operar sobre o servidor e visualizar os dados por meio de diagramas e tabelas. Estes aplicativos também possibilitam explorar as peculiaridades da agregação de dados. Na operação de drill-down, os dados são agregados progressivamente no sentido mais detalhado. Por outro lado, na operação de roll-up a agregação ocorre no sentido mais resumido. Nas ferramentas OLAP, é possível encontrar outras operações dinâmicas muito conhecidas como: o pivoting, slice-and-dice e drill-across (KIMBALL; ROSS, 2002; WU; BUCHMANN, 1997) Sistemas de informação geográfica Mapas são importantes fontes no estudo de informações geográficas, pois fornecem recursos visuais que possibilitam a extração de conhecimento com base no posicionamento, na extensão e na distribuição dos fenômenos ocorridos sobre o território geográfico. Os elementos que compõem um mapa são em geral armazenados de forma georreferenciada (i.e. segundo um sistema de coordenadas latitude e longitude) (BÉDRAD; RIVEST; PROULX, 2007). Neste sentido, novas ferramentas foram desenvolvidas com o intuito de explorar as características inerentes aos dados cartográficos representados pelos mapas. Dentre estas 10

25 ferramentas, destacam-se os SIG que são usados para armazenar, manipular, analisar e visualizar dados espaciais. Cada um desses dados espaciais é composto por informações descritivas (dados convencionais) e sua referência geográfica (dados geométricos). Estes objetos são visualizados como mapas que podem ser combinados, um acima do outro, provendo camadas de informações geográficas sobrepostas (BÉDRAD; RIVEST; PROULX, 2007; CÂMARA et al., 1996; FERRARI, 1997). Deste modo, os SIG conferem aos usuários finais, um grande poder de análise no âmbito geográfico, pois exploraram características espaciais (e.g. forma, perímetro, localização, orientação), os relacionamentos topológicos (adjacência, conectividade, proximidade, exclusão, intersecção, sobreposição entre outros) e a distribuição (e.g. concentrado, disperso, agrupado, pontual) associada aos dados geográficos (BÉDRAD; RIVEST; PROULX, 2007; MEDEIROS; PIRES, 1994). Os primeiros SIG foram desenvolvidos no Canadá durante a década de 60. O objetivo desse sistema era a criação de um inventário dos recursos naturais daquele país, auxiliando assim, no planejamento do uso destes recursos e do solo (ANTENUCCI, 1991). O custo de implantação destes sistemas era proibitivo, o que limitou seu uso às grandes corporações. Nas últimas décadas, no entanto, com o desenvolvimento de novas tecnologias (sistemas de gerenciamento de banco de dados geográficos) e redução dos custos de implantação, o uso destes sistemas foi difundido. Atualmente, eles têm sido empregados em diversas áreas como no planejamento de recursos naturais, organização das cidades, mapeamento de doenças epidemiológicas entre várias outras aplicações, sendo muitas vezes referenciado como SSD que atua especificamente no contexto geográfico (BÉDRAD; RIVEST; PROULX, 2007; CÂMARA et al., 1996) DWG e SOLAP No contexto de análise espacial, os SIG, nas últimas décadas, foram consagrados como uma importante tecnologia de suporte à decisão. Contudo, paralelamente a difusão do SIG, observou-se um vertiginoso aumento de dados geográficos nos DW convencionais estima-se que 80% de todos os dados mantidos em um DW são de natureza espacial (i.e. representam endereços, nome de lugares, coordenadas geográficas, entre outros) (FRANKLIN, 1992). Embora os SIG desempenhem a função para o qual foram projetados, eles são sistemas que atuam no nível operacional (i.e. são orientados a transações) e não acessam informações sumarizadas, não possibilitam a visualização de dados em diferentes níveis de detalhes, além disso, não foram projetados para a realização de operações de agregação em um grande volume de dados (BÉDRAD; RIVEST; PROULX, 2007). Por outro lado, ferramentas OLAP permite a descoberta de novos conhecimentos, no entanto não possuem meios para manipular dados geográficos. Nestas ferramentas, os dados geográficos são representados apenas por dados descritivos, e a análise espacial é limitada à especificação da localização nominal (e.g., nome de países, estados, regiões, cidades). O suporte a 11

26 análise espaço-temporal é muito restrito nestes sistemas, pois não provêm meios para manipular objetos espaciais e explorar características cartográficas e informações inerentes aos relacionamentos topológicos dos objetos geográficos, assim como não permitem a visualização destes objetos limitando o poder de análise no âmbito espacial (BÉDRAD; RIVEST; PROULX, 2007). Existem diversas propostas na literatura de BD que visam integrar a capacidade de armazenamento e de processamento de ferramentas OLAP e SIG (BIMONTE; TCHOUNIKINE; MIQUEL, 2005, 2006; BIMONTE et al., 2006; DAMIANI; SPACCAPIETRA, 2009; ESCRIBANO et al., 2007; MALINOWSKI; ZIMÁNYI, 2004, 2006; MALINOWSKI, 2009; POURABBAS, 2003; RICCI et al., 2001; RIVEST et al., 2005; SCOTCH; PARMANTO, [s.d.]). Este ambiente integrado é conhecido como SOLAP (Spatial OLAP) e beneficia o processo de tomada de decisões estratégicas por ampliar o tipo de processamento de consultas sobre o negócio de uma organização utilizando um DWG. DWG são DW com suporte a atributos espaciais que são usados para armazenar vetores de geometrias e definir tabelas de dimensões, medidas, hierarquias e membros espaciais como definido em (RUIZ; TIMES, 2009). O DWG, assim como o DW, pode ser representado logicamente por um esquema estrela. Este provê uma estrutura de armazenamento concisa e organizada, além de facilitar as operações SOLAP. O esquema estrela do DWG consiste em um esquema estrela tradicional que é acrescido de dimensões e/ou medidas espaciais. Neste trabalho, apenas dimensões espaciais são consideradas e o desempenho de consultas SOLAP sobre esquemas de DWG com medidas espaciais não são investigados em nosso estudo experimental para fins de redução do escopo. Em (RIVEST et al., 2005), uma classificação de medidas espaciais para sistemas SOLAP pode ser obtida. Com relação às dimensões espaciais, foi verificada a existência de três tipos de dimensões espaciais (RIVEST et al., 2005): (i) a dimensão espacial não geométrica; (ii) a dimensão espacial geométrica; e (iii) a dimensão espacial híbrida. A dimensão espacial do tipo não geométrica armazena dados geográficos descritivos sobre a localização de um objeto espacial (i.e., descrições nominais de endereços, nomes de cidades, nomes de estados, nomes de países), e nenhum dado possui geometria associada. Por outro lado, as tabelas de dimensões espaciais geométricas utilizam objetos espaciais para representar todos os membros de uma dada dimensão, em todos os níveis de detalhe, que são geograficamente referenciados. Isto permite a visualização dos membros das dimensões e possibilita o uso de operações cartográficas sobre estes. Já a dimensão híbrida utiliza dados geográficos para representar apenas um subconjunto dos membros da dimensão. Na análise experimental descrita neste documento, tanto dimensões geométricas como não geométricas foram consideradas. As dimensões híbridas foram descartadas do estudo realizado por serem semelhantes às dimensões geométricas quanto à normalização dos dados espaciais. 12

27 Ainda com relação às dimensões geográficas, os membros podem ser organizados em hierarquias espaciais. Em (MALINOWSKI; ZIMÁNYI, 2005), diversos tipos de hierarquias espaciais são propostos, porém, neste trabalho, foram consideradas apenas hierarquias espaciais simples simétricas com o relacionamento espacial está contido. Desta forma, os relacionamentos entre os objetos espaciais podem ser representados por uma estrutura de árvore, na qual cada membro de granularidade mais alta contém aqueles com níveis mais baixos de granularidade. Neste tipo de hierarquia, um objeto espacial de um nível inferior de granularidade não pode estar contido em mais de um objeto de nível superior. Todo objeto que não está no menor nível de granularidade contém pelo menos um objeto do nível inferior. Um possível exemplo deste tipo de hierarquia é: Nação como sendo o nível superior, Cidade como um nível intermediário e Endereço representando o nível inferior. É muito importante destacar que as hierarquias espaciais estão intimamente ligadas às operações de roll-up e drill-down espaciais, que são operações SOLAP de agregação de dados. 2.3 Estruturas de Indexação Índices são estruturas de acesso auxiliares cuja função é otimizar o acesso às linhas de uma dada tabela com base em certas condições de busca, possibilitando a recuperação de registros de modo eficiente. Uma estrutura de indexação oferece caminhos alternativos a um registro de modo a não alterar a disposição física dos dados (ELMASRI; NAVATHE, 2005), e possibilita selecionar e recuperar os registros que satisfazem às condições de consulta segundo uma chave de busca, a qual consiste em um conjunto arbitrário de atributos. Estas estruturas de acesso auxiliar permitem localizar registros consultando apenas uma fração do conjunto total de registros possíveis, o acesso a estes registros segue uma ordenação própria, mantendo intacta a disposição dos registros no arquivo de dados (FOLK; ZOELLICK, 1991). Estruturas que indexam os arquivos de dados geralmente tem grandes volumes de registros e, por isso, são armazenados em memória secundária. Frequentemente arrays de discos são os mecanismos utilizados. Os custos no armazenamento secundários estão associados às buscas de uma dada localização em disco. Em discos magnéticos, a cabeça de leitura, uma vez posicionada, pode processar um fluxo contíguo de bytes rapidamente. Nestes meios de armazenamento, o custo é uma combinação de busca lenta e transferência de dados rápida (FOLK; ZOELLICK, 1991). Os elementos que compõe um índice são chamados de dados de entradas (data entries). Os dados de entrada são menores que os registros do arquivo de dados o qual indexam, porque possuem menos atributos (um valor de chave, um ponteiro para o arquivo de dados e nenhum ou poucos atributos relevantes para a busca), mas também podem ocupar vários blocos em um disco. Assim, mesmo com estratégias otimizadas de buscas, há a possibilidade de realizar vários acessos a disco para recuperar os registros desejados. Operações de inserção, atualização e eliminação de registros implica, em certos casos, na reorganização custosa do índice e no gerenciamento do espaço extra concedido ao armazenamento (os blocos de overflow) (RAMAKRISHNAN; GEHRKE, 2003). 13

28 Com relação a estruturas de índices, estas são baseadas em esquemas multi-níveis, árvores ou hashing, sendo a árvore B (b-tree) e hash os exemplos mais comuns. Estas estruturas mais tradicionais, assumem uma única chave de busca e auxiliam a recuperação de registros de acordo com os valores dela. Esta chave pode ser simples ou composta, i.e., construída sobre um único atributo ou uma concatenação deles. Deste modo, índices assim caracterizados possuem apenas uma dimensão. Bancos de dados não convencionais como os geográficos e os multidimensionais diferenciam-se dos SGBDs convencionais, pois exigem a visualização de dados em espaços com duas ou mais dimensões. O espaço multidimensional é o domínio utilizado pelos Métodos de Acesso Multidimensionais (MAM) (GAEDE; GÜNTHER, 1998) para indexar elementos com dimensionalidade. O armazenamento de objetos de feições geométricas é muito custoso, por isso técnicas de aproximação (abstração) são empregadas nestes objetos para representar a sua geometria. Estes mecanismos asseguram que nenhuma feição espacial que satisfaz a um certo relacionamento espacial é descartada na resposta da consulta. A técnica de aproximação mais utilizada é o retângulo envolvente mínimo (MBR Minimum Bounding Rectangle), que consiste no menor retângulo n-dimensional que circunscreve o objeto espacial. Em um espaço bidimensional, esta aproximação consiste em quatro pares de coordenadas: (X min, Y min), (X máx, Y min), (X máx, Y máx), (X min, Y máx), onde X min e Y min são os menores valores das coordenadas X e Y do retângulo envolvente, respectivamente, enquanto X máx e Y máx são os maiores valores. A Figura 2.5 mostra um exemplo de MBR. A área vazia que não faz parte do polígono (sombreado) é conhecida por dead space e não deve ser considerada durante a avaliação do predicado espacial ou a resposta da consulta conterá falsos candidatos. Figura 2.5: Exemplo da abstração MBR. Figura 2.6: Etapas do processamento de consultas espaciais. Imagem adaptada de (CIFERRI, 2002b). O processamento de consultas espaciais por meio de MAM pode ser exemplificado com base na Figura 2.6. O processamento pode ser dividido em duas etapas: filtragem (rápido) e o refinamento (lento). Na etapa de filtragem, o MBR do predicado espacial da consulta é comparado com os MBR armazenados na estrutura MAM. Após esta comparação, tem-se uma conjunto de candidatos, e se o relacionamento espacial avaliado for do tipo está contido, então o conjunto de candidatos já é a resposta da consulta espacial, caso contrário a geometria deverá passar pela etapa 14

29 de refinamento para eliminar os falso candidatos. No refinamento, as geometrias exatas dos objetos espaciais são consultadas no banco de dados e, então, o relacionamento espacial é avaliado. No final do processamento, apenas o conjunto dos candidatos que satisfazem a condição espacial da consulta é retornado como resposta. O processamento da etapa de refinamento, por ter que acessar as geometrias exatas no banco de dados é muito custoso. Portanto, espera-se que a etapa filtragem reduza drasticamente o número de candidatos. Além do MBR, existem outras abstrações mais precisas que podem ser aplicadas na etapa de filtragem, embora possuam maior custo de armazenamento, como por exemplo, o convex-hull e o 5C (BRINKHOFF; KRIEGEL; SCHNEIDER, 1993) R-Tree R-Tree (GUTTMAN, 1984) é um índice que se baseia na localização dos objetos em um espaço multidimensional, e trata-se de um MAM. A proposta de criação do índice surgiu pela falta de uma estrutura de acesso que permitisse: (i) lidar de forma apropriada com a paginação na memória secundária; (ii) permitir a busca de dados em um universo multidimensional; (iii) viabilizar consultas espaciais sobre faixas (também conhecidas como range queries RQ); e (iv) acessar de modo eficiente um grande volume de registros. A R-Tree é uma árvore baseada nas B-Tree. Cada um dos seus nodos corresponde a exatamente uma página de disco. Existem dois tipos de nodos: folha e interno. No nodo folha os registros de entrada são da forma <MBR, rid>, onde o MBR é o envolvente do objeto espacial, e o rid é o identificador o objeto espacial no banco de dados. Os nodos internos estão estruturados como <MBR, pointer>, onde pointer é o endereço dos nodos inferiores da estrutura da árvore, e MBR é o retângulo que envolve todos os MBR dos nodos inferiores da estrutura da árvore. Deste modo, uma hierarquia com os MBRs dos objetos espaciais é construída. A Figura 2.7 exibe um exemplo da R-Tree, enquanto que a Figura 2.8 apresenta sua estrutura simplificada. Figura 2.7: Exemplo de uma R-Tree, onde seus objetos espaciais estão envolvidos pelos seus respectivos MBR (CIFERRI, 2002). 15

30 Com relação a estrutura da árvore, todo nodo, independentemente do tipo, possui um espaço para M entradas e armazena obrigatoriamente um número mínimo m de entradas (com 2 ). O parâmetro m pode ser configurado com o intuito de otimizar o desempenho da R-Tree. O nodo raiz contém no mínimo duas entradas, exceto quando folha, e é o único nodo que pode ter menos que m entradas. Figura 2.8: Estrutura simplificada da R-Tree apresentada na Figura 2.7 (CIFERRI, 2002). 2.4 Computação em Nuvem Nos últimos anos, a indústria de TI tem passado por significativas mudanças, principalmente no modo como recursos computacionais são ofertados aos usuários finais. No modelo convencional, recursos computacionais são oferecidos por centro de dados (ou do inglês, data center) tradicionais sob a forma de pacotes. Nesta abordagem, a contratação destes recursos era realizada mediante ao pagamento de um valor fixo independente da utilização dos recursos. Recentemente, no entanto, com o advento das tecnologias de redes distribuídas e virtualização de recursos computacionais, este modelo de locação mudou. Centros de dados passam a oferecer suas capacidades computacionais sob demanda, permitindo que usuários utilizem seus recursos e paguem um valor baseado no consumo, como por exemplo, o número de ciclos de processamento de CPU utilizados por determinada tarefa, armazenamento de dados em bytes ou uso da largura de banda larga para operações de upload e downloads. Este modelo de serviços ficou conhecido como computação em nuvem. Segundo (SOSINSKY, 2011), computação em nuvem refere-se às aplicações e serviços que executam sobre uma infraestrutura de redes distribuídas que utilizam recursos virtualizados e são acessados por meio de protocolos e padrões de redes presentes na Internet. Ela é caracterizada por apresentar recursos virtualizados que tem potencial ilimitado de computação, além disso os detalhes da infraestrutura física dos sistemas são omitidos para os desenvolvedores e usuários. Neste modelo computacional, os centros de dados são conhecidos como provedores, enquanto que os recursos contratados (máquinas virtuais, sistemas operacionais, aplicativos dentre outros) são denominados por serviços. Do ponto de vista operacional, estes centros de dados são compostos por várias máquinas físicas de baixo custo (centenas ou milhares), podendo ter diferentes configurações de hardware processadores, memórias e capacidade de armazenamento, porém devem conter o mesmo software. Elas comunicam-se entre si por meio de infraestruturas de comunicação. Sobre cada máquina física uma ou mais máquinas virtuais (VM) são executadas, onde cada uma delas serve 16

31 aos diversos serviços contratadas pelos usuários, conforme exemplificado na Figura 2.9. Por apresentar estas características os serviços providos pela computação em nuvem geralmente apresentam baixos custos e grande escalabilidade. Figura 2.9: Ambiente de computação em nuvem (BUYYA; BROBERG; GOSCINSKI, 2011). Segundo o NSIT (BADGER; PATT-CORNER; VOAS, 2012), National Institute of Standards and Technology dos Estados Unidos, nuvens computacionais podem oferecer diferentes modelos de implantação e de serviços conforme é resumido na Figura Modelos de implantação referem-se à localização e ao gerenciamento da infraestrutura de nuvem, enquanto que os modelos de serviço compreendem os tipos de serviços que podem ser acessados em uma plataforma de nuvem. Figura 2.10: Definições de computação em nuvem segundo o NSIT. Imagem traduzida de (SOSINSKY, 2011). Nas subseções a seguir são apresentadas as definições sobre as características essenciais, modelos de implantação, modelos de serviço oferecidos pelos provedores de nuvem e, por fim, são apresentados os conceitos de bancos de dados como um serviço (DaaS) Características Essenciais As características essenciais são vantagens que as soluções baseadas em computação em nuvem oferecem. No meio acadêmico e comercial são definidas cinco características que estão apresentadas abaixo (BADGER; PATT-CORNER; VOAS, 2012): 1. Self-service sob demanda: o usuário pode configurar os recursos contratados de 17

32 acordo com sua necessidade, ajustando a capacidade de processamento, espaço de armazenamento entre outros, não requerendo interações humana com os provedores dos serviços. 2. Amplo acesso: o acesso aos serviços é realizado por meio de mecanismos padronizados que possibilitam o uso por plataformas do tipo thin, como por exemplo, os browsers, celulares, PDAs e laptops. 3. Elasticidade rápida: capacidades computacionais podem ser adquiridas e liberadas pelos usuários de acordo com a sua demanda e a qualquer momento de forma rápida e prática. Essa característica fornece aos usuários o sentimento de que os recursos computacionais são virtualmente infinitos e que podem ser adquiridos a qualquer hora. 4. Pooling de recursos: recursos computacionais dos provedores são organizados em um pool para servir aos diversos usuários a partir de um modelo multi-inquilino, também conhecido por multi-tenant. Embora os serviços contratados pelos usuários sejam logicamente isolados, no nível de infraestrutura há um compartilhamento de recursos computacionais por meio de máquinas virtuais. Os recursos de hardware são dinamicamente atribuídos e removidos de acordo com a demanda de uso dos usuários. 5. Serviço medido: serviços em nuvem automaticamente controlam e otimizam o uso de recursos por meio de uma capacidade de medição. A automação é realizada em algum nível de abstração apropriada de acordo com o serviço contratado, por exemplo, capacidade de espaço disponível para armazenamento, tempo de processamento, uso da largura de banda ou contas de usuários ativas. O monitoramento sobre o uso do recurso busca maior transparência entre os provedores e os usuários dos recursos contratados Modelos de Implantação Os modelos de implantação como dito anteriormente compreendem a localização da infraestrutura de nuvem. São definidas quatro formas de implantar ambientes em nuvem: 1. Nuvem pública: a infraestrutura da nuvem é disponibilizada para o público em geral, podendo ser acessada por qualquer usuário que tenha conhecimento sobre a sua localização e serviços. 2. Nuvem privada: a infraestrutura é de acesso exclusivo de uma organização, o acesso a esta nuvem pode ser local ou remoto e a administração pode ficar sobre responsabilidade da própria organização ou delegada a terceiros. 3. Nuvem comunidade: trata-se de uma infraestrutura compartilhada entre organizações que compartilham do mesmo interesse. 4. Nuvem híbrida: é uma composição de duas ou mais nuvens (privadas ou públicas) 18

33 onde estas nuvens possuem identidade única, Modelos de Serviços No ambiente de computação em nuvem os serviços ofertados pelos provedores podem ser classificados em três categorias (BADGER; PATT-CORNER; VOAS, 2012): Software como um serviço (SaaS Software-as-a-Service): trata-se de um ambiente completo com aplicativos, gerenciamento e interface com o usuário. No SaaS as aplicações são providas para os clientes através de interface thin (normalmente, um navegador web). Neste modelo de serviço a única responsabilidade do usuário é o fornecimento de dados e a interação com os aplicativos. Todos os detalhes relativos à infraestrutura do ambiente fica a cargo dos provedores. São exemplos de SaaS o Office 365, Google Docs, Gmail, entre outros aplicativos. Plataforma como um serviço (PaaS Platform-as-a-Service): dispõe de máquinas virtuais, sistemas operacionais, aplicativos, serviços, APIs de desenvolvimento, entre outros serviços. Neste modelo, os clientes podem implantar suas aplicações ou fazer uso de aplicativos que foram construídos em conformidade com as linguagens e ferramentas que são disponibilizadas pelo provedor do PaaS. Os centros de dados são responsáveis pelo gerenciamento da infraestrutura de nuvem, pelo sistema operacional, e por habilitar os softwares, enquanto que os clientes podem instalar e gerenciar seus aplicativos. Pode-se citar como exemplos desta categoria de serviço, o Windows Azure (WINDOWS AZURE, 2013) e Google App Engine. Infraestrutura como um serviço (IaaS Infrastructure-as-a-Service): neste modelo estão disponíveis máquinas virtuais, armazenamento virtual, infraestrutura virtual, e outros componentes de hardwares e recursos que os clientes podem fazer uso. No IaaS é de responsabilidade do provedor o gerenciamento da infraestrutura de nuvem, enquanto todos os outros aspectos ficam a cargo do cliente, como por exemplo, o sistema operacional, as aplicações e as interações dos usuários com o ambiente. O Amazon Elastic Cloud Computing (EC2) (AMAZON EC2, 2013) e o Eucalyptus são exemplos de serviços de infraestrutura como serviço. Os modelos de serviço descritos acima também são conhecidos como SPI (Software, Plataforma e Infraestrutura). Na literatura de computação em nuvem há referências a outros modelos de serviços, tais como: StaaS (Storage-as-a-Service), IdaaS (Identity-as-a-Service) ou DaaS (Database-as-a-Service). Embora o SPI contemple todos os outros modelos, a próxima seção abordará o DaaS, objeto de estudo desta dissertação, com maior detalhe DaaS: Banco de dados como um Serviço Sistemas de armazenamento de dados em nuvem são alternativas aos SGBDs convencionais mantidos em uma infraestrutura tradicional, e se caracterizam por prover 19

34 elasticidade e escalabilidade associadas a um baixo custo de investimento. Por isso, esta solução tem sido adotada por empresas de diversos segmentos do mercado. Sejam estas empresas de pequeno porte (como as startups) que visam à redução dos custos operacionais pela terceirização da infraestrutura, ou as grandes corporações que buscam meios eficazes para lidar com o aumento inesperado na carga de trabalho (SOUSA et al., 2010). As tecnologias de virtualização possibilitaram o desenvolvimento da computação em nuvem, porque permitem o compartilhamento de recursos físicos das máquinas hospedeiras criando um pooling de recursos. Elas também proporcionam maior disponibilidade para os serviços oferecidos. Contudo, a camada de abstração decorrente da virtualização incorre em uma sobrecarga, principalmente, nas operações de leitura e escrita de dados do armazenamento secundário. Avanços nas tecnologias de virtualização possibilitaram reduzir esta sobrecarga. Assim, o impacto no desempenho na recuperação e armazenamento de dados foi minimizado, viabilizando o emprego desta arquitetura nos sistemas de armazenamento de dados (SOROR et al., 2010). Esta arquitetura de compartilhamento de recursos computacionais entre as várias máquinas, motivou a criação de novos mecanismos para o armazenamento e processamento de dados. Dentre estes, os mais conhecidos são o Google File System (GFS) (GHEMAWAT; GOBIOFF; LEUNG, 2003), o Hadoop Distributed File System (HDFS) (HADOOP, 2012) e o Distributed Hash Table (DHT) (DECANDIA et al., 2007), além de sistemas de processamento de dados distribuídos como o Google MapReduce (DEAN; GHEMAWAT, 2008), Hadoop MapReduce (HADOOP, 2012), entre outras técnicas. A literatura de BD lista algumas características presentes nos principais sistemas de DaaS, tais como: Gerenciamento autônomo: com uma carga de trabalho tão dinâmica, hardware e software precisam ser constantemente reconfigurados. Além disso, com a ausência de um administrador de banco de dados, os serviços de computação em nuvem devem prover mecanismos para automatizar ao máximo, a configuração do sistema (PATON et al., 2009). Gerenciamento de dados multi-inquilino: os sistemas classificados como DaaS são multi-inquilinos, i.e., hospedam vários inquilinos dentro de um único sistema permitindo o compartilhamento de recursos computacionais. Este compartilhamento pode ocorrer em diferentes níveis de isolamento. Em (ELMORE et al., 2011) é apresentado um estudo sobre os vários níveis de isolamento de gerenciamento de dados no DaaS. Relaxamento das propriedades ACID das transações: réplicas de dados são utilizadas pelos ambientes em nuvem para prover a alta-disponibilidade dos sistemas. Comumente, estas replicações são realizadas entre centros de dados geograficamente distantes. Contudo, Gilbert e Lynch (2002), em (GILBERT; 20

35 LYNCH, 2002), por meio do teorema Consistency, Availability, Partition Tolerance (CAP), mostra que em um sistema de banco de dados distribuído apenas duas dessas três propriedades podem ser atendidas: consistência, disponibilidade e tolerância a partições. Como consequência disto, muitos provedores de acesso relaxam sobre a consistência de dados para garantir a alta-disponibilidade almejada. Escalabilidade e desempenho: os bancos de dados nas nuvens devem apresentar meios transparentes aos usuários de escalabilidade. A escalabilidade pode ser atingida por duas abordagens: vertical e a horizontal (SOUSA et al., 2010). Na primeira, melhora-se a capacidade de hardware adicionando mais discos, processadores ou memórias, em geral funciona bem para o ambiente de banco de dados, mas traz consigo um grande investimento. Na horizontal a escalabilidade é alcançada pela adição de novas máquinas, permitindo a distribuição dos dados em diferentes SGBDs. Este método é mais complexo e difícil de ser alcançado no ambiente de dados, pois requer um planejamento sobre a fragmentação uma vez que os dados são correlacionados. Tolerância a falhas e distribuição de dados: a infraestrutura da nuvem é formada por máquinas de baixo custo, por isso é esperado que ocorram falhas. Neste sentido, os provedores de serviço devem ser capazes de oferecer SGBDs que possuam tolerância a falhas. Existem diversas abordagens para obter sistemas tolerantes a falhas como a fragmentação e distribuição de dados (ABADI, 2009). Conforme visto anteriormente, várias são as tecnologias aplicadas aos sistemas de gerenciamento de banco de dados em nuvem disponíveis no mercado. Em (SOUSA et al., 2010), foi proposta uma classificação destes sistemas com base nos seguintes critérios: modelo relacional e suporte nativo para nuvem. O primeiro parâmetro refere-se à utilização do modelo relacional, já o segundo indica se o sistema de gerenciamento foi concebido para atender aos requisitos específicos da computação em nuvem. Na Figura 2.11, são listados exemplos de sistemas conforme esta classificação. Figura 2.11: Classificações dos DaaS baseada nas tecnologias utilizadas. Imagem adaptada de (SOUSA et al., 2010). 21

36 No primeiro quadrante estão os SGBDs relacionais desenvolvidos para atuar no contexto de nuvem. Nestes sistemas, o modelo relacional foi escolhido para o armazenamento e processamento de dados, além disso eles foram projetados com base nos requisitos de computação em nuvem. O exemplo mais conhecido é o Windows Azure SQL Database, antigamente conhecido como SQL Azure, da plataforma Microsoft Azure. No segundo quadrante estão os SGBDs relacionais que são utilizados na nuvem, porém eles não foram projetados para computação em nuvem. Como exemplo destes sistemas pode-se citar o Amazon Relational Database Server (Amazon RDS) e o Relational Cloud (CURINO et al., 2011). No terceiro quadrante estão os sistemas considerados nativos para a nuvem e que não utilizam o modelo relacional. Estes sistemas utilizam a tecnologia de armazenamento de dados do tipo chave-valor ou baseada em colunas. Dentre os sistemas desta categoria, os mais conhecidos são: Amazon Dynamo e o Voldemort ambos utilizam o modelo chave-valor, enquanto o BigTable, HBase e o Cassandra são exemplos de sistemas baseados em coluna. No quarto e último quadrante estão os sistemas de armazenamento de dados não-nativos e que não consideram o modelo relacional para armazenamento e processamento de dados. Eles guardam os dados sob a forma de XML, documentos ou grafos. Como exemplos desta categoria pode-se citar o MongoDB e o CouchDB. 2.5 Benchmarks para avaliação de desempenho Esta seção discorre sobre benchmarks para avaliação de desempenho de sistemas. Na Seção 2.5.1, são descritos dois benchmarks para avaliação de desempenho de SSD: o TPC-H e o Star Schema Benchmark (SSB). O TPC-H permite a avaliação de desempenho de sistemas de SSD por meio de consultas a base de dados que lidam com enorme volume de dados. Por sua vez, o SSB adapta a estrutura do TPC-H para avaliar o desempenho de DW que são representados logicamente por um esquema estrela. A Seção discorre sobre o Spadawan Benchmark, ou Spatial Data Warehouse Benchmark, que é um benchmark baseado no SSB e destinado à avaliação de desempenho de sistemas de DWG. Neste benchmark foram propostos dois esquemas de DWG, um apresentando a redundância de objetos espaciais, enquanto que o outro é não redundante. Por fim, na Seção é apresentando Yahoo! Cloud Serving Benchmark (YCSB) para avaliação de desempenho de sistemas de gerenciamento de dados em nuvem Benchmark para DW O TPC Benchmark H (TPC-H) (TRANSACTION PROCESSING PERFORMANCE COUNCIL, 2013) é um benchmark voltado para avaliação experimental de sistemas de suporte à decisão. Ele consiste em um conjunto de consultas ad-hoc orientadas ao negócio e de atualizações de dados de modo concorrente. Tais consultas e o povoamento de dados do BD foram escolhidos para ter grande relevância em aplicações da indústria. O objetivo deste benchmark é simular SSD que lidam com um enorme volume de dados, executa consultas com alto grau de complexidade e 22

37 fornece respostas para questões críticas do negócio. O TPC-H avalia o desempenho de SSD pelo processamento de consultas diante de um banco de dados sobre condições controláveis. Para isto, ele simula a geração de consultas ad-hoc que tem aplicação prática no mundo-real. Estas consultas têm como características: possuem alto grau de complexidade; utilizam uma grande variedade de acessos; examinam uma grande porcentagem dos dados disponíveis; todas diferem entre si; e contêm parâmetros de consultas que mudam na execução da consulta. Para a avaliação do desempenho destes SSD, o TPC-H foi estruturado em 8 tabelas distintas, conforme mostra a Figura 2.12a, e representa uma aplicação genérica para vendas de produtos. O benchmark utiliza tipos de dados comuns e que estão presentes em vários SGBD comerciais. Embora tenha se difundido como um importante benchmark para SSD, o TPC-H não atende às necessidades específicas dos sistemas de DW. Diante disso, um novo benchmark foi proposto, chamado de Star Schema Benchmark (SSB) (O NEIL; O NEIL; CHEN, 2005). SSB é um benchmark baseado no TPC-H que foi projetado para mensurar o desempenho de sistemas de banco de dados que dão suporte a aplicações de data warehousing. Este benchmark é representado logicamente segundo o esquema estrela (KIMBALL; ROSS, 2002), e por isso, foi necessária a realização de uma série de alterações para adaptá-lo para sistemas de DW, como por exemplo, a desnormalização de tabelas e eliminação de atributos desnecessários às consultas multidimensionais. Estas alterações podem ser observadas na Figura 2.12b. 23

38 Figura 2.12: (a) esquema lógico do TPC-H (TRANSACTION PROCESSING PERFORMANCE COUNCIL, 2013). (b) esquema lógico do SSB (O NEIL; O NEIL; CHEN, 2005). O SSB propõe um conjunto de consultas que envolvem o uso de diversos operadores, funções de agregação e ordenação de dados. O intuito destas consultas é simular consultas analíticas e multidimensionais, as quais investigam fatos sobre diferentes perspectivas. Além disso, o benchmark preocupa-se com a cobertura de seletividade, i.e., provê um controle sobre os registros da tabela de fatos que serão acessados por uma determinada consulta para controlar o número de tuplas da tabela de fatos que serão retornados por cada consulta (O NEIL; O NEIL; CHEN, 2005). Desta forma, o SSB firmou-se como importante mecanismo de avaliação experimental para medir o desempenho de sistemas de DW convencionais. No entanto, ele não fornece meios para mensurar a eficiência de DWG. Por isso, adaptações nos esquemas do SSB foram realizadas para representação dos dados espaciais e normalização de geometrias conforme é descrito a seguir Spadawan Benchmark: benchmark para DWG O Spadawan Benchmark (Spatial Data Warehouse Benchmark) (SIQUEIRA et al., 2010) é uma proposta de benchmark que estende o SSB para avaliação de desempenho de consultas SOLAP sobre um DWG. Ele viabiliza a análise de desempenho de operações SOLAP de drill-down e roll-up sobre um DWG por meio de hierarquias espaciais predefinidas. Além disso, ele permite investigar o impacto da redundância de dados espaciais no desempenho destes sistemas. A análise de desempenho de consultas SOLAP sobre DWG tornou-se possível pelas alterações propostas pelo Spadawan para estender o esquema estrela do SSB para armazenar dados geográficos. As modificações sugeridas mantêm preservados os dados descritivos do SSB e uma hierarquia espacial foi criada com base na dimensão convencional e original do SSB. Como mostra a Figura 2.12b, ambas as tabelas de dimensões Customer e Supplier possuem a seguinte hierarquia espacial: region nation city address. O número de dados espaciais que representam cidade, país e região no Spadawan é fixo, porém os autores descrevem técnicas que podem ser empregadas para aumentar o número destes atributos permitindo uma maior seletividade (SIQUEIRA et al., 2010). O Spadawan Benchmark define consultas adaptadas do SSB para fazer uso de dados espaciais. Estas consultas foram classificadas em 4 tipos. As consultas do tipo 1, 2 e 3 têm por base a consulta Q2.3 do SSB, enquanto que a consulta do tipo 4 é fundamentada na Q3.3. Elas foram definidas com base em janelas de consultas espaciais. Janelas de consultas têm a forma quadrática, são correlacionadas com os dados espaciais (i.e. o seu tamanho depende do nível de granularidade) e são consideradas ad-hoc porque sua feição espacial não está previamente armazenada em nenhuma tabela de dimensão (SIQUEIRA et al., 2010). O Spadawan benchmark permite a investigação do impacto da redundância de dados espaciais comparando dois esquemas de DWG: um esquema redundante (chamado GRSSB) e outro não redundante (nomeado esquema híbrido ou simplesmente GHSSB). Estes esquemas são 24

39 detalhados a seguir GRSSB e GHSSB Como mencionado na seção anterior, o Spadawan Benchmark propõe dois esquemas baseados no SSB para avaliar o efeito no processamento de consultas decorrente do armazenamento de dados redundantes em um DWG: o esquema redundante (Geographic Redundant SSB, também conhecido por GRSSB) e o não redundante (Geographic Hybrid SSB, ou GHSSB). Ambos os esquemas de DWG estão representados na Figura Neles, atributos com o sufixo _geo armazenam os dados com feições geométricas da localidade. Figura 2.13: Esquemas do Spadawan Benchmark adaptado de (SIQUEIRA et al., 2010). A Figura 2.13a representa um esquema para DWG redundante. Neste, todos os dados geográficos são armazenados em cada uma das tabelas de dimensões espaciais e não são compartilhados. Por exemplo, cada tupla que represente clientes lotados no continente europeu armazenará os dados geográficos da EUROPA, isto ocorre tanto para Supplier quanto para Customer. Desta forma, fica evidente a redundância dos dados espaciais. Por outro lado, o esquema não redundante (i.e. o esquema GHSSB) foi inicialmente proposto em (SIQUEIRA et al., 2008) para cumprir as definições de tabelas de dimensões propostas em (FIDALGO et al., 2004). Ambas as tabelas de dimensões espaciais (i.e. Customer e Supplier) presentes neste esquema são classificadas como híbridas, pois mantêm tanto a descrição da geografia quanto dados convencionais (e.g., o endereço de cliente mais o nome e o número do telefone). A Figura 2.13b ilustra que Customer e Supplier compartilham as localizações de region, nation e city, mas não endereço. Testes de desempenho foram realizados nos dois esquemas e comparados em (SIQUEIRA, 25

40 2009; SIQUEIRA et al., 2008). Os resultados obtidos constataram que o esquema redundante, além de maior custo de armazenamento também apresenta redução de desempenho no processamento de consultas SOLAP, quando comparado ao híbrido Benchmark para Computação em Nuvem O Yahoo! Cloud Serving Benchmark (YCSB) (COOPER et al., 2010) é um benchmark para avaliação de desempenho e escalabilidade em sistemas de computação em nuvem. Este benchmark foi dividido incialmente em duas camadas: camada 1 desempenho e camada 2 escalabilidade. A camada de desempenho do benchmark tem por objetivo avaliar a latência das requisições realizadas ao sistema de gerenciamento de dados em nuvem, quando o mesmo está executando uma carga de trabalho. Essa métrica é importante indicativo para o desempenho, pois existe um custobenefício associado a latência e ao rendimento: para uma dada configuração de hardware, quando a carga de trabalho é incrementada, a latência de requisições individuas aumenta e o rendimento do sistema diminui. A camada de desempenho do benchmark visa caracterizar este custo-benefício, para isto mensura a latência do sistema à medida em que o rendimento é aumentado até o sistema de gerenciamento de dados ficar saturado. Deste modo, pode-se determinar um limiar aceitável de latência para o sistema analisado. A camada de escalabilidade do benchmark tem por objetivo examinar o impacto na performance à medida em que são adicionadas novas máquinas ao sistema. Para isto, foram definidas duas métricas: a scaleup e a speedup. A métrica scaleup mensura o desempenho do sistema quando o número de servidores envolvidos no processamento é incrementado. Já na speedup, o desempenho do sistema é medido quando o número de servidores responsáveis pelo processamento é incrementado enquanto uma carga de trabalho está em execução. Para a coleta destas métricas, cargas de trabalhos são disparadas a um número inicial de servidores. Em seguida, são aumentados as cargas de trabalhos e os números de servidores que compõem o sistema. Scaleup avalia a latência, que deve permanecer constante nas diferentes configurações de escala de testes. Por sua vez, a speedup verifica a escalabilidade do ambiente, por isso é esperado maior desempenho no sistema quando um novo servidor é adicionado. Contudo, a adição deste novo servidor deve ocorrer com pouco ou nenhum período de interrupção enquanto o sistema é reconfigurado para comportar o novo servidor. Para a avaliação do desempenho e escalabilidade dos sistemas em nuvem foi definida uma base de dados. Nesta base de dados é armazenada uma tabela T com C campos. Cada registro de T é identificado por uma chave-primária que é formada por uma cadeia de caracteres. Cada campo é nomeado como field0, field1 e assim por diante. Os valores de cada atributo são alfanuméricos de tamanho fixo com comprimento igual a L bytes. O YSCB também define um pacote de cargas de trabalho denominado YCSB Core Package. Um pacote é composto por uma coleção de cargas de trabalho relacionadas. Cada carga de trabalho representa um conjunto de dados de teste, requisições distribuídas e operações de leitura/escrita, 26

41 que podem ser as seguintes: insert (inclui novo registro na tabela T), update (atualiza o valor do campo C de um dado registro), read (recupera o registro a partir de um campo aleatório ou a partir de todos os campos) e scan (examina registros em ordem de chave-primária, iniciando por uma escolhida aleatoriamente até uma quantidade x de registros). O YCSB pré-define várias cargas de trabalho como: (i) update heavy, onde metade das operações são de leituras e a outra metade são de atualizações; (ii) read heavy, apenas operações de leituras; e (iii) short ranges, somente operações de scans. Todas as cargas pré-definidas avaliam tanto o desempenho quanto a escalabilidade do sistema proposto. O framework do YCSB também permite expandir o YCSB Core Package, adicionando novos pacotes ou cargas de trabalho para um sistema particular. 2.6 Conclusão Neste capítulo, foram apresentadas importantes tecnologias para o suporte à decisão. Os sistemas de DW, juntamente as ferramentas OLAP, são importantes para a elaboração de estratégias em uma instituição, pois permitem a análise de dados sobre diferentes perspectivas e sobre diferentes níveis de detalhe. No entanto, estes sistemas não provêem suporte a dados geográficos impossibilitando a análise do negócio sobre um contexto espacial. Por outro lado, os SIG surgiram como tecnologia destinada à tomada de decisões estratégicas no âmbito espacial. Eles promovem suporte a dados espaciais e sobrepõem informações para geração de novas camadas de dados e auxílio à tomada de decisão. Todavia, são sistemas que operam no nível transacional e não provêem meios para análises multidimensionais. Diante disso, os sistemas de DWG e ferramentas SOLAP foram propostas para unir o DW/OLAP às características inerentes aos SIG. Estes sistemas introduziram um grande desafio ao aliar a funcionalidade de processamento de dados geográficos em um ambiente analítico a um tempo de resposta viável. Na literatura de BD, as estruturas de indexação são amplamente conhecidas por se tratar de um método de acesso alternativo que permite a otimização da busca de registros associados a uma condição de consulta. Desafios de baixo tempo de resposta no contexto espacial motivaram a criação de métodos de acesso auxiliares baseados na localização de objetos espaciais, foi proposto, então, o conceito de MAM. Estas estruturas de indexação permitiram a realização de consultas espaciais com alta performance. Paralelamente ao desenvolvimento dos SSD, tecnologias de acesso à Internet e virtualização de servidores permitiram a criação de um novo paradigma de computação, a chamada computação em nuvem. A computação em nuvem permitiu aos centros de dados, a oferta de recursos computacionais como serviços, pelos quais paga-se por demanda de uso. Estes sistemas baseados em nuvem provocou a comunidade de banco de dados, que logo propôs tecnologias de armazenamento e processamento de dados aptas a explorar as características de elasticidade e escalabilidade, os sistemas DaaS. Estes sistemas conferem aos usuários a percepção de recursos computacionais (processamento, armazenamento e largura de banda) quase infinitos. 27

42 Estudos realizados (ABADI, 2009) sugerem que os sistemas analíticos são os que melhor se adequam ao conceito de nuvem, quando comparados ao transacional. Como dito anteriormente, os DWG introduziram um grande desafio de baixo tempo de resposta às consultas SOLAP, e até o momento que foi escrita esta dissertação não se tem conhecimento de mecanismos de indexação para estes sistemas, quando oferecidos sobre a infraestrutura de nuvem. Diante disso, este trabalho propõe uma estrutura de indexação de DWG em nuvem. 28

43 3.1 Introdução Neste capítulo são descritos trabalhos correlatos ao projeto proposto nesta dissertação. Nas seções 3.2 e 3.3 são apresentados dois índices para DW convencionais: o Índice de Projeção e o Índice Bitmap, respectivamente. A Seção 3.4 discorre sobre o software FastBit que possibilita a criação de índices bitmaps sobre diferentes configurações. Na Seção 3.5, são apresentadas a ar- Tree e o SB-Index que são estruturas de indexação para DWG. O EMINC, estrutura de índice multidimensional para sistemas de armazenamento de dados em nuvem, é comentado na Seção 3.6. Por fim, na Seção 3.7 são postos os comentários finais acerca dos trabalhos correlatos. 3.2 Índice de Projeção Índices de projeção (O NEIL; QUASS, 1997) são estruturas que conferem alto desempenho às operações de busca de registros. Um índice de projeção sobre uma coluna C de uma tabela T consiste em uma sequência de valores C ordenada segundo a numeração da linha em T. Espaços vagos são admitidos na estrutura do índice para número de linhas não utilizados. Apesar do conceito do índice de projeção ser semelhante ao da fragmentação vertical, eles são mecanismos distintos. No índice de projeção a ordem dos registros de T são preservados nesta estrutura, além disso é permitida a replicação de valores. A Figura 3.1 exibe um exemplo de índice de projeção. Para construção do índice de projeção sobre uma dada coluna C, atributo de tamanho fixo, por exemplo 4 bytes, e página de disco de 4 KBytes, pode-se alocar 1000 tuplas em cada página. O processo é repetido sucessivas vezes até a estrutura do índice estar formada. Com as tuplas no índice numeradas de 0 a n. A busca por um registro pode ser realizada calculando a página p, onde p = n/1000, e o slot s, onde s = n%1000, e % compreende a operação de módulo. Figura 3.1: Exemplo de índice de projeção (SIQUEIRA, 2009). Colunas de tamanho variado introduz desafios na recuperação de registros. Uma técnica usada para contornar este problema é fixar o tamanho da coluna com o maior valor assumido por C e, então, tratar as colunas como se fossem de tamanho fixo. 29

44 3.3 Índices Bitmap Índices bitmap é um dos mais eficientes métodos de indexação disponíveis para acelerar o processamento de consultas multidimensionais sobre faixas de valores, como as consultas OLAP sobre DW. Estes métodos de acesso oferecem alto desempenho no processamento de consultas multidimensionais sobre faixas. A origem desta estrutura, no entanto, não está relacionada aos SSD. Ela era utilizada antes mesmo do surgimento dos sistemas de bancos de dados relacionais e DW, e era considerada uma forma especial de arquivos invertidos (KNUTH, 1998). A popularização do nome índice bitmap se deve aos trabalhos de Patrick O Neil (O NEIL; QUASS, 1997). Um índice de bitmap é construído utilizando os valores distintos de um atributo A de uma dada tabela T. Aos valores assumidos por A, são associados um bitmap (vetor de bits), com tantos bits quantos forem os números de registros em T. Cada bit do vetor é definido como 1 se o atributo no registro assume o valor específico, caso contrário o bit assume o valor 0. O processamento de consultas sobre esta estrutura é realizado por meio de operações lógica (OR, AND e NOT) sobre a cadeia de bits dos vetores bitmap (STOCKINGER; WU, 2006). Os hardwares oferecem suporte nativo as operações lógicas sobre bits, assim sendo, é possível obter um desempenho satisfatório na busca de registros sobre índices bitmaps. A Figura 3.2 mostra um exemplo de um índice bitmap simples (Figura 3.2b), construído a partir da coluna lo_custkey da tabela lineorder (Figura 3.2a). No índice bitmap, o registro que tem valor 2 (destacado pela faixa horizontal), assume valor de bit 1 apenas no bitmap, para os demais, 0. O acesso aos registros originais é realizado pelo mapeamento da página e porção do disco onde os dados estão localizados em um identificador numérico, semelhante ao que ocorre no índice de projeção, definido na Seção 3.2. Figura 3.2: Exemplo de um Índice Bitmap de Junção (IBJ) sobre o esquema do Spadawan Benchmark. Índices Bitmap têm sido empregados em DW com o intuito de evitar as custosas operações de junção inerentes ao esquema estrela, as chamadas junções estrela (ou star-join). Isto é possível pela construção de um índice bitmap sobre um atributo da tabela de fatos, que também é chaveestrangeira para alguma dimensão. No exemplo anterior, o índice da Figura 3.2b é um IBJ para o atributo lo_custkey da dimensão customer. Este índice associa todas as tuplas da dimensão customer 30

45 a um conjunto de registros da tabela de fatos. Ainda com relação ao exemplo, pode-se notar que o lo_custkey, cujo valor é 2, aparece na sexta posição tanto na tabela como no arquivo do índice havendo uma relação biunívoca entre os registros da tabela e as entradas dos IBJ. Conforme mostrado anteriormente, os índices bitmap de junção são muito úteis ao processamento de consultas OLAP sobre DW. No entanto, caso os atributos da dimensão possuam alta cardinalidade o desempenho pode ser degradado, visto que é requerido um grande volume de armazenamento para os diversos vetores de bitmap (SARAWAGI, 1997). Em (STOCKINGER; WU, 2006), são propostas três técnicas para evitar os problemas associados as altas cardinalidades dos atributos: empacotamento, compressão e codificação. O autor também cita a possibilidade de combinação destas técnicas para obter melhor tempo de resposta sobre um dado custo de armazenamento. O CSB-Index proposto neste trabalho estende o SB-Index que introduziu o Índice Bitmap de Junção em DWG. Além disso, foi empregada uma técnica de compressão dos IBJ criados por meio da ferramenta FastBit Codificação O índice bitmap básico foi apresentado na Seção 3.3 e é conhecido também como índice bitmap codificado por igualdade. Nele, os vetores de bits indicam se o valor de um dado atributo é igual, ou não, ao valor da chave. Esta estratégia é eficiente para avaliar expressões de consultas baseadas em valores exatos, como por exemplo, = 38. Chan e Ioannidis, em (CHAN; IOANNIDIS, 1999), desenvolveram outras duas estratégias de codificação para o índice bitmap: a codificação por faixa e por intervalo. O objetivo destas estratégias é otimizar a avaliação de inequações sobre um índice bitmap. As expressões ã < 56,7 e 56,7 < ã 70 são exemplos destas inequações. Uma comparação entre as estratégias de codificação por igualdade e por faixa de valores foi realizada por (STOCKINGER; WU, 2006) é mostrada na Figura 3.3. Na Figura 3.3a, o atributo cuja chave assume o valor 2 está destacado por uma faixa horizontal cinza. Considerando apenas o índice codificado por igualdade (Figura 3.3b), nota-se que apenas o bitmap possui o bit 1 para este valor de chave, enquanto os demais bits da mesma faixa horizontal assumem o valor 0. Na codificação por faixa de valores, exibida na Figura 3.3c, todos os bits compreendidos entre os bitmaps e são fixados em 1, enquanto os outros, em 0. Esta estratégia é eficaz no processamento de consultas sobre faixas de valores. Considere uma busca onde deseja-se obter os valores em que 2. Na codificação por faixa, apenas o bitmap é acessado e percorrido no processamento da consulta. Por outro lado, se for utilizada a codificado por igualdade, aos vetores de bits, e é aplicada a expressão lógica OR, a qual tem por resultado um único vetor de bits com valores de A que satisfazem a condição da consulta. Assim sendo, três vetores seriam acessados para avaliar a consulta, em oposição ao único vetor da codificação por faixa. Portanto, 31

46 fica claro que a codificação por faixa de valores simplifica o processamento de consultas quando for necessária a avaliação de inequações. De modo simplificado, a codificação por faixa requer no máximo um único acesso a um vetor de bits para avaliar consultas por faixa de valores. Já a estratégia por igualdade requer em média N/2 acessos a vetores, onde N é o número total de vetores construídos sobre o atributo A de uma dada relação. Apesar de simplificar o processamento de consultas sobre faixas de valores, não é notável a redução do número de vetores de bitmap quando comparado à codificação por igualdade. Deste modo, para uma relação cuja a cardinalidade de um atributo X é dada por X, são necessários X - 1 vetores de bits para a criação do índice bitmap. Figura 3.3: Comparação entre índice de bitmap codificado por igualdade (b), codificado por faixa (c) e os valores a projeção do atributo A (a). Diante disso, foram propostas técnicas que permitam um melhor controle da quantidade de bitmaps do Índice Bitmap a fim de viabilizar o seu uso em atributos cujo domínio possui alta cardinalidade. O método de codificação que apresenta o menor número de vetores de bits é a codificação binária:, onde denota a cardinalidade do atributo. Na literatura existem diversas propostas de implementação de índices bitmaps que utilizam a codificação binária, tais como: o bitmap codificado (WU; BUCHMANN, 1997) e bit-sliced (O NEIL; QUASS, 1997). Embora esta estratégia de codificação demande menos vetores de bits na sua criação, é requerido acesso a todos os bitmaps para responder consultas por faixa de valores. A seguir, será descrito em maiores detalhes a codificação binária do índice bit-sliced. Mais informações acerca do bitmap codificado pode ser obtido em Wu e Buchmann (1997). Índices bit-sliced armazenam um conjunto de fatias de bitmaps, as quais são ortogonais aos dados mantidos em um Índice de Projeção. Para auxiliar a definição do índice bit-sliced. Considere que em uma tabela T, cada valor da coluna C pode ser representado por uma sequência de N+1 bits. Então, define-se uma função (, ), onde D assume o valor 0, exceto para aqueles registros em que existe valores para C. Os valores de D podem ser definidos como: (, 0) = 1, se o bit na posição 2 assumir o valor 1 para o n-ésimo registro de C; 32

47 (, 1) = 1, se o bit na posição 2 assumir o valor 1 para o n-ésimo registro de C; De forma geral, temos: (, ) = 1, se o bit na posição 2 assumir o valor 1 para o n-ésimo registro de C. Para cada valor i = 0,..,N, e (, ) > 0 em um registro de T, o bitmap, vai sendo definido com pela atribuição de D(n,i) ao n-ésimo bit de. Cada bitmap é denominado como fatia de bit (bit-slice) da coluna C. Em consequência da restrição (, ) > 0, nenhum bitmap é formado inteiramente por bits 0. Pela definição apresentada anteriormente, índices bit-sliced sobre atributo com altacardinalidade pode ser representado por poucos bitmaps. Por exemplo, 20 bitmaps são capazes de representar atributos cuja cardinalidade é igual a (2 20 1) = ( ). Em (O NEIL; QUASS, 1997), os autores apresentaram também testes de desempenho comparando o processamento de funções de agregação realizadas pelo bit-slices e outros métodos de acesso. Por estes testes, foi concluído que o índice proposto apresenta bom desempenho para este tipo de operação. Em consultas, cuja condição de busca é definida por faixa de valores, índices do tipo B-Tree podem apresentar melhor desempenho para faixas de valores pouco abrangentes. No entanto, quando aumenta-se a abrangência destas faixas o bit-sliced obtém melhor desempenho. Os autores também argumentam que a existência de índices de Projeção ou Bit-sliced sobre todos os atributos das dimensões envolvidas em uma consulta OLAP dispensa o cômputo de uma junção estrela explícita. Neste caso, estes índices atuam como um IBJ, conferindo agilidade ao processamento das consultas OLAP Empacotamento A técnica de empacotamento (ou binning) constrói bitmaps em pacotes (bins) ao invés de utilizar os valores distintos dos atributos (STOCKINGER; WU, 2006). Esta estratégia desassocia o número de bitmaps da cardinalidade do atributo, permitindo a construção de índices bitmap com tamanho predefinido, não importando quão ampla é a cardinalidade do atributo. Uma clara vantagem desta abordagem é o controle sobre o tamanho do índice. No entanto, ela introduz algumas incertezas no conjunto de resposta de uma consulta, se apenas o índice for pesquisado. Por isso, para obter respostas precisas é necessário acessar o arquivo de dados original dos candidatos, e verificar quais registros satisfazem a condição de consulta. O processo de leitura dos registros originais para testar as condições da consulta é chamado de checagem de candidatos. Em (STOCKINGER; WU, 2006) é apresentado um exemplo para explicar a técnica de empacotamento sobre um índice bitmap codificado por igualdade (técnicas de codificação são definidas na Seção 3.3.1), conforme mostra o exemplo da Figura 3.4. Neste exemplo, considere que o atributo A assume valores entre 0 e 100. Os valores dos atributos estão representados na segunda coluna mais à esquerda. Os possíveis valores de A são particionados em cinco pacotes : [0, 20), [20, 40), [40, 60), [60, 80) e [80, 100). Nos bitmaps dos pacotes, o valor 1 para o bit designa que 33

48 o valor do atributo consultado encontra-se naquele pacote. Por outro lado, a presença do valor 0 no bit do vetor do bitmap indica que o valor não está no pacote acessado. Para ilustrar o processamento de uma consulta Stockinger e Wu (2006), considera a seguinte busca: conte o número de registros onde a condição 37 < 63 é satisfeita. A resposta correta é dois, e contém os registros (RID) 5 e 7. No índice, é evidente que a amplitude do intervalo consultado para o valor A abrange os pacotes identificados como 1, 2 e 3. É sabido, no entanto, que todos os registros que se encontram no pacote 2 atendem às restrições da condição. Por outro lado, quando os registros dos pacotes 1 e 3 que têm bit igual a 1 são analisados, não é possível garantir que eles satisfazem a busca, porque podem ser falsos candidatos. Estes registros são apenas candidatos e os pacotes 1 e 3 são chamados de pacotes de fronteira. Registros de pacotes de fronteiram precisam ter seus valores confrontados com a condição de busca para serem considerados aptos ao conjunto resposta. Ainda com relação ao exemplo, há quatro candidatos (linhas 1 e 3 para o pacote 1, e linhas 5 e 6 para o pacote 3). O processo de análise de um candidato necessita ler estas 4 linhas no disco, e verificar se seus valores atendem às restrições impostas pela consulta do usuário. Em um banco de dados volumoso como os DW, esta análise de candidatos pode requerer a leitura de várias páginas de disco causando uma grande sobrecarga no tempo de processamento de uma consulta OLAP. Figura 3.4: Exemplo de índice bitmap com empacotamento. Imagem traduzida de (STOCKINGER; WU, 2006). Empacotamento tem se destacado como uma técnica promissora para melhorar o desempenho de índices bitmaps em bancos de dados volumosos. Abordagens para lidar com o acesso a páginas de disco foram propostas. Em (WU; STOCKINGER; SHOSHANI, 2008), é discutida uma técnica que permite indexar de modo eficiente atributos com altíssima cardinalidade. Neste trabalho foram apresentados experimentos com atributos cuja cardinalidade era de 25 milhões de registros distintos Compressão Compressão de dados é mais uma estratégia utilizada para reduzir o tamanho dos índices bitmap que tendem a ser volumosos quando aplicados em atributos com alta cardinalidade. Como 34

49 cada bitmap é utilizado separadamente, a compressão deve ser aplicada individualmente sobre cada bitmap. É sabido que o desempenho de operações sobre bitmaps comprimidos é degradado. Por isso, métodos de compressão de bitmaps têm sido propostos, sendo o Byte-Aligned Bitmap Code (BBC) (ANTOSHENKOV, 1995) e o Word-Aligned Hybrid code (WAH) (WU; OTOO; SHOSHANI, 2002) os mais conhecidos. O WAH requer mais espaço para armazenamento quando comparado ao BBC, contudo ele permite que operações sejam processadas mais rapidamente. Neste documento, apenas o WAH será descrito, pois é a estratégia utilizada pela ferramenta FastBit (Seção 3.4) utilizada neste trabalho. Na técnica WAH, uma carreira corresponde a uma sequência de bits. A técnica WAH se baseia na codificação por comprimento de carreira (RLE: run-length encoding), onde bits consecutivos idênticos são representados por seus valores de bit (0 ou 1) e por um contador (o tamanho da carreira). Em WAH, cada uma das carreiras consiste de um preenchimento (fill) e uma cauda (tail). Em um preenchimento tem-se uma sequência de valores idênticos de bits que é representada por um contador e pelo seu valor de bit. Uma cauda é um conjunto misturado de 0s e 1s que são representados literalmente sem compressão. A ideia principal do WAH é definir preenchimentos e caudas de modo que eles possam ser armazenados em palavras, i.e., a menor unidade computacional do hardware de computadores modernos. Figura 3.5: Um exemplo de compressão de uma sequência de 5456 bits segundo a estratégia WAH. Imagem traduzida de (STOCKINGER; WU, 2006). A compressão WAH exemplificada na Figura 3.5. Assumindo que uma palavra de máquina tem 32 bits, o exemplo mostra que uma sequência de 5456 bits (Figura 3.5a) é repartida em duas carreiras e codificada em três palavras. Conceitualmente, a sequência de bits é dividida em grupos de 31 bits (Figura 3.5b). Depois, grupos vizinhos que possuem sequências de bits idênticas são 35

50 consolidados (Figura 3.5c). Por fim, os grupos são codificados como palavras de máquina de 32 bits (Figura 3.5d). Cada palavra codificada pode ser definida em duas etapas: (i) o primeiro bit representa o tipo de palavra (i.e., se é de preenchimento ou de cauda), e (ii) os 31 bits restantes armazenam o valor codificado, que pode estar comprimido ou não. Com relação ao exemplo dado, a primeira carreira tem primeiro bit com valor 0, indicando que não se trata de uma palavra de preenchimento, logo é uma palavra literal (literais não são comprimidos). A segunda carreira contém um preenchimento cujo tamanho é 174 (a qual representa os 174 grupos de 31 bits cada) e uma cauda. Para codificação desta carreira, uma palavra de preenchimento e uma palavra de cauda foram necessárias. O primeiro bit da palavra de preenchimento tem valor 0 conforme era esperado, o segundo bit mantém o valor do preenchimento, 0 para o exemplo. Os 30 bits restantes armazenam o tamanho do preenchimento representado de modo binário ( ) 2 = (174) 10. Análises realizadas por Stockinger e Wu 2006 (STOCKINGER; WU, 2006) sugerem que o tempo de resposta de consultas por faixa de valores sobre vetores de bits codificados por WAH cresce linearmente ao número de acertos, como verificados nas árvores B+ e B*. No entanto, os índices bitmaps possuem como vantagem o fato de serem facilmente combinados para responder consultas ad-hoc multidimensionais sobre faixas de valores. 3.4 FastBit O FastBit (FASTBIT, 2013; O NEIL; O NEIL; WU, 2007) é um software de iniciativa livre para criação de índices bitmaps com compressão. No FastBit, os dados são organizados em uma estrutura de tabelas (com linhas e colunas), onde cada tabela é particionada verticalmente e as respectivas colunas são armazenadas em arquivos distintos. Tabelas de dados muito volumosas (com milhões ou bilhões de registros) são passíveis de fragmentação horizontal, e cada partição resultante da fragmentação pode conter milhões de linhas. Uma partição é fisicamente organizada como um diretório, onde há um arquivo contendo metadados acompanhado de arquivos de dados para cada coluna. Cada coluna é efetivamente um índice de projeção, e, este índice pode ser utilizado para responder algumas consultas de modo eficiente não requerendo estruturas de indexação adicionais. Esta implementação sob a forma de arquivos confere uma boa eficiência ao Índice Bitmap construído pelo FastBit. Todos os bitmaps de um índice estão armazenados em um único arquivo. Logicamente, o arquivo do índice contém dois grupos de valores: um para manter valores de chaves e outro para os bitmaps com compressão. O FastBit mantém os valores de chaves ordenados de forma ascendente, deste modo é possível localizar agilmente o valor desejado. Bitmaps mantidos com compressão de dados estão associados aos valores de chave. A Figura 3.6 ilustra um exemplo de índice bitmap gerado a partir do FastBit. 36

51 É importante salientar que este software implementa diversas técnicas de empacotamento e codificação. Os bitmaps são comprimidos utilizando a técnica do WAH (mostrada em detalhes na Seção 3.3.3). Embora, seja uma ferramenta eficiente para construção e manipulação de índices bitmap, o FastBit não oferece suporte à indexação de sistemas de DWG. 3.5 Índices para DWG Figura 3.6: Um IBJ criado a partir do FastBit (SIQUEIRA, 2009). Na literatura de banco de dados há poucas propostas de estruturas de indexação para DWG. Nesta seção são apresentados os trabalhos mais relevantes nesta área. Primeiro é apresentado o índice ar-tree na Seção Em seguida, a Seção discorre acerca do SB-Index que introduziu o conceito do IBJ aos DWG, evitando a realização de junções intrínsecas ao esquema estrela ar-tree A ar-tree (aggregate R-Tree) (PAPADIAS et al., 2001) é um índice espacial para DWG baseado nas R-tree e em suas variações. Para cada MBR armazenado nas entradas da ar-tree são associados valores pré-calculados de funções de agregação (como por exemplo, COUNT, SUM, AVG, etc.) aplicados a uma dada medida da tabela de fatos. Técnicas que promovem a agregação de dados em DW convencionais são bem conhecidas e trazem bons resultados ao processamento de consultas OLAP (HARINARAYAN; RAJARAMAN; ULLMAN, 1996). Estás técnicas em geral se baseiam na hierarquia definida entre os atributos de uma dada dimensão. Porém, diferentemente do que ocorre nos DW convencionais, no DWG pode haver pouco ou nenhum conhecimento prévio sobre a hierarquia de relacionamento de atributos espaciais, que permite o agrupamento dos objetos. Estas hierarquias que não são prédefinidas em tempo de projeto são referenciadas na literatura como hierarquias ad-hoc. Além disso, consultas SOLAP sobre um DWG podem requerer o agrupamento de dados baseados em mapas criados arbitrariamente, ao invés de considerar apenas os valores de atributos pré-definidos mantidos nas dimensões espaciais. Diante deste contexto, foi proposto um novo método de acesso para combinar a indexação dos atributos espaciais de um DWG. 37

52 Estrutura de dados A ar-tree é um índice para DWG que indexa o menor nível de granularidade de uma dada dimensão espacial. Ela consiste em uma R-Tree que armazena, para cada MBR, valores de função de agregação para todos os objetos espaciais englobados pelo MBR. Uma vez que, objetos espaciais quando indexados por uma R-Tree formam uma hierarquia implícita, tal hierarquia foi incorporada a treliça de Harinarayan, Rajaraman e Ullman (1996) possibilitando, assim, a seleção das agregações para materialização dos valores pré-computados. Para explicar como funciona a estrutura de dados da ar-tree, Papadias et. al. (2001) sugere um exemplo de um sistema de controle de tráfego. Nele, um sistema monitora as posições dos veículos numa cidade e o tráfego nas ruas. Veículos também podem estar em estacionamentos e não apenas em circulação pelas ruas. A Figura 3.7a mostra o esquema estrela de um DWG construído sobre esta aplicação. Neste esquema há uma tabela de dimensão espacial Local e uma tabela de fatos denominada Veículos. Os dados contidos na tabela de fatos estão retratados na Figura 3.7b. Sobre a dimensão espacial é construído um índice ar-tree que mantém os valores da medida quantidade pré-agregados segundo a função de agregação soma (SUM). Figura 3.7c exibe a ar-tree no espaço euclidiano e a Figura 3.7d mostra uma representação simplificada da ar-tree com os valores pré-computados. Figura 3.7: DWG com uma dimensão espacial Local e a ar-tree correspondente. Imagem adaptada de (SIQUEIRA, 2009). Na estrutura de dados, da Figura 3.7d, cada nodo da ar-tree possui as entradas,,,,, onde corresponde a capacidade do nodo e, e um ponteiro para o próximo nodo. Em cada entrada da forma <,.,,.,,. >,,. é o MBR que engloba os objetos no nível inferior, o ponteiro,. referencia o nodo do próximo nível inferior. Portanto, a raiz constitui o maior nível da árvore. Os resultados préagregados para cada entrada é,.. Cada objeto no nível n-1 pertence a exatamente um MBR do nível acima (n), permitindo, assim, o armazenamento de resultados parciais e a agregação deles em um passo posterior. Deste modo, uma hierarquia espacial implícita é definida a medida que surgem novos níveis intermediários na árvore, pois os MBR dos níveis intermediários englobam aqueles que estão em um nível inferior. A estrutura da ar-tree ainda pode ser estendida para permitir o armazenamento de uma lista de resultados para todas as funções de agregação de interesse. A Figura 3.8 mostra a ar-tree do sistema de controle de tráfego que mantém os resultados das funções de agregação SUM e MAX 38

53 em seus nodos. Neste exemplo, o nodo (A 1, 6, 3) engloba os valores calculados para os nodos (a 2, 3), (a 3, 1) e (a 5, 2). Figura 3.8: ar-tree com agregação de quantidade utilizando as funções SUM e MAX. Adaptado de (SIQUEIRA, 2009). Conforme mostrado anteriormente, os resultados pré-computados nos nodos não folha da árvore ar-tree definem uma hierarquia implícita. Papadias et. al. (2001) mostra que esta hierarquia pode ser incorporada à treliça de Harinarayan, Rajaraman e Ullman (1996) (HARINARAYAN; RAJARAMAN; ULLMAN, 1996), permitindo que os DWG façam uso das vantagens conferidas aos DW convencionais. A ar-tree foi estendida para indexar múltiplas dimensões. Neste caso, quando mais de uma dimensão estiver associado à tabela de fatos, mantem-se em cada entrada das ar-tree um vetor multidimensional. Este vetor indica os valores agregados para todo domínio das outras dimensões. Siqueira (2009), adapta o exemplo do sistema de tráfego adicionando mais uma dimensão (TipoVeiculo dimensão descritiva) A Figura 3.9 exibe o esquema estrela modificado. Figura 3.9: ar-tree com dimensão espacial (local) e uma descritiva (TipoVeiculo). Fonte (SIQUEIRA, 2009). Na Figura 3.10 é exibida a estrutura da árvore ar-tree da Figura 3.9 após ser estendida para lidar com mais de uma dimensão. Para cada entrada do índice foi adicionado um vetor unidimensional utilizado para correlacionar os valores das medidas agregadas com os dados da dimensão descritiva TipoVeiculo. Presume-se que a ordem dos dados da tabela de dimensão TipoVeiculo (Figura 3.9c) é respeitada na disposição dos dados de cada vetor associado às entradas dos nodos da ar-tree. Esta suposição é feita porque Papadias et. al apenas mencionam a possibilidade desta extensão, porém nenhum comentário sobre a implementação desta estrutura é realizado. No exemplo ilustrado, a entrada que mantém o MBR A 1 tem o vetor {2, 1, 3}. Isto é, no interior de A 1 há dois caminhões, um carro e três motos. Outra vantagem da ar-tree está relacionada à materialização de visões. A materialização de visão consiste na seleção de um nível de uma ar-tree para materialização. Para atingir tal objetivo, cria-se uma visão da árvore por meio de redefinições de ponteiros, interligando alguns de seus níveis e dispensando outros intermediários, uma vez que nodos intermediários de uma ar- 39

54 Tree podem não ser materializados. A construção de uma visão materializada não modifica o índice, pois cria uma estrutura separada. Figura 3.10: ar-tree com suporte a mais de uma dimensão. Uma consideração é feita com relação a hierarquias pré-definidas, i.e., aquelas já conhecidas em tempo de projeto: a materialização é preferível à indexação utilizando a ar-tree. Logo, o processamento de consultas SOLAP sobre estas hierarquias pode ser feito com maior agilidade usando visões materializadas e não estrutura proposta. Contudo, dimensões ad-hoc são beneficiadas pela estrutura de indexação provida pela ar-tree (PAPADIAS et al., 2001). Apesar da ar-tree ter sido proposta originalmente para lidar apenas com dimensões espaciais. Os autores afirmam que o método pode ser considerado para manipulação de medidas espaciais. Sendo assim, ponteiros para objetos que representem as medidas espaciais devem ser adicionados à lista que mantém os resultados das funções de agregação. Papadias et. al. 2011, consideram ainda que medidas espaciais e convencionais podem coexistir numa mesma estrutura de indexação. Na próxima seção será abordado o processamento de consultas SOLAP sobre este método de acesso Processamento de Consultas O processamento de consultas SOLAP sobre a ar-tree é realizado por meio de busca na árvore. O processo inicia-se na raiz e continua recursivamente podendo chegar até o nível folha. Para cada entrada do ar-tree a JC é testada e espera-se que ocorra uma destas três condições: (i) o MBR da entrada e a JC são disjuntos; (ii) o MBR está totalmente contido na JC; ou (iii) há uma sobreposição parcial do MBR pela JC. No primeiro caso, os valores da entrada são descartados do conjunto resposta e não há necessidade de percorrer os níveis inferiores deste nodo, i.e., ocorre uma poda neste ramo da árvore. No segundo caso, a JC engloba o MBR contido na entrada do índice, e neste caso, recupera-se os valores agregados não havendo necessidade de percorrer os nodos que compõem o próximo nível. Por fim, no terceiro caso, onde há uma sobreposição parcial da JC, os demais níveis deste ramo serão testados recursivamente com a JC. A busca encerra quando não houver mais possibilidade de 40

55 varreduras na árvore. De modo geral, o processamento de consultas nas árvores ar-tree é semelhante ao da R- Tree. Contudo, há uma diferença fundamental entre estes algoritmos de busca. Na R-Tree, se a JC for muito grande, uma busca sequencial sobre os dados é realizada. Por outro lado, na ar-tree, que promove a agregação de registros, há duas possibilidades: (i) a JC muito grande; e (ii) JC muito pequena. Quando a JC é muito grande, o MBR dos nodos intermediários engloba vários nodos internos, neste caso pode-se recuperar os valores agregados contidos nestes nodos, evitando-se buscas nos nodos internos. Se uma JC é muito pequena, então a ar-tree tem comportamento semelhante a um MAM, permitindo a seleção dos candidatos. Um caso particular de consultas SOLAP sobre DWG considera a presença de mais de uma janela de consulta (JC). Um exemplo desse tipo de consulta é: para cada JC encontre o número total de carros em seu interior e que estão nos segmentos de ruas. Nesta situação, a árvore é percorrida seguindo apenas os nós que intersectam parcialmente as JC, obtém-se ao longo do percurso os valores agregados dos nodos. Caso a consulta seja realizada em um nível de granularidade menor, como por exemplo, para cada segmento de rua no interior da JC, calcule o número de carros, há necessidade de testar os nodos no interior da JC, a fim de encontrar os MBR dos objetos espaciais candidatos. Desta forma, a ar-tree é processada como um MAM sobre a tabela de fatos SB-INDEX SB-Index (SIQUEIRA, 2009), ou Spatial Bitmap Index, é uma estrutura de indexação para DWG em que os atributos espaciais estão organizados segundo uma hierarquia pré-definida. Este método introduz o uso do IBJ ao processamento de consultas SOLAP sobre um DWG evitando o processamento das junções-estrela. Para atingir tal objetivo, o SB-Index faz uso de técnicas de bitmap como a codificação por igualdade e a compressão, e assim alcança melhor desempenho no processamento das consultas multidimensionais. O SB-Index consiste em uma adaptação do Índice de Projeção, o qual é construído sobre a chave-primária das tabelas de dimensões espaciais. Em cada entrada de registro do SB-Index há um valor de chave e um MBR, os quais estão associados a um determinado objeto espacial. Um diferencial do SB-Index é que ele permite filtrar os predicados espaciais, transformando-os em predicados convencionais os quais podem ser computados em conjunto com os demais predicados convencionais. Como resultado desta operação, consultas podem ser respondidas utilizando índice bitmap de junção estrela. Além disso, o SB-Index permite o processamento de operações de drilldown e roll-up envolvendo predicados espaciais tais como consultas sobre faixas com operações de interseção e está contido. Nas seções a seguir, são descritos a estrutura de dados, o processo de construção do SB- Index e, por fim, o funcionamento do processamento de consultas. 41

56 Estrutura de dados do SB-Index Em um SB-Index cada registro de entrada, também denominado de sbitvector (Spatial Bit- Vector), é composto por uma chave-valor e um MBR. A chave-valor referencia a chave-primaria da tabela de dimensão espacial e serve para identificar o objeto geográfico representado pelo seu MBR. A chave de valor é representada por um inteiro, visto que normalmente há a presença de chaves artificiais em DW. O MBR que compõe o registro de entrada do SB-Index é representado por dois pares de coordenadas em um espaço bidimensional: (, ) e (, ). Estas coordenadas podem ser armazenadas como quatro número em dupla precisão. Assim sendo, o tamanho de uma entrada do sbitvector, denotado por S, pode ser obtido com a expressão: = ( ) + 4 ( ). O SB-Index pode ser definido como um array do tipo sbitvector, em que há uma correspondência biunívoca entre a posição da entrada do array do sbitvector com as entradas do IBJ definido sobre a chave-primária da tabela de dimensão espacial. Deste modo, o i-ésimo registro de entrada do SB-Index aponta, implicitamente, para a i-ésima entrada do IBJ conforme pode ser visto na Figura Além disso, o SB-Index é mantido na memória secundária sob a forma de um arquivo sequencial junto com o arquivo do índice bitmap de junção estrela. Figura 3.11: Dimensão espacial City, a tabela de dimensão Supplier e a tabela de fatos Lineorder (SIQUEIRA et al., 2011). Em (SIQUEIRA et al., 2011) um exemplo da estrutura do SB-Index é apresentado com base no esquema híbrido do benchmark Spadawan, visto na Seção Na Figura 3.11 é mostrada a dimensão espacial City que contém um atributo espacial city_geo e a chave-primária city_pk. Por exemplo, city_pk = 1 está associado ao s_suppkey = 3 e lo_suppkey = 3. Assim, SB-Index[0] mantém o valor de chave 1 e o MBR do objeto espacial identificado por city_pk = 1, como mostrado na Figura Além disso, B é um índice bitmap de junção estrela definido sobre o atributo city_pk da tabela de dimensão City para indicar que as operações de junção entre a tabela de fatos e a dimensão devem ser processadas com base no valor de city_pk. O vetor de bit apontado por B[0] especifica as tuplas da tabela de fatos que correspondem a condição de city_pk = 1. Dessa forma, para acessar o vetor de bits relacionado ao SB-index[0] requer apenas usar o endereço 0 (zero) para acessar B, ou seja, B[0]. 42

57 Figura 3.12: A estrutura do SB-Index acompanhado do IBJ criado utilizando FastBit. Traduzida de (SIQUEIRA et al., 2011) Construção do SB-INDEX O processo de construção do SB-Index é realizado por meio de uma conexão ao sistema de banco de dados que mantém o DWG. Através desta conexão são recuperados os valores da chaveprimária da tabela de dimensão espacial e os respectivos MBR que representam os objetos espaciais. O conjunto solução obtido na busca de dados é ordenado de forma ascendente com base no valor da chave-primária. Para cada tupla recuperada, cria-se um sbitvector atribuindo a chave e o MBR. Quando o array de sbitvector se torna cheio, os registros são copiados para uma página de disco da memória secundária. Um valor muito pequeno de bytes é mantido sem uso em cada página armazenada, com o propósito de evitar a fragmentação dos índices entre as páginas do disco. A Figura 3.13, mostra as etapas do processo de construção do SB-Index. Figura 3.13: Processo de construção do SB-Index (SIQUEIRA, 2009) Processamento de consulta O SB-Index avalia o predicado espacial de uma consulta SOLAP transformando-o em um predicado convencional e, então, realiza a consulta sobre um IBJ para obter a resposta de uma dada 43

58 consulta. O processamento de consulta SOLAP sobre um SB-Index é mostrado na Figura 3.14 e pode ser dividido em duas etapas: a filtragem (compreendida entre as etapas de 1 a 3) e refinamento (etapas 3 a 5). Figura 3.14: Processamento de consultas do SB-Index A etapa de filtragem tem início com o carregamento da estrutura de indexação (array de sbitvector) da memória secundária para a principal. Uma vez na memória principal, uma leitura sequencial é realizada nela. Para cada entrada, o MBR armazenado é testado contra o predicado espacial de uma JC. Se no teste for obtido sucesso, esta entrada do índice é um candidato a resposta, então a chave-primária correspondente é coletada (passo 2 da Figura 3.14). Após ler cada uma das páginas do arquivo, uma coleção de candidatos é definida, i.e., uma coleção de chave-primárias de objetos que podem satisfazer o predicado da consulta SOLAP é identificada. Com o conjunto de possíveis soluções formados, é preciso verificar quais deles compõem realmente a resposta da consulta. Este refinamento e requer o acesso à tabela de dimensão espacial utilizando cada uma das chaves-primárias para recuperar a geometria exata do objeto espacial, como ilustrado no passo 4. Então, estas feições geométricas são comparadas com o predicado espacial utilizando as funções apropriadas disponíveis nos SGBD. Caso atendam ao predicado espacial, o valor chave do sbitvector é utilizado para compor o novo predicado convencional. Isto é mostrado no passo 5 da Figura 3.14, quando o SB-Index transforma o predicado espacial em um predicado convencional que é concatenado à consulta SOLAP. A consulta SOLAP é utilizada para acessar o índice bitmap de junção estrela para produzir a resposta final. O CSB-Index proposto nesta dissertação estende as funcionalidades do SB-Index para explorar os conceitos de elasticidade presentes em ambientes de computação em nuvem. 3.6 EMINC EMINC (ZHANG et al., 2009), sigla do inglês Efficient Multi-Dimensional Index with Node Cube, é uma estrutura de indexação multidimensional desenvolvido especificamente para sistemas de armazenamentos de dados em nuvem construídos sobre sistemas de arquivos distribuídos que normalmente empregam o uso de chave-valor. A estrutura deste índice é baseada 44

59 na combinação da R-Tree (GUTTMAN, 1984) e da KD-Tree (BENTLEY, 1975). Por isso, o EMINC é capaz de processar consultas tipicamente multidimensional oferecendo meios eficazes para a recuperação de dados e manutenção da estrutura do índice, além de prover suporte a consultas por igualdade e sobre faixa de valores. Antes de prosseguir com o detalhamento acerca do EMINC, faz-se necessária uma explanação sobre a arquitetura de nuvem. Como afirmado anteriormente, a infraestrutura de nuvem é formada por um agrupamento de centenas ou milhares de máquinas. Estas máquinas são classificadas em duas categorias: mestres e escravos. Os mestres armazenam metadados sobre todo o sistema além dos dados. Já os escravos mantêm apenas registros de dados e suas réplicas para melhor eficiência e segurança. As requisições dos clientes são realizadas sobre os nodos mestres, os quais são responsáveis por definir quais nodos escravos são mais adequados para processar as solicitações dos usuários. Tendo isto posto, o EMINC faz uso desta distinção de papeis para definir sua arquitetura. A estrutura de indexação do EMINC consiste de uma R-Tree mantida nos mestres e de KD-Tree armazenadas nos nodos escravos, conforme mostra Figura Cada folha da R-Tree contém um nodo cubo (cube node) e um ou mais ponteiros que referenciam os nós escravos correspondentes. Um nodo cubo é uma sequência de intervalo de valores. Cada intervalo representa faixa de valores de um atributo indexado. Caso exista apenas um único valor em uma dimensão, o intervalo correspondente é tido como um valor pontual. Por exemplo, é construído um índice bidimensional sobre os atributos idade e salário de uma data tabela T, então, um nodo cubo definido por {[30,40],[100,200]} indica que o servidor escravo ao qual este nodo cubo está associado possui registros de idade que variam de 30 até 40, e que o atributo salário está na faixa de valores de 100 a 200. Portanto, o objetivo do nodo cubo é prover meios para identificar os nodos escravos que atendem à consulta desejada, evitando acessos àqueles nodos que são irrelevantes ao processamento da consulta. Deste modo, aumenta-se a eficiência da estrutura de indexação na recuperação dos dados. Com relação ao processamento de consultas usando o EMINC, é verificado se a busca é realizada para um único valor ou para uma faixa de valores de chave. Então, cria-se uma consulta cubo (query cube). Consulta cubo corresponde a uma sequência de intervalos, e cada intervalo representa as faixas de valores de um atributo da consulta. Se algum dos lados do intervalo de valores do atributo não for especificado, lhe é atribuído o maior valor positivo ou negativo que o atributo pode assumir. Com a consulta cubo criada, a estrutura da R-Tree é percorrida no nodo mestre para determinar quais são os nodos escravos que estão relacionados à ela. Para isto, os nodos cubos são testados em busca daqueles que intersectam a consulta cubo. A interseção de dois cubos, i.e. do nodo cubo e da consulta cubo, ocorre pela sobreposição dos respectivos intervalos definidos em atributo (tanto na consulta, quanto no nodo). Caso algum dos intervalos seja representado por um 45

60 ponto, então é testado se o outro intervalo contém este valor. Se ambos forem do tipo pontual, é verificado se os pontos são iguais. Por causa da verificação de interseção, vários nodos da árvore que são irrelevantes à consulta podem ser descartados. Após descartar estes nodos, o processamento da consulta segue nas máquinas escravas onde as buscas são realizadas sobre as KD-Tree. 3.7 Conclusão Figura 3.15: Arquitetura do EMINC. Neste capítulo, foram mostradas importantes pesquisas e propostas sobre estruturas de indexação destinadas aos SSD. A carga de trabalho submetida a um ambiente decisório difere das operações destinadas ao ambiente operacional. Por isso, é necessário a criação de novas estratégias de indexação especificas para a demanda deste ambiente. Em DW convencionais, os Índices de Projeção e Bitmap são exemplos destas estruturas. Índices de projeção são eficientes estruturas de dados para busca de valores de um dado atributo, pois possibilitam acesso rápido, uma vez que as entradas possuem tamanho fixo e são mantidas num vetor. Já os Índices Bitmaps mostraram ser eficientes mecanismos para recuperação de dados em DW, pois evitam o processamento das operações de junção estrela. Estruturalmente, o índice bitmap mantém um vetor de bits para cada valor distinto de um dado atributo. A busca de dados nos vetores de bits é realizada por operações lógicas AND e OR que são processadas rapidamente pelos hardwares. Contudo, é sabido que a alta cardinalidade dos atributos degrada a eficiência do Índice Bitmap, tanto nos requisitos de armazenamento, quanto no processamento de consulta. Por isso, foram propostas diversas estratégias para encontrar um equilíbrio entre o custo de armazenamento e o tempo de processamento, tais como: o empacotamento, a compressão e a codificação. 46

61 Stockinger e Wu (2006) mostram em seu trabalho que estas técnicas podem ser combinadas garantindo maior eficácia ao índice. O software FastBit é uma ferramenta que permite a criação de índices de projeção e de bitmaps. Inicialmente, ele foi concebido para testes de compressão de dados. Porém, devido a sua eficiência, tornou-se um importante método para armazenar e recuperar dados volumosos em diversos segmentos de pesquisa. O FastBit introduziu uma técnica de compressão de bitmaps conhecida como WAH (Word-Aligned Hybrid code) que permite a compressão de dados sem degradar o tempo de processamento. Embora estas estruturas sejam eficientes para DW convencionais, elas não são capazes de indexar corretamente DWG por causa da natureza complexa dos dados presentes nestes sistemas. Por isso, novos métodos de acesso foram criados como: a ar-tree e o SB-Index. A ar-tree se baseia nas já consolidadas R-Tree e suas respectivas variações, e servem para indexar os atributos espaciais de um DWG. Normalmente, estes índices são aplicados ao menor nível de granularidade espacial. Em cada entrada da ar-tree são armazenados um MBR (que engloba os objetos do nível imediatamente inferior) e um valor (ou uma lista de valores) resultante do cômputo de funções de agregação (como o SUM, AVG, COUNT etc.). Os objetos indexados pela ar-tree formam uma hierarquia espacial implícita possibilitando a seleção de agregações para materialização de valores pré-computados. A materialização dos valores pré-computadores evita que consultas realizem estas custosas operações em tempo de execução alcançando melhor desempenho no processamento das consultas. Embora a ar-tree lide de forma eficiente com objetos espaciais, estes índices não evitam as custosas operações de junção inerentes ao esquema estrela do DWG. Logo, outra estrutura de indexação para DWG foi proposta por Siqueira (2009): o SB-Index. O SB-Index é um índice que introduziu o uso de IBJ no processamento de consultas SOLAP sobre um DWG. Nele predicados espaciais são avaliados e transformados em um predicado convencional. Assim, torna-se possível a aplicação de um IBJ para evitar a junção estrela conferindo excelente desempenho às consultas SOLAP. Estas estruturas de indexação garantem bons resultados no tempo de recuperação de dados. Contudo, elas não satisfazem os requisitos de sistemas de armazenamento de dados em nuvem, onde bancos de dados são distribuídos em diversas máquinas para garantir melhor escalabilidade, elasticidade e tolerância a falhas. Por isso, o desenvolvimento de novas estruturas de indexação se faz necessário. O EMINC é uma proposta de índice multidimensional destinada ao processamento de consultas no contexto de computação em nuvem. Ele é aplicado aos sistemas de armazenamento em nuvem que emprega o conceito de chave-valor, e tem por objetivo o processamento eficiente de consultas sobre faixa de valores em sistemas de gerenciamento de dados em nuvem. Para isto, as técnicas de indexação R-Tree e a KD-Tree foram combinadas de modo a melhorar a recuperação de dados. Vale ressaltar, no entanto, que esta estrutura não se destina ao processamento de consultas 47

62 SOLAP em DWG. Com o intuito de viabilizar baixo tempo de resposta aos DWG mantidos em nuvem, é proposto neste trabalho o CSB-Index, método de acesso que estende o SB-Index para adequá-lo ao contexto de nuvem, possibilitando o processamento de consultas de modo distribuído. O capítulo a seguir define o CSB-Index, apresenta sua estrutura e mostra como são processadas consultas sobre ele. 48

63 4.1 Introdução Cloud Spatial-Bitmap Index, ou CSB-Index, é uma estrutura de indexação que estende o SB-Index para prover suporte aos sistemas de DWG construídos sobre uma infraestrutura de nuvem. DWG mantidos em nuvem diferem dos convencionais por ter seus dados distribuídos em diversas máquinas. Esta distribuição confere ao ambiente, uma maior disponibilidade, elasticidade e escalabilidade. O CSB-Index contém todas as características presentes no SB-Index, tais como: (i) reutilização de técnicas conhecidas para Índice Bitmap como o empacotamento, compressão e codificação; (ii) o acesso otimizado a dimensões espaciais que mantém os atributos organizados segundo uma hierarquia pré-definida, permitindo a realização de operações OLAP (como por exemplo, roll-up e drill-down); (iii) a filtragem e transformação do predicado espacial em convencional; e (iv) o uso IBJ no processamento de consultas SOLAP, evitando as custosas operações de junção-estrela. A extensão realizada no CSB-Index garante ao índice a capacidade de realizar consultas de modo paralelo sobre uma infraestrutura distribuída. Assim como SB-Index, cada entrada na estrutura do CSB-Index contém um valor de chaveprimária (referente à dimensão espacial indexada) e um MBR que representa um determinado objeto espacial. A diferença entre as estruturas de dados destes índices reside no armazenamento de um valor que corresponde à chave de distribuição, que é um código que identifica quais as federações do DWG que contêm o registro associado à chave-primária. Nas próximas seções são descritos a estrutura de dados, a arquitetura do índice, o processo de construção do índice e o processamento de consultas do CSB-Index. 4.2 Estrutura de Dados do CSB-Index Cada entrada do CSB-Index é semelhante ao sbitvector definido pelo SB-Index, onde estão armazenados um campo para a chave-primária da tabela de dimensão espacial (representado por um valor inteiro) e o MBR que representa o objeto espacial associado à chave (quatro valores de dupla precisão). No entanto, na estrutura do CSB-Index também é armazenada, em cada entrada, um valor inteiro que representa a chave de distribuição. A chave de distribuição corresponde a um código que identifica o banco de dados na nuvem que mantém a geometria exata do objeto espacial representado pelo MBR. Assim sendo, cada entrada E possui a seguinte estrutura <E.pk, E.MBR, E.distribuicao> e é chamada de csbitvector. O tamanho T de cada entrada E pode ser obtido por: = ( ) + 4 ( ) + ( ). 49

64 A estrutura de dados do CSB-Index corresponde a um vetor unidimensional, cujas entradas são do tipo csbitvector definido anteriormente. A Figura 4.1 mostra a estrutura de indexação do CSB-Index e um IBJ (gerado a partir do FastBit) ambas construídas sobre a dimensão espacial City. Na Figura 4.1 é possível observar que para o objeto espacial com city_pk = 1 (armazenada na entrada CSBINDEX[0]) há um vetor correspondente no IBJ, cuja entrada é B[0]. Deste modo, evidencia-se a existência de uma associação implícita entre as estruturas. A Figura 4.1 também ilustra os valores das chaves de distribuição. Neste exemplo, a entrada com city_pk = 1 tem a sua geometria exata armazenada no banco de dados cuja chave de distribuição possui valor 1, city_pk = 2 o valor da chave de distribuição é igual a 2, portanto a geometria é mantida no banco de dados resultante da fragmentação para o valor igual a 2. É importante ressaltar que a estrutura de CSB-Index é mantida na memória secundária como um arquivo sequencial junto com os arquivos do IBJ construídos pelo software FastBit. Figura 4.1: Estrutura de dados do CSB-Index e o Índice IBJ criado pelo FastBit. Na próxima seção é apresentada a arquitetura definida para o processamento e armazenamento do CSB-Index. 4.3 Arquitetura do Ambiente na Nuvem Usando o CSB-Index A arquitetura do CSB-Index é apresentada na Figura 4.2. Esta arquitetura é composta por uma máquina virtual e diversos servidores de bancos de dados mantidos sobre uma infraestrutura de nuvem. Nesta máquina virtual são armazenadas as estruturas CSB-Index (mantidas sob a forma de arquivos sequenciais) e os arquivos dos índices bitmap de junção criados a partir do software FastBit. Por sua vez, os servidores de bancos de dados são responsáveis pelo armazenamento dos dados de um DWG, os quais podem ser particionados para obter maior escalabilidade, elasticidade e desempenho. 50

65 Nesta arquitetura, os usuários realizam as consultas SOLAP a partir da máquina virtual que tem por função processá-las e, ou, redirecioná-las aos servidores adequados garantido a recuperação das informações solicitadas. O processamento destas consultas pode ser auxiliado pelo CSB-Index, que realiza a filtragem e transformação do predicado espacial em um predicado convencional, viabilizando o uso do IBJ. Em cada entrada do CSB-Index é mantida uma referência implícita para o banco de dados que mantém a geometria exata do objeto indexado, conforme mostra a Figura 4.2. Esta arquitetura possibilita o processamento paralelo das consultas SOLAP sobre os diversos servidores que mantém os dados do DWG. Figura 4.2: Arquitetura do CSB-Index. 4.4 Construção do Índice CSB-Index A construção do índice requer acesso a todos os nodos dos bancos de dados que mantêm os dados do DWG no ambiente de nuvem. O processo inicia-se pela realização de consultas, de modo paralelo, a cada nodo que compõe o DWG. A consulta tem por objetivo: (i) recuperar as chaves-primárias da tabela de dimensão espacial; (ii) o MBR dos respectivos objetos espaciais, utilizando-se para isto as funções disponíveis no SGBD; e (iii) o valor das chaves de distribuição que identificam o nodo que contém a geometria exata do objeto espacial. Como as consultas são realizadas em paralelo, a ordenação da chave-primária deve ocorrer após obter todos os resultados. De posse dos resultados já ordenados, cria-se um buffer na memória principal, cujo tamanho corresponde ao da página da memória secundária. Neste buffer, estruturas do tipo csbitvector geradas pelos resultados da consulta são copiados. Quando o buffer se torna cheio, ele é transferido para a memória secundária sob a forma de um arquivo sequencial. O processo se repete sucessivamente até que todas as entradas do índice estejam armazenadas no disco. Em cada página de disco de 4 KB, é possível armazenar 102 entradas do csbitvector, onde 51

66 cada uma possui 40 bytes, totalizando 4080 bytes em uma única página de disco. Portanto, verificase que 16 bytes no final da página não ficam preenchidos com dados de índice. Isto é necessário para evitar um número maior de leituras ao disco em consequência da fragmentação da estrutura de indexação. A Figura 4.3 mostra o processo de construção do CSB-Index, desde a extração das informações dos bancos de dados até o armazenamento na memória secundária. Figura 4.3: Etapas da construção do CSB-Index. O algoritmo que descreve o processo de criação do CSB-Index é apresentado na Figura 4.4. Construir (C, U, idx, T, pk, Atr, LF, FED) Entradas: C: quantidade máxima de objetos do tipo csbitvector que uma página de disco é capaz de armazenar U: número de bytes inutilizados entre duas páginas; idx: arquivo CSB-Index; T: tabela de dimensão espacial; pk: atributo que compõe a chave-primária da tabela T; Atr:atributo espacial da tabela T; LF: lista das federações que compõe o DWG; FED: identificador da federação (chave de distribuição); Saída: Declarações: colecaorecordptr: vetor de resultados de consultas ao SGBD 01 para cada FED em LF faça em paralelo 02 colecaorecordptr[fed] execute_sgbd(fed, SELECT pk, X min(atr), Y min(atr), X max(atr), Y max(atr), fedkey FROM T ) 03 fim para cada 04 recordptr concatenar(colecaorecordptr) 05 ordenar(recordptr) 06 i 0 07 abra (idx) 08 enquanto (recordptr eof) faça 09 enquanto (i C) e (recordptr eof) faça 10 Buffer[i].pk recordptr.pk 11 Buffer[i].X min recordptr.x min 52

67 12 Buffer[i].Y min recordptr.y min 13 Buffer[i].X max recordptr.x max 14 Buffer[i].Y max recordptr.y max 15 Buffer[i].fedkey recordptr.fedkey 16 i i recordptr.proximo() 18 fim-enquanto 19 i 0 20 escreva(buffer, idx) 21 avance(u, idx) 22 fim-enquanto 23 feche (idx) Figura 4.4: Algoritmo para construção do CSB-Index. O algoritmo da Figura 4.4 mostra o pseudocódigo para a criação da estrutura do CSB- Index. Para construção do índice é iniciado um processo que realiza consultas distribuídas (de modo paralelo) aos diversos nodos da federação que compõe o DWG (linhas 01 a 03). Estas consultas têm por objetivo recuperar os pares de coordenadas (X min, Y min) e (X max, Y max) que definem o MBR do atributo espacial (Atr) de uma dada tabela de dimensão espacial (T), bem como, os valores da chave-primária e da chave de distribuição associados ao objeto espacial. Ao término de todas as consultas (linha 03), são obtidos conjuntos de respostas para cada federação. Na linha 04, estes conjuntos são concatenados de modo a compor apenas um único conjunto de resultados, o recordptr. Este conjunto único é, então, ordenado segundo os valores do campo da chave-primária (linha 05). Na linha 6, é zerado o valor do contador i que representa o número de entradas que são armazenadas em cada página do arquivo do CSB-Index. O arquivo da estrutura do CSB-Index é criado e aberto na linha 07 do algoritmo. As linhas 08 até 22 descrevem um processo de repetição que percorre todos os elementos do recordptr. Em cada iteração deste processo, deve-se preencher um buffer, cujo comprimento é igual C, com entradas do tipo csbitvector obtidas a partir dos dados provenientes das consultas realizadas, i.e. com valores do recordptr, linhas de 10 à 15. Então, incrementa-se o contador i (linha 16) e avança para o próximo elemento do conjunto resposta ( recordptr ) na linha 17. Este processo para preenchimento do buffer ocorre sucessivamente até que ele fique cheio (i > C), ou até todos os registros do recordptr já tenham sido todos lidos (recordptr eof). Quando o buffer está cheio, ele tem o seu conteúdo armazenado em uma página do disco do arquivo do índice (linha 20). Em seguida, o ponteiro do arquivo do índice é avançado em U bytes, para evitar a fragmentação de páginas de disco (linha 21). O processo de escrita da estrutura do CSB-Index no arquivo do índice encerra quando todos os registros do conjunto resposta das consultas foram lidos. Por fim, na linha 23, o arquivo do índice é fechado finalizando a construção do CSB-Index. CSB-Index. Na próxima seção é mostrado como ocorre o processamento de consulta com o uso do 53

68 4.5 Processamento de Consulta O processamento de consultas no CSB-Index é análogo ao do SB-Index. Primeiro, o predicado espacial de uma consulta SOLAP é avaliado e transformado em um predicado convencional. Então, realiza-se a consulta sobre um IBJ para obter a resposta da consulta SOLAP. No entanto, DWG armazenados na nuvem tem seus dados distribuídos em diversos nodos, consequência da elasticidade inerente a este ambiente computacional. Por isso, o processamento de consultas deve ser adaptado a esta realidade. O processamento de consultas SOLAP sobre um CSB-Index é mostrado na Figura 4.5 e pode ser dividido em duas etapas: a filtragem (compreendida entre as etapas de 1 a 3) e o refinamento do predicado espacial (etapas 3 a 5 da Figura 4.5). Figura 4.5: Processamento de consultas utilizando o CSB-Index. O processo de filtragem inicia-se pelo carregamento da estrutura de indexação do CSB- Index da memória secundária para a principal. Esta etapa compreende a transição entre o primeiro e o segundo passo da Figura 4.5. Uma vez na memória principal, realiza-se uma leitura sequencial na estrutura do índice. Para cada entrada, o MBR armazenado é confrontado com o predicado espacial. Caso atenda a restrição da consulta SOLAP, a entrada é tida como uma entrada do tipo candidata ao conjunto-resposta. Então, para esta entrada do CSB-Index, os valores da chaveprimária da tabela de dimensão espacial são recuperados junto com a chave de distribuição que indica o servidor de banco de dados na nuvem que mantém a geometria exata do objeto espacial relativo ao MBR da entrada. Cada entrada candidata tem sua chave-primária armazenada em um vetor bidimensional, onde: (i) a primeira posição deste vetor corresponde ao código identificado do servidor de banco de dados na nuvem (i.e. a chave de distribuição); e (ii) a segunda dimensão é composta por um conjunto de valores de chave primárias das entradas candidatas a resposta da consulta SOLAP que estão associadas com a chave de distribuição. Então, o processo de filtragem é finalizado. Com a formação do conjunto de candidatos à resposta, é preciso agora verificar quais deles compõem de fato o conjunto resposta da consulta. Inicia-se, então, o processo de refinamento. Este refinamento requer o acesso às tabelas de dimensões espaciais distribuídas nos diversos servidores 54

69 de bancos de dados que compõem o DWG. Com base na chave de distribuição, consultas paralelas são submetidas aos servidores de bancos de dados, e com base nas chaves-primárias, a geometrias exatas dos objetos espaciais são recuperadas. É importante destacar que na execução de processos paralelos, o tempo de resposta é limitado ao processamento da consulta com menor desempenho, e, portanto, neste caso, são evitadas buscas nos servidores de bancos de dados hospedados na nuvem que não possuem candidatos à resposta da consulta SOLAP. Estas feições geométricas são comparadas com o predicado espacial utilizando funções apropriadas disponíveis no SGBD na nuvem. As geometrias que estão em conformidade com o predicado espacial têm suas chaves recuperadas para compor o novo predicado convencional. Neste ponto, passo 5 da Figura 4.5, o CSB-Index transforma o predicado espacial em um convencional que é concatenado à consulta SOLAP. Por fim, um índice bitmap de junção estrela é utilizado para produzir a resposta final. O algoritmo que descreve o mecanismo de processamento de consultas usando o CSB- Index é apresentado na Figura 4.6. ProcessamentoConsulta (idx, C, R, JC, T, Atr, Consulta, Predicado_Convencional, pk, Candidatos, Fedkey, QtdFederacao ) Entradas: idx: arquivo do CSB-Index; C: capacidade de objetos do tipo csbitvector que uma página de disco armazena; R: um relacionamento espacial ( está contido, intersecta ou contém ) JC: janela de consulta espacial T: tabela de dimensão espacial Atr: atributo espacial Consulta: cadeia de caracteres da consulta SOLAP sem o predicado espacial predicado_convencional: uma cadeia de caracteres que conterá o predicado convencional resultante do processamento de consultas do CSB-Index; pk: o atributo que compõe a chave-primária da tabela T; Candidatos: vector bidimensional armazenado na memória com os candidatos de cada banco de dados da nuvem. Fedkey: chave de distribuição que identifica a federação. QtdFederacao: número total de federações Saída: resposta da consultas SOLAP Declarações: pagina: página do disco que contém um vetor de csbitvector; buffer: objeto do tipo csbitvector extraído do arquivo do CSB-Index; Refinamento: lista de resposta da etapa de refinamento; 01 abra (idx) 02 n 0 03 enquanto não (eof (idx)) 04 leia (idx, pagina) 05 copie (pagina, buffer) 06 para i 0 até C faça 07 se R(buffer[i], jc) então 08 Candidatos[buffer[i].fedkey][n] buffer[i].pk 09 n n fim-para-cada 11 fim-enquanto 12 feche(idx) 55

70 13 para cada fedkey em QtdFederacao faça paralelo 14 se candidatos[fedkey] vazio 15 então Refinamento[fedkey] execute_sgbd(fedkey, SELECT R(jc, atr), pk FROM T WHERE pk IN candidados[fedkey] ) 16 fim-para-cada 17 se refinamento vazio 18 então concatene (Refinamento, predicado_convencional) 19 concatene (predicado_convenvional, consulta) 20 Resposta execute_fastbit(consulta) Figura 4.6: Algoritmo de processamento de consultas usando o CSB-Index. O algoritmo da Figura 4.6 inicia pela abertura do arquivo do CSB-Index na linha 01. O valor do contador n que indica o número de candidatos à resposta da consulta é zerado (linhas 01 e 02). As linhas de 03 até 11 descrevem um processo iterativo sobre todas as entradas do CSB-Index, as quais armazenam os MBR que representam os objetos espaciais que possam satisfazer o predicado espacial. Neste processo, as páginas do arquivo de índice são lidas e copiadas para um buffer na memória principal (linhas 04 e 05). Nas linhas de 06 até 10, um novo procedimento iterativo é iniciado e tem por objetivo percorrer todas as entradas contidas na página copiada para o buffer. Cada entrada i do CSB-Index, no buffer, tem seu MBR testado contra a JC segundo um relacionamento espacial R. Caso satisfaça a condição de R, a chave-primária relativa à entrada é armazenada num vetor correspondente ao valor de sua chave de distribuição, por fim, o número n de candidatos à resposta é incrementado (linhas 07 e 09). Após obter os conjuntos de candidatos à resposta da condição espacial, o arquivo do CSB- Index é fechado encerrando a etapa de filtragem (linha 12). O processo de refinamento é iniciado na linha 13 do algoritmo da Figura 4.6. Das linhas 13 a 16, cada banco de dados que compõe a federação em que o DWG está armazenado é consultado de modo paralelo. Na linha 14, verificase se há ou não candidatos no banco de dados da federação fedkey. Caso haja, então realiza-se a consulta ao SGBD para verificar se o relacionamento espacial R entre a geometria exata do candidato com a JC definida foi atendido. Em caso positivo, o resultado é armazenado no vetor refinamento. Com o refinamento finalizado, o predicado espacial é transformado em um predicado convencional (linhas 17 a 19). Na linha 17, é confirmado se existem candidatos atendem a condição espacial, em caso afirmativo, a chave-primária destes são concatenadas ao predicado convencional (linhas 18). Em seguida, na linha 19, o novo predicado convencional é adicionado a cadeia de caracteres da consulta original. Por fim, na linha 20, o aplicativo FastBit é executado com base na consulta SOLAP. Um arquivo com as respostas destas consultas é retornado finalizando o processamento da consulta. 4.6 Conclusão Neste capítulo foi apresentado o CSB-Index que é um índice voltado ao processamento de consultas SOLAP sobre um DWG mantido em nuvem. O índice estende o SB-Index possibilitando o processamento de consultas de modo distribuído, requisito desejado nos ambientes de 56

71 computação em nuvem. Esta estrutura de indexação é formada por um vetor unidimensional composto por entradas do tipo csbitvector. Em um csbitvector são armazenados o valor da chave-primária da tabela de dimensão espacial, dois pares de coordenadas que definem o MBR que representa o atributo espacial indexado e uma chave de distribuição que referencia o banco de dados que mantém a geometria exata do objeto. Além disso, a estrutura mantém uma referência implícita com as entradas do índice bitmap de junção. A arquitetura do CSB-Index é composta por uma máquina virtual que é utilizada para armazenamento da estrutura do CSB-Index e IBJ, além de servir de ponto de entrada para as consultas dos usuários. Esta máquina virtual é conectada aos diversos nodos do DWG, permitindo a recuperação das informações solicitadas. Além da arquitetura, foi descrito o processo de construção do CSB-Index. Neste processo, consultas são submetidas aos diversos bancos de dados que compõem o DWG, e têm por objetivo recuperar as informações necessárias à criação das entradas do tipo csbitvector. A estrutura é mantida em disco como um arquivo sequencial. Por fim, foi mostrado o processamento de consultas sobre o CSB-Index que realiza uma leitura sequencial na estrutura do CSB-Index. Para cada uma das entradas lidas, o MBR armazenado é comparado com uma JC utilizando um dado relacionamento espacial. Nesta etapa são filtrados os objetos candidatos a resposta da consulta. Estes objetos são adicionados em listas de acordo com a referência ao banco de dados em que estão contidos, i.e. a chave de distribuição. Já o processo de refinamento realiza buscas, de modo paralelo, em cada nodo para verificar se a geometria exata do objeto atende a condição desejada. Então, o predicado espacial é convertido em um predicado convencional tornando possível a aplicação do IBJ para obter a resposta final da consulta SOLAP. É importante ressaltar que o paralelismo utilizado nas consultas da etapa refinamento, possibilita ao CSB-Index a capacidade de explorar a elasticidade e escalabilidade presentes nos sistemas de armazenamento em nuvem. No próximo capítulo são exibidos testes de desempenho realizados com o CSB-Index para comprovar a sua eficácia em um ambiente construído com base em um benchmark. 57

72 5.1 Introdução Este capítulo discorre sobre os testes de desempenho que foram realizados para investigar a viabilidade do CSB-Index como estrutura de indexação para sistemas de DWG. Além disso, descreve análises investigativas que foram conduzidas com o intuito de verificar o impacto do uso de federações no tempo de processamento de consultas SOLAP do tipo drill-down ou roll-up. Na Seção 5.2 é apresentado o projeto de experimento que descreve os testes de desempenho realizados bem como o objetivo de cada um deles. A Seção 5.3 discorre sobre o ambiente de testes utilizado para avaliação do experimento, nele são descritas a plataforma computacional utilizada e as ferramentas necessárias à avalição de desempenho. As bases de dados utilizadas nos experimentos são apresentadas na Seção 5.4. A Seção 5.5 descreve a carga de trabalho que foi submetida aos DWG, nestas cargas de trabalho são realizadas consultas com objetivo de simular operações do tipo roll-up/drill-down. Para execução das consultas distribuídas foi construído um aplicativo para processar as cargas de trabalho de modo paralelo e distribuído, detalhes sobre este aplicativo são fornecidos na Seção 5.6. A Seção 5.7 mostra os resultados obtidos para os testes de viabilidade envolvendo o CSB-Index. Já a Seção 5.8 apresenta uma análise investigativa sobre o impacto da distribuição dos dados em um DWG mantido em nuvem. Por fim, as considerações finais sobre os testes de desempenho realizados neste trabalho são discutidas na Seção Projeto de Experimento Este experimento tem por objetivo avaliar a viabilidade do CSB-Index como estrutura de indexação para DWG mantidos em nuvem, e analisar o impacto da federação no tempo de resposta de consultas SOLAP do tipo drill-down ou roll-up. A federação de um banco de dados em nuvem pode ser interpretada como um particionamento horizontal sobre determinadas tabelas armazenadas no banco de dados. A fragmentação destas tabelas ocorre segundo valores de um atributo, também conhecido como chave de distribuição, que compõe a sua chave-primária. Para análise de viabilidade do CSB-Index foram propostas análises experimentais que visam: (i) verificar o tempo de criação e custo de armazenamento da estrutura do CSB-Index; (ii) comparar o tempo de processamento de consultas SOLAP do tipo roll-up ou drill-down auxiliadas pelo CSB-Index com outros métodos de acesso; (iii) investigar o impacto de consultas SOLAP submetidas a um DWG, quando incrementa-se o número de servidores por meio da adição de novos membros à federação e, consequentemente, aumenta-se o balanceamento de carga entre estes servidores; e (iv) analisar o impacto da escalabilidade dos dados do DWG comparando bases 58

73 de dados de tamanhos distintos. Para a realização destes experimentos foram utilizadas duas bases de dados com volumes de dados distintos, construídas a partir do esquema RBF-GHSSB (Regionbased Federation GHSSB), o qual se baseia no GHSSB (descrito na Seção 2.5.2) e será detalhado na Seção 5.4. Além disso, foi desenvolvido um aplicativo que executa consultas aos diversos bancos de dados em paralelo, permitindo uma comparação justa entre o processamento de consultas utilizando métodos de acessos disponíveis no SGBD com o processamento de consultas auxiliado pelo CSB-Index, o qual faz uso do paralelismo no mecanismo de processamento de consultas. Detalhes sobre esta aplicação serão apresentados na Seção 5.6. A segunda análise, por sua vez, tem por objetivo investigar o impacto da federação no tempo de processamento de consultas SOLAP sobre um DWG. Para isto, foram utilizados dois esquemas distintos de DWG: o RBF-GHSSB e o DBF-GHSSB (Date-based Federation GHSSB). Estes esquemas serão detalhados na Seção 5.4. Para a análise investigativa foram definidas diferentes configurações de federações (i.e. quantidades membros nas federações e, consequentemente, números de servidores para processamento das consultas) sobre as bases que mantêm os dados dos DWG. Consultas SOLAP foram submetidas a cada uma destas configurações, e seus tempos de processamento foram comparados segundo cada esquema de DWG com o objetivo de para verificar o impacto das federações no desempenho. 5.3 Configuração do Ambiente de Teste As análises experimentais deste trabalho foram conduzidas na infraestrutura de computação em nuvem Windows Azure (WINDOWS AZURE, 2013) e Windows Azure SQL Database (WINDOWS AZURE SQL DATABASE, 2013) na versão No Windows Azure, uma máquina virtual (VM) de médio porte foi contratada para o armazenamento da estrutura de indexação, bem como para servir de interface entre o usuário e o banco de dados em nuvem durante a realização dos experimentos. A VM é munida com um processador AMD Opteron 4171 HE de 2.09 GHz, com dois cores, 3 GB de memória principal e disco rígido com capacidade de 126 GB. O Windows Server 2008 R2 é o sistema operacional contido nesta VM. Para criação da estrutura de indexação do IBJ foi utilizado o FastBit O CSB-Index proposto neste trabalho foi desenvolvido na versão 11 da linguagem C++, a qual oferece recursos nativos (thread) de programação concorrente (WILLIAM, 2012), e compilado no Visual Studio Além do CSB-Index e do FastBit, estão instalados nesta VM o.net Framework 4.0 e ferramentas de conexão com o banco de dados, requisitos considerados essenciais para a correta execução do CSB-Index. O Windows Azure SQL Database foi escolhido por ser um SGBD já consolidado no mercado. Ademais, trata-se de um sistema de gerenciamento de dados desenvolvido nativamente para a computação em nuvem, conforme discutido na Seção 2.4.4, permitindo explorar os benefícios deste ambiente com maior eficácia. Além disso, ao contrário de outros sistemas de 59

74 armazenamento de dados disponíveis em nuvem, o Azure SQL Database é um SGBD que provê meios para o correto armazenamento, recuperação e manipulação de objetos espaciais, conforme as especificações da OGC (OPEN GEOSPATIAL CONSORTIUM, 2013), um requisito fundamental para este trabalho de pesquisa. 5.4 Bases de Dados Para realizar os testes experimentais propostos neste trabalho, dois esquemas distintos de DWG foram utilizados: o RBF-GHSSB e DBF-GHSSB. Estes esquemas são adaptações do GHSSB proposto por (SIQUEIRA et al., 2010) e descrito na Seção para utilizar federações. No RBF-GHSSB, o banco de dados que armazena os dados do DWG foi fragmentado horizontalmente segundo a localização (região) do cliente, enquanto que o DBF-GHSSB foi particionado com base no ano em que o pedido foi realizado. O esquema RBF-GHSSB é detalhado na Seção 5.4.1, já o esquema DBF-GHSSB é apresentado na Seção RBF-GHSSB A análise de viabilidade do CSB-Index como estrutura de indexação para DWG mantidos em nuvem utilizou o esquema RBF-GHSSB (Region-Based Federation GHSSB) para realização dos testes experimentais. A Figura 5.1 mostra as adaptações realizadas no GHSSB, Figura 5.1(a), para obter o esquema RBF-GHSSB que é mostrado na Figura 5.1(b). Na Figura 5.1(b) as tabelas destacadas em azul correspondem às tabelas federadas, enquanto aquelas em cinza são ditas tabelas de referência cujos valores (no momento da criação da federação) são replicados entre os diversos bancos de dados resultantes. Conforme dito anteriormente, para os bancos de dados construídos a partir deste esquema de DWG foi definida uma federação segundo a localização dos clientes (dimensão Customer). Então, as tabelas que armazenam as feições geométricas de Cidade, Nação e Região City, Nation e Region respectivamente, Figura 5.1(a) compartilhadas entre as dimensões Supplier e Customer foram separadas. Isto porque não há a obrigatoriedade dos clientes e fornecedores estarem lotados em uma mesma região. Assim, as tabelas S_City, S_Nation e S_Region foram criadas para a dimensão Supplier, e as tabelas C_City, C_Nation e C_Region foram criadas para Customer conforme ilustra a Figura 5.1(b). Além da separação destas tabelas, o campo Fedkey (o qual representa a chave de distribuição da federação) foi adicionado à chave-primária das tabelas C_Address, C_City, C_Nation, C_Region, Customer e Lineorder. Os valores deste campo são definidos conforme a chave-primária da tabela Region, i.e. region_pk, permitindo a fragmentação do banco de dados com base nas cinco possíveis regiões dos clientes. É importante ressaltar que a fragmentação do banco de dados no Windows Azure SQL Server ocorre de acordo com os valores do atributo da chave de distribuição, neste caso Fedkey. O campo Fedkey é adicionado em todas as tabelas ditas federadas. Com relação à geração de dados para o experimento, foram geradas duas instâncias do SSB, uma com fator de escala igual a 5 e outra com fator de escala 1. Para o fator de escala 5 foram 60

75 produzidas cerca de 30 milhões de tuplas na tabela de fatos, 5 regiões distintas, 5 nações por região (totalizando 25 nações), 10 cidades por nação um total de 250 cidades e certa quantidade de endereços por cidade que variam de 538 até 669. Cidades, nações e regiões são representadas por polígonos enquanto que endereços são expressos por pontos. Polígonos foram adaptados de uma base real a Tiger/Line ( enquanto pontos são sintéticos e foram gerados por meio de um algoritmo proposto pelo benchmak Spadawan. Este programa cria pontos contidos em MBR definidos sobre objetos que representam cidades. Após a criação destes pontos, foi verificado se os pontos estavam contidos nos objetos espaciais. Por sua vez, quando aplicado o fator de escala 1 na geração de dados pelo SSB são obtidas 6 milhões de tuplas na tabela de fatos, lineorder, porém o número de regiões, nações e cidades permanecem constantes. Figura 5.1: Esquemas GHSSB e o RBF-GHSSB. A Tabela 5.1 mostra um exemplo da distribuição das tuplas nos cinco bancos de dados obtidos pela federação do DWG conforme a região em que o cliente reside. A coluna Fedkey representa o identificador de cada banco de dados resultante da fragmentação horizontal. Tabela 5.1: Número de tuplas presentes em cada tabela federada para o esquema RBF-GHSSB do DWG gerado a partir do fator de escala 5. Fedkey Número de tuplas em cada tabela para cada membro da federação Region Nation City Address Customer Lineorder

76 5.4.2 DBF-GHSSB Nos testes experimentais que visam investigar o efeito das federações sobre o tempo de processamento de consultas SOLAP foi utilizado o esquema DBF-GHSSB (Date-Based Federation GHSSB) que é mostrado na Figura 5.2. Este esquema também foi adaptado do GHSSB proposto pelo benchmark Spadawan para dar suporte à criação de federações que se baseiam no ano em que os pedidos foram realizados. Para permitir as federações pelo ano do pedido, o campo fedkey, o qual corresponde à chave de distribuição da federação, foi adicionado às chaves-primárias da tabela de fatos (Lineorder) e da tabela de dimensão temporal (Date), conforme mostra a Figura 5.2. Então, as tabelas destacadas em azul na Figura 5.2 representam as tabelas federadas (i.e. aquelas que serão particionadas de acordo com os valores da chave de distribuição), enquanto que as tabelas em cinza são as tabelas de referências (que são replicadas para o banco de dados de cada membro da federação). Os valores do campo fedkey é do tipo inteiro definido segundo os valores do campo d_year de Date. Os dados desta base foram gerados a partir do fator de escala 1 do SSB o que produziu 6 milhões de tuplas na tabela de fatos, 2556 tuplas na tabela Date que correspondem aos dias dos anos de 1992 até 1998, deste modo é possível gerar uma federação com 7 membros. As geometrias que representam os endereços, cidades, nações e regiões foram obtidos de forma análoga ao esquema RBF-GHSSB, visto anteriormente. Com relação a distribuição das tuplas das tabelas federadas do esquema DBF-GHSSB, na Tabela 5.2 é mostrado um exemplo para um DWG gerado a partir do SSB fator 1 e que foi federado segundo os valores da coluna Fedkey, que estão associados aos valores do atributo Ano da dimensão temporal. Figura 5.2: Esquema de DWG adaptado do GHSSB, no qual uma federação sobre o ano do pedido foi criada. 62

77 Tabela 5.2: Número de tuplas presentes em cada tabela federada para o esquema DBF-GHSSB de DWG gerado a partir do fator de escala 1. Fedkey Ano Número de tuplas em cada tabela para cada membro da federação Date Lineorder Carga de Trabalho A carga de trabalho proposta para execução dos testes experimentais visa a análise de desempenho das operações de drill-down e roll-up com base no tempo de resposta das consultas. Então, foram definidos três tipos de consultas SOLAP baseadas na consulta Q2.3 do SSB. Para atingir o objetivo da análise realizada algumas adaptações foram necessárias. Primeiro, a dimensão fornecedor da consulta original foi substituída por consumidor. Esta alteração tem por objetivo fazer uso da federação dos dados para reduzir o tempo de resposta das consultas, e além disso, a dimensão consumidor apresenta maior número de tuplas, aumentando, assim, o custo das operações de junção. Para transformar as consultas do SSB em consultas SOLAP, os predicados convencionais destacados nas Figura 5.3, Figura 5.4 e Figura 5.5 foram substituídos por predicados espaciais baseados em janelas de consulta (JC) ad-hoc. Estas janelas de consulta são quadráticas e têm distribuição correlacionada com os dados espaciais. Os centroides das mesmas são endereços de consumidores escolhidos aleatoriamente, oriundos da tabela c_address. Operações de drill-down e roll-up são viabilizadas pelas JC, pois elas permitem a agregação de dados em diferentes níveis de granularidade. Para tal finalidade, são utilizadas 4 consultas de um mesmo tipo, porém aplicadas aos diferentes níveis de granularidade espacial. Para cada nível, utilizam-se JC com tamanhos distintos, mas que possuem o mesmo centroide. A Figura 5.6 exemplifica a aplicação das janelas de consultas de acordo com os níveis de granularidade para realização de operações de drill-down e roll-up. Consultas do Tipo 1, conforme ilustra a Figura 5.3, tem por objetivo o processamento de operações SOLAP de drill-down/roll-up. Para isto, o relacionamento espacial está contido é testado para o menor nível de granularidade, i.e. endereço, que é representado por pontos espaciais. Para os demais níveis aplica-se o relacionamento espacial intersecta. Consultas do Tipo 2 faz uso do predicado está contido em todos os níveis de granularidade (Figura 5.4). Por fim, consultas do Tipo 3 (Figura 5.5) realizam as operações de drill-down e roll-up avaliando o relacionamento está contido para endereço e contém para os outros. 63

78 Figura 5.3: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo 1. Figura 5.4: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo 2. Figura 5.5: Adaptação da consulta Q2.3 do SSB adaptada para consulta do Tipo 3. Figura 5.6: Exemplos de janelas de consultas para os diferentes níveis de granularidade. 64

79 Nos experimentos realizados e descritos nesta dissertação a amplitude das JC foi considerada de acordo com o trabalho de Siqueira (2009). A definição da área de abrangência das JC nos diversos níveis de granularidade foi calculada com base na área do MBR que engloba todas as feições geográficas do DWG. A área deste MBR doravante será denominada por extent. A Tabela 5.3 exibe a fração do extent para os diversos níveis de granularidade e para cada tipo de consulta. Observa-se que as consultas do Tipo 2, em que o predicado está contido é testado, possuem as maiores JC. Isto foi necessário para tentar englobar as feições geométricas que representam objetos espaciais em diversos níveis de granularidade. Tabela 5.3: Frações do extent cobertas por cada JC para os níveis de granularidade. Tipo da consulta Granularidade Tipo 1 Tipo 2 Tipo 3 Endereço 0,001% 0,01% 0,0001% Cidade 0,05% 0,1% 0,0005% Nação 0,1% 10% 0,001% Região 1% 25% 0,01% 5.6 Processador de Consultas em Paralelo Bancos de dados armazenados em nuvem, quando federados, são particionados horizontalmente originando novos bancos de dados. Estes bancos de dados, apesar de comporem uma mesma federação, são independentes entre si e seus dados podem ser mantidos em servidores distintos. Por isso, para recuperar todas as informações de uma dada consulta é preciso realizar buscas em cada membro da federação. Embora aumente a complexidade da busca de dados, o uso de federações possibilita a distribuição da carga de trabalho entre vários servidores por meio de consultas que executam em paralelo. Para realizar os testes experimentais descritos neste trabalho, uma aplicação que realiza consultas em paralelo foi desenvolvida, Figura 5.7. Ela foi implementada utilizando a linguagem de programação C# com.net Framework 4.0 e a biblioteca open source Enzo SQL Shard (ENZO SQL SHARD, 2013) em sua versão Esta biblioteca define uma extensão da linguagem de consultas e desenvolvimento T-SQL do Windows Azure SQL Database, denominada D-SQL. A linguagem D-SQL possibilita a execução de consultas sobre diversos bancos de dados, distribuindo a carga de trabalho. Além disso, oferece suporte a consultas sobre federações do Windows Azure SQL Database. Especificamente para o processamento de consultas sobre uma federação, o Enzo SQL Shard busca nos metadados quais são os membros de uma dada federação antes de executar a consulta SQL. Uma vez conhecidos os membros, submete-se a consulta desejada em cada um deles. Após o processamento desta consulta, um conjunto de respostas é obtido. Porém, o agrupamento dos dados pela cláusula GROUP BY não é realizado corretamente, pois são processados individualmente em cada membro da federação. Na Figura 5.7 é exibida a tela deste aplicativo. Para realizar as consultas distribuídas neste aplicativo é preciso informar no campo de conexão (representado pelo número 1) os dados para 65

80 conexão ao banco de dados, nome do servidor, porta, banco de dados, nome de usuário e senha. No campo 2, deve ser informado o arquivo que contém as consultas que compõem a carga de trabalho. Nos testes experimentais realizados neste trabalho, este arquivo contém pelo menos 4 consultas que juntas simulam uma consulta SOLAP do tipo roll-up ou drill-down. O nome dado à federação é informado no campo 3 e serve para busca dos metadados utilizados para identificar quais são os nodos (ou membros) da federação, bem como os valores da chave de distribuição armazenados em cada membro. Por fim, o campo 4 é responsável por apresentar os resultados obtidos pelo processamento destas consultas. Figura 5.7: Tela do aplicativo para realizar consultas paralelas distribuídas sobre o Azure SQL Database. Conforme afirmado anteriormente, consultas que fazem uso de agrupamento de dados não são processadas corretamente, por isso é necessário realizar alguns passos além do processamento da consulta no Enzo SQL Shard. O pseudocódigo do algoritmo de processamento de consultas utilizado pelo aplicativo é exibido na Figura 5.8. ConsultarEmParalelo (arquivocargatrabalho, listafederacao, fagg, campo) Entradas: arquivocargatrabalho: arquivo que contém a carga de trabalho. listafederacao: todas as federações de um dado banco de dados. fagg: função de agregação (MAX, MIN, AVG, COUNT, etc) que deve ser aplicada ao resultado. Campo: campo que deve ser agregado. Saída: resultadofinal: vetor que armazena todos os resultados de consultas. Declarações: Consulta: cadeia de caracteres que contém a consulta do arquivo. 01 n 0 02 abra(arquivocargatrabalho) 66