Carlos Filipe Marques Teixeira Júnior. Guilherme Rangel Ferreira. RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS - PDF
Download "Carlos Filipe Marques Teixeira Júnior. Guilherme Rangel Ferreira. RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS"
Victor Gabriel Carmona Casado
1 Universidade Federal Fluminense Instituto de Computação Departamento de Ciência da Computação Carlos Filipe Marques Teixeira Júnior Guilherme Rangel Ferreira UMA COMPARAÇÃO ENTRE SGBD S RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS Niterói-RJ 2014
2 ii CARLOS FILIPE MARQUES TEIXEIRA JÚNIOR GUILHERME RANGEL FERREIRA UMA COMPARAÇÃO ENTRE SGBD S RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS Monografia apresentada por Carlos Filipe Marques Teixeira Júnior e Guilherme Rangel Ferreira como exigência do curso de bacharelado em Ciência da Computação da Universidade Federal Fluminense sob a orientação do professor Daniel Cardoso Moraes de Oliveira. Orientador: Prof. DANIEL CARDOSO MORAES DE OLIVEIRA Niterói-RJ 2014
3 iii CARLOS FILIPE MARQUES TEIXEIRA JÚNIOR GUILHERME RANGEL FERREIRA UMA COMPARAÇÃO ENTRE SGBD S RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS Monografia apresentada por Carlos Filipe Jr e Guilherme Rangel Ferreira como exigência do curso de bacharelado em Ciência da Computação da Universidade Federal Fluminense sob a orientação do professor Daniel de Oliveira. Aprovado por: Prof. DANIEL CARDOSO MORAES DE OLIVEIRA, D.Sc. - Orientador IC-UFF Prof. VANESSA BRAGANHOLO MURTA, D.Sc. IC-UFF KARY A. C. S. OCAÑA, D.Sc. COPPE-UFRJ Niterói-RJ 2014
4 iv Agradecimentos Agradecemos àqueles que são a nossa base, nossos pais, irmãos e familiares, pela paciência em épocas de provas e trabalhos; pelos incentivos; preocupações; e apoio incondicional, sem os quais teria sido muito mais difícil atingir nossos objetivos e chegar aonde chegamos. Aos nossos colegas de faculdade, pelos inúmeros momentos de felicidades e risadas nos intervalos, nas aulas e no dia-a-dia; pelas noites sem dormir estudando juntos; e por toda ajuda e amizade nesses mais de quatro anos de universidade e além. Aos nosso professores ao longo desse curso, pela excelência; pelos importantes ensinamentos, didáticos e de vida; e pelo comprometimento com o nosso aprendizado. Ao nosso orientador, Daniel de Oliveira, por toda a paciência, apoio e dedicação ao longo de todo o tempo em que trabalhamos juntos. Esse projeto com certeza não teria a mesma qualidade sem ele. À professora Vanessa Braganholo e à doutora Kary Ocaña por terem aceitado participar da banca. A todos aqueles que nos ajudaram de alguma maneira, mesmo que de forma sutil e indireta, na realização desse projeto.
5 v Resumo A chamada e-science é, atualmente, detentora da crescente atenção de muitos estudos. Tal área é facilitada pela existência de workflows científicos, responsáveis por gerir os recursos disponíveis, otimizando assim o desempenho, e tirar a preocupação do cientista no que diz respeito a encadear os resultados de cada passo do processo. Um fator muito importante para experimentos científicos é, em geral, a proveniência dos dados, que documenta todos os dados e passos tomados para chegar em um determinado resultado. Com isso, ela permite a reprodutibilidade do experimento, tornando-o válido para a comunidade científica. A proveniência pode ser armazenada de diversas maneiras: bancos de dados relacionais, RDF, etc. Cada um deles com vantagens e desvantagens. Entretanto, muitas dessas abordagens não escalam e com o aumento do volume de dados de proveniência isso pode ser um problema. Com o surgimento dos SGBDs NoSQL, cujo foco é a escalabilidade, pode ter surgido uma solução simples para o armazenamento escalável da proveniência. A principal contribuição deste trabalho se dá pela migração dos dados de proveniência de um banco relacional para um banco de dados NoSQL, comparando-se diversos fatores, como desempenho, escalabilidade e robustez. Palavras-chave: e-science, workflow científico, banco de dados NoSQL, computação em nuvem, sistema gerenciador de workflows científicos, SGWfC.
6 vi Abstract The so-called e-science is, nowadays, the detainer of the growing attention of many studies. Such area is eased by the existence of scientific workflows, which are responsible of managing the available resources, thus optimizing the performance, and linking the results of each step of the whole process, freeing the scientist of this concern. A very important matter for scientific experiments is, in general, the data provenance, which documents all the data and steps taken towards a specific result. Therefore, it allows the reproducibility of the experiment, making it valid to the scientific community. Provenance can be stored in several ways: relational databases, RDF, etc. Each one of them has it s own advantages and disadvantages. However, many of those approaches don t scale and with the increase of the provenance data volume this can be an issue. With the appearance of the NoSQL DBMSs, which focus is scalability, may have arisen a simple solution for scalable storage of provenance data. The main contribution of this work is the migration of the provenance data from a relational database to a NoSQL database, having several factors compared, such as performance, scalability and toughness. Keywords: e-science, scientific workflow, NoSQL database, cloud computing, scientific workflow management system, SWfMS.
7 Sumário Resumo Abstract Lista de Figuras v vi ix 1 Introdução 1 2 Conceitos Relacionados E-Science Workflows Científicos Proveniência Computação em Nuvem NoSQL Cassandra SciCumulus Introdução Conceitos Gerais Arquitetura Testes e Considerações Finais Desenvolvimento Abordagem Proposta Modelagem Modificação do Driver de Acesso ao Banco Distribuição do Banco de Dados vii
8 viii 5 Análise de Resultados Ambiente de Execução Casos de Testes Trabalhos Relacionados 30 7 Conclusão 32 Apêndice A Script de Criação da Keyspace 39
9 ix Lista de Figuras 2.1 Um exemplo de um workflow para a previsão do tempo para uma cidade Script em SQL Script em CQL Arquitetura Conceitual do Scicumulus Resultados do Scicumulus Query modificada Comparação dos scripts de criação em SQL e CQL Inicialização da keyspace do Cassandra Tempo de execução do workflow SciPhy Tempo de execução de quatro workflows concorrentes
10 Capítulo 1 Introdução Vários dos novos problemas na área de computação são relacionados à área que foi popularmente denominada de Big Data. O termo Big Data [1] é usado para descrever qualquer coleção de conjuntos de dados que são tão grandes e complexos que se torna difícil trabalhar com esses dados usando as técnicas de processamento de dados tradicionais. Um desses problemas é o de como gerenciar e guardar de forma eficiente os dados de proveniência [2] em workflows científicos [3]. Quando um cientista roda um experimento científico, na grande maioria das vezes, ele precisa que o experimento termine o mais rápido e eficientemente possível, para que ele possa coletar os resultados e prosseguir com a sua pesquisa. Também, para melhor entender e analisar os resultados, é interessante que ele possa ter os dados de proveniência, dados estes que detalham e documentam a história e os caminhos dos dados de entrada, desde o início do experimento até o final. Além disso, outra ferramenta bastante útil para os cientistas são os workflows científicos, que eximem do cientista, que na maioria das vezes não possui um conhecimento aprofundado em computação, a responsabilidade de gerenciar e encadear os dados entre experimentos, automatizando, assim, esse processo. Logo, o problema do armazenamento de dados de proveniência é um problema importante para a comunidade científica. Quando os experimentos científicos são executados, muitas das vezes são geradas quantidades enormes de dados de proveniência, e a atividade de escrever esses dados no banco de dados pode ser um grande gargalo para o bom desempenho geral do experimento. No momento, muitos dos workflows científicos escrevem os seus dados em bancos de dados relacionais [2]. Os cientistas utilizam essa abordagem, principalmente, por causa da sua difusão e da facilidade de utilização da lin-
11 2 guagem de consultas SQL. Os bancos de dados relacionais atuais são bastante eficientes, porém eles possuem a desvantagem de não serem muito escaláveis, ou seja, para conjuntos de dados muito grandes, o desempenho deles não é proporcional ao aumento do volume de dados. Na era do Big Data, é necessário criar soluções que armazenem e processem grandes quantidades de dados sem que haja perda de desempenho. Além disso, tendências em arquiteturas de computadores, como a computação em nuvem [4] e a necessidade crescente de prover serviços escaláveis, estão fazendo com que, nos últimos anos, surjam os SGBDs (i.e. Sistemas Gerenciadores de Banco de Dados) NoSQL, com o foco em escalabilidade. Bases de dados NoSQLs são abordagens que sacrificam as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) [5] em troca de escalabilidade horizontal, com formas de armazenamento diversas: desde grafos, passando por documentos, até colunas largas (onde os valores são armazenados em colunas, ao invés de em linhas como no modelo relacional). Devido a isso, este trabalho se foca na migração dos dados de proveniência de um banco de dados relacional para um banco de dados não-relacional, que possui a vantagem de ser completamente escalável e eficiente para grandes volumes de dados, além de possuir a vantagem de ser facilmente distribuído em diferentes máquinas. O banco a ser migrado é o banco de dados de proveniência do SciCumulus [6], um Sistema de Gerência de Workflows Científicos (SGWfC), que executa workflows em paralelo em ambientes de nuvem. Dentre os bancos de dados não-relacionais analisados, o escolhido para teste e implementação foi o Cassandra [7], um banco de dados conhecido por ser altamente escalável e de fácil gerenciamento de distribuição. Além da migração da base de dados para uma base não-relacional, faremos uma análise comparativa entre os resultados obtidos pela versão anterior, com o banco de dados relacional PostgreSQL, e com o banco de dados não-relacional Cassandra, analisando características como escalabilidade e desempenho.
12 Capítulo 2 Conceitos Relacionados 2.1 E-Science No início, o termo e-science [8] era normalmente utilizado para descrever as ciências que faziam uso de ambientes de redes altamente distribuídos e que usavam um volume de dados imenso, requerendo assim um trabalho computacional intensivo e muitas vezes técnicas capazes de lidar com um volume grande de dados, como computação em grid. Atualmente o termo já é utilizado de forma mais genérica, sendo usado para descrever a ciência onde se tem a aplicação da computação no empreendimento da pesquisa científica moderna, incluindo as etapas de preparação, experimentação, coleta de dados, disseminação dos resultados, acessibilidade e armazenamento em longo prazo de todo o material gerado durante o processo científico [9]. Esse material normalmente inclui a análise e modelagem dos dados, conjuntos de dados brutos e ajustados, produção de manuscritos e esboços, publicações diversas, etc. Outra característica da e-science é o reuso dos dados, fazendo assim com que os cientistas e pesquisadores economizem tempo e dinheiro ao prevenir a necessidade de duplicar a coleta de dados, principalmente em casos nos quais essa coleta é longa, podendo durar anos e até décadas. Ela também permite a modelagem e a simulação computacional dos dados coletados, aumentando assim a eficiência e reduzindo o tempo de introdução do produto no mercado, no caso de produtos médicos e científicos. Em suma, a e-science possui a habilidade de permitir a exploração de teorias a fim de pesquisa e também de ajudar a solucionar problemas nas áreas da saúde, meio ambiente, energia, indústria tecnológica, entre outros.
13 4 Graças aos recursos computacionais da e-science, como a capacidade para lidar com grandes volumes de dados e de gerenciar redes e aplicações distribuídas, ela é amplamente utilizada pelas outras ciências, como por exemplo, biomedicina, biologia computacional, física, química, geologia, etc., e até mesmo as ciências sociais que compartilham os mesmos métodos de pesquisa com as ciências naturais. 2.2 Workflows Científicos O termo workflow [10] é usado para descrever a progressão e a sequência dos passos (tarefas, eventos, interações), muitas vezes automatizados, de processos industriais, administrativos, etc., pelo qual uma parte do trabalho vai do estado inicial até o final, visando criar ou adicionar valor para as atividades da organização. Em um workflow sequencial, cada passo depende da ocorrência e, às vezes, do resultado do passo anterior; já em um workflow paralelo dois ou mais passos podem ocorrer concomitantemente. Workflows científicos [11] são um tipo específico de workflow focados em analisar, compor e executar uma série de passos computacionais e de manipulação de dados em uma aplicação científica. Um dos objetivos dos workflows científicos é combater a alta complexidade nas aplicações e experimentos científicos atuais, onde muitas vezes esses problemas estão ligados com os desafios da e-science. Os workflows científicos são geralmente caracterizados por descrever os processos em termos do fluxo de dados, ao invés do foco em fluxo de controle dos workflows empresariais. Experimentos em e-science dependem da habilidade de realizar projetos científicos colaborativos usando grandes conjuntos de dados, que normalmente são distribuídos entre diferentes redes de computadores ou grids. Processos automatizados, utilizados para obter resultados bem-sucedidos em experimentos e simulações, abrangem várias ações relacionadas aos dados, incluindo: aquisição, transformação, análise, visualização, etc. Esses processos precisam ser lógicos, estruturáveis, confiáveis, repetíveis e verificáveis, também sendo possível fazer a examinação posterior desses resultados para fins legais, avaliação da pesquisa, e de pedidos de financiamento. As técnicas de workflow garantem que os procedimentos automatizados são feitos na ordem correta, de acordo com um conjunto pré-definido de regras, para atingir um objetivo final, como mostrado na Figura 2.1. Usando essas técnicas para modelar e im-
14 plementar experimentos automatizados podemos garantir que o objetivo do experimento é alcançado e que os resultados possuem integridade. 5 Figura 2.1: Um exemplo de um workflow para a previsão do tempo para uma cidade. 2.3 Proveniência A proveniência [12] de dados pode ser descrita como a história do dado, e as entidades, entradas, sistemas e processos que influenciaram o dado, provendo assim um registro da história do dado e das suas origens. Podemos dizer que os dados de proveniência representam as respostas para as sete perguntas sobre os dados originais [13], sendo elas: quem, o que, onde, por que, quando, qual e como. Os dados de proveniência possuem diversas aplicações, de acordo com Simmhan [14], como por exemplo: qualidade dos dados, onde a linhagem dos dados de proveniência é usada para estimar a qualidade e a confiança dos dados finais com base nos dados originais e suas transformações, além de poder também fornecer provas sobre as origens dos dados; trilha de auditoria, onde os dados de proveniência podem ser usados para traçar uma rota de auditoria do dado, determinar o uso dos recursos e detectar erros na
15 6 criação dos dados; reprodutibilidade, onde, com informações detalhadas sobre os dados de proveniência, é possível reproduzir o processo; atribuição, onde se pode estabelecer os direitos de cópia e saber quem são os donos dos dados, além de permitir a sua citação e atribuir responsabilidade em caso de erro nos dados; informacional, onde se é possível realizar consultas baseando-se na linhagem para a descoberta de dados, além de fornecer o contexto necessário para interpretar tais dados. De uma maneira geral, a proveniência pode ser caracterizada em duas formas: prospectiva e retrospectiva [15] [16]. A proveniência prospectiva está interessada em capturar e armazenar os dados relativos à estrutura do processo que levou à geração de um determinado produto. Ou seja, no contexto de workflows científicos, a proveniência prospectiva está preocupada em capturar os dados relativos à estrutura do workflow bem como as configurações de ambiente utilizadas para executá-lo. Já a proveniência retrospectiva tem o foco em capturar os dados e seus descritores produzidos a partir da execução de um determinado processo, no nosso caso, de um determinado workflow. Dados de proveniência retrospectiva englobam tempos de início e fim de execução, arquivos produzidos, erros que ocorreram, informações de desempenho de atividades, entre outros. O grau de utilidade da proveniência em um certo domínio está diretamente ligado à granularidade da proveniência coletada. O custo de coletar e guardar a proveniência costuma ser inversamente proporcional à granularidade. Tal granularidade pode ser classificada como grão-fino ou grão-grosso, onde a proveniência de grão-fino se refere ao registro da linhagem de um item específico de dados, e a proveniência de grão-grosso se refere ao registro do histórico de um conjunto de dados. 2.4 Computação em Nuvem Computação em nuvem [4] se refere a usar máquinas virtuais providas sob demanda, vindas da internet a partir de data centers compartilhados. Ou seja, ao invés de comprar um cluster de computadores, achar espaço físico no laboratório, encontrar um administrador, e além disso deixar o cluster ocioso quando ele não está sendo utilizado, é possível terceirizar a computação para instalações remotas na nuvem, e pagar apenas pelo que for usado. Os serviços de computação em nuvem podem ser, de modo geral, divididos em três
16 7 categorias: Infraestrutura-como-um-serviço (do inglês IaaS), Plataforma-como-um-serviço (PaaS) e Software-como-um-serviço (SaaS). Infraestrutura-como-um-serviço, como por exemplo o Amazon Web Services [17], provê a infraestrutura computacional na forma de hardware virtualizado. Às vezes é chamada de utility computing, por causa do seu modelo de ser preciso pagar apenas pela capacidade necessária, aumentando quando for necessário, semelhante à forma como eletricidade, combustível e água são consumidos. Plataforma-como-um-serviço na nuvem é definida como um conjunto de software e ferramentas para o desenvolvimento de produtos hospedadas na infraestrutura do provedor, onde os desenvolvedores criam aplicações na plataforma do provedor pela internet. Exemplos são o GoogleApps [18] e Force.com [19]. No modelo software-como-um-serviço, o vendedor fornece a infraestrutura de hardware, software e interage com o usuário através de um portal front-end. Como o provedor do serviço hospeda a aplicação e os dados, o usuário final pode usar o serviço de qualquer lugar, e esses serviços variam de web-based s a controle de inventário e processamento de banco de dados. Uma das vantagens da computação na nuvem é a sua enorme economia de escalabilidade, onde alugar um computador por 1000 horas custa o mesmo preço de alugar 1000 computadores por uma hora. Além disso, também é possível se ter uma interface simples e intuitiva para gerenciar múltiplos computadores e seus recursos. No entanto, a maior vantagem de computação em nuvem é a sua elasticidade, ou seja, sua facilidade em adicionar ou retirar recursos computacionais. Tipicamente, uma nuvem consiste em um grupo de computadores designados dinamicamente que pode ampliar a sua capacidade computacional rapidamente a pedido do usuário. Além disso, esses computadores são máquinas virtuais que possuem poucas restrições quanto às suas capacidades, podendo assim ser possível adicionar mais recursos extras, de acordo com a necessidade do usuário. Essa extrema flexibilidade oferece novas modalidades de uso para a computação voltada para a pesquisa. No caso da ciência, o termo computação em nuvem é usado mais como um sinônimo de computação distribuída sobre uma rede, que significa a habilidade de rodar uma aplicação em vários computadores conectados ao mesmo tempo. Por exemplo, caso seja necessário terminar um experimento até um prazo determinado, é possível alocar mais
17 8 recursos e máquinas para rodar o experimento mais rápido a fim de cumprir o prazo. Para pesquisas e experimentos que são reprodutíveis, é possível salvar a máquina virtual a qual o experimento foi realizado em uma imagem, e simplesmente repassar essa imagem para outros, com o intuito de reprodução do experimento ou extensão da análise por eles mesmos. 2.5 NoSQL O termo NoSQL tem sido usado atualmente para descrever um grande número de banco de dados emergentes, que possuem como característica serem não-relacionais e distribuídos. Estes bancos muitas vezes não davam suporte ao ACID (atomicidade, consistência, isolamento e durabilidade), características chave dos tradicionais sistemas de banco de dados relacionais. Entre as características dos NoSQLs, podemos citar, entre outros: o fato de serem altamente escaláveis e poderem ser facilmente distribuídos entre nós adicionais quando o volume de dados aumentar; a capacidade de lidar com imensos volumes de dados, popularmente apelidados de Big Data; o fato de a maioria dos bancos de dados NoSQL serem de código aberto e gratuitos, economizando assim na compra das licenças de uso dos bancos; modelos de dados flexíveis, onde em muitos casos as restrições são mínimas, fazendo com que a adição de novas colunas seja uma tarefa simples e descomplicada, resultando em um forma simplificada de realizar mudanças no modelo do banco de dados; etc. Quanto ao modelo de dados, os bancos de dados NoSQL podem ser geralmente classificados em quatro grandes grupos [20]: modelo chave/valor, o mais simples deles, onde todos os itens do banco são guardados como um atributo (ou chave) junto com o seu valor; modelo de documento, onde cada item é um documento sem estrutura previamente definida, podendo um documento conter outros documentos, numa estrutura similar à do XML; modelo de grafos, para quando as relações entre os dados podem ser bem representadas por grafos, como no caso de mapas de ruas, relações sociais, etc.; e o modelo de colunas largas, no qual os bancos de dados suportam um grande número de colunas por linhas e eles são otimizados para consultas em grandes conjuntos de dados. Neste trabalho usaremos um banco com o modelo de colunas largas.
18 Cassandra A base de dados Cassandra surgiu, inicialmente, como um projeto dos desenvolvedores do Facebook [21], a fim de criar um banco de dados que fosse escalável e otimizado para o propósito da rede social. Em 2008, seu código foi aberto para a comunidade e, posteriormente, mantido pela fundação Apache e colaboradores de diversas empresas. O Cassandra é um banco de dados não-relacional de natureza distribuída (NoSQL) que se utiliza do modelo de dados de linhas particionadas com consistência ajustável. Essas linhas são armazenadas em tabelas (denominadas ColumnFamilies); o primeiro componente da chave primária de uma tabela é chamado chave de partição (do inglês, partitioning key), pois é ela quem define em qual partição - se houver mais de uma - a linha deverá ser armazenada; dentro de uma partição, as linhas são agrupadas pelo restante da chave, chamado de chaves de agrupamento (do inglês, clustering keys). Ainda falando das chaves, é importante ressaltar a não-existência de chaves estrangeiras no Cassandra. Esse modelo permite que as tabelas possam ser criadas, removidas ou alteradas em tempo de execução, sem que haja bloqueio de atualizações (updates) ou consultas. Por outro lado, não são suportadas junções (joins) ou sub-consultas (subqueries), sendo necessário, então, delegar essas ações para as aplicações que farão uso do banco. Em certo nível, é possível pensar nas tabelas, linhas e colunas do Cassandra da mesma forma que em um banco relacional. Em ambas as abordagens é possível definir tabelas, as quais possuem colunas com tipos de dados associados, além de ser possível criar índices para permitir uma consulta eficiente através dos valores armazenados nas colunas. No entanto, existe uma diferença importante. O Cassandra foi projetado, desde o início, para ser um sistema distribuído, o que faz com que seja necessário priorizar a desnormalização sobre a normalização e as junções presentes nos bancos de dados clássicos, a fim de obter um desempenho satisfatório. Quanto à consistência, o comportamento padrão do Cassandra, diferentemente dos bancos relacionais, não garante a consistência dos dados em todas as réplicas, ou seja, se ao menos um nó possui um determinado dado, ele considera a transação como completa. Isso é feito com o objetivo de diminuir os tempos de leitura e escrita, de forma a não prejudicar sua escalabilidade. É possível, no entanto, alterar essa consistência para cada leitura e escrita em particular.
19 Cassandra Querying Language Pelo fato de possuir um modelo de dados diferente do comumente utilizado nos bancos relacionais, não é possível a utilização do SQL para consultar seus dados. Para esse fim, foi criada uma linguagem de consultas completamente nova, denominada Cassandra Querying Language, ou, simplesmente, CQL. Apesar de ser uma linguagem criada a partir do zero, ela possui muitas semelhanças com o SQL, com o intuito de minimizar os esforços de familiarização em um processo de migração de tecnologias. É possível notar, através de um script escrito tanto em SQL (Figura 2.2), quanto em CQL (Figura 2.3), que a estruturação de ambas as linguagens é muito parecida. Figura 2.2: Script em SQL. Figura 2.3: Script em CQL.
20 11 Porém, apesar das semelhanças, existem também algumas diferenças provenientes do modelo de dados. Em CQL, por exemplo, não é possível realizar um SELECT em uma coluna que seja referenciada na cláusula WHERE sem que a mesma faça parte da chave primária, ou possua um índice secundário declarado. Além disso, se o atributo fizer parte da chave primária e for uma clustering key, se faz necessário que a clustering key imediatamente antes declarada na chave primária também esteja presente, a menos que seja a primeira clustering key declarada. Ainda em relação à cláusula WHERE, no caso da partitioning key ser composta, sempre que uma de suas partes aparecer, as outras devem, obrigatoriamente, se fazer presentes. Quanto à restrição dos parâmetros em uma consulta, apenas os operadores = e IN são aceitos para a partitioning key. As clustering keys, por sua vez, possuem os mesmos operadores que o SQL possui, com exceção do operador <>. Vale ressaltar que a utilização de operadores diferentes de = nas clustering keys só é válido caso a clustering key declarada imediatamente antes faça uso do operador = na mesma sentença. A exceção, novamente, é caso seja a primeira clustering key declarada. Existem também os índices secundários, que permitem que a consulta seja feita em cima de algum atributo que não esteja declarado na chave primária. Porém, é aconselhável que se tente restringir as consultas aos componentes da chave primária. Caso haja a real necessidade de criar índices secundários, a preferência é que sejam criados em tabelas que possuam baixa cardinalidade, pois quando um atributo que possui um índice secundário aparece em uma consulta, é necessário visitar todos os nós em que a keyspace se faz presente, não sendo, portanto, uma consulta tão otimizada quanto uma realizada apenas sobre os atributos da chave primária. Por último, caso se deseje ordenar uma consulta por algum atributo, utiliza-se a cláusula ORDER BY. Mas, diferentemente de sua contraparte no SQL, só é possível ordenar pelos atributos presentes na clustering key e, como tudo que envolve clustering keys, é necessário respeitar sua ordem de declaração. Uma alternativa a essa opção seria ordenar na aplicação que utiliza o banco, adicionando um overhead à mesma.
21 Capítulo 3 SciCumulus 3.1 Introdução Podemos descrever o SciCumulus [6] como uma engine entre o Sistema de Gerencia de Workflows Científicos (SGWfC), do inglês Scientific Workflow Management System (SWfMS), [11] e a nuvem, que faz o uso de varredura de parâmetros e paralelismo na fragmentação dos dados, visando assim uma diminuição no tempo de execução de um workflow científico. Em alguns casos, como em workflows para mineração de dados, o mesmo workflow é executado exaustivamente usando diferentes configurações de parâmetros até o final da exploração, fazendo assim com que a técnica de varredura de parâmetros seja necessária. Além disso, em vários outros casos, as variações dos workflows não conseguem ser processadas em tempos viáveis por um único computador, ou por um cluster pequeno. Para isso, os cientistas precisam de paralelismo no workflow para reduzir o tempo total de execução. Esses experimentos que utilizam a varredura de parâmetros podem envolver a exploração de milhares de parâmetros e, muitas vezes, usam estruturas de repetição (laços) em cima de dezenas de atividades complexas de workflows. Esse tipo de modelo computacional necessita de algum nível de paralelismo para que ele consiga ser executado em um tempo viável. Embora esse tipo de modelo seja um bom candidato a processamento paralelo, o número total de tarefas (dependentes ou independentes) e processadores disponíveis o torna complexo para ser gerenciado de uma maneira ad-hoc. Recentemente o paradigma de Diversas Tarefas Computacionais (do inglês Many Tasks Computing, MTC) [22] foi
22 13 proposto para solucionar o problema de executar múltiplas tarefas paralelas em múltiplos processadores. Esse paradigma consiste em usar diversos recursos computacionais ao longo de pequenos períodos de tempo para executar diversas tarefas computacionais. Alguns SGWfCs atuais já estão explorando o paralelismo de workflows usando o MTC em ambientes de computação homogêneos, como clusters computacionais. Esse tipo de ambiente depende de um controle centralizado dos recursos, que facilita o paralelismo e se beneficia de redes de comunicação de alta velocidade, trazendo assim um alto desempenho para o experimento científico. Devido à mudança dos experimentos científicos das máquinas locais para a nuvem, há um aumento da demanda por paralelização nesses experimentos, e isso ainda é um desafio. É possivel ter a realização desses experimentos pelos cientistas de uma forma ad-hoc, porém de uma forma não escalável e bastante propensa a erros. As ferramentas existentes para executar workflows científicos usando processamento paralelo se focam mais em ambientes homogêneos, onde, na nuvem, o cientista tem que gerenciar ele mesmo aspectos importantes como a inicialização das instâncias das máquinas virtuais, o agendamento das atividades do workflow nos diferentes ambientes de nuvem, o impacto da transferência dos dados, etc. A infraestrutura computacional deveria ser capaz de prover maneiras de fazer com que os cientistas não tivessem que lidar com o complexo gerenciamento de workflows paralelos na nuvem, ou seja, ela mesma ser capaz de cuidar de uma forma trasnparente da inicialização, monitoramento e controle da execução distribuída. Existem ferramentas, como o Map-Reduce [23], que visam facilitar a distribuição e o controle de atividades paralelas nos nós. Embora ele facilite a distribuição, o conceito do Map-Reduce é um pouco desconectado do paradigma de workflows e experimentos científicos, além de supor um certo conhecimento de programação por parte dos cientistas. Do ponto de vista dos cientistas é mais vantajoso ter uma forma simples e transparente de controlar e monitorar as execuções distribuídas das atividades dentro de um workflow. Uma possível solução é usar um middleware que promova a transparência de execução de workflows científicos em nuvens usando o MTC, como o SciCumulus. Ele é um middleware que suporta e provê o paradigma MTC de paralelismo em nuvens para workflows científicos e também provê suporte para dados de proveniência, isolando assim os cientistas da complexidade dos ambientes de nuvem e de coletar os dados distribuídos de proveniência.
23 3.2 Conceitos Gerais 14 Alguns conceitos são importantes para entender o funcionamento e a arquitetura do SciCumulus, entre eles o conceito de atividade de nuvem, os tipos de paralelismo suportados pelo SciCumulus e os seus componentes. Uma das mais importantes definições na arquitetura do SciCumulus é a noção de atividade de nuvem. Uma atividade de nuvem, que é executada no SciCumulus, contém o programa a ser executado, a sua estratégia de paralelização, os seus valores de parâmetros e os dados a serem consumidos. As atividades de nuvem são bem diferentes das atividades de workflow, já que as atividades de workflow não se preocupam com as estratégias de paralelismo escolhidas pelos cientistas. As atividades de nuvem requerem que os cientistas especifiquem metadados do paralelismo tais como o tipo de paralelismo, o número de fragmentos a serem produzidos, requisitos de desempenho, restrições de tempo, parâmetros a serem explorados, e o intervalo dos valores de parâmetro a serem explorados. Um exemplo de atividade de nuvem pode incluir um programa de bioinformática BLAST [24], e os seus parâmetros e conjuntos de dados os quais são encapsulados em uma única unidade de trabalho a ser executada em um ambiente de nuvem. As atividades de nuvem do SciCumulus são regidas por uma máquina de estado finito, que possui quatro estados: inicializada, ativada, enfileirada e finalizada. Quando o SciCumulus começa uma atividade de nuvem, ela recebe um estado inicializada. Se, por alguma razão, a atividade de nuvem não consegue começar a execução imediatamente, ela recebe o estado de enfileirada. A atividade de nuvem pode proceder para o estado ativado se ela puder ser executada normalmente. Assim que a execução da atividade termina, ela recebe o estado de finalizada. Quando a atividade de nuvem tem um problema, como dados ou um programa corrompidos, e não consegue ser executada, ela vai do estado inicializada (ou enfileirada) direto para o estado finalizada. O SciCumulus tem como objetivo prover um middleware que permite aos cientistas implementar dois tipos de funcionalidades paralelas, que são os tipos mais comuns entre os experimentos científicos: a varredura de parâmetros [25] e o paralelismo de dados [26]. Um dado workflow científico W é representado por uma quádrupla (A, P t, I, O) onde: A é o conjunto {a 1, a 2,..., a n } de atividades que compõem o workflow W ; I é o conjunto {i 1, i 2,..., i m } de dados a serem consumidos; P t é o conjunto {pt 1, pt 2,..., pt r } de parâmetros de W ; e O é o conjunto de dados de saída {o 1, o 2,..., o n }.
24 15 O paralelismo de dados pode ser caracterizado pela execução simultânea de uma atividade de nuvem a i, onde cada execução de a i consome um subconjunto específico de dados de entrada. Isso é alcançado gerando várias instâncias de a i no ambiente de nuvem e cada instância guarda um subconjunto específico (i 1, i 2,..., i m ) do conjunto inteiro de entrada I. A varredura de dados pode ser definida como sendo execuções simultâneas de uma atividade de nuvem a i, onde cada execução de a i consome um subconjunto específico dentre os possíveis valores para os parâmetros P t. Isso pode ser alcançado replicando a atividade de nuvem a i nas várias instâncias do ambiente de nuvem e cada instância guarda um subconjunto específico dos possíveis valores de parâmetros. 3.3 Arquitetura O SciCumulus é um middleware leve feito para distribuir, controlar e monitorar a execução paralela das atividades de um workflow científico (ou até workflows inteiros) de um SGWfC para um ambiente de nuvem, como a Amazon EC2. Ele controla a execução das atividades de um workflow em um conjunto distribuído de máquinas virtuais, e, além disso, ele próprio é distribuído. A sua arquitetura é dividida em três camadas: (i) Desktop - despacha as atividades do workflow para serem executadas no ambiente de nuvem usando um SGWfC local como o VisTrails [27]; (ii) Distribuição - gerencia a execução das atividades na nuvem; e (iii) Execução - executa programas do workflow. A Figura 3.1 representa a arquitetura conceitual do SciCumulus nas três principais camadas. A camada de Desktop visa prover componentes que permitam aos cientistas compor e executar os seus workflows de uma forma paralela e transparente, diminuindo assim a complexidade da fase de modelagem. A ideia principal é substituir os componentes do SGWfC local pelos do SciCumulus, que se comunicam com os componentes de distribuição, a fim de estimular a distribuição dos dados e a paralelização. Essa camada possui cinco componentes: Desktop Setup, Uploader, Dispatcher, (Provenance) Capturer e Downloader. Esses últimos quatro componentes devem ser inseridos pelo cientista no worflow científico sequencial original (também modelado pelo cientista), substituindo cada atividade que pode ser paralelizada. Se o cientista planeja paralelizar uma atividade a i, ela deve ser substituída por esses quatro componentes para promover a paralelização do workflow.
25 16 Figura 3.1: Arquitetura Conceitual do Scicumulus Dentre os principais componentes da camada de Desktop, podemos citar o Uploader, que move os dados (arquivos, parâmetros, etc.) para a nuvem enquanto que o Downloader coleta os resultados finais das instâncias da nuvem. Eles são usados preferencialmente quando o experimento científico usa dados de entrada de tamanho pequeno e produz dados de saída também pequenos. Isso é devido ao overhead da transferência de dados pela internet para o ambiente de nuvem, o que pode tornar inviável transferir quantidades de dados imensos. Em casos de experimentos com grandes quantidades de dados, estes já devem estar no ambiente de nuvem para evitar a transferência de dados. Outro componente importante, principalmente para o escopo dessa monografia, é o Provenance Capturer, que coleta os dados de proveniência da nuvem. Ele é promulgado quando a execução paralela distribuída termina, onde ele coleta os dados de proveniência distribuídos, os guarda nas instâncias de nuvem e os transfere para o repositório local. Dessa forma, os cientistas podem escrever consultas tais como Em quais instâncias virtualizadas são guardados os resultados do workflow W1 que foi executado no dia 03/03/2010
26 17 às 3:03pm? Ao analisar os dados de proveniência, engenheiros de computação podem avaliar o desempenho para poder melhorar alguns componentes. O repositório de proveniência foi modelado para conectar a proveniência esperada e a proveniência distribuída retrospectiva [12] coletada durante o ciclo de vida do experimento científico [28]. A camada de distribuição gerencia a execução paralela das atividades de nuvem no ambiente distribuído. Todos os componentes dessa camada estão hospedados na nuvem. Essa camada possui oito componentes: Execution Broker, Data Fragmenter, Parameter Sweeper, Encapsulator, Scheduler, Distribution Controller e Data Summarizer. Dentre os componentes mais importantes, temos o Parameter Sweeper e o Data Fragmenter, que cuidam das possíveis funcionalidades paralelas suportadas pelo SciCumulus, a varredura de parâmetros e a fragmentação de dados. O Parameter Sweeper lida com as combinações dos parâmetros recebidos pelo workflow cliente para uma atividade de nuvem específica que está sendo paralelizada. Os parâmetros do workflow podem ser diretamente ou indiretamente dependentes dos conjuntos de dados de entrada. O Data Fragmenter fragmenta os dados originais e gera subconjuntos deles para serem distribuídos pelas instâncias virtualizadas para execução. É importante ressaltar que o componente Data Fragmenter é dependente do problema, ou seja, ele tem que mudar o seu comportamento dependendo do tipo/formato dos dados de entrada a serem fragmentados. Por exemplo, no caso de arquivos do tipo FASTA [24], existe um método específico para fragmentá-los baseado na distribuição das sequências de DNA dentro do arquivo. Logo, o fragmentador de dados precisa ser adaptado para fragmentar um tipo específico de dado de entrada. No entanto, não é tão trivial implementar componentes que são independentes do problema, e foram necessárias técnicas de reuso de software [29] para alcançar esse feito. Tanto o componente de fragmentação de dados e o de varredura de parâmetros são implementados em cada instância da nuvem, já que quando os dados a serem consumidos e os arquivos de parâmetros já estão na nuvem, é necessário executar essas atividades em cada instância para evitar transferência de dados desnecessária. A última camada é a camada de execução, que cuida da execução das atividades de nuvem nas instâncias virtualizadas. Ela possui cinco componentes principais: Instance Controller, Data Fragmenter, Parameter Sweeper, Configurator e Executor. O Data Fragmenter e o Parameter Sweeper operam da mesma maneira de quando eles estão na camada
27 18 de distribuição. Quando eles já estão sendo executados na camada de distribuição, eles não são chamados na camada de execução. O Instance Controller atua como uma interface entre a camada de distribuição e a camada de execução, e também é responsável por controlar o fluxo de execução na instância. O Configurator é o responsável por montar todo o ambiente. Ele desempacota as atividades de nuvem, cria réplicas do programa para um local específico, cria diretórios para guardar os arquivos de parâmetros, guarda os dados a serem consumidos, e cria diferentes áreas de trabalho para diferentes execuções. Assim que todo o ambiente está montado, o Executator é chamado. O Executator chama o programa específico, passando os parâmetros e gerando linhas de comando para executá-lo. Ele também é o responsável por guardar os dados de proveniência em um repositório local. Se ocorrer algum erro, ele é o componente responsável por mandar a mensagem para o Instance Controller que manda a mensagem para o Distribution Controller. 3.4 Testes e Considerações Finais Grandes experimentos científicos tendem a durar bastante tempo, onde várias execuções usando diferentes parâmetros e dados de entrada são necessárias para chegar a uma conclusão final e confirmar ou refutar uma hipótese [30]. Essas execuções demoram bastante tempo e cientistas tem que usar técnicas de paralelismo para melhorar o desempenho. No entanto, não é uma tarefa trivial gerenciar execuções paralelas de grandes workflows científicos [28], particularmente em ambientes de nuvem. O SciCumulus foi criado com o intuito de solucionar esse problema de execução paralela de workflows científicos na nuvem, provendo alto desempenho e monitorando e guardando as informações de execução para serem analisados. A fim de avaliar o real ganho em desempenho do SciCumulus, foram rodados experimentos de simulação [6]. Os resultados da simulação mostraram ganhos em desempenho nos dois tipos de paralelização utilizados, a varredura de parâmetros e a fragmentação de dados. Para avaliar o overhead do SciCumulus usando diferentes instâncias virtualizadas, o experimento foi rodado usando 100 e 128 fragmentos e 100 e 128 valores de parâmetros, o que leva a 100 e 128 pequenas atividades de nuvem em cada experimento. O tempo de execução do workflow diminuiu significantemente com o aumento do número de ins-
28 19 tâncias virtualizadas envolvidas nas atividades de nuvem distribuídas, como é mostrado nas Figuras 3.2. O overhead de transferir os dados do SGWfC local para o ambiente de nuvem e vice-versa e também o overhead de inicializar as instâncias foram aceitáveis quando comparados com o grau de paralelismo obtidos com a varredura de parâmetros e a fragmentação de dados. (a) Fragmentação de dados fragmentos (b) Fragmentação de dados fragmentos (c) Varredura de parâmetros combinações(d) Varredura de parâmetros combinações Figura 3.2: Resultados do Scicumulus
29 Capítulo 4 Desenvolvimento 4.1 Abordagem Proposta Quando um cientista roda um experimento científico, muitas vezes é necessário analisar cada passo do processo científico, o acesso aos dados e o ambiente para questões de reprodutibilidade, validação, reconstrução e linhagem. É importante saber o ambiente no qual uma aplicação é executada (por exemplo, operações com ponto flutuante podem gerar resultados distintos em máquinas diferentes) e, além disso, o cientista pode querer rodar novamente as tarefas que falharam, ou, até mesmo, todas as tarefas. Ou seja, os dados de proveniência são de suma importância para um experimento científico, pois eles proveem todas essas informações e mais ainda. No entanto, para experimentos grandes, um experimento científico pode acabar gerando quantidades imensas de dados, muitas vezes até Gigabytes, e tudo isso apenas durante a execução do experimento, sem contar com os resultados finais. Ou seja, é preciso identificar uma maneira eficiente de escrever e ler todos esses dados em tempo de execução, de forma que não atrapalhe o desempenho do próprio experimento. Além disso, é preciso se preocupar também com o aumento do tamanho do banco de dados, já que grandes quantidades de dados serão escritos nele. Logo, é preciso encontrar uma forma de ter um banco de dados que seja otimizado para a escrita de dados, já que na maioria dos casos os workflows científicos escrevem muito mais dados do que leem; um modelo de dados que seja facilmente escalável, ou seja, que não perca desempenho quando for preciso escrever imensas quantidades de dados; um modelo de dados flexível, que seja facilmente adaptável às demandas dos cientistas, e que
30 21 seja possível modificá-lo de forma fácil, mesmo posteriormente à sua criação; e que tudo isso seja feito de forma transparente à execução do workflow científico, isto é, sem perdas significantes em seu desempenho geral. A solução adotada foi usar um modelo de dados não-relacional, optando assim por um banco de dados do tipo NoSQL, e o banco escolhido foi o Cassandra. Além de ter um modelo não-relacional, o Cassandra ainda pode atuar como um banco de dados distribuído, podendo assim ter o banco de dados partilhado entre vários nós, ou, caso seja necessário e/ou vantajoso, em apenas um nó. Caso os dados de proveniência sejam pequenos e gerados a uma velocidade também pequena, uma solução de armazenamento centralizada [31], ou seja, um único nó, é mais recomendada. No entanto, quando existe um volume alto de escritas simultâneas, uma solução de armazenamento distribuída, ou seja, diversos nós, possui um melhor desempenho. Tendo diversos nós é possível espalhar as requisições de escrita para vários nós, alcançando assim um alto desempenho escalável e um bom balanceamento da carga de escrita [32] [33]. 4.2 Modelagem Como fora mencionado anteriormente, esse trabalho é focado no SciCumulus, middleware responsável pelo gerenciamento de workflows científicos. Isto posto, é necessário mapear os dados de proveniência a serem gravados no banco de dados - ou, no caso, remapear levando em conta as restrições do Cassandra. O modelo utilizado no PostgreSQL deve ser adaptado de forma que não haja perda de semântica e que o desempenho não seja muito afetado. A remodelagem dos dados levou em conta as consultas a serem feitas, de forma que fosse possível remapear o modelo sem que a semântica fosse prejudicada, uma vez que as consultas foram respeitadas e não foram modificadas, exceto quando extremamente necessário. Nesses casos, o processamento das consultas é delegado à aplicação, como por exemplo a consulta da Figura 4.1, que foi quebrada em duas outras consultas que fornecem informações à aplicação, agora responsável por processá-las (checar se todas as tarefas de uma determinada atividade já terminaram). Essas delegações de responsabilidade geram overheads que antes não existiam e que podem vir a impactar no desempenho da aplicação.
31 22 Figura 4.1: Query modificada. Além disso, para preservar a semântica, algumas outras tarefas também foram delegadas à aplicação, como ordenação de resultados pela partitioning key, já que o CQL aceita apenas membros da clustering key como parâmetro para a cláusula ORDER BY. Era necessário, ainda, pensar em como conseguir o próximo ID de cada tabela. No PostgreSQL, a abordagem adotada foi criar uma procedure para cada tabela, de forma que sempre que algum registro fosse adicionado a uma das tabelas, a procedure incrementava o ID em questão. Como no Cassandra não existe a opção de IDs auto-incrementáveis, como em alguns bancos relacionais, ou de procedures, havia ainda duas possíveis soluções para escolhermos: recuperar os registros e ordená-los pela ID na aplicação, de forma que o primeiro ID fosse o último utilizado (à medida que a base de dados cresce, essa abordagem se torna inviável devido ao overhead cada vez maior); ou, como o Cassandra prioriza a desnormalização, criar uma tabela de metadados, cuja única função é armazenar o último valor utilizado para cada ID do sistema, de forma que o tempo de recuperação do valor seja sempre constante. A abordagem escolhida, inicialmente, foi a última. Porém, nessa abordagem, existe uma falha, que é quando são executados múltiplos workflows concorrentes. Para resolver esse impasse, não utilizamos a tabela de metadados e modificamos o tipo da ID para UUID (i.e. Universally Unique Identifer). Esse problema será abordado mais adiante no texto. O modelo do banco de proveniência do SciCumulus que se encontra no PostgreSQL é baseado no modelo PROV-Wf [34], que estende o padrão PROV [35] do W3C. O mo-
32 23 delo utilizado no PostgreSQL foi adaptado de forma que não houvesse perda de semântica. Dessa forma, cada tabela do PostgreSQL foi mapeada para uma Column Family no Cassandra, sendo que sempre que houvesse uma restrição de parâmetros não coberta pelo Cassandra, teríamos que adaptar o script de criação dos objetos. Na Figura 4.2 ilustramos o mapeamento de uma tabela, a hactivation. Figura 4.2: Comparação dos scripts de criação em SQL e CQL. Na Figura 4.2 podemos perceber algumas diferenças importantes. Primeiramente, no Cassandra temos a criação de um UUID, que é um identificador universal que evita que ocorram colisões de identificadores no momento do armazenamento. Basicamente, quando não utilizamos o UUID são realizadas diversas atualizações em uma tabela de metadados para se recuperar o último identificador utilizado de cada tabela, o que acaba impactando no tempo final de execução do workflow. Além disso, retornando ao problema citado anteriormente, não é possível executar mais de um workflow concorrentemente, pois existe o caso em que uma instância do SGWfC consulta a tabela de metadados para resgatar o último identificador e uma outra instância do SGWfC consulta a tabela antes que a anterior pudesse gravar o último identificador utilizado. Nesse caso, teríamos duas instâncias de SGWfC utilizando os mesmos identificadores e existiriam informações conflitantes, e como o SciCumulus é orientado aos dados de proveniência, a execução de um workflow acabaria interferindo na do outro.
33 24 Além disso, índices foram criados para todos os campos que faziam parte de predicados de seleção de alguma consulta executada pelo SciCumulus. Por exemplo, no caso do campo status, o SciCumulus verifica quais tarefas já executaram via proveniência e isso requer uma consulta onde status = FINISHED, logo um índice sobre esse campo se faz necessário no Cassandra. Figura 4.3: Inicialização da keyspace do Cassandra. Além disso, antes de criamos as Column Families no Cassandra, devemos definir uma keyspace a ser usada. No caso do experimento realizado nesse artigo criamos uma keyspace específica para as Columns Families do SciCumulus conforme apresentado na Figura 4.3. Na Figura 4.3 podemos perceber que a keyspace criada está replicada em um nó utilizando a estratégia SimpleStrategy que posiciona a primeira réplica do banco de proveniência em um nó determinado pelo particionador e as réplicas adicionais são colocadas no próximo nó no sentido horário do anel de nós que fazem parte da rede de replicação do Cassandra. 4.3 Modificação do Driver de Acesso ao Banco Para substituir o PostgreSQL pelo Cassandra, foi necessário, evidentemente, substituir o driver de acesso ao banco no projeto do SciCumulus. Existem inúmeros drivers que fornecem acesso à API do Cassandra via Java, porém nenhum oficial. Através de pesquisas, então, decidimos por utilizar o Java driver da Datastax [36], que foi altamente recomendado por ser completo e de uso bem simplificado, além de ser mais rápido em algumas situações se comparado aos outros drivers. O driver escolhido permite tanto consultas síncronas quanto assíncronas, resultando em uma melhora no desempenho em determinadas situações. Além disso, possui suporte à funcionalidade chamada de Prepared Statement, que um faz pré-processamento da consulta a ser enviada posteriormente, criando uma espécie de modelo com caracteres coringa a serem substituídos pelos valores reais. Com isso, caso uma determinada consulta precise ser enviada diversas vezes, com variação de parâmetros, haverá um ganho de
34 25 desempenho, uma vez que não é necessário criar a mesma consulta todas as vezes, apenas associar os valores distintos aos wildcards. Caso se faça necessário o envio de um lote (batch) de consulta do tipo UPDATE, INSERT, ou DELETE, o driver oferece a funcionalidade de Batch Statements, que nada mais é que um lote de consulta, que são enviadas de uma vez, não necessitando, portanto, que sejam abertas diversas conexões com o banco (uma para cada consulta a ser enviada), apenas uma. 4.4 Distribuição do Banco de Dados A distribuição do Cassandra se dá de forma fácil, devido ao fato de ter sido projetado como um banco distribuído desde o início. Para fazê-lo, é preciso indicar na hora de criar um keyspace qual a política de replicação que ele deve adotar, além da escolha da arquitetura de distribuição, modificando o arquivo de configurações cassandra.yaml. No nosso caso, utilizamos a arquitetura Ec2Snitch, própria para quando se usa VMs da Amazon. Além disso, é necessário instalar uma instância do Cassandra em cada máquina, escolher um nome para o cluster de nós e determinar qual ou quais nós farão o papel de seeds (nós que possuem a função de guardar a lista dos nós pertencentes ao anel lógico de distribuição para que os outros nós possam encontrá-los). Após essas configurações, o banco está devidamente distribuído e pronto para ser utilizado, sem maiores preocupações quanto à distribuição da carga ou regras de partição dos dados, diferentemente de como a distribuição é feita nos bancos tradicionais. Utilizando os bancos de dados relacional e NoSQL executamos então um estudo comparativo entre as abordagens para verificar as vantagens e as desvantagens da utilização de SGBDs NoSQL na gerência dos dados de proveniência em workflows científicos.
35 Capítulo 5 Análise de Resultados 5.1 Ambiente de Execução A fim de comparar o desempenho da aplicação original, o SGWfC SciCumulus utilizando o banco de dados PostgreSQL, e a modificada, usando o Cassandra, é necessário estabelecer as mesmas condições de execução do SciCumulus para ambos os SGBDs. Para tal, foi configurado o ambiente com a mesma capacidade de processamento tanto para o SciCumulus-PostgreSQL quanto para o SciCumulus-Cassandra. Em ambos os casos utilizamos 16 máquinas virtuais do tipo small (EC2 ID: m1.small GB de memória RAM, 1 núcleo de CPU equivalente a um processador GHz 2007 Opteron, 160 GB de armazenamento) no ambiente da Amazon EC2, um ambiente de nuvem com recursos sob demanda. Como o SciCumulus é orientado ao banco de proveniência, ele consulta o banco para realizar as várias tarefas como escalonamento e monitoramento. Qualquer impacto no SGBD pode fazer com que a execução paralela do workflow também seja impactada, podendo ocasionar assim perda no desempenho. Para analisar o impacto da mudança do SGBD no SciCumulus, executamos o workflow SciPhy [37] utilizando tanto o PostgreSQL quanto o Cassandra. O SciPhy é um workflow de bioinformática que executa uma varredura de parâmetros em um conjunto de sequências de DNA, RNA ou aminoácidos e gera diversas árvore filogenéticas, que apresentam o quanto um organismo se assemelha a outro evolutivamente.
36 5.2 Casos de Testes 27 O SciPhy foi executado com vários conjuntos de dados de entrada de forma que pudéssemos analisar como o SGBD NoSQL se comportaria com o aumento do volume de dados de entrada. A Figura 5.1 apresenta os tempos de execução do textitworkflow para cada conjunto de dados de entrada com apenas uma máquina executando o PostgreSQL e o Cassandra (instâncias rotuladas como 1N) e com três máquinas executando o Cassandra e o PostgreSQL com o Pgpool (instâncias rotuladas como 3N). Figura 5.1: Tempo de execução do workflow SciPhy. Nos casos das execuções com os SGBDs em apenas um nó, podemos perceber que sem a distribuição efetiva dos dados o Cassandra insere um overhead significativo na execução do workflow. Por exemplo, quando processamos 200 arquivos de entrada o tempo de execução do SciCumulus com PostgreSQL dura minutos, com o Cassandra sem UUID a duração é de minutos e com o Cassandra com UUID a duração é de minutos. Apesar de sabermos que a versão sem UUID é menos eficiente já que necessita realizar consultas sucessivas à tabela de metadados, mesmo com a utilização do UUID
37 28 ainda temos uma degradação de 11,08% no tempo de execução do workflow, o que gera uma diferença absoluta de 9,2 horas. Isso se dá devido as consultas que o SciCumulus necessita executar durante o curso de execução do workflow. Toda vez que uma consulta no PostgreSQL necessita realizar uma junção, mais de uma consulta deve ser realizada no Cassandra, o que faz com que a cada atividade a ser despachada, uma consulta seja executada com um overhead embutido. Analisamos também o caso em que o SGBD se encontra distribuído em 3 nós (séries em vermelho na Figura 5.1). Nesses casos, tanto a execução do Cassandra com UUID quanto a sem o uso do UUID apresentaram um desempenho melhor do que o PostgreSQL utilizando o Pgpool. Essa vantagem se deu já que cada nó executor do SciCumulus grava seus dados de proveniência o que faz com que tenhamos várias centenas de gravações concorrentes no SGBD. O Cassandra é otimizado justamente para esse fim (acelerar as inserções) o que fez com que seu desempenho tenha sido melhor. O ganho na inserção no Cassandra se deve a associação de um disco em separado para a gravação de logs. Quando as Column Families compartilham a mesma unidade de disco com o log, ocorrem deteriorações nas operações. No caso, a execução com o uso de UUID foi 19% mais eficiente do que com o uso do Pgpool. Em todos esses casos, executamos apenas uma instância do SciPhy. Para analisar como o Cassandra se comportaria com vários workflows executando concorrentemente, iniciamos 4 instancias do SciPhy consumindo 200 arquivos de entrada cada uma e utilizando o Cassandra com UUID (já que sem o uso do UUID existe a possibilidade de um workflow interferir no outro, como comentado no capítulo anterior) e o PostgreSQL e Pgpool (Figura 5.2). O Cassandra apresentou um desempenho superior em todos os casos, mas principalmente quando utilizadas 3 nós para o SGBD. Esse desempenho se dá justamente devido a sua otimização de escrita e também ao controle de acessos concorrentes do Cassandra, que é otimizado. No caso, a execução do Cassandra com 3 nós foi 12% mais eficiente que a execução com o Pgpool o que nos dá uma diferença de aproximadamente 9 horas.
38 29 Figura 5.2: Tempo de execução de quatro workflows concorrentes. Além disso, vale ressaltar que em todas as execuções em que o Cassandra encontravase distribuído, a distribuição da carga foi excelente, com, mais ou menos, 1/3 do total de dados para cada nó.