27th BRAZILIAN SYMPOSIUM ON DATABASES - USPdata.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_min_cc.pdf · 27th BRAZILIAN SYMPOSIUM ON DATABASES ... Linguagens e Estudos de Casos no Contexto

27th BRAZILIAN SYMPOSIUM ON DATABASES

Lectures

PROCEEDINGS

October 15th-18th, 2012 São Paulo, São Paulo, Brazil

Promotion

Brazilian Computer Society - SBC SBC Special Interest Group on Databases

Organization Universidade de São Paulo - USP Realization Instituto de Matemática e Estatística - USP Lectures Chair

Marcio K. Oikawa (UFABC)

ii

Editorial

The Brazilian Symposium on Databases (SBBD) comes to 27th edition in 2012. This traditional event of brazilian scientific community on Database Technology is supported by Brazilian Computer Society (SBC) and this year will be hosted in São Paulo, São Paulo State, Brazil. The event will meet professors, researchers, Information Technology professionals and students. This event is organized as set of many different technical tracks, with special attention of this text to SBBD Lectures. SBBD Lectures are small courses about some specific subject and aim to present an introductory or advanced discussion concerning with current trends on Database research. During lectures, audience has the opportunity to open discussions about relevant subjects and collaborate on building a collective knowledge with experts. This year, lectures are organized as 4-hour presentations, favoring the speaker with more time to introduce and develop his or her works. In 2012, some special attention was given to undergraduate students in Computer Science and related courses. We classify SBBD Lectures as a single opportunity to meet students and debate relevant subjects, that may explored through both graduation courses and companies interested in real world problems. Although the motivation indicates undergraduation students, all covered subjects would be naturally used on graduation studies and research projects. Because of some internal logistics decisions of SBBD, WebMedia and SBSC, only two (2) proposals were accepted. The choice has considered the analysis of nine (9) initial proposals, submitted by research groups from different brazilian regions. The evaluation was based on technical criteria, such as originality, relevance, format and connection to the audience. During this process, this committee had the essential collaboration of profs. Edson P. Pimentel (UFABC), Humberto L. Razente (UFABC), Kelly R. Braghetto (UFABC) and Luciano V. Araújo (USP). We are very grateful to the unconditional support of SBBD 2012 Steering Committee, SBBD 2012 event coordinators, SBBD 2012 Program Committee, Local Organization Committee, authors, speakers and participants. The SBBD Lectures organization committee has worked hard to provide the best conditions to a very enjoyable event. See you in São Paulo.

Márcio K. Oikawa, UFABC SBBD 2012, Lectures Chair

iii


October 15th – 18th, 2012

São Paulo, São Paulo, Brazil

Promotion Brazilian Computer Society - SBC SBC Special Interest Group on Databases

Organization

Universidade de São Paulo - USP

Realization

Instituto de Matemática e Estatística - USP

SBBD Steering Committee

José Palazzo Moreira de Oliveira (UFRGS) – Chair Angelo Brayner (UNIFOR) Alberto Laender (UFMG) Cláudia Bauzer Medeiros (UNICAMP) Cristina Dutra de Aguiar Ciferri (ICMC-USP) Marco A. Casanova (PUC-Rio)

SBBD 2012 Committee Steering Committee Chair

José Palazzo Moreira de Oliveira (UFRGS) Local Organization Chair João Eduardo Ferreira (IME-USP) Program Committee Chair

Marco A. Casanova (PUC-Rio) Short Papers Chair

Renata Galante (UFRGS) Demos and Applications Chairs

José Maria da Silva Monteiro Filho (UFC) Javam de Castro Machado (UFC)

Thesis and Dissertation Workshop Chairs Fabio Porto (LNCC) Ana Maria de C. Moura (LNCC)

Tutorials Chair Cristina Dutra de Aguiar Ciferri (ICMC-USP)

Lectures Chair Marcio K. Oikawa (UFABC)

Local Organization Committee João Eduardo Ferreira (IME-USP) – Chair Isabel Italiano (EACH-USP) Kelly R. Braghetto (UFABC) Luciano V. Araújo (EACH-USP) Marcio K. Oikawa (UFABC)

iv

Lectures Program Committee Marcio K. Oikawa - Chair (UFABC) Edson P. Pimentel (UFABC) Humberto L. Razente (UFABC) Kelly R. Braghetto (UFABC) Luciano V. Araújo (USP)

v


Lectures

Table of Contents Bancos de dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Contexto de Big Data .....................................................................................................................................1 Marcos Rodrigues Vieira, Josiel Maimone de Figueiredo, Gustavo Liberatti, Alvaro Fellipe Mendes Viebrantz Inclusão de Consultas por Similaridade em SGBDs: Teoria e Prática .........................................31 Daniel dos Santos Kaster, Caetano Traina Jr.

Minicurso

1Bancos de Dados NoSQL: Conceitos, Ferramen-tas, Linguagens e Estudos de Casos no Contextode Big Data

Marcos Rodrigues Vieira1, Josiel Maimone de Figueiredo2, Gustavo Liberatti2,Alvaro Fellipe Mendes Viebrantz2

1IBM Research Laboratory - [email protected]

2Instituto de ComputaçãoUniversidade Federal de Mato Grosso (UFMT)[email protected], {liberatti.gustavo, alvarowolfx}@gmail.com

Abstract

This lecture presents the data models, tools and languages concepts related to NoSQLdatabases, with a big emphasis on the Big Data domain. The main goal of this lectureis to provide an introductory, comparative and practical view of the definitions and themain tools and languages for NoSQL products currently available in the market. Sincethe definitions and tools for NoSQL are evolving rapidly in the past years, here we givea special focus on the most used and well-known NoSQL technologies for manipulatingvery large volumes of data. As a practical example, we present two use cases of NoSQLapplications in different domains: (1) a use case involvingsensor datasets from micro-meteorological towers; and (2) a use case of NoSQL technologies applied to a largevolume of textual dataset representing patent documents. We also discuss the impactsand consequences of the adoption of NoSQL products by the industry, IT staff, and thescientific database community.

1

MinicursosSimpósio Brasileiro de Bancos de Dados - SBBD 2012

Resumo

Este minicurso apresenta os conceitos relacionados a modelagem, ferramentas e lin-guagens de manipulação de banco de dados NoSQL, com principal enfoque para BigData. Este minicurso tem como objetivo principal dar um visão introdutória, compara-tiva e prática dos conceitos e das principais ferramentas e linguagens NoSQL disponí-veis no mercado para diferentes domínios de problemas e aplicações. Como o conceitoe ferramentas de NoSQL estão em rápida evolução nos últimos anos, o enfoque princi-pal é voltado para as tecnologias mais adotadas e difundidasde manipulação de grandevolume de dados utilizando ferramentas NoSQL. Como exemplopratico, é apresentadodois estudos de casos de uso NoSQL em diferentes domínios de aplicações: (1) estudode caso envolvendo dados de sensores presentes em torres micrometeorológicas; e (2) autilização de tecnologias NoSQL aplicadas para dados textuais em grande bases de pa-tentes. Por fim, são apresentados os impactos da adoção desses produtos na indústria,aos usuários de TI, e também a comunidade científica de banco de dados.

1.1. Introdução

Um dos grandes desafios atualmente na área de Computação é a manipulação e proces-samento de grande quantidade de dados no contexto deBig Data. O conceitoBig Datapode ser resumidamente definido como uma coleção de bases de dados tão complexae volumosa que se torna muito difícil (ou impossível) e complexa fazer algumas ope-rações simples (e.g., remoção, ordenação, sumarização) deforma eficiente utilizandoSistemas Gerenciadores de Bases de Dados (SGBD) tradicionais. Por causa desse pro-blema, e outros demais, um novo conjunto de plataformas de ferramentas voltadas paraBig Datatem sido propostas, como por exemplo Apache Hadoop [3].

A quantidade de dados gerada diariamente em vários domíniosde aplicaçãocomo, por exemplo, da Web, rede sociais, redes de sensores, dados de sensoriamento,entre diversos outros, estão na ordem de algumas dezenas, oucentenas, de Terabytes.Essa imensa quantidade de dados gerados traz novos grandes desafios na forma de mani-pulação, armazenamento e processamento de consultas em várias áreas de computação,e em especial na área de bases de dados, mineração de dados e recuperação de informa-ção. Nesse contexto, os SGBD tradicionais não são os mais adequados, ou “completos”,às necessidades do domínio do problema deBig Data, como por exemplo: execução deconsultas com baixa latência, tratamento de grandes volumes de dados, escalabilidadeelástica horizontal, suporte a modelos flexíveis de armazenamento de dados, e suportesimples a replicação e distribuição dos dados.

Uma das tendências para solucionar os diversos problemas e desafios geradospelo contextoBig Data é o movimento denominado NoSQL (Not only SQL). NoSQLpromove diversas soluções inovadoras de armazenamento e processamento de grande


2

volume de dados. Estas soluções foram inicialmente criadaspara solucionar problemasgerados por aplicações, por exemplo, Web 2.0 que na sua maioria necessitam operarcom grande volume de dados, tenham uma arquitetura que “escale” com grande facili-dade de forma horizontal, permitam fornecer mecanismos de inserção de novos dados deforma incremental e eficiente, além da necessidade de persistência dos dados em aplica-ções nas nuvens (cloud computing). Essas diversas soluções vêm sendo utilizadas commuita frequência em inúmeras empresas, como por exemplo, IBM, Twitter, Facebook,Google e Yahoo! para o processamento analítico de dados delogs Web, transaçõesconvencionais, entre inúmeras outras tarefas.

Atualmente, existe uma grande adoção e difusão de tecnologias NoSQL nosmais diversos domínios de aplicação no contexto deBig Data. Esses domínios envol-vem, em sua maioria, os quais os SBGD tradicionais ainda sãofortementedominantescomo, por exemplo, instituições financeiras, agências governamentais, e comercio deprodutos de varejo. Isto pode ser explicado pelo fato que existe uma demanda muitogrande para soluções que tenham alta flexibilidade, escalabilidade, performance, e su-porte a diferentes modelos de dados complexos.

Podemos basicamente resumir as características deBig Dataem quatro propri-edades:(1) dados na ordem de dezenas ou centenas de Terabytes;(2) poder de cres-cimentoelástico horizontal; (3) fácil distribuição dos dados e/ou processamento; e(4)tipos de dados variados, complexos e/ou semiestruturados.A característica de manipu-lação de dados na ordem (ou maior) de Terabytes envolve, entre outros aspectos, o re-quisito de alto poder computacional de processamento, manipulação e armazenamentode dados. O poder de crescimento elástico esta relacionado ao fato de que a quantidadede dados pode variar de alguns Megabytes a várias centenas deTerabytes (e vice-versa)em um espaço de tempo relativamente curto, fazendo com que a estrutura de hardwa-re/software demandada tenha que se adaptar, i.e. seja alocada/desalocada sob demandada aplicação. A distribuição significa que os dados devem serdistribuídos de formatransparente em vários nós de processamento, o que demanda armazenamento e pro-cessamento distribuído. E a quarta característica esta relacionada a adoção de modelosmais apropriados, flexíveis e eficientes para o armazenamento de tipos de dados com-plexos, variados e semiestruturados. Vale ressaltar que o modelo relacional tradicionalnão é o mais adequado para tais propriedades acima citadas pois não possui suficienteflexibilidade para o armazenamento de dados e na evolução do modelo de dados.

Em relação a SGBD tradicionais, a distribuição dos dados de forma elástica é in-viabilizado pois o modelo de garantia de consistência éfortementebaseado no controletransacional ACID (Atomicity, Consistency, Isolatione Durability). Esse tipo de con-trole transacional é praticamente inviável quando os dadose o processamento são distri-buídos em vários nós. O teorema CAP (Consistency, Availability e Partition tolerance)mostra que somente duas dessas 3 propriedades podem ser garantidas simultaneamente


3

em um ambiente de processamento distribuído de grande porte. A partir desse teorema,os produtos NoSQL utilizam o paradigma BASE (Basically Available, Soft-state, Even-tually consistency) para o controle de consistência, o que consequentemente traz umasensível diminuição no custo computacional para a garantiade consistência dos dadosem relação a SGBD tradicionais.

Dentro do aspecto do processamento dos dados, o principal paradigma adotadopelos produtos NoSQL é oMapReduce[13]. Em resumo, tal paradigma divide o pro-cessamento em duas etapas: (1)Map, que mapeia e distribui os dados em diversos nósde processamento e armazenamento; e (2)Reduce, que agrega e processa os resultadosparciais para gerar um resultado final (ou intermediário para outro processo MapRe-duce). Dentre os vários produtos NoSQL existentes, podemosconsiderar que o maisrepresentativo é o Apache Hadoop [3], cuja implementação doalgoritmo MapReduceé hoje considerada a referência. Atualmente existem diversas grandes e médias empre-sas que estão utilizando Hadoop para as mais diversas finalidades, como IBM, Google,Twitter, Yahoo!, Netflix, Facebook, e algumas agências financeiras internacionais.

Além do Apache Hadoop, existem vários outros produtos NoSQLdisponíveisno mercado, onde eles se diferem principalmente na complexidade para o suporte a di-ferentes tipos de dados, como por exemplo documentos, dadosem forma destreams,dados semiestruturados e em forma de grafos, entre outros. Alguns exemplos de servi-ços baseados em Hadoop são: Amazon Elastic MapReduce, Oracle BigData Appliance,EMC Greenplum, Teradata, Microsoft Windows Azure.

Nesse contexto de grande adoção e uso de sistemas baseados emtecnologiasNoSQL, este minicurso tem como objetivo principal introduzir os conceitos relaciona-dos a NoSQL nos mais variados domínios de aplicações deBig Data.

1.1.1. Descrição da Estrutura do Minicurso

Este mini-curso esta estruturado da seguinte forma:

1. Introdução, Motivação e Conceitos emBig Data (duração 30 minutos): estemódulo faz uma introdução, motivação e descrição dos conceitos relacionados aocontexto deBig Data. Esta parte faz um enfoque nos principais desafios trazidospor esse contexto no qual é demandado o gerenciamento de grande quantidadede informações não estruturadas e semiestruturadas de forma distribuída, comestrutura elástica, e uso em ambiente computacional de nuvem (cloud computing);

2. Descrição e Conceitos de NoSQL (duração 60 minutos): este módulo cobre osconceitos relacionados a NoSQL no contexto deBig Data, tais como os produ-tos, linguagens de acesso, manipulação e processamento dosdados. Além disso,esta parte visa dar uma visão geral dos diferentes produtos NoSQL disponíveis


4

no mercado, como por exemplo: Column Store (e.g., Hadoop, Casandra, AmazonSimpleDB, Hypertable), Document Store (e.g., Apache CouchDB, MongoDB),Key-Value/Tuple Store (e.g., Voldemort, Redis, MemcacheDB), Graph Databases(e.g, Neo4J, HyperGraphDB). Assim, serão abordadas implementações existen-tes para os problemas de distribuição, transações, mineração e a infraestruturacomputacional de nuvem;

3. Estudo de caso 1 (duração 60 minutos): este módulo apresenta um estudo decaso de solução NoSQL no contexto deBig Datade dados textuais a partir de umaaplicação de bases de patentes. Este módulo descreve as soluções escolhidas, suasvantagens/desvantagens, e suas implementações;

4. Estudo de caso 2 (duração 60 minutos): este módulo descreve o uso destreamsde dados originados de sensores em torres micrometeorológicas. Este módulodescreve a forma de manipular essas informações dentro da solução de produtosNoSQL;

5. Desafios, direções futuras, problemas em aberto (duração 30minutos): estemódulo apresenta os desafios de adoção desses novos produtospor ambientes tra-dicionais de desenvolvimento de sistemas baseados na tecnologia relacional. Étambém levantado o problema de adaptação do ambiente tradicional, no qual di-versas padronizações já consolidadas (e.g., padrões de projetos, bibliotecas,dri-versde conexão, mapeamento objeto-relacional) precisam ser adaptadas para ob-tenção das informações originárias dos produtos NoSQL. Será abordado tambémo impacto desses novos produtos nos atores envolvidos, ou seja, programadores eadministradores (DBA).

1.2. Conceitos Relacionados a NoSQL

Embora as terminologias relacionadas ao contexto NoSQL ainda são inconsistentes esem padronização, aqui definimos os termos e conceitos mais utilizados. Para o bom en-tendimento do contexto NoSQL, é preciso primeiramente a definição de alguns concei-tos fundamentais que estão relacionados com essa tecnologia, bem como as influênciasque direcionam o desenvolvimento de novos produtos relacionados a NoSQL. Portanto,a abordagem utilizada neste minicurso é a de descrever as influências externas e, pos-teriormente, abordar as consequências internas para produtos NoSQL, ou seja, como asatuais soluções foram implementadas visando solucionar osproblemas existentes. Pormotivos já citados anteriormente, este minicurso não tem a intenção de cobrir de formaextensiva e completa os conceitos relacionados ao domínio NoSQL. No entanto, aquifornecemos várias referências para trabalhos que tenham uma explicação e definiçãomais aprofundada relacionados ao tema aqui exposto.


5

Os trabalhos disponíveis na literatura relacionados a NoSQL explicam, em suagrande maioria, o surgimento de NoSQL no contexto de grande quantidade de dados ge-rados em um espaço de tempo (relativamente) curto. Como consequência dessa grandequantidade de dados, sistemas disponíveis para a manipulação desses dados gerados ne-cessitam de um grande poder de processamento de forma eficiente e escalável. Além daalta taxa de geração dos dados, outro fator que influenciou a criação de sistemas NoSQLfoi o suporte a tipo de dados complexos, semiestruturados ounão estruturados. Alémdo volume de geração desses dados ser grande, outro fator predominante é relacionadaa dificuldade de modelagem de tais tipos de dados. Esses tiposde dados estão hojepresentes em inúmeros domínios de aplicações, tais como Web2.0, redes sociais, redesde sensores, entre outros.

Nas últimas décadas os SGBD tradicionais baseados no modelorelacional vêmincorporando novas características que transcendem o modelo relacional original. Exem-plos dessas novas funcionalidades são o suporte a outros tipos de dados nativos, comoobjetos, temporal, espacial, XML, documentos de textos, entre outros.

Essas novas funcionalidades suportadas por SGBD são, basicamente, encapsu-lamentos de extensões do modelo objeto-relacional. Deste modo, as políticas de transa-ção, replicação, segurança e gerenciamento dos dados continuam, em sua grande maio-ria, as mesmas pois não existem grandes grandes mudanças estruturais nos SGBD. Poroutro lado, uma grande vantagem da adição de novas funcionalidades aos SGBD é quea estrutura corporativa que utiliza os SGBD não sofre grandes mudanças (e.g., os proce-dimentos de backup, segurança, continuam os mesmos). No entanto, essa abordagem desolução única adotada pelos SGBD relacionais vem sendo criticada por varias pessoaspois novas demandas de mercado requerem abordagens mais adequadas (e.g., a lingua-gem SQL não consegue representar todas as demandas pelas novas aplicações) [30].

1.2.1. Big Data

O termoBig Dataé bem amplo e ainda não existe um consenso comum em sua defi-nição. Porém,Big Datapode ser resumidamente definido como o processamento (efi-ciente e escalável) analítico de grande volumes de dados complexos produzidos por(várias) aplicações. Exemplos de aplicações no contextoBig Datavaria bastante, comoaplicações científicas e de engenharias, redes sociais, redes de sensores, dados deWebClick, dados médicos e biológicos, transações de comércio eletrônico e financeiros, en-tre inúmeras outras. As semelhanças entre os dados desses exemplos de aplicações in-cluem: grande quantidade de dados distribuídos, características de escalabilidade sobdemanda, operações ETL (Extract, Transform, Load [27]) de dados “brutos” (raw)semi- ou não estruturados para dados estruturados e, a necessidade de extrair conhe-cimento da grande quantidade de dados [12].

Três fatores influenciaram o grande aumento de volume de dados sendo coleta-


6

dos e armazenados para posterior análise: difusão dos dispositivos captação de dados,dispositivo com armazenamento na ordem de Terabytes e aumento de velocidade detransmissão nas redes. Os dispositivos de aquisição, bem como os dispositivos de ar-mazenamento de grande escala se difundiram principalmentepelo seu barateamento(e.g., redes de sensores, GPS,smartphones), enquanto que as redes aumentaram suavelocidade e abrangência geográfica. Outro fator importante é a facilidade de gera-ção e aquisição de dados gerados digitalmente, como máquinas fotográficas digitais,smartphones, GPS, etc. Como consequência novas demandas estão surgindo, como ademanda por análise de grande volume de dados em tempo real (data analytics), o au-mento do detalhamento das informações, bem como plataformas escaláveis e eficientesde baixo custo [10].

Basicamente, podemos resumir as características do contexto Big Dataem qua-tro propriedades:(1) dados na ordem de dezenas ou centenas de Terabytes (podendochegar a ordem de Petabytes),(2) poder de crescimento elástico,(3) distribuição doprocessamento dos dados; e(4) tipos de dados variados, complexos e/ou semiestrutura-dos. A característica de análise dos dados na ordem de Terabytes envolve, entre outrosaspectos, o requisito de alto poder computacional de armazenamento e processamentodos dados. A elasticidade esta relacionada ao fato de que a quantidade de dados podevariar de alguns Megabytes a vários Terabytes (e vice-versa) em um espaço de temporelativamente curto, fazendo com que a estrutura de software/hardware adapta-se sobdemanda, i.e. seja alocada/desalocada dinamicamente. A distribuição significa que osdados devem ser distribuídos de forma transparente em vários nós espalhados de pro-cessamento, o que demanda armazenamento, processamento e controle de falhas distri-buído. Finalmente, a quarta característica esta relacionada a adoção de modelos maisapropriados, flexíveis e eficientes para o armazenamento de tipos de dados variados esemiestruturados. Vale ressaltar que o modelo relacional não é o mais adequado poisnão possui flexibilidade para o armazenamento de dados e evolução no modelo para taistipos de dados citados acima.

A análise de dados (data analytics) no contexto deBig Datanormalmente en-volve processamento da ordem de Terabytes em dados de baixo valor (i.e., informaçãooriginal “bruta”) que são transformados para dados de maiorvalor (e.g., valores agre-gados/sumarizados). Mesmo com a grande quantidade de dadosBig Data em si nãogarante a qualidade da informação, pois a análise continua,em grande parte, sendomuito subjetiva. Isso se deve ao fato que os dados em si não sãoautoexplicativos, ondeo processo de limpeza, amostragem, e relacionamento dos dados continua sendo críticoe passível a erros, aproximações e incertezas [14]. Por exemplo, a análise de dados daordem de Petabytes (ou Exabytes) de cunho científicos (e.g.,dados genômicos, físicaambiental e simulações numéricas) tem se tornado muito comum hoje em dia, onde éaceitável que o resultado da análise contenham imprecisão (i.e., erro entre certos limites


7

de erros), porém seja computado de forma (relativamente) rápida e/ou em tempo real.

Recentemente, ambientes de computação em nuvem (cloud computing) têm sidoutilizados para o gerenciamento de dados em forma deBig Data, enfocando principal-mente em duas tecnologias: Bases de Dados Como Serviço (Database as a Service(DaaS)) e Infraestrutura Como Serviço (Infrastructure as a service(IaaS)) (para mai-ores detalhes, vide [21, 1]). DaaS utiliza um conjunto de ferramentas que permite ogerenciamento remoto dos servidores de dados mantidos por uma infraestrutura externasob demanda. Essa infraestrutura IaaS fornece elasticidade, pagamento sob demanda,backup automáticos, e rapidez de implantação e entrega.

As principais características que envolvem os ambientes emnuvem são: escala-bilidade, elasticidade, tolerância a falhas, auto gerenciamento e a possibilidade de funci-onar em hardwarecommodity(comum). Por outro lado, a maioria dos primeiros SGBDrelacionais comerciais foram desenvolvidos e concebidos para execução em ambientescorporativos. Em um ambiente de computação em nuvem traz inúmeros desafios doponto de vista computacional. Por exemplo, o controle de transação na forma tradicio-nal (i.e., definida pelas propriedades ACID) em um ambiente de nuvem é extremamentecomplexo.

De uma maneira geral, os ambientes em nuvem precisam ter a capacidade desuportar alta carga de atualizações e processos de análisesde dados. Osdata centerssão uma das bases da computação em nuvem, pois uma grande estrutura como serviçoescalável e dinâmica é fornecida para vários clientes. Um ambiente de gerenciamentode dados escalável (scalable data management) pode ser dividido em:(1) uma aplicaçãocomplexa com um SGBD gerenciando uma grande quantidade de dados (single tenant);e (2) uma aplicação no qual o ambiente deve suportar um grande número de aplicaçõescom dados possivelmente não muito volumosos [2]. A influência direta dessas duascaracterísticas é que o SGBD deve fornecer um mesmo esquema genérico para inúmerosclientes com diferentes aplicações, termo denominado bases de dadosmultitenant.

É importante lembrar que em ambientesmultitenanta soma dostenantpodegerar um grande volume de dados armazenado no SGBD. Este característica é apro-priadamente gerenciada pelo ambiente em nuvem, onde novas instâncias de SGBD sãocriadas em novos nós e/ou servidores do ambiente (os dados dediferentestenantsãoindependentes entre si).

Em ambientes tradicionais, quando uma aplicação cresce suacomplexidade oSGBD atende às requisições e a escalabilidade do sistema no modo que aumenta o seupoder computacional. Por exemplo, o poder computacional dosistema como um todocresce a medida que mais memória e/ou número de nós doclustersão adicionados aoservidor. No entanto, esta abordagem são caras, dependentes de arquitetura, e normal-mente não presentes em SGBD livres (open sources).


8

1.2.2. Consistência

Consistência pode ser definido como um contrato entre um processo e um dados ar-mazenado (distribuídos), no qual o dados armazenado especifica precisamente qual éo resultado de operações de escrita e leitura na presença de concorrência. O modelode consistência pode ser definido em dois casos: centrado nosdados e centrado no cli-ente [6]. Modelo de consistência centrado nos dados refere-se ao estado interno dosistema de armazenamento, ou seja, a consistência é alcançada no momento em quetodas as cópias de um mesmo dado se tornam iguais. Já o modelo de consistência cen-trado no cliente fornece garantias apenas para um cliente (em específico) em relação aconsistência de acesso aos dados do cliente em questão. Neste último caso, quando ocliente verifica o “quanto” eventual a consistência é (o que mede o tamanho da janela deinconsistência), duas perspectivas podem existir: a do ambiente servidor, e a do cliente.Para o servidor pode aplicar o gerenciamento centrado nos dados, enquanto que para ocliente não faz diferença o que está ocorrendo no servidor [32], pois o cliente possuicontroles próprios para identificar dados “caducos”.

O interesse e uso do teorema CAP (Consistency, Availability e Partition tole-rance), também conhecido como Brewer’s theorem [7], pelos SGBD têm atingido no-vas demandas em aplicações que requerem vários nós de processamento. O teoremaCAP, resumidamente, afirma que existem três propriedades que são úteis em SGBD:C:consistência, cujo objetivo é permitir que transações distribuídas em vários nós agemcom a semântica de “tudo-ou-nada”, bem como (quando existirem) das réplicas esta-rem sempre em um estado consistente;A: disponibilidade, tem como objetivo mantero sistema sempre disponível, e em caso de falha o sistema devecontinuar funcionandocom alguma réplica dos recursos indisponíveis;P: tolerância a partições, cujo objetivoé manter o sistema operando mesmo no caso de falhas de rede, para isso é dividido oprocessamento dos nós em grupos que não se comunicam (os subgrupos continuam oprocessamento independentemente) [29]. O teorema CAP afirma que não é possívelalcançartodosos três objetivos simultaneamente quando erros existem, porém uma daspropriedades tem que ser desprezada.

Existem duas direções na escolha de A ou C:(1) a primeira necessita de forteconsistência como propriedade para tentar maximizar a disponibilidade [18]. A van-tagem de existir uma política forte de consistência é que as aplicações podem ser de-senvolvidas com mais simplicidade. Por outro lado, controles complexos devem serimplementados nas aplicações caso não exista o controle de consistência;(2) a segundadireção prioriza disponibilidade e tenta maximizar a consistência, sendo que um dosargumentos é que o ambiente indisponível traz perdas financeiras para o usuário do ser-viço. Portanto o serviço estará sempre com os dados disponíveis, mesmo que em algunsmomentos não esteja com os dados consistentes. Em aplicações Web que utilizam aescalabilidade horizontal é necessário decidir entre A ou C, enquanto que os SGBD


9

tradicionais preferem a propriedade C a A ou P.

No contexto NoSQL, o teorema CAP tem sido usado com a justificativa de des-prezo da consistência, de forma que os produtos normalmentenão permitem transaçõesque ultrapassam mais de um nó. Ou seja, não há controle de réplicas pois o teoremaCAP justifica esse ponto, que é substituída pela “consistência eventual”. Nessa abor-dagem, é garantido que todas as réplicas eventualmente convergem ao mesmo estadono momento que a conectividade for restabelecida e passar o tempo necessário para osincronismo finalizar. Portanto, a justificativa de desprezar a propriedade C é que aspropriedades A e P continuam sendo garantidas.

Com relação a manipulação de dados complexos e não estruturados, o con-trole de tolerância a falhas pode ser complexo. Esta complexidade é que no contexto< key,value> o modelo de processamento é diferente de modelos como, por exemplo,XML que é fortemente baseado em hierarquia. Com o objetivo defornecer melhor de-sempenho e alta escalabilidade, os produtos NoSQL (em contraste com a política decontroles de transação do tipo ACID) utilizam a abordagem denominada BASE (Basi-cally Available, Soft state, Eventually consistent). Esta abordagem envolve a eventualpropagação de atualizações e a não garantia de consistêncianas leituras.

A abordagem BASE é implementada de forma diferente em algunsprodutos.Por exemplo, alguns produtos se denominam “eventualmente consistentes”, porem for-necem algum tipo de consistência como a política de controlede concorrência multiver-sionada (MVCC) [9]. O leitor pode encontrar maiores detalhes da consistência eventualem [32].

1.2.3. Escalabilidade

Uma propriedade importante nos produtos NoSQL é o poder de escalar horizontalmentede forma não compartilhada (i.e., replicando e particionando os dados em diferentesservidores). Isto permite que um grande volume de operaçõesde leitura/escrita possamser executadas de forma muito eficiente.

Além dos conceitos de particionamento e distribuição serembem definidos, nãoexiste a aplicação do conceito de bases de dados federados emprodutos NoSQL. Emprodutos NoSQL, toda a base é considerada uma só, enquanto que em bases de dadosfederados é possível administrar e usar separadamente cadabase de dados e, em algunsmomentos, utilizar todas as bases como se fossem apenas uma única.

O conceito de escalabilidade vertical está relacionada como uso de vários nú-cleos/CPU que compartilham memória e discos. Portanto, mais núcleos e/ou memóriaspodem ser adicionados para aumentar o desempenho do sistema, porém essa abordagemé limitada e normalmente é cara. Já a escalabilidade horizontal está relacionada com afuncionalidade de distribuição de dados e de carga por diversos servidores, sem o com-


10

partilhamento de memória ou disco. Esta última abordagem permite o uso de máquinasmais baratas e comuns (i.e., hardwarecommodity).

Escalabilidade dinâmica é uma das mais importantes e principais propriedadesde um ambiente em nuvem, porém é um grande problema para os SGBD tradicionais.Por exemplo, Websites mais acessados são reconhecidos por sua massiva escalabilidade,baixa latência, possibilidade de aumentar (sob demanda) a capacidade da base de dados,e possuir um modelo de programação relativamente simples. Essas características nãosão encontradas em SGBD sem pagar um alto custo: somente a escalabilidade verti-cal é fácil de ser alcançada; já para a escalabilidade horizontal, os SGBD normalmentereplicam os dados para manter a sincronização dos dados. Alguns ambientes utilizamgrids para fornecerem escalabilidade horizontal em nível de sistema operacional (a es-calabilidade e distribuição são mantidas pelo servidor de aplicação em nível de sistemaoperacional). Realizar essas ações com o SGBD envolvem o usode soluções caras eque não atendem adequadamente a questão de elasticidade. Assim, essa estratégia deum modelo único de SGBD contemplar todos os modelos de dados está encontrandobarreiras para o contexto deBig Data. Se por um lado os produtos objeto-relacionalfornecem diversas funcionalidades de extensão e encapsulamento, por outro lado a ma-nutenção da mesma plataforma corporativa está se tornando inviável financeiramente,pois a maioria das soluções são caras e feitas para funcionarem ambientes declusterenuvem.

SGBD voltados para operações de data warehouse fornece escalabilidade ho-rizontal, contudo as consultas normalmente são complexas envolvendo várias junçõescom diferentes tabelas e a taxa de leituras sobre escritas é muito alta, ou seja, as opera-ções executadas são em sua grande maioria de leituras.

Já a escalabilidade horizontal em produtos NoSQL (e.g., Apache Cassandra) éalcançada com o particionamento dos dados utilizando a técnica chamada Tabela HashDistribuída (Distributed Hash Table(DHT)) [11]. Nesta técnica, as entidades dos dadossão representadas por pares< key,value>, ondekeyé uma chave que identifica unica-mente a entidade representada porvalue. O conjunto de entidades do domínio de dadossão organizados em grupos que são colocados em um nó do ambiente.

A técnicashardingé outra técnica para particionamento horizontal dos dadosem uma arquitetura sem compartilhamento de recursos. Diferentes das técnicas de di-visão dos dados por colunas (i.e., técnicas de normalizaçãoe particionalmente vertical),na técnicashardingos dados de uma tabela são divididos por tuplas (rows. Cada par-tição forma parte de umshard, onde pode ser recuperada a partir de um SGBD especí-fico. Existem inúmeras vantagens de particionamento usandoesta técnica, por exemplo,como as tabelas estão divididas e distribuídas em múltiplosservidores, o número total detuplas em cada tabela de cada servidor é reduzido. Consequentemente, o tamanho dos


11

índices também são reduzidos, o que geralmente melhora o desempenho de consultas.Outra vantagem é que uma base de dados onde oshardfoi aplicado pode ser separadoem diferentes máquinas, e múltiplosshardspodem ser alocados em diferentes máquinas.Com isso, é possível distribuir uma base de dados em um númerogrande de máquinas, oque significa que o desempenho do SGBD pode ser espalhado por diferentes máquinas.No entanto, a técnica deshardingé relativamente difícil de ser implementada, pois a di-visão dos dados muito geralmente é feita de forma estática e com conhecimento prévioda distribuição dos dados. Uma alternativa para este problema é a utilização dehashingpara distribuição dos dados de uma forma mais dinâmica.

1.2.4. O Paradigma de Programação MapReduce

Nos últimos anos, o paradigma chamadoMapReduce[13] tem ganhado grandeatenção e muitos adeptos tanto na indústria quanto na área acadêmica. Este paradigmafoi inicialmente proposto para simplificar o processamentode grande volume de dadosem arquiteturas paralelas e distribuídas (e.g., clusters). O enfoque principal doMapRe-duceé tornar transparente os detalhes da distribuição dos dadose balanceamento decarga, permitindo que o programador enfoque somente nos aspectos de tratamento dosdados [24].MapReduceé voltado para uso emclustersde computadorescommodities,onde os dados são distribuídos e armazenados utilizando como pares< key,value>(vários valores podem ser armazenados para a mesma chave). Ambas as funçõesMape Reducesão definidas com relação aos dados estruturados em pares< key,value>.Como consequência desta arquitetura, o paradigmaMapReducefornece uma aborda-gem altamente escalável voltado para o processamento intensivo de grande volume dedados (i.e., o alto desempenho da arquitetura é conseguida através da alocação dos da-dos e computação em um mesmo nó).

Provavelmente uma das maiores vantagens deste paradigma é asua simplici-dade, onde a manipulação dos dados é feita pelo uso de duas funções básicas:Map(função de mapeamento) eReduce(função de redução). Ambas funções são codifica-das pelo programador na linguagem do ambiente, que normalmente é uma linguagemprocedural. Porém, alguns produtos possibilitam o uso de linguagens declarativas comSQL (e.g, Hive [4, 31]), que são depois transformadas em funçõesMap eReduce.

Resumidamente, a funçãoMap tem como entrada um par de dados, com o tipoin one domínio de dados, e retorna uma lista de pares em um domínio diferente. Isto é,a funçãoMap(k1,v1)→ list(k2,v2). A funçãoMapé aplicada em paralela para cada pardo conjunto de dados de entrada, gerando uma lista de pares para cada chamada). Emuma segunda etapa, o processoMapReducecoleta e agrupa todos os pares com a mesmakeydas listas, criando um grupo para cada diferentekeygerada. Este conjunto de paresé construído utilizando uma função de mapeamento (hash) utilizando os valoreskeydos


12

pares, que então são distribuído em diversos nós para serem utilizado na faseReduce.

A funçãoReduceé então aplicada a cada grupo em paralelo, onde é produzidouma coleção de valores em um mesmo domínio:Reduce(k2, list(v2)) → list(v3). Oconjunto de pares< key,value> de cada conjunto intermediário são processados porjobs independentes. Este processamento na faseReducegera, para cada nó, resultadosintermediários ordenados porkey, e que são direcionados para um arquivo no sistemade arquivos. Esse conjunto de arquivos deve ser então processados (i.e., agregadosem um único resultado) para gerar o resultado final. A Figura 1.1 ilustra o paradigmaMapReducepara contar palavras em um arquivo grande de texto.

Figura 1.1: Exemplo de um processoMapReducepara contar palavras.

No momento em que umjob é iniciado em um nó, os pares< key,value> sãotransferidos em partes aos nós de mapeamento. Uma nova instância de mapeamento égerada para cada registro de entrada. Esses pares são coletados localmente no nó demapeamento através de uma função em um nó de redução. Após receber os dados, osnós de redução ordenam os pares e geram novos pares do tipo< ki , lista(vi) >, cujoresultado é gravado em um arquivo.

Geralmente, a implementação do paradigmaMapReduceenvolve um sistemade arquivos distribuído, umenginedistribuído que permite a execução de tarefas demapeamento e redução nos nós hospedeiros, e a implementaçãode uma arquiteturade programação (e.g., formato de entrada/saída, funções departicionamento) [19]. Osdetalhes de paralelização, organização de tarefas, acessoa dados concorrentes e controlede falhas são transparentes ao usuário. Portanto, esse nível de abstração permite que ousuário enfoque no algoritmo em si, em vez de, por exemplo, aspectos de controle defalhas e concorrência dos processos.


13

As implementações deMapReducenormalmente incluem uma API simples quedescreve qual parte do processamento é feito em paralelo (etapa demapeamento), equal parte do processamento é feito depois do agrupamento emum nó (etapa deredu-ção). O paradigmaMapReducenão obriga o uso de um modelo de dados específico, oque permite que virtualmente qualquer tipo de dado possa serutilizado [17].

Alguns exemplos de uso deMapReducemais comuns são no contexto dedataanalytics(e.g., Web logs), onde normalmente todos os registros do conjunto de da-dos necessitam serem processados (a leitura dos dados é feito sequencialmente semmuita complexidade no acesso). No entanto, o paradigmaMapReducenão é eficienteem tarefas onde o acesso é feito em subconjuntos dos dados (e.g., sort-merge basedgrouping) [16]. Análises complexas de dados emMapReducesão fornecidas por pro-dutos que seguem enfoques direcionados, como PigLatin [5, 25] que tem desempenhoadequado para agrupamentos e Jaql que tem integração com a plataforma R. Podemosconsiderar que o poder do paradigmaMapReducetem íntima relação com o poder deprocessamento existente em ambientes em nuvem. AmbientesMapReducetêm maiorfacilidade na carga de informações quando comparados com ambientes de SGBD tra-dicionais, pois os dados são armazenados em seu estado original (i.e., sem transforma-ções), enquanto que a transformação dos dados é feita no momento do processamentoda consultas.

Em relação ao contexto de SGBD, o paradigmaMapReduceé considerado poralguns pesquisadores um retrocesso no processamento paralelo de dados [20]. Já osenvolvidos nesse paradigma defendem queMapReducenão é um SGBD. Nos últimosanos, várias comparações foram feitas entreMapReducee SGBD, com alguns casosde sucesso para ambos os lados (por exemplo, Hadoop sendo de 2-50 vezes mais lentoque SGBD paralelos, ganhando somente nas operações de carga[26]). Hadoop é muitocriticado por possuir uma baixa eficiência por nó (em torno de5MB/s): o foco principalé na escalabilidade e tolerância a falhas, em detrimento a eficiência. Um exemplo dedesempenho alcançado pelo Hadoop envolveu o uso de 3.800 nóspara ordenamentode 100TB de dados, o que não levou em conta por exemplo aspectos como gasto deenergia. Já os SGBD paralelos têm seu foco na eficiência explorando opipelinederesultados intermediários entre operações de consulta. Exemplos apresentados em [28]ilustram que a maioria dos processamentos analíticos processam relativamente poucaquantidade de dados, na ordem de Gigabytes, como por exemplo90% dos processosem um cluster Facebook tem a quantidade de dados menor que 100GB. Outro aspectointeressante é que inúmeros algoritmos são muito complexospara serem escaláveis eadaptados com o paradigmaMapReduce, como no caso de algoritmos de aprendizadode máquina que são executados em processamentos analíticos.

Normalmente a entrada para o processamentoMapReduceé um arquivo armaze-nados em blocos contínuos em um sistema de arquivos distribuído, onde as funçõesMap


14

e Reduceprocessam cada arquivo em paralelo. Esse enfoque funciona adequadamenteporque o contexto envolve a leitura sequencial de cada arquivo concorrente em cada nó.No entanto, o acesso a dados contínuos fisicamente não ocorreem diversas situações deprocessamento analítico de dados científicos (existe uma grande limitação e dificuldadeno uso do paradigmaMapReducepara dados científicos). Um exemplo disso é o arma-zenamento de matrizes, que logicamente uma posição linhavs coluna próximas podenão ser da mesma forma em relação ao armazenamento físico. Algumas soluções comoSciHadoop tentam levar em conta ambas as organizações físicas e lógicas [8].

Existem também algumas soluções que propõem o uso integradode SGBD Re-lacional e NoSQL. Em resumo, estas soluções armazenam os dados utilizando arqui-teturas NoSQL, e utilizam o paradigmaMapReducepara processos ETL, por exemplogeração de cubos em produtos Data Warehouse tradicionais. Existem diversas lingua-gens de consulta construídas sobre uma plataforma MapReduce, como Hive [4, 31] ouPigLatin [5, 25]. Essas linguagens possuem limitações paraos programadores quandocomparadas com o processamentoMapReducetradicional, incluindo otimizações vol-tadas para diminuir a transferência de dados pela rede.

1.3. Ferramentas

Os produtos NoSQL possuem várias características comuns entre si (vide Seção 1.2),porém se diferenciam quanto ao modelo de dados utilizados (i.e., os produtos são clas-sificados pela representação dos dados). Atualmente, os principais produtos NoSQLdisponíveis1, são organizados segundo seu modelo de dados a seguir:

• Baseado em Coluna (Column Stores): Hbase, Cassandra, Hypertable, Accu-mulo, Amazon SimpleDB, Cloudata, Cloudera,SciDB, HPCC, Stratosphere;

• Baseado em Documentos (Document Stores): MongoDB, CouchDB,BigCouch,RavenDB, Clusterpoint Server, ThruDB, TerraStore, RaptorDB, JasDB, SisoDB,SDB, SchemaFreeDB, djondb;

• Baseado em Grafos (Graph-Based Stores): Neo4J, Infinite Graph, Sones, In-foGrid, HyperGraphDB, DEX, Trinity, AllegroGraph, BrightStarDB, BigData,Meronymy, OpenLink Virtuoso, VertexDB, FlockDB;

• Baseado em Chave-Valor (Key-Value Stores): Dynamo, Azure Table Storage,Couchbase Server, Riak, Redis, LevelDB, Chordless, GenieDB, Scalaris, TokyoCabinet/Tyrant, GT.M, Scalien, Berkeley DB, Voldemort, Dynomite, KAI, Mem-cacheDB, Faircom C-Tree, HamsterDB, STSdb, Tarantool/Box, Maxtable, Pin-

1listagem obtida em www.nosql-database.org


15

caster, RaptorDB, TIBCO Active Spaces, allegro-C, nessDB,HyperDex, Mne-sia,LightCloud, Hibari, BangDB.

Dentre esses vários produtos NoSQL, a seguir detalhamos os principais.

1.3.1. Apache Hadoop e IBM BigInsights

O projeto Apache Hadoop [3] é atualmente a referência do paradigmaMapReduce. Esteprojeto envolve um conjunto de ferramentas voltadas para o processamento de dados deforma escalável, confiável e distribuída. O conjunto de projetos relacionados ao Hadoopsão ilustrados na Figura 1.2.

Figura 1.2: Conjunto de subprojetos relacionados ao projeto Apache Hadoop.

O Hadoop é constituído de duas camadas muito importantes: a camada de arma-zenamento, Hadoop Distributed File System (HDFS), e a de processamento dos dados,Hadoop MapReduce Framework. Essas duas camadas são minimasrequiridas para ofuncionamento do paradigmaMapReduce.

O produto IBM InfoSphere BigInsights [15] é uma plataforma flexível destinadaao processamento de grandes volumes de dados. Esta plataforma tem como diferenciala integração do Apache Hadoop com configuração automatizadapelo instalador, alémde fornecer um terminal de administração.

1.3.1.1. Apache Hadoop

O Apache Hadoop é umframework MapReduceque facilita o desenvolvimento de apli-cações para o processamento de grande volume de dados de forma distribuída, paralela,e com tolerância a falhas. A ideia principal para o desenvolvimento de um processa-


16

mento do tipo (Job) MapReduceenvolve o particionamento dos dados em partes in-dependentes. Estas partes são processadas por uma função demapeamento de formatotalmente paralela em cada nó doclusterde computadores. Esteframeworkordena assaídas das funções de mapeamento e que servem de entrada paraas funções de redução.Na maioria dos casos, as entradas e saídas desses processo são armazenadas no sistemade arquivos HDFS. O Apache Hadoop também pode organizar a ordem de execução dosprocessos, e monitoramento e re-execução em caso de falhas nas tarefas.

1.3.1.2. Hadoop Distributed File System (HDFS)

HDFS é um sistema de arquivos distribuídos voltado para o processamento de volumede dados na ordem de Terabytes (ou Petabytes). Este sistema também suporta controlede falhas e acesso paralelo, sendo que os arquivos são automaticamente armazenados deforma redundante e transparente em vários nós. Para que qualquer dado seja processadopor um dos produtosHadoop, é preciso que os dados esteja armazenados no sistema dearquivos visualizado pelo ambiente. Isto é, apesar do HDFS ser o mais usual, também épossível utilizar outros sistemas de arquvos, como o NFS. Oscontroles do HDFS fazemcom que em cada nó os dados sejam armazenados em blocos contínuos, o que facilitamuito o acesso aos dados de forma sequencial. Outra importante característica é o nãocacheamento dos arquivos, dado que estes podem chegar a tamanhos extremamentegrandes.

1.3.1.3. Apache Hive

O sistema Apache Hive [4] incorpora ao framework Hadoop funcionalidades dedatawarehouse, i.e., o Hive facilita operações de sumarização e consultasad-hocvoltadaspara análise de grandes volumes de dados. O desenvolvedor pode definir consultasutilizando funçõesMap/Reduceou utilizar a linguagem Hive QL. Esta linguaguem ébaseada em SQL e encapsula o processamentoMapReduce. A organização dos dadospelo Hive é feita pelas seguintes estruturas:

• Databases: usado comonamespacepara resolver conflitos de nomes;

• Table: dados dentro de um mesmo esquema;

• Partition: especifica a divisão dos dados de umaTablepara o armazenamento;

• Bucket: forma de organização de umPartition, i.e., um grupo deBucketformauma partição.


17

1.3.2. Apache CouchDB e BigCouch

O produto Apache CouchDB, implementado em Erlang, é voltadopara trabalhar comdocumentos no padrão JSON. Sua interface de comunicação se dá através do padrãoHTTP, fornecendo acesso no formato de umserviço Webno padrãoRestfule as consul-tas e transformações são feitas com a linguagem Javascript,mas ele pode ser estendido,funcionando por exemplo com outras linguagens descript como CoffeScript e Python.O controle de concorrência é realizada seguindo a politica MVCC (Multi-Version Con-currency Control) e conflitos são resolvidos em nível de aplicação.

Para permitir a escalabilidade horizontal do CouchDB, foi desenvolvido o pro-duto BigCouch que facilita a construção declusterelástico de instancias de CouchDB.Para este curso foram desenvolvidos exemplos utilizando o produto BigCouch.

1.3.3. SciDB

O produto SciDB é voltado para análise de dados em contextos comerciais ou científi-cos, e utiliza um modelo de dados de Vetor Multidimensional.Sua plataforma é voltadapara analise de grande quantidade de dados, sendo escalávelpara execução emclustercomum ou em ambiente de nuvem. Apesar de não utilizar o paradigmaMapReduceestásendo incluído neste Curso para ilustrar um modelo de dados diferenciado.

Seu modelo devetor funciona de forma que um vetor (array) é composto dedimensões e atributos. Um vetor de dimensãon temd1,d2, ...,dn dimensões. O tamanhode uma dimensão é a quantidade de valores ordenados nessa dimensão. Por exemplo,um vetor bidimensional (i, j) pode possuir os valoresi = (1,2, ...,10) e j = (1,2, ...,30),ou seja,i possui 10 atributos ej possui 30 atributos.

Para processamento das informações a arquitetura do SciDB envolve três com-ponentes principais: onó coordenador, o nó de trabalhoe ocatálogo. O nó coordena-dor organiza o processamento e interage diretamente com o cliente que fez a requisição.O nó de trabalhoarmazena os dados (de forma não compartilhada) e faz o processa-mento da consulta. E o nó decatálogoutiliza o SGBD Postgresql para armazenar asinformações sobre ocluster, bem como da distribuição dos dados. Um dos parâmetrosutilizados para distribuição dos dados entre os nós é o denominadochunk, que estabe-lece para cada dimensão a quantidade de registros distribuídos em cada nó.

O SciDB provê duas interfaces de programação, a AQL (Array Query Language)e a AFL (Array Functional Language). A linguagem AFL possui as mesmas funcionali-dades da AFL porem com uma abordagem funcional, além de prover recursos adicionaispara manipulação de metadados e arrays. Para exemplificar o uso do SciDB foi imple-mentado um exemplo com dados ambientais, conforme apresentado no Tópico 1.4.2.


18

1.4. Estudo de Caso

Para este curso foram preparados dois tipos de exemplos e seuuso em produtos NoSQLdiferentes. Dessa forma, o enfoque não eh ser aprofundar em questões de desempenhoou detalhes de administração de cada produto, mas sim demonstrar as funcionalidadese conceitos básicos no uso desses produtos.

1.4.1. Dados de Patentes

De uma forma geral no Brasil as informações contidas no sistema de propriedade indus-trial ainda não têm sido bem utilizadas pela indústria ou pela academia, quer seja paraproteção dos conhecimentos, quer seja como fonte de informação tecnológica.

Trabalhos elaborados por Marmor [22] e pela Organização Mundial da Proprie-dade Intelectual (OMPI) [33] mostram que cerca de dois terços de todas as publicaçõestécnicas são apresentadas somente através do sistema de patentes. Essa característica,por si só, as tornariam imprescindíveis, ou no mínimo desejáveis, no desenvolvimentode qualquer atividade criativa envolvendo as áreas técnicas. Além de fornecer infor-mações técnicas inéditas, o conhecimento dessas informações propicia a eliminação depossíveis coincidências, representando economia de tempoe de recursos financeiros,além de ser fonte de inspiração para novos desenvolvimentos, contudo estudos demons-tram que a utilização do sistema de patentes, ainda é muito pouco conhecida e percebidapelo setor de pesquisa do país [23].

Uma das dificuldades observadas é o custo na obtenção das informações conti-das no sistema de patentes, que claramente tem sido um empecilho para sua utilização,principalmente na fase inicial da pesquisa onde o usuário deuma forma geral não temmuita intimidade com o sistema de informação. Muitos dessesusuários, ainda que te-nham participado dos cursos de busca ora disponíveis, não dominam as técnicas debuscas capazes de assegurar a obtenção das informações corretas que em tese poderiamconter as respostas aos seus problemas. O IC-UFMT desenvolveu em conjunto com aCoordenação de Estudos e Programas do Centro de Disseminação da Informação Tec-nológica do Instituto Nacional de Propriedade Industrial (CEDIN-INPI) a ferramentaINPITec que pretende auxiliar na solução desse problema de uso de bases de patentes,por ser baseado na filosofia de software livre a relevância da ferramenta fundamenta-se na possibilidade da sociedade em geral ser beneficiada comum software gratuitoque utiliza as informações contidas no sistema de Propriedade Industrial para analisarsetores tecnológicos de interesse.

A partir dos dados importados principais bases disponíveis, o sistema gera umgrande número de relatórios e gráficos, automatizando a seleção dos documentos paraposterior análise, que constitui a etapa fundamental no processo de elaboração de estu-dos envolvendo dados de patente.


19

1.4.1.1. Descrição do Estudo de Caso

Os dados utilizados neste trabalho foram da base de patentesdo USPTO, que são for-necidas gratuitamente para download pelo Google Patents, do período de 2005 a 2012.Esses arquivos tem por volta de 500MB e estão no formato XML, portanto foram utili-zados 200GB de dados de patentes como objeto de estudo.

Esses arquivos XML possuem vários patentes juntas e cada patente possui infor-mações importantes como, classificação internacional, título, resumo, números e datasde publicação e depósito e informações adicionais dos depositantes e inventores.Essesdados são suficientes para serem geradas informações que auxiliem no processo de pros-pecção tecnológica que são muito importantes para empresas.

1.4.1.2. Ambiente de Processamento

Para este minicurso, foi utilizada a estrutura do IC-UFMT. Oclusterde Hadoop foi cri-ado com 4 máquinas utilizando o produto IBM BigInsights Basic Edition (isto facilitoumuito a criação e manutenção docluster).

1.4.1.3. Configuração do Ambiente de Programação

Para reprodução dos exemplos de uso do Hadoop são necessários conhecimentos bási-cos da linguagem Java e seu uso na ferramenta Eclipse, bem como a criação de projetosutilizando Maven. Neste curso as seguintes versões foram utilizadas: a JDK 1.6, Maven3.0.4, Hadoop 0.20 no ambiente de desenvolvimento Eclipse Juno.

Para auxiliar na manipulação dos arquivos XML foi utilizadaa biblioteca XS-tream da Codehaus2 que fornece uma maneira simples de fazer um mapeamento XML-Objeto. Também é recomendada a instalação de algumplugin no Eclipse para Maven,neste caso foi usado o M2Eclipse.

1.4.1.4. Implementando um Exemplo de WordCount

Para exemplificar o uso das funçõesMap Reducediretamente noframework, um exem-plo de processamento de contagem de palavras eh apresentado. Nesse contexto de pa-tentes, foi utilizado somente o resumo da patente e fazer a contagem de palavras nomesmo. Os passos utilizados neste exemplo seguem:(1) a implementação de três clas-ses:Map, ReduceeGooglePatentWordCount. Esta ultima realiza a preparação dos dados

2http://xstream.codehaus.org


20

e faz a chamada das outras duas classes;(2) gerar um arquivo.jar, que empacota todoo código construído, e implantá-lo no ambiente Hadoop.

Devemos escrever duas classes que estendam respectivamente das seguintesclasses:Mapper e Reducer. Essas classes são genéricas e devem ser parametrizadascom os tipos de entradas e saídas das funções deMap e Reduce, sendo que esses pa-râmetros devem implementar a interfaceWritable (o Hadoop já fornece alguns tiposbásicos que seguem essa interface).

1 p u b l i c s t a t i c c l a s s Map ex t en d s Mapper <LongWr i tab le , Text , Text , I n t W r i t a b l e > {2 p r i v a t e Tex t word = new Text ( ) ;3 p r i v a t e f i n a l s t a t i c I n t W r i t a b l e one = new I n t W r i t a b l e ( 1 );45 p u b l i c vo id map ( LongWr i tab le key , Tex t va lue , Contex t c o nt e x t )6 th rows j av a . i o . IOExcept ion , I n t e r r u p t e d E x c e p t i o n , IOExcept ion {7 S t r i n g x m l S t r i n g = htmlTagClean ( v a l u e . t o S t r i n g ( ) ) ;8 i f ( x m l S t r i n g . t r i m ( ) . l e n g t h ( ) > 0) {9 t r y {

10 SAXBui lder sax = new SAXBui lder ( ) ;11 Document doc = sax . b u i l d ( new S t r i n g Read e r ( x m l S t r i n g ) );12 Element r o o t = doc . getRootElement ( ) ;13 S t r i n g a b s t r a c t T e x t = r o o t . g e t C h i l d ( " a b s t r a c t " ) . g e t Tex t ( ) ;14 S t r i n g T o k e n i z e r t o k e n i z e r = new S t r i n g T o k e n i z e r ( a b s t ra c t T e x t ) ;15 wh i le ( t o k e n i z e r . hasMoreTokens ( ) ) {16 word . s e t ( t o k e n i z e r . nex tToken ( ) ) ;17 c o n t e x t . w r i t e ( word , one ) ; }18 } ca t ch ( JDOMException e ) {19 e . p r i n t S t a c k T r a c e ( ) ; }20 c o n t e x t . w r i t e ( word , one ) ; } } }

Figura 1.3: ClasseMappara contagem de palavras contidas no resumo das patentes.

A classeMap, ilustrada na Figura 1.3, estendeu deMappercom os parâmetrosque indicam a entrada e a saída da funçãoMap, que no caso a entrada vai ser umaentidade XML e vamos ter como saída uma chave com a palavra e o numero 1 paracada palavra que depois vai ser somada na função deReduce. No contexto usado, foinecessário extrair as marcaçõeshtml contidas no resumo da patente e separar todas aspalavras no texto para serem contadas.

1 p u b l i c s t a t i c c l a s s Reduce ex t en d s Reducer <Text , I n t W r i ta b l e , Text , I n t W r i t a b l e > {2 p u b l i c vo id r ed u ce ( Tex t key , I t e r a b l e v a l ues ,3 Contex t c o n t e x t ) th rows IOExcept ion , I n t e r r u p t e d E x c e p ti o n {4 i n t sum = 0 ;5 f o r ( I n t W r i t a b l e v a l : v a l u es ) { sum += v a l . g e t ( ) ; }6 c o n t e x t . w r i t e ( key , new I n t W r i t a b l e ( sum ) ) ; } }

Figura 1.4: ClasseReducepara contagem de palavras contidas no resumo das patentes.

A classeReduce, que estende deReducer, parametrizaas saídas da funçãoMap(i.e., uma palavra seguida de um número) e os tipos da saída dométodoReducequeserão os mesmo tipos, mas vão representar a contagem total das palavras. A funçãoé bem simples, como já foi visto, teremos uma lista de númerosque foram emitidosna função de map para cada palavra, então nosso trabalho aquié apenas agregar essesvalores, neste caso apenas fazer a soma dos valores.


21

Outra questão importante é que os dados originais precisam ser ajustados, poiso Hadoop por padrão particiona os arquivos a serem processados por linha do arquivo.Esse comportamento obviamente não funciona com arquivos XML pois precisamos quecada funçãoMap receba uma entidade XML para que ela consiga extrair informaçõesde cada patente. Para tal vamos utilizar um classe que estende InputFormat, ou seja,ela determina qual é o formato de entrada dos dados e como ele deve ser particionado.O projeto Apache Mahout já desenvolveu uma classeXMLInputFormat3 que faz exata-mente o que desejamos, sendo necessária apenas que seja informado quais são asstringsde inicio e fim da entidade XML.

Para finalizar, vamos construir a parte final doJob, que determina todas as con-figurações iniciais, as delimitações do XML, as entradas e saídas doJob. Os caminhosdas entradas e saídas vão ser passados como parâmetro na execução doJob.Segue oexemplo de tal configuração.

1 p u b l i c s t a t i c c l a s s Goog lePaten tWordCount{2 p u b l i c s t a t i c vo id main ( S t r i n g [ ] a r g s ) th rows Ex cep t i o n {3 C o n f i g u r a t i o n conf = new C o n f i g u r a t i o n ( ) ;45 conf . s e t ( " x m l i n p u t . s t a r t " , "<us−p a t en t−a p p l i c a t i o n " ) ;6 con f . s e t ( " x m l i n p u t . end " , " </ us−p a t en t−a p p l i c a t i o n > " ) ;78 Job j o b = new Job ( conf , " Google P a t e n t Word Count " ) ;9

10 j o b . se t O u t p u t K ey C l ass ( Tex t . c l a s s ) ;11 j o b . se t O u t p u t V a l u eC l a ss ( I n t W r i t a b l e . c l a s s ) ;1213 j o b . s e t J a r B y C l a s s ( Goog lePaten tWordCount . c l a s s ) ;14 j o b . se t Map p e r C l ass (Map . c l a s s ) ;15 j o b . se t Red u ce r C l as s ( Reduce . c l a s s ) ;1617 j o b . s e t I n p u t F o r m a t C l a s s ( XmlInputFormat . c l a s s ) ;18 j o b . se t O u t p u t F o r m a t C l ass ( Tex tOutpu tFormat . c l a s s ) ;1920 F i l e I n p u t F o r m a t . s e t I n p u t P a t h s ( job , new Path ( a r g s [ 1 ]) ) ;21 F i l eO u t p u t F o r m a t . s e t O u t p u t P a t h ( job , new Path ( a r g s [ 2] ) ) ;2223 j o b . w a i t F o r Co m pl e t io n ( t r u e ) ; } }

Figura 1.5: Classe que prepara os dados e chamadas às funçõesMap/Reduce.

Para gerar o arquivojar executável dentro do Hadoop, iremos utilizar o Mavenpara darbuild no nosso projeto. Para isso temos que descrever como será esse build,para que ele construa ojar contendo aslibs que nós utilizamos no projeto. Vamosutilizar o seguinte XML de configuração debuild. Após essa fase é preciso adicionarno arquivopom.xml o caminho para o arquivo, ilustrado na Figura 1.6 (job.xml), eas configurações debuild. Segue o conteúdo que deve ser adicionado aopom.xml.

Agora para gerar o jar é muito simples. Pelo terminal, na pasta do projeto, épreciso executar os comandos:mvncleane mvnpackage, o que gera na pastatarget doprojeto um arquivojar com onomedopro jeto+verso+ job. Agora podemos submeter

3https://github.com/apache/mahout/blob/ad84344e4055b1e6adff5779339a33fa29e1265d/examples/src/main/java/org/apache/mahout/classifier/bayes/XmlInputFormat.java


22

1 <assembly2 xmlns=" h t t p : / / maven . apache . org / p l u g i n s / maven−assembly−p l u g i n / assembly / 1 . 1 . 0 "3 xmlns : x s i =" h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema− i n s t a n c e "4 x s i : schemaLocat ion =" h t t p : / / maven . apache . org / p l u g i ns / maven−assembly p l u g i n / assembly / 1 . 1 . 05 h t t p : / / maven . apache . org / xsd / assembly−1 .1 .0 . xsd ">6 < id > job </ id >7 < formats >8 < format > j a r < / fo rmat >9 </ fo rmats >

10 f a l s e 11 <dependencySets >12 <dependencySet >13 <unpack > f a l s e </ unpack >14 <scope > run t ime </ scope >15 < o u t p u t D i r e c t o r y > l i b < / o u t p u t D i r e c t o r y >16 <exc ludes >17 <exc lude >${ a r t i f a c t . g roup Id } : $ { a r t i f a c t . a r t i f a c t Id } </ exc lude >18 </ exc ludes >19 </ dependencySet >20 <dependencySet >21 <unpack > f a l s e </ unpack >22 <scope >system </ scope >23 < o u t p u t D i r e c t o r y > l i b < / o u t p u t D i r e c t o r y >24 <exc ludes >25 <exc lude >${ a r t i f a c t . g roup Id } : $ { a r t i f a c t . a r t i f a c t Id } </ exc lude >26 </ exc ludes >27 </ dependencySet >28 </ dependencySets >29 < f i l e S e t s >30 < f i l e S e t >31 < d i r e c t o r y >\ ${ b a s e d i r } / t a r g e t / c l a s s e s </ d i r e c t o r y >32 < o u t p u t D i r e c t o r y >/ < / o u t p u t D i r e c t o r y >33 <exc ludes >34 <exc lude >∗ . j a r < / exc lude >35 </ exc ludes >36 </ f i l e S e t >37 </ f i l e S e t s >38 </ assembly >

Figura 1.6: Arquivojob.xml contendo a configuração do Maven para inserir as clas-ses geradas no Hadoop.

1 2 3 4 < a r t i f a c t I d >maven−assembly−p l u g i n </ a r t i f a c t I d >5 <v e r s i o n >2 .2 .1 < / v e r s i o n >6 < c o n f i g u r a t i o n >7 < d e s c r i p t o r s >8 < d e s c r i p t o r > s r c / main / j av a / j o b . xml < / d e s c r i p t o r >9 </ d e s c r i p t o r s >

10 < a r ch i v e >11 < m an i f es t >12 <mainClass >br . ufmt . p a t e n t . wordcount . j o b . GooglePatentWordCount < / mainClass >13 </ m an i f es t > </ a r ch i v e > </ c o n f i g u r a t i o n >14 < ex ecu t i o n s >15 < ex ecu t i o n >16 < id >make−assembly </ id >17 <phase >package </ phase >18 <goa ls >19 <goa l > s i n g l e </ goa l >20 </ goa ls > </ ex ecu t i o n > </ ex ecu t i o n s > 

Figura 1.7: Conteúdo do arquivopom.xml que referenciajob.xml.

o arquivo jar para que nossojob possa ser executado, para isso é preciso copiar ojarpara a máquina que é oNamenodeno clustere guardar o destino do arquivo, pois omesmo deve ser chamado para execução do processamento.


23

Para que o Hadoop possa executar ojob é preciso utilizar a interface fornecidapela ferramenta da IBM, que em uma instalação padrão vai responder pela porta 8080do Namenode. Nessa interface, na abaJobs, é possível submeter ojob clicando nobotão "CreateJarJob. . . ".

1.4.1.5. Utilizando o Hadoop como Ferramenta de ETL

Aqui tratamos o seguinte problema: Como executar consultasnos dados de patentes ecomo armazenar estes dados que suporte consultas eficientes. Para a resolução desteproblema vamos utilizar o Apache Hive. O Hive consegue utilizar a estrutura do Ha-doop para armazenar os dados e abstrai oMapReduceem forma de consulta SQL. Nomomento do processamento a consulta SQL é transformada em umjob MapReducerque é executado nocluster.

Mas temos que adequar nossos dados a estrutura que ele fornece para trabalhar.O formato mais simples é um formato de arquivo em que cada registro se encontra euma linha do arquivo e os campos estão delimitados por algum caractere especial. Issonos lembra o formato de um arquivo CSV, então nosso trabalho aqui é transformar osdados XML em um arquivo com formatação CSV e importar os dadospara dentro doHive. Para tal tarefa vamos aproveitar a estrutura do Hadooppara trabalhar com umagrande quantidade de dados e de forma paralela.

Nossa funçãoMapvai ter como objetivo converter as entidades XML em objetosJava e emitir para cada patente (usando como chave o atributodatadepublicao), criartodas as representações do objeto no formato CSV. Neste exemplo é criada uma tabelaúnica que contem todas as combinações de classificaçõesvs. depositantes, conforme ocódigo ilustrado na Figura 1.8.

1 p u b l i c c l a s s Goog lePaten tMapper ex t en d s Mapper <LongWr itab le , Text , Text , Text > {2 p r i v a t e Tex t pubNumber = new Text ( ) ;3 p r i v a t e Tex t p p S t r i n g = new Text ( ) ;45 p u b l i c vo id map ( LongWr i tab le key , Tex t va lue , Contex t c o nt e x t )6 th rows j av a . i o . IOExcept ion , I n t e r r u p t e d E x c e p t i o n {7 S t r i n g x m l S t r i n g = v a l u e . t o S t r i n g ( ) ;8 i f ( x m l S t r i n g . t r i m ( ) . l e n g t h ( ) > 0) {9 P r o j e c t P a t e n t p a t e n t = G o o g l e P a t e n t T o P r o j e c t P a t e n t U t il . co n v e r t G o o g l eP a t en t ( x m l S t r i n g ) ;

10 i f ( p a t e n t != n u l l ) {11 f o r ( C l a s s i f i c a t i o n i p c : p a t e n t . g e t C l a s s i f i c a t i o n ( ) ){12 f o r ( A p p l i can t app : p a t e n t . g e t A p p l i c a n t s ( ) ) {13 p a t e n t . s e t I p c S e l e c t ( i p c ) ;14 p a t e n t . s e t A p p l i c a n t S e l e c t ( app ) ;15 pubNumber . s e t ( p a t e n t . g e t P u b l i ca t i o n N u m b er ( ) ) ;16 p p S t r i n g . s e t ( p a t e n t . t o S t r i n g ( ) ) ;17 c o n t e x t . w r i t e ( pubNumber , p p S t r i n g ) ; } } } } }

Figura 1.8: Preparação dos dados pela funçãoMap a serem inseridos no Hive.

Explicando um pouco o código: Recebemos uma entidade em XML,converte-


24

mos para um objeto java contendo os atributos de interesse, usando a bibliotecaXStream,e depois geramos todas as combinações com as classificações edepositantes dentro daspatentes para a funçãoReduce. Agora o código da funçãoReduceé bem simples. Comonão temos nenhuma agregação a fazer, apenas iteramos pelos valores gerados para cadachave e passamos para a saída do Job.

1 p u b l i c c l a s s G o o g l eP a t en tReduce r ex t en d s Reducer <Text ,Text , Text , Text > {2 p u b l i c vo id r ed u ce ( Tex t key , I t e r a b l e <Text > v a l u es , Contex t c o n t e x t )3 th rows IOExcept ion , I n t e r r u p t e d E x c e p t i o n {4 f o r ( Tex t v a l : v a l u es ) {5 c o n t e x t . w r i t e ( key , v a l ) ; } } }

Figura 1.9: Preparação dos dados pela funçãoReducea serem inseridos no Hive.

1.4.1.6. Utilizando o CouchDB para Processar Patentes

Para a construção do exemplo de uso do CouchDB com informações de patentes foramrealizados os seguintes passos:

1. Transformação do formato XML para o formato JSON;

2. Inserção dos dados no CouchDB;

3. Construção de consulta que com o uso de agregações faz a contagem de patentese as organiza na hierarquia definida pelo padrão da classificação internacional.

O CouchDB manipula as informações no formato JSON, assim é preciso fazer atransformação dos dados das patentes do formato XML para serem enviados para o ar-mazenamento. Apesar dessa transformação ser relativamente simples o maior problemaé trabalhar com arquivos XML grandes (500MB), que acabam porconsumir muito me-mória durante seu processamento.

Para este exemplo foi construído umscript em NodeJS que ler os documentosXML, converter cada entidade de patente para o formato JSON eapós isso enviar parao CouchDB. Foi escolhida essa linguagem por possuir uma grande variedade de biblio-tecas desenvolvidas pela comunidade e que vão suprir as necessidades para a transfor-mação. As ferramentas utilizadas para este exemplo foram:

1. NodeJS para implementação;

2. Biblioteca Cradle para transformação4;

4Endereço: https://github.com/cloudhead/cradle


25

3. Biblioteca Node-BufferedReader para carregamento dos arquivos5;

4. Biblioteca Node-xml2js6.

A Figura 1.10 apresenta o código em NodeJS que faz a transformação de XMLpara JSON e insere em bloco de 100 patentes no CouchDB. Como pode ser visto,o valor do identificador padrão utilizado pelo CouchDB foi substituído pelo camponumerodepublicacaopara garantir que não exista documentos duplicados dentro dobanco, já que o CouchDB não tem restrições de unicidades paraos campos além doid.

1 v a r xml2 js = r e q u i r e ( ’ xml2js ’ ) ;2 v a r p a r s e r = new xml2 js . P a r s e r ( ) ;3 / / usa ’ p a t en t e ’ que f o i l i d a p e l o Bu f f e r ed Read e r no cod igoa n t e r i o r4 p a r s e r . p a r s e S t r i n g ( p a t en t e , f u n c t i o n ( e r r , r e s u l t ) {5 i f ( e r r ) {6 co n so l e . l o g ( ’ Er ro no p a r se de XML−> JSON ’ ) ;7 co n so l e . l o g ( e r r ) ;8 } e l s e {9 / / Modi f icamos a i d da p a t e n t e

10 v a r docID = r e s u l t [ ’ us−b i b l i o g r a p h i c−data−a p p l i c a t i o n ’ ] [ ’ p u b l i c a t i o n−r e f e r e n c e ’ ] [ ’ document−id ’ ] ;11 v a r pub = docID [ ’ count ry ’ ] + docID [ ’ doc−number ’ ] + ’ ’ + docID [ ’ da te ’ ] ;12 r e s u l t [ ’ _ id ’ ] = pub ;13 p a t e n t e s . push ( r e s u l t ) ;14 i f ( p a t e n t e s . l e n g t h >= 100 ) {15 v a r t em p P a t en t es = p a t e n t e s ;16 p a t e n t e s = [ ] ;17 db . save ( t em p P a t en t es , f u n c t i o n ( e r r , r e s ) {18 i f ( e r r ) {19 co n so l e . l o g ( ’ Er ro ao s a l v a r no CouchDB ’ ) ;20 co n so l e . l o g ( e r r ) ;21 } e l s e { t em p P a t en t es = [ ] ; } } ) ; } } } ) ;22 p a t e n t e = ’ ’ ;

Figura 1.10: Conversão e inserção em lote no CouchDB das patentes no formato JSON.

A forma escolhida para gerar um exemplo de estatística foi a criação de umavisão no CouchDB que usa agregação para mostrar a contagem donumero de patentesdentro da hierarquia estabelecida pela classificação internacional. Uma visão é guar-dada internamente como umdesigndocumente é executada no momento em que é feitaa consulta à visão. Para construção da visão foram criadas asfunçõesMap e Reduce.Na funçãoMap, ilustrada na Figura 1.11, são organizadas os campos da classificação,de forma que recebe apenas um parâmetro, que é o documento em que está sendo exe-cutado. Partindo desse documento os dados são extraídos e com a funçãoEmit, sãodefinidos quais dados vão ser passados para a função deReduce. A funçãoEmit recebedois parâmetros, umachavee umvalor, podendo ser chamada mais de uma vez, comono exemplo estão sendo enviadas todas as classificações dentro de uma patente para afunção deReduce(se tiver mais de uma classificação). Outro ponto a ser observado éque as chaves e os valores passados para essas funções podem ser listas, no exemplo asclassificações são separadas nos seus campos principais.

5Endereço: https://github.com/Gagle/Node-BufferedReader6Endereço: https://github.com/Leonidas-from-XIV/node-xml2js


26

1 f u n c t i o n ( doc ) {2 v a r i p c r s = doc [ ’ us−b i b l i o g r a p h i c−data−a p p l i c a t i o n ’ ] [ ’ c l a s s i f i c a t i o n s−i p c r ’ ] [ ’ c l a s s i f i c a t i o n−i p c r ’ ] ;3 / / V e r i f i c a se e s t e o b j e t o eh um Ar ray4 i f ( O b j ec t . p r o t o t y p e . t o S t r i n g . c a l l ( i p c r s ) == ’ [ o b j e c tAr ray ] ’ ) {5 f o r ( v a r i i n i p c r s ) {6 v a r s e c t i o n = i p c r s [ i ] [ ’ s e c t i o n ’ ] ;7 v a r c l a z z = i p c r s [ i ] [ ’ c l a s s ’ ] ;8 v a r s u b c l a s s = i p c r s [ i ] [ ’ su b c l ass ’ ] ;9 v a r group = i p c r s [ i ] [ ’ main−group ’ ] ;

10 v a r subgroup = i p c r s [ i ] [ ’ subgroup ’ ] ;11 v a r i p c = s e c t i o n + c l a z z + s u b c l a s s + group + subgroup ;12 emi t ( [ s e c t i o n , c l azz , su b c l ass , group , subgroup , i p c ] ,1 ) ; }13 / / Senao t r a t a como um o b j e t o s i m p l es14 } e l s e {15 v a r s e c t i o n = i p c r s [ ’ s e c t i o n ’ ] ;16 v a r c l a z z = i p c r s [ ’ c l a s s ’ ] ;17 v a r s u b c l a s s = i p c r s [ ’ su b c l ass ’ ] ;18 v a r group = i p c r s [ ’ main−group ’ ] ;19 v a r subgroup = i p c r s [ ’ subgroup ’ ] ;20 v a r i p c = s e c t i o n + c l a z z + s u b c l a s s + group + subgroup ;21 emi t ( [ s e c t i o n , c l azz , su b c l ass , group , subgroup , i p c ] ,1 ) ; } }

Figura 1.11: FunçãoMappara a visão por classificação das patentes.

A funçãoReduce, ilustrada na Figura 1.12, aplica uma função de agregação naschaves e valores enviados pela funçãoMap, que nesse caso é apenas a soma dos valorespara cada chave, obtendo assim a contagem de classificações.

1 f u n c t i o n ( keys , v a l u es , r e r e d u c e ) { r e t u r n sum ( v a l u es ) ; }

Figura 1.12: FunçãoReducepara a visão por classificação das patentes.

Como pode ser observado, a funçãoReducerecebe 3 parâmetros:keys, valueserereduce. A chave recebida pela função pode vir no formato de listas, já que é possívelfazer isso na funçãoMap. A variávelvaluescorresponde a todos os valores associadoscom uma determinada chave. Já a variávelrereduceé um booleano que diz se essafunçãoReducejá foi executa em uma mesma chave. Isto deve ser levado em conside-ração em determinados casos nos quais a função de agregação não deve ser aplicada damesma forma se a funçãoReducepassar duas vezes pela mesma chave.

1.4.2. Dados Micrometeorológicos

Os dados obtidos através de simulações científicas, experimentos e observações emlarga escala, facilmente chegam a terabytes, devido ao aumento do número de transis-tores dentro dos chip’s, conhecido como a lei de Moore e o barateamento dos mesmos.Entre esses equipamentos encontra-se aqueles que são voltados para medir dados micro-meteorológicos, sendo esses coletados através de vários sensores efetuando medições demúltiplas variáveis.

Assim, a quantidade de dados é muito significativa, pois vários sensores podemmedir várias variáveis micrometeorológicas em um tempo curto, por exemplo, medira temperatura entre 10 e 10 segundos, assim a quantidade de dados cresce 3153600


27

por ano e por variável medida. Após a obtenção dos dados alguns cálculos realiza-dos sobre os mesmos pode demorar muito tempo para seu processamento, no contextodo Programa de Pós-Graduação em Física Ambiental (PGPFA-UFMT), existem várioscálculos que demandam esse tempo, por exemplo, o cálculo para obter dimensão frac-tal, o expoente de Lyapunov, a análise de recorrência, entreoutros. Para otimizar essetempo pode-se utilizar algumas soluções com enfoque em paralelismo, comoclustersde computadores, ou GPU (Graphics Processing Unit).

Apesar deste Curso não abordar esses cálculos complexos, a ideia é demonstraro uso do produto SciDB para armazenamento e processamento devariáveis microme-teorológicas. Dessa forma, o exemplo aqui apresentado envolve variáveis (evaporação,insolação, precipitação, temperatura máxima, temperatura minima, umidade relativado ar e velocidade do vento) captadas em 4 locais diferentes no Estado de MT entreos anos de 1985 a 2010. Os seguintes passos foram necessáriospara construir o exem-plo: (1): conversão dos dados do formato CSV para o formato SciDB;(2): inserçãodos dados na base SciDB em forma de vetor unidimensional;(3): conversão do vetorunidimensional para vetores multidimensionais, ou seja, conversão de atributos para di-mensões. Para inserção de dados o SciDB fornece o aplicativocsv2scidbque convertedo formato CSV (separado por “,”) para o formato de leitura doSciDB, assim, depoisde convertidos usa-se a funçãoLoad (em AFL) para inserção dos dados na base.

1.5. Considerações Finais

Este minicurso apresentou os conceitos, linguagens e ferramentas das principais tecno-logias NoSQL. Também foi apresentado a aplicação de produtos NoSQL em dois estu-dos de casos, como os produtos Hadoop, Hive, BigCouch, e SciDB. Podemos observarque, pela grande quantidade de produtos NoSQL disponíveis no mercado, o desenvol-vedor possui uma grande variedade de produtos para a escolha. Esta vantagem podeas vezes ser um problema, principalmente se o desenvolvedornão tiver um conheci-mento profundo dos diversos produtos. Outro importante impacto para a atividade dodesenvolvedor é a variedade de linguagens envolvidas, ondecada produto possui sualinguagem específica, seu formato de entrada, seus comandos, entre outras característi-cas. Com isso, vemos que manter um ambiente com vários produtos é a uma tendênciafrequentemente praticada nos sistemas atuais.

1.6. Descrição dos Palestrantes

Marcos Rodrigues Vieira: possui graduação em Engenharia de Computação pela Univ.Federal de São Carlos (UFSCar) (2001), mestrado em Ciênciasda Computação e Ma-temática Computacional pela Univ. de São Paulo (USP), São Carlos (2004), e Douto-rado em Ciências da Computação pela University of California, Riverside (UCR), EUA(2011). Atualmente é pesquisador da IBM Research/Brazil, ecolaborador do Computer


28

Science Department da UCR e do Instituto de Ciências Matemáticas e de Computação(USP, São Carlos).

Josiel Maimone de Figueiredo: possui graduação em Engenharia de Compu-tação pela UFSCar (1998), mestrado em Ciência da Computaçãopela UFSCar (2000)e doutorado em Ciências da Computação e Matemática Computacional, com ênfase emBanco de Dados, pela USP, São Carlos (2005). Atualmente é professor adjunto do Ins-tituto de Computação da Univ. Federal de Mato Grosso (UFMT),sendo credenciado noPrograma de Pós-Graduação em Física Ambiental do Institutode Física da UFMT.

Gustavo Liberatti : aluno de graduação do curso de Bacharelado em Ciênciada Computação pela UFMT desde 2008, onde atua principalmente nos seguintes temas:processamento de imagens, geo-referenciamento, serviçosWeb e Linux. É bolsista deIniciação Científica em projeto de tratamento textual de dados.

Alvaro Fellipe Mendes Viebrantz: aluno de graduação do curso de Bachare-lado em Ciência da Computação pela UFMT desde 2009. Atualmente é bolsista deIniciação em Desenvolvimento Tecnológico e Inovação com atuação em sistemas demanipulação de informações de patentes.

Referências[1] D. Agrawal, S. Das, and A. El Abbadi. Big data and cloud computing: New wine or just new

bottles?Proc. VLDB Endow., 3(2):1647–1648, 2010.

[2] D. Agrawal, S. Das, and A. El Abbadi. Big data and cloud computing: current state and futureopportunities. InEDBT, page 530, 2011.

[3] Apache Hadoop. http://hadoop.apache.org, 2012.

[4] Apache Hive. hive.apache.org, 2012.

[5] Apache Pig. http://pig.apache.org, 2012.

[6] D. Bermbach and S. Tai. Eventual consistency: How soon iseventual? An evaluation of AmazonS3’s consistency behavior. InWorkshop on Middleware for Service Oriented Computing, 2011.

[7] E. A. Brewer. Towards robust distributed systems (abstract). InSymp. on Principles of DistributedComputing, PODC, page 7, New York, NY, USA, 2000.

[8] J. B. Buck, N. Watkins, J. LeFevre, K. Ioannidou, C. Maltzahn, N. Polyzotis, and S. Brandt. SciHa-doop: Array-Based Query Processing in Hadoop. InSC, page 66, 2011.

[9] R. Cattell. Scalable SQL and NoSQL data stores.ACM SIGMOD Record, 39(4):12, May 2011.

[10] S. Chaudhuri. What next? A Half-Dozen Data Management Research Goals for Big Data and theCloud. InPODS, page 1, 2012.

[11] I. Clarke. A distributed decentralised information storage and retrieval system. InPhD Thesis.University of Edinburgh, 1999.

[12] A. Cuzzocrea, I.-y. Song, and K. C. Davis. Analytics over large-scale multidimensional data: thebig data revolution! InInt’l Workshop on Data Warehousing and OLAP (DOLAP), page 101, 2011.


29

[13] J. Dean and S. Ghemawat. MapReduce: Simplified Data Processing on Large Clusters. InSixthSymposium on Operating System Design and Implementation (OSDI), 2004.

[14] D. Fisher, R. DeLine, M. Czerwinski, and S. Drucker. Interactions with Big Data Analytics.Inte-ractions, 19(3):50, May 2012.

[15] IBM InfoSphere BigInsights. www.ibm.com/software/data/infosphere/biginsights, 2012.

[16] M.-y. Iu and W. Zwaenepoel. HadoopToSQL: a mapReduce query optimizer. InEuroSys, 2010.

[17] S. Khatchadourian, M. Consens, and J. Simeon. Web data processing on the cloud.Conf. of theCenter for Advanced Studies on Collaborative Research (CASCON), page 356, 2010.

[18] I. Konstantinou, E. Angelou, D. Tsoumakos, C. Boumpouka, N. Koziris, and S. Sioutas. TIRA-MOLA: Elastic NoSQL Provisioning Through a Cloud Management Platform. InSIGMOD, 2012.

[19] V. Kumar, H. Andrade, B. Gedik, and K.-l. Wu. DEDUCE: at the intersection of MapReduce andstream processing. InEDBT, page 657, 2010.

[20] K.-H. Lee, Y.-j. Lee, H. Choi, Y. D. Chung, and B. Moon. Parallel data processing with MapReduce:a survey.ACM SIGMOD Record, 40(4):11, Jan. 2012.

[21] D. B. Lomet. Data management on cloud computing platforms. In S. P. Beng Chin Ooi, editor,IEEE Data Engineering Bulletin, volume 32, pages 1–82. 2009.

[22] A. Marmor, W. Lawson, and J. Terapane. The Technology Assessment and Forecast Program of theUnited States Patent and Trademark Office.World Patent Information, 1(1):15–23, 1979.

[23] J. S. Nunes and L. Goulart. Universidades Brasileiras -Utilização do Sistema de Patentes de 2000a 2004. Technical report, INPI/CEDIN/DIESPRO, 2007.

[24] A. Okcan and M. Riedewald. Processing theta-joins using MapReduce.SIGMOD, page 949, 2011.

[25] C. Olston, B. Reed, U. Srivastava, R. Kumar, and A. Tomkins. Pig latin: a not-so-foreign languagefor data processing. InSIGMOD, page 1099, 2008.

[26] A. Pavlo, E. Paulson, A. Rasin, D. J. Abadi, D. J. DeWitt,S. Madden, and M. Stonebraker. Acomparison of approaches to large-scale data analysis.SIGMOD, page 165, 2009.

[27] J. C. Ralph Kimball.DW ETL toolkitThe Data Warehouse ETL Toolkit: Practical Techniques forExtracting, Cleaning, Conforming, and Delivering Data. John Wiley, 2004.

[28] A. Rowstron, D. Narayanan, A. Donnelly, G. O’Shea, and A. Douglas. Nobody ever got fired forusing Hadoop on a cluster.Int’l Workshop on Hot Topics in Cloud Data Processing, 2012.

[29] M. Stonebraker. In Search of Database Consistency.Commun. ACM, 53(10):8, Oct. 2010.

[30] M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos, N. Hachem, and P. Helland. The End ofan Architectural Era (It’s Time for a Complete Rewrite).VLDB, pages 1150–1160, 2007.

[31] A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Zhang, S. Antony, H. Liu, R. Murthy,S. Anthony, P. Wyckoff, F. Data, and I. Team. Hive - a petabytescale data warehouse using Hadoop.In ICDE, pages 996–1005, 2010.

[32] W. Vogels. Eventually Consistent.Queue, 6(6):14, Oct. 2008.

[33] WIPO. Using Patent Information for the Benefit of Your Small and Medium-sized Enterprise, 2012.


30

Minicurso

2Inclusão de Consultas por Similaridade emSGBDs: Teoria e Prática

Daniel dos Santos Kaster1 and Caetano Traina Junior2

1Departamento de Computação (DC)Universidade Estadual de Londrina (UEL){[email protected]}

2Instituto de Ciências Matemáticas e de Computação (ICMC)Universidade de São Paulo (USP){[email protected]}

Abstract

The amount of complex data (images, videos, temporal series and others) is growing fast.Complex data are suitable to be retrieved by similarity, which means to define queries ac-cording to a given similarity criterion. Existing DBMSs do not support similarity queries,demanding implementing new resources to be employed in applications over complexdata. This chapter presents the main similarity queries found in the literature, as well asthe most widely used algorithms and indexing structures to execute them, and case studiesof implementing support for the inclusion of similarity queries in off-the-shelf DBMSs.

Resumo

A quantidade de dados complexos (imagens, vídeos, séries temporais e outros) tem cres-cido rapidamente. Dados complexos são adequados para serem recuperados por simila-ridade, o que significa definir consultas de acordo com um dado critério de similaridade.Os SGBDs existentes não possuem suporte a consultas por similaridade, demandando aimplementação de novos recursos para que possam ser usados em aplicações sobre dadoscomplexos. Este capítulo apresenta as principais consultas por similaridade encontradasna literatura, bem como os algoritmos e estruturas de indexação mais difundidos para suaexecução, e estudos de caso de implementação de recursos para a inclusão de consultaspor similaridade em SGBDs de mercado.


31

1.1. IntroduçãoDados complexos, tais como imagens, vídeos, séries temporais e outros, trazem uma de-manda inerente por recursos de recuperação de dados que os Sistemas de Gerenciamentode Bancos de Dados (SGBDs) tradicionalmente não provêm. Isto se deve, principalmente,ao fato de que a maioria dos domínios de dados complexos não definem uma relação deordem total entre elementos. Assim, os operadores de comparação relacionais (‘<’, ‘≤’,‘>’ e ‘≥’) não podem ser usados e os operadores ‘=’ e ‘6=’ são praticamente inúteis. Paradados complexos é mais natural realizar consultas por similaridade, definindo relaçõesde similaridade entre pares de elementos, que consideram as características particularesde cada domínio de aplicação. Estas consultas retornam os elementos do conjunto de da-dos que atendem a certos critérios de similaridade em relação a um ou mais elementos dereferência, também chamados elementos de consulta.

A maioria das alternativas desenvolvidas incluir suporte à consultas por similari-dade em SGBDs são fracamente acopladas ao motor dos gerenciadores, o que limita oaproveitamento dos recursos oferecidos nativamente pelos SGBDs. Uma alternativa maiseficiente consiste em embutir as funcionalidades necessárias à recuperação por similari-dade em um subsistema especializado acessível ao processador de consultas do SGBD.Este subsistema especializado capacita o SGBD a executar consultas por similaridadeintegradas às demais operações fornecidas. Outra alternativa consiste em estender a lin-guagem SQL para incluir operações por similaridade e implementar mecanismos que su-portem as extensões propostas.

Este capítulo introduz o conceito de avaliação de similaridade entre dados comple-xos (Seção 1.2) e apresenta os principais tipos de consultas por similaridade (Seção 1.3),suas representações algébricas (Seção 1.4) e os algoritmos e estruturas de indexação maisdifundidos para executá-las (Seção 1.5). Apresenta, também, aspectos de implementaçãopara o desenvolvimento e uso de índices para dados complexos (Seção 1.6) e estudos decaso de inclusão de consultas por similaridade em SGBDs (seções 1.7 e 1.8). Na con-clusão do capítulo (Seção 1.9) são apresentados alguns tópicos de pesquisa em aberto naárea.

1.2. Avaliação de SimilaridadeA avaliação de similaridade compreende uma sequência de tarefas computacionais queresultam em um valor que quantifica o quão similares dois dados complexos são. Dadoscomplexos em geral podem ser modelados por meio de conjuntos de atributos que suma-rizam o seu conteúdo. Esses conjuntos de atributos são denominados na literatura comovetores de características. A similaridade entre dois vetores de características é calcu-lada por meio de uma função matemática. Em geral, a avaliação de similaridade utilizafunções de distância, que calculam a dissimilaridade entre dois vetores de característi-cas. Ou seja, quanto menor a distância, maior a similaridade entre os objetos comparados,sendo que uma distância igual a zero significa identidade ou total similaridade. Existe umagrande variedade de distâncias relatadas na literatura [Wilson and Martinez, 1997], sendoque as mais utilizadas são as funções da família Minkowski (Lp).

Há autores que defendem a idéia de que a mente humana define um espaçode similaridade, onde os conceitos são organizados segundo suas relações de similari-


32

dade [Gauker, 2007]. Seguindo esta idéia, cada par 〈S,δ 〉, onde S é um domínio definidopor um vetor de características e δ é uma função de distância definida sobre este domí-nio, é definido como uma instância do espaço de similaridade e o conjunto de todasinstâncias de espaço de similaridade possíveis formam uma abstração do espaço de si-milaridade humano [Barioni et al., 2011]. Nesta abstração do espaço de similaridade,a captura da interpretação humana é modelada pela escolha de uma instância do espaçode similaridade que defina da maneira mais próxima possível à interpretação do usuário.Esta “instância ideal” é referenciada na literatura como espaço (de similaridade) semân-tico [He et al., 2002]. Há inúmeras áreas de pesquisa e técnicas envolvidas no processode aproximação do espaço de similaridade semântico, como mostra a Figura 1.1. Estailustração não tem o intuito de ser exaustiva, mas de incluir os conceitos mais comuns emtorno da avaliação de similaridade. Uma instância do espaço de similaridade é formadapor um domínio definido por um vetor de características (após todos os procedimentosde pré-processamento, extração e pós-processamento) e uma função de distância (defi-nida pela função de cálculo e por todos os valores de parâmetros utilizados). Portanto,qualquer modificação realizada em um destes componentes gera uma nova instância doespaço de similaridade.

Figura 1.1. Espaço de similaridade e técnicas envolvidas na definição de sua semântica.

A Figura 1.1 destaca que alguns conceitos afetam diretamente os componentesde uma instância do espaço de similaridade. A extração de características é o passoelementar de processamento de dados complexos e multimídia para definir o componentevetor de características, pois para muitos desses tipos de dados, a sua representação ori-ginal é limitada para descrever o seu conteúdo. Por exemplo, imagens são normalmenterepresentadas por seus padrões de cor, textura e forma, cujas características podem serextraídas da imagem como um todo (escopo global) ou de regiões segmentadas da ima-gem (escopo local) [Datta et al., 2008]. O processo de seleção de características consisteem obter um subconjunto do vetor de características original, incluindo as característicasque são relevantes para discriminar os objetos. Em geral, os métodos de seleção de ca-


33

racterísticas são fortemente baseados em estatística e em algoritmos de aprendizado demáquina [Guyon and Elisseeff, 2003, Yuan et al., 2011]. A transformação de caracte-rísticas tem por objetivo criar novas dimensões no espaço de características, combinandoe transformando as dimensões definidas pelas características originais. Os métodos detransformação mais utilizados são a análise de componentes principais (Principal Com-ponent Analysis – PCA) e a análise discriminante linear (Linear Discriminant Analysis –LDA) [Blanken et al., 2007]. Todas essas tarefas constroem ou modificam o vetor de ca-racterísticas, definindo o domínio do conjunto de dados. De forma semelhante, a funçãode distância pode ser modificada aplicando-se técnicas de ponderação, visando produzirinstâncias do espaço de similaridade que sejam mais próximas da expectativa do usuá-rio. A ponderação de características atribui um peso específico para cada dimensãodo vetor de características, para destacar ou reduzir a influência de cada uma delas deforma a aprimorar a qualidade da avaliação de similaridade [Lee and Street, 2002]. Aponderação de distâncias parciais é aplicada quando um dado complexo é representadopor vários vetores de características distintos e a avaliação de dissimilaridade agrega asdissimilaridades parciais entre pares de vetores de características em uma dissimilaridadeglobal, visando encontrar pesos para as distâncias parciais de forma que nenhuma de-las seja subestimada ou superestimada na avaliação global de similaridade [Barrios andBustos, 2011, Bueno et al., 2009]. A figura também mostra que em um nível mais altoestão as informações externas, técnicas e algoritmos que são utilizados para para definircomo serão implementados os conceitos que afetam diretamente os componentes de umainstância do espaço de similaridade (extração, seleção e transformação de característicase ponderação de distâncias). Neste nível encontram-se algoritmos de processamento dedados complexos, técnicas de descoberta de conhecimento, realimentação de relevância,aprendizado de máquina e outros.

1.3. Consultas por SimilaridadeOs SGBDs oferecem recursos eficazes para realizar buscas sobre os dados usando rela-ções de igualdade e de ordem total existentes nos dados armazenados (tais como númerose textos curtos). Porém, para dados multimídia e outros dados complexos, as buscas porigualdade ou por ordem não se aplicam, ou simplesmente, são de pouca serventia. Paraesses tipos de dados é mais relevante fazer uso de consultas por similaridade, que con-sistem em procurar por elementos em um conjunto que, segundo algum critério de simi-laridade, sejam mais “parecidos” ou mais “distintos” com/de um determinado elemento.Existem dois tipos básicos de consultas por similaridade: a consulta por abrangência e aconsulta aos k-vizinhos mais próximos [Böhm et al., 2001], definidas a seguir.

Consulta por abrangência (Range query – Rq): retorna todos os elementos dissimila-res de um elemento de consulta até no máximo um certo limiar. Formalmente, sejaS um domínio de dados, S ⊆ S um conjunto de elementos, sq ∈ S um elemento deconsulta, δ uma função de distância definida sobre elementos de S e ξ um limiarde dissimilaridade, uma Rq retorna os elementos si ∈ S tais que δ (sq,si)≤ ξ . Exis-tem duas variações básicas para a consulta por abrangência: a consulta pontual ea consulta por abrangência reversa. A consulta pontual (Point query – Pq) é umaconsulta por abrangência com ξ = 0, cujo objetivo é identificar se o elemento deconsulta está armazenado no banco de dados. A consulta por abrangência reversa


34

(Reversed Range query – Rq−1), é uma busca por abrangência que procura peloselementos fora da área de abrangência, isto é, a resposta é formada pelos elementossi ∈ S tal que δ (sq,si)> ξ .

Consulta aos k-vizinhos mais próximos (k-Nearest Neighbors query – k-NNq):retorna os k elementos mais similares ao elemento de consulta sq, isto é, os kelementos si ∈ S com menor valor para δ (si,sq). Se houver dois ou mais elementossituados à mesma distância do elemento de referência, que podem ser escolhidoscomo o k-ésimo vizinho mais próximo, pode-se escolher um desses elementosarbitrariamente ou pode-se selecionar todos os elementos “empatados” com ok-ésimo, retornando mais do que k elementos. Uma variação desta consulta é aconsulta aos k-vizinhos mais distantes (k-Farthest Neighbors query – k-FNq),que retorna os k elementos mais dissimilares ao elemento de consulta, de acordocom a função de distância indicada.

A Figura 1.2(a) mostra uma representação visual de uma Rq, onde os elementosde S localizados na bola centrada em sq e com raio ξ compõem a resposta para a consulta,e a Figura 1.2(b) mostra a representação de uma k-NNq, com k = 4 (na figura, sq nãopertence ao conjunto de dados S)1.

�

sq sq

s1

s2

s3s4

(a) (b)

Figura 1.2. Representação da consulta por abrangência (a) e da consulta aosk-vizinhos mais próximos, com k = 4 (b).

Uma extensão às consultas por abrangência e aos k-vizinhos mais próximos sãoas consultas em que há mais de um elemento de consulta. Neste caso, há algumas inter-pretações possíveis para a busca:

• retorne os elementos mais próximos ou que estejam no raio de abrangência de al-gum dos elementos de consulta;

• retorne os elementos mais próximos ou que estejam no raio de abrangência de todosos elementos de consulta; ou

• retorne os elementos mais próximos ou que estejam no raio de abrangência segundouma função que agrega todos os elementos de consulta.

1Neste texto, sem perda de generalidade, as figuras que apresentam elementos no espaço são apresenta-das no espaço R2 e usando a distância Euclideana (L2) para facilitar o entendimento.


35

A primeira alternativa corresponde a uma união de várias buscas por similaridadesobre o conjunto de entrada, uma para cada elemento de consulta, e a segunda alternativacorresponde a uma interseção dessas buscas. A terceira opção, por outro lado, refere-se às consultas por similaridade agregada, cujo objetivo é avaliar a similaridade de cadaelemento armazenado com relação a todos os elementos de consulta, segundo uma funçãoaplicada sobre estas similaridades [Papadias et al., 2005]. Neste capítulo, esta função édenominada função agregadora de distâncias (∆). Por exemplo, Razente et al. [2008]definem uma família de funções agregadoras de distâncias para responder a consultaspor similaridade agregada. Dado um domínio S, um conjunto de elementos S ⊆ S, umelemento s ∈ S, um conjunto de elementos de consulta Q ⊆ S, essa família de funçõesagregadoras de distâncias é dada por:

dg(s,Q) = g

√∑

sq∈Q(δ (s,sq)g ∗wq) (1)

onde δ é uma função de distância definida sobre S, cada wq é um peso correspondente acada elemento de consulta sq e g∈R∗ é o fator de agregação (grip factor), sendo que dife-rentes valores para g levam a interpretações distintas sobre como a agregação é realizada.A noção de função agregadora de distâncias permite definir as consultas a seguir.

Consulta por abrangência agregada (Aggregated Range query – ARq): dado um con-junto S⊆ S, um conjunto de elementos de consulta Q⊆ S, |Q| ≥ 1, uma função dedistância δ definida sobre S, uma função ∆ agregadora de distâncias δ e um limiarde dissimilaridade ξ , a consulta ARq retorna os elementos cujo valor da função∆ seja menor ou igual a ξ . Variações da consulta por abrangência agregada sãoa consulta pontual agregada (Aggregated Point query – APq) e a consulta porabrangência reversa agregada (Aggregated Reversed Range query – ARq−1).

Consulta aos k-vizinhos mais próximos agregados (Aggregated k-Nearest Neighborquery – k-ANNq): dado um conjunto S ⊆ S, um conjunto de elementos de con-sulta Q ⊆ S, |Q| ≥ 1, uma função de distância δ definida sobre S, uma função ∆

agregadora de distâncias δ e um inteiro k ≥ 1, a consulta k-ANNq retorna os k ele-mentos mais similares aos elementos em Q, de acordo com a função ∆. Uma varia-ção é a consulta aos k-vizinhos mais distantes agregados (Aggregated k-FarthestNeighbor query – k-AFNq).

Outra categoria de consultas por similaridade são as junções por similari-dade [Böhm and Krebs, 2002], que atuam sobre dois conjuntos de dados complexos esão apresentadas a seguir.

Junção por abrangência (Range join – onRq): dados dois conjuntos R⊆ S e S⊆ S, umafunção de distância δ definida sobre S e um limiar de abrangência ξ , esta consultarecupera os pares de elementos ri ∈ R e s j ∈ S distantes no máximo ξ entre si.

Junção pelos k-vizinhos mais próximos (k-NN join – onkNN): dados dois conjuntosR ⊆ S e S⊆ S, uma função de distância δ definida sobre S e um número inteiro


36

k ≥ 1, esta consulta retorna os pares de elementos ri ∈ R e s j ∈ S de maneira quecada elemento de R apareça no resultado concatenado com cada um dos seusk-vizinhos mais próximos em S. Observe-se que a esta operação não é comutativa,ou seja, R1 onkNN R2 6= R2 onkNN R1.

Junção dos k-pares de vizinhos mais próximos (k-Closest Neighbor join – onkCN):dados dois conjuntos R ⊆ S e S ⊆ S, uma função de distância δ sobre S e umnúmero inteiro k ≥ 1, esta consulta retorna os k pares de elementos ri ∈ R e si ∈ Smais próximos entre si.

A Figura 1.3 ilustra esses três tipos de junção por similaridade. Nessa figura,os círculos pretos representam elementos do conjunto R e os de cor cinza representamelementos do conjunto S.

�

�

�

(a) (b) (c)

Figura 1.3. Operações de junção por similaridade. (a) Junção por abrangência.(b) Junção pelos k-vizinhos mais próximos, com k = 2. (c) Junção dos k-pares devizinhos mais próximos, com k = 4.

1.4. Representação Algébrica de Consultas por SimilaridadeVisto que dados complexos demandam um tratamento adequado em termos de represen-tação e otimização de consultas, algumas abordagens algébricas para consultas por simi-laridade têm sido propostas na literatura. Os trabalhos voltados a incluir a noção de simi-laridade no modelo relacional concentram-se em três linhas principais. A primeira linhaentende a noção de similaridade como imprecisão, ou grau de pertinência a um conjunto,e define a estrutura da álgebra utilizando conceitos da lógica nebulosa (fuzzy) [Penzo,2005]. A segunda linha procura estender o modelo relacional através da introdução doconceito de relações ordenadas (ranked relations), cujas tuplas são classificadas segundoum critério de ranking definido pelo usuário [Belohlávek and Vychodil, 2010, Li et al.,2005]. A terceira linha de trabalhos visando incluir similaridade no modelo relacionalconsidera apenas acrescentar operadores por similaridade à álgebra relacional, sem modi-ficar a estrutura das relações[Barioni et al., 2011, Ferreira et al., 2009, Silva et al., 2009,Traina Jr. et al., 2006]. Esta seção apresenta as definições das consultas por similaridadeseguindo as definições do modelo relacional enriquecido com operadores por similari-dade. A notação utilizada neste capítulo é derivada dos trabalhos de Barioni et al. [2011]e Ferreira et al. [2009].


37

1.4.1. Seleções por Similaridade

As consultas por abrangência, aos vizinhos mais próximos e por similaridade agregadatêm o comportamento semelhante ao da seleção relacional. Isto é, essas consultas re-tornam os elementos de um conjunto de entrada, que podem ser tuplas de uma relação,que satisfazem um determinado critério de similaridade, que pode ser definido por umpredicado de seleção. Estas operações são classificadas como seleções por similaridade esão denotadas por dois operadores de consulta, σ e σ , utilizados, respectivamente, pararepresentar consultas por similaridade por abrangência (Rq, ARq e variações) e por vizi-nhança (k-NNq, k-ANNq e variações). A expressão condicional aceita pelos operadoresde consulta σ e σ tem a forma 〈S j θ Q〉, onde S j é um atributo da relação de entrada, cujodomínio é um domínio de dados complexos S, θ é um operador por similaridade e Q⊆ Sé um conjunto de elementos de consulta.

O operador por similaridade para o operador de consulta σ tem a formaRq[δ ,∆,ξ ], onde δ é uma função de distância, ∆ é uma função agregadora de distâncias δ

e ξ é o limiar de dissimilaridade. Se deseja-se representar uma consulta por abrangêncianão agregada, omite-se a função agregadora de distâncias ∆ e Q tem que ser um conjuntounitário, podendo ser denotado na expressão condicional como {sq} ou, simplesmente, sq.Desta forma, as expressões a seguir mostram como são representadas (a) uma consulta porabrangência e (b) uma consulta por abrangência agregada:

a) σS j Rq[δ ,ξ ] sq(R) b) σS j Rq[δ ,∆,ξ ] Q(R)

produzindo, respectivamente, uma relação R′a que contém as tuplas ti ∈ R tais queδ (ti.S j,sq) ≤ ξ , e uma relação R′b que contém as tuplas tm ∈ R tais que ∆(tm.S j,Q) ≤ ξ ,onde ti.S j e tm.S j são os valores do atributo S j nas tuplas ti e tm. As consultas pontuais(agregadas) são representadas de forma semelhante, mas com ξ = 0, e as consultas porabrangência reversa (agregada) também, mas usando o operador por similaridade Rq−1.

O operador por similaridade para o operador de consulta σ tem a formakNN[δ ,∆,k], onde δ é uma função de distância, ∆ é uma função agregadora de distân-cias δ e k ≥ 1 é o número de vizinhos2. Se deseja-se representar consultas aos vizinhosmais próximos/distantes não agregados, omite-se ∆ e Q tem que ser unitário. As ex-pressões a seguir representam: (a) uma consulta aos k-vizinhos mais próximos e (b) umaconsulta aos k-vizinhos mais próximos agregados:

a) σS j kNN[δ ,k] sq(R) b) σS j kNN[δ ,∆,k] Q(R)

produzindo, respectivamente, uma relação R′a que contém as tuplas ti ∈ R que são osvizinhos mais próximos de sq de acordo com o valor de δ (ti.S j,sq) e uma relação R′bque contém as tuplas tm ∈ R que são os vizinhos mais próximos de Q de acordo com∆(tm.S j,Q). As consultas aos k-vizinhos mais distantes (agregados) são representadas deforma semelhante, mas utilizando o operador por similaridade kFN.

2Uma extensão a esse operador por similaridade que aceita uma condição adicional à busca foi propostaem [Kaster, 2012]. Este operador estendido, denominado de operador de consulta aos k-vizinhos maispróximos estendida com condições (condition-extended k-NN query – ck-NNq) possui um poder de expres-sividade maior que o operador kNN, permitindo representar novas variações de consultas por similaridade.


38

1.4.2. Junções por Similaridade

As junções por similaridade são representadas por operadores de consulta estendidos,on e on, cujas condições de junção são baseadas em operadores por similaridade. Asjunções por abrangência (onRq), pelos k-vizinhos mais próximos (onkNN) e dos k-pares devizinhos mais próximos (onkCN) utilizam, respectivamente, os operadores Rq, kNN e kCNna condição de junção. Sejam R1 e R2 duas relações, sendo que Si e S j são atributos de ummesmo domínio de dados complexos S e pertencem, respectivamente, a R1 e R2, e seja δ

uma função de distância definida sobre S. As junções por similaridade são representadasalgebricamente conforme segue:

a) R1onSi Rq[δ ,ξ ] S jR2 b) R1onSi kNN[δ ,k] S jR2 c) R1onSi kCN[δ ,k] S jR2

sendo (a) uma onRq, (b) uma onkNN e (c) uma onkCN. Estas consultas produzem relaçõescujas tuplas são a concatenação das tuplas tm ∈ R1 e tn ∈ R2 que satisfazem o critérioindicado pelo respectivo operador por similaridade usado na condição de junção.

1.5. Algoritmos para Consultas por Similaridade em Métodos de Acesso Mé-tricos

Um aspecto fundamental dos algoritmos para consultas por similaridade está relacionadoà utilização de um Método de Acesso (MA) apropriado. A maioria dos SGBDs fornecemestruturas de indexação para dados tradicionais, como variantes da B-Tree e estruturas dehashing. Contudo, essas estruturas não são adequadas para a execução de consultas porsimilaridade. As subseções a seguir apresentam os principais tipos de MA usados paraconsultas por similaridade e os algoritmos para resolver as consultas Rq e k-NNq sobreárvores métricas, que são os MAs que têm se mostrado mais eficientes para a indexaçãode dados complexos. A Slim-tree [Traina Jr. et al., 2002] será usada como exemplo paraa descrição dos algoritmos.

1.5.1. Métodos de Acesso para Consultas por Similaridade

Os Métodos de Acesso Espaciais (MAEs), também conhecidos como Métodos deAcesso Multidimensionais, foram propostos para indexar dados espaciais. Exemplos re-presentativos de MAEs são a k-d-B-tree [Robinson, 1981] e a R-tree [Guttman, 1984] esuas variantes, tais como a R*-tree [Beckmann et al., 1990]. Alguns SGBDs comerciais jáimplementam variantes da R-tree, tais como o Oracle Database, o IBM Informix DynamicServer e o PostgreSQL, utilizado-a majoritariamente em aplicações de geoprocessamento.MAEs também podem ser utilizados para indexar outros tipos de dados complexos, taiscomo dados multimídia [Böhm et al., 2001]. Neste caso, um vetor de características come atributos é visto como um ponto no espaço e-dimensional definido pelas característicase as consultas são agilizadas através da aplicação de propriedades geométricas na cons-trução do MAE e na delimitação da área de consulta. Contudo, quando as assinaturas doselementos multimídia têm muitas características, os MAEs passam a não ser eficientes.Eles degradam rapidamente com o aumento da dimensionalidade dos dados, tornando-seinviáveis para dimensionalidades maiores que uma dezena.

Para dados de alta dimensionalidade ou adimensionais (sem dimensão fixa) forampropostos os Métodos de Acesso Métricos (MAMs). A abordagem dos MAMs assume


39

que os objetos estão em um espaço métrico, importando apenas as suas relações de si-milaridade. Um espaço métrico é formalmente definido como um par M= 〈S,δ 〉, ondeS é um domínio de dados e δ é uma métrica, isto é, uma função δ : S×S→ R+ queexpressa a distância entre elementos de S e que satisfaz as seguintes propriedades, paraquaisquer s1,s2,s3 ∈ S: (i) identidade: δ (s1,s1) = 0; (ii) simetria: δ (s1,s2) = δ (s2,s1);(iii) não negatividade: 0 < δ (s1,s2)< ∞ se s1 6= s2; e (iv) desigualdade triangular:δ (s1,s3)≤ δ (s1,s2)+δ (s2,s3). As distâncias da família Minkowski, com p ≥ 1 sãométricas, portanto espaços vetoriais utilizando qualquer uma destas distâncias formamespaços métricos. Outros exemplos de métricas são a distância de Mahalanobis [Mahala-nobis, 1936] e a distância Canberra [Kokare et al., 2003]. Os MAMs podem ser utilizadospara indexar praticamente qualquer tipo de dado, sendo necessária e suficiente a defini-ção de uma métrica adequada. Vários trabalhos têm apresentado propostas de MAMsna literatura, incluindo estruturas estáticas e dinâmicas. Dentre os MAMs estáticos, quesão aqueles que não podem sofrer novas atualizações/remoções sem degenerar as estru-turas criadas, pode-se citar a VP-tree (Vantage Point tree) [Yianilos, 1993] e a MVP-tree(Multi-Vantage Point tree) [Bozkaya and Özsoyoglu, 1997]. O primeiro MAM dinâmicodesenvolvido foi a M-tree [Ciaccia et al., 1997], que pode ser visto como uma adapta-ção do MAE R-tree para indexar dados em domínios métricos. A M-tree é uma árvorebalanceada com crescimento bottom-up e com dois tipos de nós (internos e folha), quepermite a inserção de elementos a qualquer momento, mantendo-se sempre balanceada,sem a necessidade de reorganizações periódicas. A Slim-tree [Traina Jr. et al., 2002] éuma evolução da M-tree, que traz como melhorias a avaliação e minimização do grau desobreposição entre seus nós e um novo algoritmo de split, baseado na árvore de cober-tura minimal (Minimal Spanning Tree – MST). Outros exemplos de MAMs dinâmicossão a DBM-tree (Density-Based Metric tree) [Vieira et al., 2006] e os índices da famíliaOmni [Traina Jr. et al., 2007].

1.5.2. Estrutura da Slim-tree

Para facilitar o entendimento dos algoritmos, a estrutura da Slim-tree será descrita re-sumidamente. Em uma Slim-tree, os elementos são agrupados em disco em páginas detamanho fixo, cada página correspondendo a um nó da árvore. Os elementos são arma-zenados nas folhas, organizados em uma estrutura hierárquica que utiliza um elementorepresentante como centro de uma região de cobertura dos elementos de uma subárvore,delimitada por um raio máximo de cobertura. Para reduzir os cálculos de distância duranteas buscas, as distâncias entre cada elemento de um nó e o seu respectivo representante sãocalculadas no momento da inserção e armazenadas na árvore.

Existem dois tipos de nós na Slim-tree, os nós internos (index-nodes) e os nós fo-lha (leaf-nodes). A estrutura de um leaf-node, onde são armazenados todos os elementos,é a seguinte:

leaf-node [vetor de 〈OIdi,d(si,srep),si〉]

onde OIdi é o identificador do elemento si e d(si,srep) é a distância entre o elemento si esrep, que é o representante desse nó. A estrutura de um index-node, é a seguinte:

index-node [vetor de 〈si,ri,d(si,srep),Ptr(Tsi),#Ent(Ptr(Tsi))〉]


40

onde si armazena o elemento representante da subárvore apontada por Ptr(Tsi), ri é oraio de cobertura do nó (distância entre o representante e o elemento mais distante aorepresentante nesse nó), d(si,srep) é a distância entre si e o representante desse nó, e#Ent(Ptr(Tsi)) armazena o número de entradas da subárvore apontada por Ptr(Tsi).

A Figura 1.4 ilustra a disposição de uma Slim-tree com capacidade máxima de 3elementos por nó. Os círculos brancos representam nós folha, e os de cor cinza nós índice.Os elementos representantes de cada nó são mostrados em preto, e os demais elementosindexados em cor cinza.

s1

s8

s4

s8

s13

s1

s2

s4

s11

s2

s16

s17

s1

s6

s7

s8

s10

s9

s4

s3

s5

s13

s15

s14

s11

s12

s1

s2

s3

s4

s5

s6

s7

s8

s9

s10

s11

s12

s13

s14

s15

s16

s17

Figura 1.4. Representação visual de uma Slim-tree e sua estrutura lógica. Acapacidade máxima dos nós é igual a 3.

1.5.3. Algoritmo para Consulta por Abrangência

Os algoritmos de consulta em estruturas hierárquicas em geral utilizam a estratégiabranch-and-bound, onde a busca começa pela raiz da estrutura, e em cada passo utilizam-se propriedades do domínio de dados em questão para determinar quais nós devem serexaminados e quais podem ser descartados. Para dados imersos em um espaço métrico,a desigualdade triangular é a principal propriedade utilizada. Na Slim-tree, ao visitar nósíndice, a desigualdade triangular permite descartar subárvores inteiras se não houver so-breposição entre a região de consulta (bola centrada no elemento de consulta sq com raioξ ) e a região de cobertura da subárvore (bola centrada no elemento representativo do nói e o raio de cobertura ri), como ilustra a Figura 1.5. Isto é, a subárvore enraizada noelemento si pode ser descartada sem a necessidade calcular-se a distância entre si e sq sea expressão (a) a seguir for válida, ou pode ser descartada após calcular-se δ (sq,si) se aexpressão (b) for válida:

a) |δ (sq,srep)−δ (srep,si)|> ξ + ri b) δ (sq,si)> ξ + ri

onde ξ é o limiar de dissimilaridade da consulta. Ressalte-se que os valores δ (srep,si) não


41

são calculados durante as buscas, pois foram armazenados na estrutura na inserção doselementos. A desigualdade triangular também permite descartar elementos em nós folhasem calcular a sua distância ao elemento de consulta se a condição a seguir for satisfeita:

|δ (sq,srep)−δ (srep,si)|> ξ

ss1

s2 sq

R1

Rrep

R2

R +�(s , s )rep 1 1

rep

R +�(s , s )rep 2 2

�

Figura 1.5. Descarte de subárvores na Slim-tree. Ambas subárvores enraizadasem s1 e s2 podem ser podadas na busca, porém apenas s1 é descartado sem anecessidade de se calcular sua distância ao elemento de consulta sq.

O Algoritmo 1.1 apresenta a função de busca por abrangência na Slim-tree. Aoacessar um nó índice, o algoritmo procura descartar subárvores usando a propriedade dedesigualdade triangular (linhas 5 e 7), visitando recursivamente as subárvores não descar-tadas (linha 8). Ao acessar um nó folha, o algoritmo primeiro tenta descartar elementossem calcular a distância ao elemento de consulta e, em seguida, após calcular a distância(linhas 11 e 13). Os elementos não descartados fazem parte da resposta à consulta e sãoincluídos no resultado (linha 14).

1.5.4. Algoritmo para Consulta aos k-Vizinhos Mais Próximos

Ao contrário do que ocorre na Rq, na k-NNq não existe um raio de consulta definido aprincípio. Os algoritmos iniciam com um raio infinito, que é reduzido gradativamentedurante o percurso da estrutura à medida que são encontrados elementos mais próximosao elemento de consulta. Desta forma, a ordem de visitação dos nós pode interferir con-sideravelmente no desempenho do algoritmo. Os principais algoritmos para execução deconsultas k-NN em métodos de acesso hierárquicos são os seguintes.

• Depth-First k-NN: percorre recursivamente a estrutura utilizando uma busca emprofundidade para construir a resposta.

• Best-First k-NN [Roussopoulos et al., 1995]: define a ordem de visitação dos nósem uma k-NNq com base na distância mínima entre o elemento de consulta e asregiões cobertas pelos nós a serem visitados. A cada passo do algoritmo, o nó coma menor distância mínima é visitado, pois a subárvore enraizada neste elemento tem


42

Algoritmo 1.1: Consulta por abrangência na Slim-treeEntrada: Nó a ser visitado (node), elemento de consulta (sq) e raio de abrangência (ξ )Saída: Elementos cuja distância de sq seja menor ou igual a ξ

início1result←∅;2se node é um nó índice então3

para cada si em node faça4se |δ (sq,srep)−δ (srep,si)| ≤ ξ + ri então5

distance← δ (sq,si);6se distance ≤ ξ + ri então7

retorna rangeQuery(Ptr(Tsi),sq,ξ );8

senão9para cada si em node faça10

se |δ (sq,srep)−δ (srep,si)| ≤ ξ então11distance← δ (sq,si);12se distance ≤ ξ então13

result.add (si, distance);14

retorna result;15fim16

a maior probabilidade de conter elementos mais próximos ao elemento de consultadentre as subárvores não visitadas.

• Incremental k-NN [Hjaltason and Samet, 1999]: utiliza uma fila de prioridade glo-bal, contendo os nós a serem processados e também a resposta para a consulta(elementos), e define heurísticas que garantem que os k elementos mais próximosestão sempre no início da fila. Assim, para obter-se o k + 1-ésimo elemento nãoé necessário reiniciar a busca, bastando continuar percorrendo a fila de prioridadea partir do passo anterior, o que torna o algoritmo muito eficiente em termos deacessos a disco e cálculos de distância. O problema dessa técnica é o custo de ge-renciamento da fila de prioridade, que tende a ser muito elevado, degenerando o seudesempenho.

Uma outra estratégia de aprimoramento consiste em estimar um raio inicial paraa k-NNq, de tal forma que a capacidade de poda do algoritmo seja potencializada. Porexemplo, Vieira et al. [2007] propuseram utilizar a dimensão de correlação fractal (D2)do conjunto de dados para realizar essa estimativa, obtendo desempenho consideravel-mente superior com relação à inicialização do raio dinâmico com ∞. Finalmente, existemvárias abordagens que utilizam heurísticas para responder a consultas aproximadas aosvizinhos mais próximos, tais como os trabalhos baseados na técnica LSH (Locality Sen-sitive Hashing) [Pan and Manocha, 2011].

O Algoritmo 1.2 apresenta a implementação do Best-First k-NN sobre a Slim-tree.Na Slim-tree, a distância mínima entre um elemento de consulta sq e uma subárvore Tsi ,cuja abrangência é uma bola centrada em si com raio ri, é dada por:

mindist(sq,Tsi) = max{δ (sq,si)− ri,0} (2)


43

Algoritmo 1.2: Consulta aos k-vizinhos mais próximos na Slim-treeEntrada: Nó raiz (rootNode), elemento de consulta (sq) e número de vizinhos (k)Saída: Os k-vizinhos mais próximos a sqinício1

result←∅;2priorQueue←∅;3priorQueue.add(rootNode, ∞);4result.setMaxDistance(∞);5enquanto priorQueue 6=∅ faça6

node← priorQueue.removeMin();7se node é um nó índice então8

para cada si em node faça9se |δ (sq,srep)−δ (srep,si)| ≤ result.getMaxDistance()+ri então10

minDistance← mindist(sq,Tsi );11se minDistance ≤ result.getMaxDistance() então12

priorQueue.add(Ptr(Tsi), minDistance);13minMaxDistance← minmaxdist(sq,Tsi );14se minMaxDistance < result.getMaxDistance() então15

result.add(NULL, minMaxDistance);16se result.getNumElements() > k então17

result.removeLast();18remova todas as entradas de priorQueue tais que19

mindist(sq,Tsi ) > result.getMaxDistance();20

senão /* node é um nó folha */21para cada si em node faça22

se |δ (sq,srep)−δ (srep,si)| ≤ result.getMaxDistance() então23distance← δ (sq,si);24se distance ≤ result.getMaxDistance() então25

result.add(si, distance);26se result.getNumElements() > k então27

result.removeLast();28remova todas as entradas de priorQueue tais que29

mindist(sq,Tsi ) > result.getMaxDistance();30

retorna result;31fim32

uma vez que nenhum elemento em Tsi pode estar a uma distância de sq menor queδ (sq,si)− ri. Esse valor é usado para organizar a fila de prioridade (priorQueue) doalgoritmo, que é inicializada com o nó raiz (linha 4). O algoritmo usa também a estruturade dados result para armazenar os vizinhos mais próximos encontrados e a sua distân-cia do elemento de consulta. A distância entre sq e o k-ésimo elemento corrente é obtidapor meio da função getMaxDistance() da estrutura result, que faz o papel do raiode busca dinâmico, que é inicializado como ∞ (linha 5). Enquanto houver elementos nafila de prioridade, o elemento com distância mínima estimada é retirado (linhas 6-7). Seo nó corrente é um nó índice, cada elemento do nó é avaliado e o algoritmo tenta podar asubárvore respectiva usando a desigualdade triangular (linhas 8-10). Se a subárvore nãopuder ser podada, o algoritmo calcula a distância mínima entre o elemento de consulta e


44

a subárvore Tsi , o que implica em calcular δ (sq,si), e verifica novamente se a subárvorepode ser descartada, com base neste valor (linhas 11-12). Caso a poda não seja possível,a subárvore é inserida na fila de prioridade, com base no valor mindist(sq,Tsi), para serprocessada posteriormente (linha 13). Em seguida, o algoritmo calcula a menor distânciamáxima entre sq e Tsi (linha 14), cujo valor é dado por:

minmaxdist(sq,Tsi) = δ (sq,si)+ ri (3)

que é um limite superior utilizado para ajustar o raio dinâmico de consulta enquanto oprocesso ainda está visitando nós índice, pois garantidamente existe um elemento s j nasubárvore Tsi tal que δ (s j,sq) ≤ minmaxdist(sq,Tsi). Se esse valor for menor que adistância máxima do resultado atual, o algoritmo faz uma inserção nula com distânciaigual ao limite superior minmaxdist(sq,Tsi) (linhas 15-16). Se esta inserção fizer comque o resultado tenha mais do que k elementos, o algoritmo remove o último elemento,atualizando o raio dinâmico, e remove as entradas da fila de prioridade cujas distânciasforem maiores que o novo raio de consulta, pois estas subárvores podem ser seguramentepodadas neste momento (linhas 17-20). Ao acessar um nó folha, o algoritmo primeirotenta descartar elementos sem calcular a distância ao elemento de consulta e, em seguida,após calcular a distância (linhas 23-25). Os elementos não descartados fazem parte daresposta à consulta e são incluídos no resultado (linha 26). Novamente, caso esta inserçãofaça com que o resultado extrapole k elementos, o algoritmo remove o último elemento etambém as entradas da fila de prioridade cujas distâncias são maiores que o novo raio deconsulta (linhas 27-30).

1.6. Desenvolvimento e Uso de Índices com a Biblioteca ArboretumEsta seção introduz os fundamentos para o desenvolvimento e uso de índices para da-dos complexos em uma biblioteca de métodos de acesso. Existem várias bibliotecas demétodos de acesso, dentre as quais a Arboretum é uma opção muito interessante. A Ar-boretum3 é uma biblioteca C++ de código aberto, desenvolvida pelo Grupo de Bases deDados e Imagens do Instituto de Ciências Matemáticas e de Computação da USP (GBDI-ICMC-USP). A Arboretum implementa um conjunto de estruturas e mecanismos para odesenvolvimento de métodos de acesso. Ela é organizada em 3 camadas, como mostra aFigura 1.6. A Camada de Usuário define as classes que definem os objetos das aplicaçõese as classes que implementam os comparadores entre objetos. A Camada de Estruturascontém as estruturas de indexação e estruturas auxiliares e a Camada de Armazenamentocontém gerenciadores de páginas e seus componentes, que provêm funções para o geren-ciamento de acesso paginado a disco ou a memória.

Existem várias estruturas de indexação implementadas na Arboretum, sendo amaioria delas Métodos de Acesso Métricos (MAMs). Para utilizar uma estrutura exis-tente, é necessário definir uma classe para representar os objetos a serem armazenados. Aserialização é um conceito fundamental da Arboretum, para permitir o armazenamentode objetos em disco. Desta forma, as classes de objetos devem respeitar a interfacestObject, que define os seguintes métodos:

3http://gbdi.icmc.usp.br/arboretum


45

Objetos Comparadores

Estruturas de indexação

Gerenciadores de página

Usuário

Estruturas

Armazenamento

Figura 1.6. Arquitetura da biblioteca Arboretum.

virtual stObject * Clone();virtual const stByte * Serialize();virtual stSize GetSerializedSize();virtual void Unserialize(const stByte * serializedObj,

stSize serializedObjSize);

onde o método Clone retorna uma cópia do objeto, o método Serialize retorna umasequência de bytes com o objeto serializado, o método GetSerializedSize retornao tamanho serializado do objeto e o método Unserialize reconstrói um objeto a partirde seu formato serializado4. Também é preciso definir um comparador para a classe deobjeto criada. No caso de MAMs, o comparador é uma função de distância, que deveimplementar a interface stMetricEvaluator, que define o seguinte método:

virtual stDistance GetDistance(stObject * obj1, stObject * obj2)

que retorna a distância entre os dois objetos fornecidos. A Arboretum utiliza templatesC++ para parametrizar os tipos de dados manipulados pelas estruturas. Por exemplo, parainstanciar um MAM na Arboretum, o tipo de objeto e o comparador devem ser fornecidoscomo parâmetros de template. Desta forma, o MAM não precisa conhecer detalhes daimplementação do tipo de objeto ou do comparador, podendo ser parametrizado paraindexar tipos de objetos específicos que atendam às necessidades das aplicações alvo,apenas acessando a interface das classes informadas como parâmetros.

Para ilustrar o processo de instanciação, suponha-se que é desejado indexar his-togramas normalizados de cores de imagens em uma Slim-tree organizada pela distân-cia Manhattan (L1). Um histograma normalizado de cores pode ser armazenado em umvetor de números reais. A Arboretum possui a classe ByteOIDArrayObject, queimplementa um vetor serializável segundo a interface stObject, cujo tipo de cada po-sição do vetor é parametrizável. A Arboretum também implementa a função L1 na classestManhattanMetricEvaluator, que calcula a distância entre dois vetores de ca-racterísticas e também é parametrizada com o tipo de cada posição dos vetores. Com estesrequisitos, a parametrização da Slim-tree pode ser feita através das definições de tipos aseguir:

4Os tipos stByte, stSize e stDistance são redefinições de tipos básicos de dados estabelecidasna Arboretum e correspondem, respectivamente, aos tipos “byte”, inteiro sem sinal e real de dupla precisão.


46

typedef ByteOIDArrayObject<float> THistogram;typedef stManhatanMetricEvaluator<float> TManhattanFloat;typedef stSlimTree<THistogram, TManhattanFloat> mySlimTree;

Além da definição dos parâmetros da Camada de Usuário, as estruturas de indexa-ção dependem da Camada de Armazenamento para realizar a persistência das estruturas.Entre outras coisas, a Camada de Armazenamento define 2 classes básicas: stPage estPageManager. A classe stPage implementa uma página de dados, armazenandoum conjunto contíguo de bytes, cujo significado não importa para esta classe. A classestPageManager define a interface que os gerenciadores de página devem implementarpara armazenar e recuperar páginas de disco ou de memória requisitadas pelas estruturasde indexação. Por exemplo, o código a seguir instancia um gerenciador de páginas paradisco e uma Slim-tree parametrizada pelo tipo mySlimTree:

stPageManager * pageManager = new stDiskPageManager("slim.idx",8192);mySlimTree * slimTree = new mySlimTree(pageManager);

onde os dois parâmetros fornecidos na instanciação do gerenciador de páginas são, res-pectivamente, o nome do arquivo de dados a ser utilizado e o tamanho de página (embytes), e o parâmetro da Slim-tree é o gerenciador de páginas a ser usado pela estrutura.Cada estrutura de dados possui seus métodos próprios de consulta e manipulação doselementos indexados. As consultas por similaridade retornam conjuntos de resultados se-gundo a interface stResult, que define as operações de manipulação dos resultados eé parametrizada com o tipo de objeto armazenado pela estrutura. O resultado é formadopor pares 〈objeto, distância〉, que armazenam o elemento retornado e sua distância ao(s)elemento(s) de consulta, ou triplas 〈objeto1, objeto2, distância〉, no caso de junções porsimilaridade. Por exemplo, o código a seguir executa sobre a Slim-tree criada uma con-sulta k-NN, tendo center como elemento de referência e k = 10, percorre o conjunto deresultados e, ao final, destrói o resultado:

stResult<tHistogram> * result;result = slim->NearestQuery(center, 10);stResult<tHistogram>::tItePairs it = result->beginPairs();while (it != result->endPairs()) {

THistogram * histogram = (THistogram *)(*it)->GetObject();stDistance distance = (stDistance)(*it)->GetDistance();// utilize o objeto e a distância recuperadosit++;

}delete result;

onde o tipo stResult<tHistogram>::tItePairs é um iterador da classe para-metrizada stResult, que permite acessar os pares 〈objeto, distância〉 do resultado.

A arquitetura modular da Arboretum favorece a implementação de novas estrutu-ras de indexação. Um índice é definido em uma classe principal e um conjunto de classesauxiliares. Uma classe auxiliar bastante comum é aquela que define o nó (ou bucket) daestrutura sobre uma página stPage. Esta classe é a que implementa a lógica do conteúdodas páginas, que são tratadas apenas como sequências de bytes pelos gerenciadores de pá-ginas. As demais classes auxiliares dependem de cada estrutura, mas a biblioteca provêum variedade de classes auxiliares, o que permite reduzir o esforço de implementação eajuda a manter a homogeneidade das interfaces de acesso às estruturas desenvolvidas.


47

1.7. Inclusão de Consultas por Similaridade no SGBD OracleEsta seção apresenta a implementação de um módulo para consultas por similaridadesobre o SGBD Oracle, utilizando as interfaces da arquitetura extensível do Oracle (Ora-cle Extensible Architecture Framework). O módulo FMI-SiR5 (user-defined Features,Metrics and Indexes for Similarity Retrieval) [Kaster et al., 2010] é um módulo de SGBDque provê operadores, extratores de características, funções de distância e métodos deacesso para responder eficientemente a consultas por similaridade integradas às demaisoperações de busca disponibilizadas pelo SGBD. Além de suportar aplicações que de-mandam manipulação eficiente de dados complexos, a abordagem adotada pelo FMI-SiRfacilita a integração de resultados de pesquisa a um SGBD do mercado. A implementaçãodo FMI-SiR sobre o Oracle é denominada FMI-SiRO, que é descrita nesta seção. Existeainda uma extensão a esse módulo, denominada Medical FMI-SiR (MedFMI-SiR) [Kasteret al., 2011a], que aborda a recuperação de imagens médicas combinando característicasvisuais e metadados DICOM.

1.7.1. A Arquitetura do FMI-SiRO

O FMI-SiRO é acoplado ao SGBD Oracle através das interfaces da arquitetura extensíveldo Oracle. Desta forma, ele é controlado pelo processador de consultas do SGBD e inte-grado às demais funcionalidades do SGBD, permitindo executar eficientemente consultascombinando condições baseadas em similaridade e condições baseadas em critérios con-vencionais. Todas as informações sobre os dados complexos podem ser armazenadas nobanco de dados de forma integrada, incluindo metadados, vetores de características des-crevendo os seus conteúdos e os dados binários em si. As aplicações cliente utilizam asfuncionalidades do FMI-SiRO acessando diretamente a interface do SGBD, sem a neces-sidade de bibliotecas adicionais. Isto permite que aplicações desenvolvidas em qualquerlinguagem sejam capazes de recuperar dados complexos por similaridade através de umaconexão simples com o SGBD. Assim, múltiplas aplicações podem fazer uso comparti-lhado de um repositório centralizado de dados complexos, com integridade e segurançareforçadas e com funcionalidades de recuperação por similaridade.

O FMI-SiRO é implementado como uma biblioteca compartilhada dinâmica emC/C++, composta por um conjunto de funções para extração de características, funçõesde distância e funções de gerenciamento de índices para dados complexos. As funçõesde distância e os métodos de acesso são providos pela biblioteca Arboretum. Os extra-tores de características também são organizados em bibliotecas portáveis, o que facilita ainclusão de novos extratores. As operações de busca por similaridade são disponibiliza-das por novos operadores incorporados pelo FMI-SiR à linguagem SQL, que permitem arepresentação de operações por similaridade em sentenças SELECT padrão.

Com o FMI-SiRO, as principais etapas de um processo de recuperação por si-milaridade são atendidas. A Tabela 1.1 resume as funcionalidades implementadas noFMI-SiRO, relacionando-as com as tarefas de recuperação por similaridade diretamentesuportadas. Para explicar a implementação do FMI-SiRO, será utilizado um exemplo queconsidera a existência de uma tabela chamada image_table, contendo um identifica-dor id, um atributo image contendo uma imagem digital (dado complexo) e um atributo

5http://cross.dc.uel.br/projects/fmisir


48

image_sign, do tipo BLOB, para armazenar o vetor de características utilizado paradescrever o conteúdo da imagem, que é utilizado nas consultas por similaridade.

Tarefa Funcionalidade

Extração de característicasFunções generateSignature ereadSignatureFromFile

Cálculo de similaridade UDFs <distance_name>_distance

Indexação das característicasNovos tipos de índice Slim_<distance_name>e operadores para execução indexada<distance_name>_dist e <distance_name>_kNN

Tabela 1.1. Funcionalidades do FMI-SiRO para suporte à recuperação por similaridade.

1.7.2. Extração de Características

A primeira tarefa necessária à recuperação de dados complexos por similaridade é geraçãode vetores de características descrevendo o conteúdo do dado complexo armazenado. Odado complexo em si pode ser carregado e gerenciado pelo SGBD utilizando funções demanipulação de BLOBs. Isto permite que procedimentos eficientes de carga de grandesvolumes de dados providos pelo SGBD sejam utilizados.

A extração de características é embutida em funções do SGBD. No FMI-SiRO,a extração é feita por meio da função SQL generateSignature, que invoca extra-tores de características implementados em C++ na biblioteca compartilhada. A funçãogenerateSignature tem a forma:

generateSignature(complexData BLOB, signature BLOB,extractor VARCHAR, parameters VARCHAR)

onde o parâmetro complexData recebe o dado complexo de entrada, signature éo BLOB que irá armazenar o vetor de características gerado, extractor é o nome doextrator desejado e parameters é uma string contendo os parâmetros passados parao extrator de características. Esta função pode ser invocada em sentenças SQL, comoexemplificado a seguir:

FOR c IN (SELECT image, image_sign FROM image_table FOR UPDATE) LOOPgenerateSignature(c.image, c.image_sign, ’Histogram’, ’256’);

END LOOP;

onde c é um cursor iterando sobre as tuplas da relação image_table, c.image ec.image_sign são os atributos da tupla corrente do cursor que armazenam, respecti-vamente, a imagem de entrada e o vetor de características gerado, Histogram indicaque está sendo solicitado a extração do histograma de cores da imagem de entrada e oparâmetro 256 é o número desejado de bins do histograma. Observe-se que o vetor decaracterísticas é um parâmetro de saída, portanto, é necessário acessar este atributo utili-zando um bloqueio exclusivo, expresso no exemplo pela cláusula FOR UPDATE.

A extração de características também pode ser implementada em ferramentas exe-cutadas externamente ao SGBD. Neste caso, basta carregar os vetores de característicasgerados por essas ferramentas no banco de dados. No FMI-SiRO esta tarefa é realizadapor uma função SQL, denominada readSignatureFromFile, que tem a forma:


49

readSignatureFromFile(absoluteFileName VARCHAR, signature BLOB,numFeatures INT, offset INT)

onde absoluteFileName é o caminho absoluto para o arquivo contendo as caracterís-ticas, signature é o BLOB que irá guardar o vetor de características, numFeaturesé a quantidade de características a serem lidas do arquivo de entrada e offset é a quan-tidade de campos do arquivo de entrada a serem desconsiderados antes de começaremas características desejadas. O arquivo de entrada é um arquivo texto simples, contendoos valores das características separados por espaços. Esta função SQL mapeia para umafunção C++ da biblioteca compartilhada que serializa as características lidas do arquivode entrada em formato binário no BLOB informado no parâmetro signature.

1.7.3. Cálculo de Similaridade

Tendo computado os vetores de características, os dados complexos estão aptos para sercomparados por similaridade. Para isso, o FMI-SiRO fornece funções de distância, queretornam o valor de dissimilaridade entre dois vetores de características e podem ser cha-madas em sentenças SQL. As funções de distância são definidas no FMI-SiRO por meiode funções definidas pelo usuário (User-Defined Functions – UDFs) que têm a seguinteforma:

<distance_name>_distance(signature1 BLOB, signature2 BLOB)

onde <distance_name> é o nome da função de distância implementada. O FMI-SiROimplementa várias funções de distância, tais como a Manhattan_distance, aEuclidean_distance e a Canberra_distance. Além disso, novas funções dedistância podem ser incluídas de acordo com os requisitos das aplicações. As funçõesde distância do FMI-SiRO podem ser utilizadas para formular consultas por similaridade,com execução sequencial, utilizando a sintaxe SQL padrão. Por exemplo, a consulta aseguir é uma consulta por abrangência (Rq) sobre a tabela image_table, utilizandoa função de distância Manhattan (L1):

SELECT image FROM image_tableWHERE Manhattan_distance(image_sign, center_sign) <= 0.5;

onde center_sign é um BLOB contendo o vetor de características da imagem de con-sulta e o valor 0.5 é o limiar de dissimilaridade. As consultas aos k-vizinhos maispróximos (k-NNq) com execução sequencial são representadas utilizando funções de ja-nela (window functions) do padrão SQL, como no exemplo a seguir:

SELECT image FROM (SELECT image, ROW_NUMBER()

OVER (ORDER BY Manhattan_distance(image_sign, center_sign)) AS rnFROM image_table

) WHERE rn <= 10;

onde a função ROW_NUMBER atribui a um novo atributo (rn) a posição de cada tuplade acordo com a janela definida, que neste caso ordena as tuplas pelo valor da distânciaManhattan entre o vetor de características da imagem armazenada e o vetor de caracterís-ticas da imagem de consulta (center_sign). O atributo rn é, então, usado na condi-ção de filtragem consulta externa, para retornar apenas os k-vizinhos mais próximos (no


50

exemplo, k = 10). As variações da consultas Rq e k-NNq, as seleções por similaridadeagregada e as junções por similaridade também são representáveis usando o FMI-SiRO(mais detalhes em [Kaster, 2012]). Como já citado, as consultas apresentadas nesta seçãosão executadas por meio de uma varredura sequencial na tabela de entrada. Para melho-rar o desempenho de execução, é preciso oferecer índices para responder a buscas porsimilaridade, que é o assunto da próxima seção.

1.7.4. Indexação de Características

O SGBD Oracle provê uma interface extensível de indexação, que permite definir osmétodos necessários para implementar os novos tipos de índices. Estes métodos são en-capsulados em um tipo de dados que define uma classe de objetos, que possui a seguinteinterface:

CREATE OR REPLACE TYPE index_im_type AS OBJECT (scanctx RAW(4),STATIC FUNCTION ODCIIndexCreate(),STATIC FUNCTION ODCIIndexDrop(),STATIC FUNCTION ODCIIndexInsert(),STATIC FUNCTION ODCIIndexDelete(),STATIC FUNCTION ODCIIndexUpdate(),STATIC FUNCTION ODCIIndexStart(),MEMBER FUNCTION ODCIIndexFetch(),MEMBER FUNCTION ODCIIndexClose());

No FMI-SiRO, a implementação deste novo tipo de dados mapeia as funções de-claradas para funções externas C++ da biblioteca compartilhada dinâmica. A versão cor-rente do FMI-SiRO define um novo tipo de índices utilizando a implementação do MAMSlim-tree (Seção 1.5.2) na biblioteca Arboretum. Na verdade, o FMI-SiRO define umconjunto de novos tipos de índices baseados na Slim-tree, pois os MAMs são depen-dentes da função de distância utilizada para definir o espaço métrico onde os dados sãorepresentados. Então, há um novo tipo de índice Slim-tree para cada distância imple-mentada no FMI-SiRO: Slim_Manhattan, Slim_Canberra, etc. Além disso, ummesmo atributo armazenando um vetor de características pode possuir mais de um índiceSlim-tree, desde que utilizando funções de distância diferentes. Esta abordagem permiteefetuar buscas indexadas mediante diferentes combinações de vetores de características efunções de distância.

Novos tipos de índices no Oracle exigem a declaração de operadores para dispararas buscas sobre o índice. Na concepção da Oracle, um operador associa uma funçãodefinida pelo usuário a um tipo de índice. Por isso, o FMI-SiRO define um operador paraa consulta por abrangência e um operador para a consulta aos k-vizinhos mais próximospara cada função de distância implementada. Por exemplo, o operador de consulta porabrangência para a distância Manhattan é definido como:

CREATE OPERATOR Manhattan_dist BINDING (BLOB, BLOB)RETURN FLOAT USING Manhattan_distance;

onde Manhattan_distance é a função definida pelo usuário que implementa o cál-culo desta função de distância. O operador de consulta aos k-vizinhos mais próximos


51

(Manhattan_kNN) é definido de forma semelhante. Os novos tipos de índices essen-cialmente estabelecem a associação entre os operadores e os tipos de dados que de-finem as classes que contêm os métodos para manipular os índice. Por exemplo, ainstrução a seguir cria o tipo de índice Slim_Manhattan, associando os operadoresManhattan_dist e Manhattan_kNN ao tipo de dados index_im_type:

CREATE INDEXTYPE Slim_Manhattan FORManhattan_dist(BLOB, BLOB), Manhattan_kNN(BLOB, BLOB)USING index_im_type;

Com a definição do novo tipo de índice, o processador de consultas do SGBDpassa a aceitar a criação de índices usando este novo tipo. A sintaxe para criar índicesutilizando os novos tipos de índices disponibilizados pelo FMI-SiRO é a mesma usadapara criar índices de outros tipos. Por exemplo, a instrução a seguir cria um índice do tipoSlim_Manhattan sobre o atributo image_sign da tabela image_table:

CREATE INDEX image_sign_Slim_Manhattan_ix ON image_table(image_sign)INDEX TYPE IS Slim_Manhattan PARAMETERS (’8192’);

onde o único parâmetro considerado na implementação corrente do FMI-SiRO é o ta-manho em bytes das páginas do índice (8192). A criação de um índice disparao processo ilustrado na Figura 1.7. O processador de consultas invoca a funçãoODCIIndexCreate, definida no tipo de dados que implementa o índice, passando asinformações a respeito do índice a ser criado, tais como o nome da tabela e o nome doatributo a ser indexado (Passo 1). A função ODCIIndexCreate requisita à Arbore-tum a criação de uma Slim-tree vazia (Passo 2). Em seguida, a função consulta os dados(vetor de características e rowId) armazenados na tabela (Passo 3). Utilizando os locali-zadores de LOB (LobLocators) dos vetores de características, a função recupera os dadosdos BLOBs (Passo 4) e insere os vetores de características com os respectivos rowIdsna Slim-tree (Passo 5). Por fim, a função retorna o controle ao processador de consultas(Passo 6). Observe que os índices do FMI-SiRO são armazenados em arquivos de da-dos externos ao SGBD, gerenciados por meio da biblioteca Arboretum, que implementaacesso paginado aos dados e com controle de cache.

Os índices criados são dinamicamente atualizados quando ocorrem inserções(INSERT), remoções (DELETE) ou atualizações (UPDATE) nas tabelas indexadas.As funções que implementam estas operações nos índices (ODCIIndexInsert,ODCIIndexDelete e ODCIIndexUpdate) executam os passos 4-6 do processo decriação do índice, utilizando o LobLocator e o rowId da tupla atualizada, que são for-necidos pelo processador de consultas como parâmetros. Quando um índice é removido(via DROP INDEX, DROP TABLE, etc.), o processador de consultas invoca a funçãoODCIIndexDrop, que elimina o arquivo externo que armazenava o índice, e, em se-guida, remove do catálogo do banco as informações a respeito do índice.

Para executar consultas por similaridade sobre os novos tipos de índices ofere-cidos pelo FMI-SiRO é preciso utilizar os operadores associados nas consultas. Porexemplo, as consultas por abrangência devem ser escritas utilizando os operadores<distance_name>_dist no lugar das funções <distance_name>_distance


52

(sign)

Processadorde Consultas

1

5

3

2

4

6

Oracle Database

informações índice

criar estrutura

código de retorno

código de retorno

inserir elementoscódigo de retorno

cons

ulta

r atri

buto

+ ro

wId

s

vetores de

características

LobL

ocat

ors

LobLocators

(sig

n)

IndexCreate Arboretum

Arquivode

Índice

disk page

disk pageid

Figura 1.7. Passos executados pela função ODCIIndexCreate.

para poderem fazer uso de índices na sua execução. Desta forma, para que a Rq apresen-tada na Seção 1.7.3 possa ter uma execução indexada, ela tem que ser reescrita conformesegue:

SELECT image FROM image_tableWHERE Manhattan_dist(image_sign, center_sign) <= 0.5;

sendo que o comportamento do processador de consultas ao avaliar esta consulta é oseguinte. Ao encontrar o operador Manhattan_dist, o processador de consultastenta invocar uma consulta por abrangência no índice Slim_Manhattan construídosobre o atributo image_sign. Caso este índice não exista, o processador de consul-tas invoca a função Manhattan_distance para cada tupla da relação de entrada,efetuando uma execução sequencial da operação. Observe-se que se existir um índiceno atributo do vetor de características, mas que utiliza outra função de distância (porexemplo, um índice Slim_Euclidean) ele também não pode ser usado para execu-tar a consulta. A ordem dos parâmetros dos operadores também é importante para oprocessador de consultas. O primeiro parâmetro sempre deve ser o atributo indexado,caso contrário o índice não é invocado e o processador de consultas realiza a execu-ção sequencial da consulta. Ou seja, mesmo que exista um índice Slim_Manhattanno atributo image_sign, ele não será utilizado se a consulta for escrita usandoManhattan_dist(center_sign, image_sign), pois o atributo indexado é osegundo parâmetro.

As consultas aos k-vizinhos mais próximos com execução indexada noFMI-SiRO utilizam uma sintaxe semelhante às consultas por abrangência, porém usandoos operadores <distance_name>_kNN. Por exemplo, a k-NNq apresentada na Se-ção 1.7.3 deve ser escrita conforme segue para ter execução indexada:

SELECT image FROM image_tableWHERE Manhattan_kNN(image_sign, center_sign) <= 10;

retornando os 10 vizinhos mais próximos ao vetor de características de consultacenter_sign, considerando a distância Manhattan. Observe-se que a sintaxe para a


53

execução de k-NNq indexadas no FMI-SiRO não utiliza funções de janela, como ocorrecom as k-NNq com execução sequencial. Esta é uma restrição imposta pela interface deindexação da arquitetura extensível do Oracle. Um efeito colateral desta restrição é que aoescrever uma k-NNq utilizando a sintaxe da execução indexada, se não existir um índicepara executar esta operação, o FMI-SiRO solicita ao processador de consultas que aborte aexecução, emitindo uma mensagem de erro ao usuário. Isto porque o FMI-SiRO não é ca-paz de reescrever automaticamente a consulta segundo a sintaxe da execução sequencial,pois no contexto da função não há informação suficiente para isso.

1

5

3

2

4

6

78

10

9

14

12

11

13

consultaSQL

resultadocódigo de retorno

código de retorno

código de retorno

consulta no índice

elementosrowIds (aloc. mem.)context key

context key

context key (liber. m

em.)

params +

(center sign)

LobLocator

(center sign)

LobLocator

center sign

número de linhas

rowIdschamada final

rowIds

rowIds

tuplas

(tuplas)

Arboretum

Arquivode

Índice

disk page

disk pageid

IndexStart

IndexFetch

IndexClose

ContextArea

Processadorde Consultas

Oracle Database

Aplicação

Figura 1.8. Execução de uma consulta por similaridade indexada no FMI-SiRO.

A execução de uma busca indexada no FMI-SiRO ocorre como ilustradona Figura 1.8. A aplicação envia uma consulta SQL para o SGBD (Passo 1).Quando o processador de consultas do SGBD identifica um operador por similaridade(<distance_name>_dist ou <distance_name>_kNN), ele consulta o catálogodo banco procurando por um índice associado a este operador para executar a opera-ção de busca. Se o índice é encontrado, o processador de consultas chama a funçãoODCIIndexStart, passando informações sobre o operador, sobre o índice e sobre opredicado utilizado, e também o LobLocator do vetor de características de consulta e olimitante da busca (o limiar de dissimilaridade, para consultas baseadas em abrangência,ou o número de vizinhos, para consultas aos vizinhos mais próximos/distantes) (Passo 2).A função ODCIIndexStart carrega o vetor de características apontado pelo LobLo-cator do elemento de consulta (Passo 3) e executa a consulta indicada sobre o índice nabiblioteca Arboretum (Passo 4). Então, a função armazena os rowIds dos elementos re-tornados pelo índice na área de contexto da sessão corrente do usuário, identificando áreade memória por uma chave única (Passo 5). A chave de identificação da área de contextoé armazenada na variável scanctx do objeto do tipo de dados que implementa o índice,para ser utilizada nas próximas funções invocadas (fetch e close). A função, então, retorna


54

o controle ao processador de consultas (Passo 6). Em seguida, o processador de consultainvoca a função ODCIIndexFetch, fornecendo o número de linhas nrows a serem recu-peradas (Passo 7). A função ODCIIndexFetch obtém a chave de identificação da áreade contexto, acessando na variável scanctx do objeto que implementa o índice, e recu-pera os primeiros nrows rowIds armazenados na área de contexto (Passo 8), retornando-osao processador de consultas (Passo 9). Se houverem mais rowIds no resultado, o proces-sador de consultas faz novas chamadas à função ODCIIndexFetch, até que o conjuntode resultados seja completado. Quando a fase de recuperação do resultado é finalizada,o processador de consultas chama a função ODCIIndexClose para encerrar a busca(Passo 10). A função ODCIIndexClose recupera a chave da área de contexto, libera amemória alocada para armazenar os resultados da busca (Passo 11) e retorna o controleao processador de consultas (Passo 12).

Como o FMI-SiRO utiliza as interfaces da arquitetura extensível do Oracle, o oti-mizador de consultas é ciente das buscas por similaridade indexadas. Desta forma, eleé capaz de intercalar a execução de buscas por similaridade com as demais operaçõessuportadas pelo SGBD, de forma a identificar os caminhos de acesso mais eficientes aosdados. No plano de execução gerado pelo processador de consultas do Oracle, uma buscapor similaridade indexada é identificada como uma varredura em um índice de domínio(DOMAIN INDEX). A listagem a seguir mostra o plano de execução gerado para a k-NNqapresentada nesta seção:

|Id | Operation | Name |------------------------------------------------------------------| 0 | SELECT STATEMENT | || 1 | TABLE ACCESS BY INDEX ROWID| IMAGE_TABLE || 2 | DOMAIN INDEX | IMAGE_SIGN_SLIM_MANHATTAN_IX |

É fundamental observar que, embora as consultas apresentadas na descrição doFMI-SiRO considerem operações baseadas em similaridade, estas operações podem serutilizadas em conjunto com as demais operações de consulta fornecidas pelo SGBD.Desta forma, é possível executar consultas complexas envolvendo operações baseadas emsimilaridade e operações relacionais tradicionais, utilizando a sintaxe SQL apresentada.

1.8. Inclusão de Consultas por Similaridade no Padrão SQLUma outra alternativa para inclusão de consultas por similaridade em SGBDs consisteem estender a linguagem SQL. Barioni et al. [2009] propuseram uma extensão à SQL in-cluindo novos tipos para dados complexos, instruções de definição de dados para associaratributos de tipos complexos a extratores de características e funções de distância e umasintaxe enxuta para representação de consultas por similaridade.

Nesta proposta, os dados complexos são armazenados em novos tipos: monolíti-cos e particulado. Os tipos monolíticos armazenam dados em formato binário. Exemplosde tipos monolíticos são STILLIMAGE e AUDIO, definidos para armazenar imagens etrilhas de áudio. O tipo particulado (PARTICULATE) é usado para agregar atributosde uma tabela que representam um dado complexo. Por exemplo, as coordenadas ge-ográficas de um elemento podem ser armazenadas em dois atributos distintos de umatabela. Definindo-se um atributo do tipo PARTICULATE agregando os dois atributos


55

de coordenada permite-se que eles sejam tratados em conjunto no processo de avaliaçãode similaridade. A associação entre um tipo de dado complexo e a instância do espaçode similaridade desejada (formada pelo vetor de características e a função de distância –cf. Seção 1.2) é feita por meio de uma nova instrução de definição de dados, denominadaCREATE METRIC. Sem entrar em detalhes sobre a sintaxe completa desta operação, ainstrução a seguir exemplifica a definição de uma métrica de similaridade sobre o tipoSTILLIMAGE que utiliza um histograma de cores para representar as imagens e a funçãode distância Manhattan para calcular a dissimilaridade:

CREATE METRIC HistogramL1 USING LP1 FOR STILLIMAGE(HistogramEXT (HistogramFeature AS Histo));

onde HistogramL1 é o nome da métrica, LP1 indica a distância Manhattan,HistogramEXT é o nome do extrator de características, HistogramFeature é onome da característica extraída e Histo é um alias para acessar esta característica emuma consulta. Métricas de similaridade são associadas a atributos complexos por meiode uma restrições do tipo METRIC. Por exemplo, a instrução a seguir cria uma tabelacontendo um atributo STILLIMAGE associado à métrica HistogramL1 definida ante-riormente:

CREATE TABLE image_table (id INT PRIMARY KEY,image STILLIMAGE METRIC USING (HistogramL1));

Note-se que a tabela criada não contém um atributo para armazenar o vetor de ca-racterísticas que descreve a imagem. Isto porque a proposta é que o usuário concentre-seapenas nos dados do seu domínio de aplicação, portanto, as características e outros dadosauxiliares devem ser armazenados implicitamente em um catálogo específico gerenciadopelo mecanismo de busca por similaridade. As consultas por similaridade são representa-das em instruções SELECT utilizando novas construções sintáticas. Na cláusula WHERE,utiliza-se a seguinte construção:

<atributo> NEAR [ANY|ALL|SUM|MAX] <Q> [STOP AFTER <k>] [RANGE <ξ>]

onde <atributo> é o nome de um atributo complexo, NEAR indica que trata-se de umaoperação por similaridade, os termos ANY, ALL, SUM e MAX são usados para representarconsultas por similaridade agregada e junções por similaridade, <Q> é o conjunto deelementos de consulta e os termos [STOP AFTER <k>] e [RANGE <ξ>] indicam,respectivamente, que a consulta é baseada em vizinhos mais próximos e/ou abrangência.Usando esta construção sintática, as consultas a seguir são exemplos de uma Rq, comξ = 0,5, e de uma k-NNq, com k = 10, respectivamente:

SELECT image FROM image_tableWHERE image NEAR ’center_image.jpg’ RANGE 0.5;

SELECT image FROM image_tableWHERE image NEAR ’center_image.jpg’ STOP AFTER 10;

onde center_image.jpg é a imagem de referência cujo vetor de características égerado automaticamente na execução da consulta.


56

O SIREN6 (SImilarity Retrieval ENgine) [Barioni et al., 2005] é um protótipo emC++ que implementa sobre os SGBDs Oracle e PostgreSQL um interpretador para a ex-tensão à linguagem SQL apresentada nesta seção. O SIREN utiliza funções de distância eestruturas de indexação da biblioteca Arboretum para executar as consultas por similari-dade e implementa extratores de características. As aplicações conectam-se ao SIREN esubmetem instruções da SQL estendida. Se as instruções utilizam apenas operações SQLpadrão, o interpretador repassa as instruções diretamente ao SGBD, que as executa e de-volve o resultado obtido. Se o interpretador detecta uma instrução estendida de definiçãode dados, ele trata esta instrução e atualiza o catálogo específico do SIREN conforme ne-cessário. Atualizações e consultas também são interceptadas. Por exemplo, nas inserçõese modificações o interpretador invoca o processo extração de características dos dadoscomplexos de forma transparente, com base nas métricas de similaridade associadas aosatributos de tipos complexos, e armazena os vetores de características gerados no catá-logo do SIREN. Nas consultas, se o interpretador detecta uma operação por similaridade,ele executa esta operação sobre os índices na Arboretum, reescreve a consulta originalsubstituindo a operação por similaridade por uma subconsulta baseada no conjunto deidentificadores dos elementos retornados pela consulta por similaridade. A consulta rees-crita é enviada ao SGBD, que retorna as tuplas que satisfazem a consulta por similaridadee os demais critérios fornecidos, se for o caso.

1.9. Conclusão e Linhas de PesquisaEste capítulo apresentou os principais conceitos e técnicas relacionados a consultas porsimilaridade e estudos de caso de inclusão de suporte a estas operações em SGBDs. Em-bora a área de recuperação por similaridade tenha evoluído consideravelmente nos últimosanos, ainda há vários tópicos de pesquisa em aberto. Dentre outros tópicos, pode-se citar:

• proposta de novas operações de busca por similaridade, a exemplo da consulta k-NNestendida com condições [Kaster, 2012, Kaster et al., 2011b];

• desenvolvimento de algoritmos e estruturas de dados que permitam executar efici-entemente consultas multi-critério envolvendo condições baseadas em similaridade;

• desenvolvimento de métodos de previsão de seletividade e de custo para os diversostipos de consultas por similaridade;

• extensão dos métodos de busca para uso de funções não métricas de dissimilaridade;

• desenvolvimento de algoritmos de análise e mineração de dados baseados em con-sultas por similaridade;

• definição de estratégias para reduzir a lacuna semântica entre a similaridade com-putada pelos sistemas de recuperação por similaridade e a expectativa do usuário, afim de aprimorar da qualidade dos resultados.

AgradecimentosEste trabalho teve apoio do CNPq, da FAPESP e da Capes.

6http://gbdi.icmc.usp.br/siren


57

ReferencesM. C. N. Barioni, H. L. Razente, J. Traina, Caetano, and A. J. M. Traina. Querying

complex objects by similarity in SQL. In SBBD, pages 130–144, Uberlândia, MG,2005. SBC.

M. C. N. Barioni, H. L. Razente, A. J. M. Traina, and C. Traina Jr. Seamlessly integratingsimilarity queries in SQL. Software, Practice Experience, 39(4):355–384, 2009.

M. C. N. Barioni, D. S. Kaster, H. L. Razente, A. J. M. Traina, and C. Traina Jr. Ad-vanced Database Query Systems: Techniques, Applications and Technologies, chapterQuerying Multimedia Data by Similarity in Relational DBMS. IGI Global, Hershey,Pennsylvania, USA, 2011.

J. M. Barrios and B. Bustos. Automatic weight selection for multi-metric distances. InSISAP, pages 61–68, Lipari Island, Italy, 2011. ACM.

N. Beckmann, H.-P. Kriegel, R. Schneider, and B. Seeger. The R*-tree: An efficient androbust access method for points and rectangles. In SIGMOD, pages 322–331. ACM,1990.

R. Belohlávek and V. Vychodil. Query systems in similarity-based databases: logicalfoundations, expressive power, and completeness. In SAC, pages 1648–1655, Sierre,Switzerland, 2010. ACM.

H. M. Blanken, A. P. de Vries, H. E. Blok, and L. Feng, editors. Multimedia Retrieval.Data-Centric Systems and Applications. Springer, 1 edition, 2007.

T. Bozkaya and Z. M. Özsoyoglu. Distance-based indexing for high-dimensional metricspaces. In SIGMOD, pages 357–368, Tucson, AZ, 1997. ACM.

R. Bueno, D. S. Kaster, A. A. Paterlini, A. J. M. Traina, and C. T. Jr. Unsupervisedscaling of multi-descriptor similarity functions for medical image datasets. In CBMS,pages 1–8, Albuquerque, New Mexico, USA, 2009. IEEE.

C. Böhm and F. Krebs. High performance data mining using the nearest neighbor join. InICDM, pages 43–50, Maebashi City, Japan, 2002. IEEE.

C. Böhm, S. Berchtold, and D. A. Keim. Searching in high-dimensional spaces - indexstructures for improving the performance of multimedia databases. ACM ComputingSurveys, 33(3):322 – 373, 2001.

P. Ciaccia, M. Patella, and P. Zezula. M-tree: An efficient access method for similaritysearch in metric spaces. In VLDB, pages 426–435, Athens, Greece, 1997. MorganKaufmann.

R. Datta, D. Joshi, J. Li, and J. Z. Wang. Image retrieval: Ideas, influences, and trends ofthe new age. ACM Computing Surveys, 40(2):1–60, 2008.

M. R. P. Ferreira, A. J. M. Traina, I. Dias, R. Chbeir, and C. T. Jr. Identifying algebraicproperties to support optimization of unary similarity queries. In AMW, volume 450 ofCEUR Workshop Proceedings, Arequipa, Peru, 2009. CEUR-WS.org.


58

C. Gauker. A critique of the similarity space theory of concepts. Mind & Language, 22(4):317–345, 2007.

A. Guttman. R-tree : A dynamic index structure for spatial searching. In SIGMOD, pages47–57, Boston, MA, 1984. ACM.

I. Guyon and A. Elisseeff. An introduction to variable and feature selection. Journal ofMachine Learning Research, 3:1157–1182, 2003.

X. He, W.-Y. Ma, O. King, M. Li, and H. Zhang. Learning and inferring a semanticspace from user’s relevance feedback for image retrieval. In ACM Multimedia, pages343–346, Juan-les-Pins, France, 2002. ACM.

G. R. Hjaltason and H. Samet. Distance browsing in spatial databases. ACM Transactionson Database Systems, 24(2):265 – 318, 1999.

D. S. Kaster. Tratamento de condições especiais para busca por similaridade em bancosde dados complexos. PhD thesis, Instituto de Ciências Matemáticas e de Computação(ICMC), Universidade de São Paulo (USP), 2012.

D. S. Kaster, P. H. Bugatti, A. J. M. Traina, and C. Traina Jr. FMI-SiR: A flexible andefficient module for similarity searching on Oracle database. Journal of Informationand Data Management, 1(2):229–244, 2010.

D. S. Kaster, P. H. Bugatti, M. Ponciano-Silva, A. J. M. Traina, P. M. A. Marques, A. C.Santos, and C. Traina Jr. MedFMI-SiR: A powerful DBMS solution for large-scalemedical image retrieval. In ITBAM, volume 6865 of Lecture Notes in Computer Sci-ence, pages 16–30. Springer, 2011a.

D. S. Kaster, W. D. Oliveira, R. Bueno, A. J. M. Traina, and C. Traina Jr. Nearest neighborqueries with counting aggregate-based conditions. Journal of Information and DataManagement, 2(3):401–416, 2011b.

M. Kokare, B. Chatterji, and P. Biswas. Comparison of similarity metrics for textureimage retrieval. In Conference on Convergent Technologies for Asia-Pacific Region,volume 2, pages 571–575, 2003.

K.-M. Lee and W. N. Street. Incremental feature weight learning and its application to ashape-based query system. Pattern Recognition Letters, 23(7):865–874, 2002.

C. Li, K. C.-C. Chang, I. F. Ilyas, and S. Song. RankSQL: Query algebra and optimizationfor relational top-k queries. In SIGMOD, pages 131–142, Baltimore, Maryland, USA,2005. ACM.

P. C. Mahalanobis. On the generalised distance in statistics. Proceedings of the NationalInstitute of Sciences of India, 2(1):49–55, 1936.

J. Pan and D. Manocha. Fast GPU-based locality sensitive hashing for k-nearest neighborcomputation. In ACM GIS, pages 211–220. ACM, 2011.


59

D. Papadias, Y. Tao, K. Mouratidis, and C. K. Hui. Aggregate nearest neighbor queries inspatial databases. ACM Transactions on Database Systems, 30(1):529 – 576, 2005.

W. Penzo. Rewriting rules to permeate complex similarity and fuzzy queries within arelational database system. IEEE Transactions on Knowledge and Data Engineering,17(2):255–270, 2005.

H. L. Razente, M. C. N. Barioni, A. J. M. Traina, and C. Traina Jr. Aggregate similarityqueries in relevance feedback methods for content-based image retrieval. In SAC, pages869–874, Fortaleza, Ceara, Brazil, 2008. ACM.

J. T. Robinson. The k-d-b-tree: A search structure for large multidimensional dynamicindexes. In SIGMOD, pages 10–18. ACM, 1981.

N. Roussopoulos, S. Kelley, and F. Vincent. Nearest neighbor queries. In M. J. Carey andD. A. Schneider, editors, SIGMOD, pages 80–91, San Jose, CA, 1995. ACM.

Y. N. Silva, W. G. Aref, and M. H. Ali. Similarity group-by. In ICDE, pages 904–915,Shanghai, China, 2009. IEEE.

C. Traina Jr., A. J. M. Traina, C. Faloutsos, and B. Seeger. Fast indexing and visualiza-tion of metric datasets using Slim-trees. IEEE Transactions on Knowledge and DataEngineering, 14(2):244–260, 2002.

C. Traina Jr., A. J. M. Traina, M. R. Vieira, A. S. Arantes, and C. Faloutsos. Efficientprocessing of complex similarity queries in RDBMS through query rewriting. In CIKM,pages 4–13, Arlington, VA, USA, 2006.

C. Traina Jr., R. F. S. Filho, A. J. M. Traina, M. R. Vieira, and C. Faloutsos. The omni-family of all-purpose access methods: a simple and effective way to make similaritysearch more efficient. The International Journal on Very Large Databases, 16(4):483–505, 2007.

M. R. Vieira, J. Traina, Caetano, F. J. T. Chino, and A. J. M. Traina. DBM-tree: Tradingheight-balancing for performance in metric access methods. Journal of The BrazilianComputer Society, 11(3):37–52, 2006.

M. R. Vieira, J. Traina, Caetano, A. J. M. Traina, A. S. Arantes, and C. Faloutsos. Es-timating suitable query radii to boost k-nearest neighbor queries. In SSDBM, Banff,Canada, 2007. ACM Press.

D. R. Wilson and T. R. Martinez. Improved heterogeneous distance functions. Journal ofArtificial Intelligence Research, 6:1–34, 1997. Morgan Kaufmann Publishers.

P. N. Yianilos. Data structures and algorithms for nearest neighbor search in generalmetric spaces. In ACM/SIGACT-SIAM SODA, pages 311–321, Austin, TX, 1993.

Y.-H. Yuan, Q.-S. Sun, Q. Zhou, and D.-S. Xia. A novel multiset integrated canonical cor-relation analysis framework and its application in feature fusion. Pattern Recognition,44:1031–1040, 2011.


60

Documents

27th BRAZILIAN SYMPOSIUM ON DATABASES - USPdata.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_min_cc.pdf · 27th BRAZILIAN SYMPOSIUM ON DATABASES ... Linguagens e Estudos de Casos no Contexto