Carlos Filipe Marques Teixeira Júnior. Guilherme Rangel Ferreira. RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS

Tamanho: px
Começar a partir da página:

Download "Carlos Filipe Marques Teixeira Júnior. Guilherme Rangel Ferreira. RELACIONAIS E NoSQL PARA DADOS DE PROVENIÊNCIA EM WORKFLOWS CIENTÍFICOS"

Transcrição

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ó.

Interoperabilidade entre Bancos de Dados Relacionais e Bancos de Dados NoSQL

Interoperabilidade entre Bancos de Dados Relacionais e Bancos de Dados NoSQL Minicurso: Interoperabilidade entre Bancos de Dados Relacionais e Bancos de Dados NoSQL Geomar A. Schreiner Ronaldo S. Mello Departamento de Informática e Estatística (INE) Programa de Pós-Graduação em

Leia mais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais Computação em Nuvem Computação em nuvem: gerenciamento de dados Computação em nuvem (Cloud Computing) é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

USE O PODER DA NUVEM. VEJA COMO A NUVEM PODE TRANSFORMAR SEUS NEGÓCIOS.

USE O PODER DA NUVEM. VEJA COMO A NUVEM PODE TRANSFORMAR SEUS NEGÓCIOS. USE O PODER DA NUVEM. VEJA COMO A NUVEM PODE TRANSFORMAR SEUS NEGÓCIOS. A computação em nuvem é uma mudança de paradigma no gerenciamento de TI e de datacenters, além de representar a capacidade da TI

Leia mais

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com

Cloud Computing. Andrêza Leite. andreza.lba@gmail.com Cloud Computing Andrêza Leite andreza.lba@gmail.com Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing O

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS Quando falamos em arquitetura, normalmente utilizamos esse termo para referenciar a forma como os aplicativos computacionais são estruturados e os hardwares

Leia mais

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva The Eucalyptus Open- source Cloud-computing System Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva Sumário Introdução Trabalhos Correlatos Eucalyptus Design Conclusões Visão Geral Introdução:

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 1 Conceitos da Computação em Nuvem A computação em nuvem ou cloud computing

Leia mais

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II Pollyanna Gonçalves Seminário da disciplina Banco de Dados II Web 2.0 vem gerando grande volume de dados Conteúdo gerado por redes sociais, sensores inteligentes, tecnologias de colaboração, etc. Novas

Leia mais

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados Sistema de Bancos de Dados Conceitos Gerais Sistema Gerenciador de Bancos de Dados # Definições # Motivação # Arquitetura Típica # Vantagens # Desvantagens # Evolução # Classes de Usuários 1 Nível 1 Dados

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer

Leia mais

Carlos Eduardo Paulino Silva

Carlos Eduardo Paulino Silva CAPTURA DE DADOS DE PROVENIÊNCIA DE WORKFLOWS CIENTÍFICOS EM NUVENS COMPUTACIONAIS Carlos Eduardo Paulino Silva Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Sistemas

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

2 Computação na Nuvem

2 Computação na Nuvem 18 2 Computação na Nuvem 2.1 Definição A ideia essencial da computação na nuvem é permitir um novo modelo onde o consumo de recursos computacionais, e.g., armazenamento, processamento, banda entrada e

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Cassandra - Particionamento de Dados Sistemas Distribuídos Douglas Macedo Hugo Lourenço Sumário Introdução Conceito Anel Multíplos Data center Fatores envolvidos Arquitetura do Sistema Módulo de Particionamento

Leia mais

Introdução a Banco de Dados

Introdução a Banco de Dados Introdução a Banco de Dados O modelo relacional Marta Mattoso Sumário Introdução Motivação Serviços de um SGBD O Modelo Relacional As aplicações não convencionais O Modelo Orientado a Objetos Considerações

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

SciCumulus 2.0: Um Sistema de Gerência de Workflows Científicos para Nuvens Orientado a Fluxo de Dados *

SciCumulus 2.0: Um Sistema de Gerência de Workflows Científicos para Nuvens Orientado a Fluxo de Dados * paper:6 SciCumulus 2.0: Um Sistema de Gerência de Workflows Científicos para Nuvens Orientado a Fluxo de Dados * Vítor Silva 1, Daniel de Oliveira 2 e Marta Mattoso 1 1 COPPE Universidade Federal do Rio

Leia mais

Uma visão mais detalhada do software HP LoadRunner

Uma visão mais detalhada do software HP LoadRunner Boletim técnico Uma visão mais detalhada do software HP LoadRunner Índice Um novo enfoque no teste de desempenho: a solução HP LoadRunner 3 A solução HP LoadRunner e a terminologia dos testes de desempenho

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Bancos de Dados Distribuídos Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Conceitos Sistema distribuído. Banco de dados distribuído (BDD). Coleção de multiplos

Leia mais

Classificação::Modelo de implantação

Classificação::Modelo de implantação Classificação::Modelo de implantação Modelo de implantação::privado Operada unicamente por uma organização; A infra-estrutura de nuvem é utilizada exclusivamente por uma organização: Nuvem local ou remota;

Leia mais

Paralelização de Tarefas de Mineração de Dados Utilizando Workflows Científicos 1

Paralelização de Tarefas de Mineração de Dados Utilizando Workflows Científicos 1 Paralelização de Tarefas de Mineração de Dados Utilizando Workflows Científicos 1 Carlos Eduardo Barbosa, Eduardo Ogasawara, Daniel de Oliveira, Marta Mattoso PESC COPPE Universidade Federal do Rio de

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

Opções para impressão de códigos de barras para impressoras Zebra em ambientes Oracle WMS e MSCA RELATÓRIO INFORMATIVO SOBRE APLICAÇÃO

Opções para impressão de códigos de barras para impressoras Zebra em ambientes Oracle WMS e MSCA RELATÓRIO INFORMATIVO SOBRE APLICAÇÃO Opções para impressão de códigos de barras para impressoras Zebra em ambientes Oracle WMS e MSCA RELATÓRIO INFORMATIVO SOBRE APLICAÇÃO Direitos autorais 2004 ZIH Corp. Todos os nomes e números de produtos

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

Levantamento sobre Computação em Nuvens

Levantamento sobre Computação em Nuvens Levantamento sobre Computação em Nuvens Mozart Lemos de Siqueira Doutor em Ciência da Computação Centro Universitário Ritter dos Reis Sistemas de Informação: Ciência e Tecnologia Aplicadas mozarts@uniritter.edu.br

Leia mais

Gestão do Conteúdo. 1. Introdução

Gestão do Conteúdo. 1. Introdução Gestão do Conteúdo 1. Introdução Ser capaz de fornecer informações a qualquer momento, lugar ou através de qualquer método e ser capaz de fazê-lo de uma forma econômica e rápida está se tornando uma exigência

Leia mais

Distribuição de Bases de Dados de Proveniência na Nuvem *

Distribuição de Bases de Dados de Proveniência na Nuvem * Distribuição de Bases de Dados de Proveniência na Nuvem * Edimar Santos 1, Vanessa Assis 1, Flavio Costa 1, Daniel de Oliveira 2 e Marta Mattoso 1 1 Programa de Engenharia de Sistemas e Computação COPPE

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Gestão em Sistemas de Informação. Profa.: Me. Christiane Zim Zapelini E-mail: christianezapelini@nwk.edu.br

Gestão em Sistemas de Informação. Profa.: Me. Christiane Zim Zapelini E-mail: christianezapelini@nwk.edu.br Gestão em Sistemas de Informação Profa.: Me. Christiane Zim Zapelini E-mail: christianezapelini@nwk.edu.br Gestão em Sistemas de Informação Cloud Computing (Computação nas Nuvens) 2 Cloud Computing Vocês

Leia mais

Computação em Grid e em Nuvem

Computação em Grid e em Nuvem Computação em Grid e em Nuvem Computação em Nuvem Molos 1 Definição Um grid computacional é uma coleção recursos computacionais e comunicação utilizados para execução aplicações Usuário vê o grid como

Leia mais

Computação em Nuvem & OpenStack

Computação em Nuvem & OpenStack Computação em Nuvem & OpenStack Grupo de Pesquisa em Software e Hardware Livre Ação Computação em Nuvem: Charles Christian Miers André Rover de Campos Glauber Cassiano Batista Joinville Roteiro Definições

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Shermila Guerra Santa Cruz Orientador: Ricardo Rodrigues Ciferri

Shermila Guerra Santa Cruz Orientador: Ricardo Rodrigues Ciferri Shermila Guerra Santa Cruz Orientador: Ricardo Rodrigues Ciferri O que é computação em nuvem (CN)? Vantagens e desvantagens da computação em nuvem Serviços da computação em nuvem SaaS, IasS, PasS e DbasS

Leia mais

CLOUD COMPUTING PEDRO MORHY BORGES LEAL. MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010

CLOUD COMPUTING PEDRO MORHY BORGES LEAL. MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010 CLOUD COMPUTING PEDRO MORHY BORGES LEAL MAC0412 - Organização de Computadores Prof. Alfredo Goldman 7 de dezembro de 2010 0 CLOUD COMPUTING 1 1. Introdução Com o grande avanço da tecnologia de processadores,

Leia mais

Uma Breve Introdução. Andréa Bordin

Uma Breve Introdução. Andréa Bordin Uma Breve Introdução Andréa Bordin O que significa? NoSQL é um termo genérico que define bancos de dados não-relacionais. A tecnologia NoSQL foi iniciada por companhias líderes da Internet - incluindo

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

CLOUD COMPUTING NAS EMPRESAS: NUVEM PÚBLICA OU NUVEM PRIVADA? nubeliu.com

CLOUD COMPUTING NAS EMPRESAS: NUVEM PÚBLICA OU NUVEM PRIVADA? nubeliu.com CLOUD COMPUTING NAS EMPRESAS: NUVEM PÚBLICA OU NUVEM PRIVADA? nubeliu.com SUMÁRIO Introdução... 4 Nuvem pública: quando ela é ideal... 9 Nuvem privada: quando utilizá-la... 12 Alternativas de sistemas

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Avaliação de dependabilidade em infraestruturas Eucalyptus geograficamente distribuídas

Avaliação de dependabilidade em infraestruturas Eucalyptus geograficamente distribuídas Avaliação de dependabilidade em infraestruturas Eucalyptus geograficamente distribuídas Jonathan Brilhante(jlgapb@cin.ufpe), Bruno Silva(bs@cin.ufpe) e Paulo Maciel(prmm@cin.ufpe) Agenda 1. 2. 3. 4. 5.

Leia mais

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados SISTEMA DE BANCO DE DADOS Banco e Modelagem de dados Sumário Conceitos/Autores chave... 3 1. Introdução... 4 2. Arquiteturas de um Sistema Gerenciador... 5 3. Componentes de um Sistema... 8 4. Vantagens

Leia mais

SQL Structured Query Language

SQL Structured Query Language Janai Maciel SQL Structured Query Language (Banco de Dados) Conceitos de Linguagens de Programação 2013.2 Structured Query Language ( Linguagem de Consulta Estruturada ) Conceito: É a linguagem de pesquisa

Leia mais

Universidade Agostinho Neto Faculdade de Ciências Departamento de Ciências da Computação

Universidade Agostinho Neto Faculdade de Ciências Departamento de Ciências da Computação Universidade Agostinho Neto Faculdade de Ciências Departamento de Ciências da Computação Nº 96080 - Adário de Assunção Fonseca Muatelembe Nº 96118 - Castelo Pedro dos Santos Nº 96170 - Feliciano José Pascoal

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Computação em Nuvem Introdução Centralização do processamento Surgimento da Teleinformática Década de 60 Execução de programas localmente Computadores

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

Leia mais

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS

COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS RELATÓRIO EXECUTIVO DE NEGÓCIOS COMPUTAÇÃO EM NUVEM: TENDÊNCIAS E OPORTUNIDADES DE NEGÓCIOS TM RELATÓRIO EXECUTIVO DE NEGÓCIOS A visão da computação em nuvem por Aad van Schetsen, vicepresidente da Compuware Uniface, que mostra por que

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Cisco Intelligent Automation for Cloud

Cisco Intelligent Automation for Cloud Dados técnicos do produto Cisco Intelligent Automation for Cloud Os primeiros a adotarem serviços com base em nuvem buscavam uma economia de custo maior que a virtualização e abstração de servidores podiam

Leia mais

Workflow de documentos eficiente e transparente com o

Workflow de documentos eficiente e transparente com o Workflow com o DocuWare Solution Info Workflow de documentos eficiente e transparente com o DocuWare As soluções de workflow para documentos com o DocuWare melhoram a organização de sua empresa; processos

Leia mais

CONHECIMENTOS ESPECÍFICOS

CONHECIMENTOS ESPECÍFICOS CONHECIMENTOS ESPECÍFICOS Acerca dos conceitos básicos de gerenciamento de projetos e considerando o PMBOK, julgue os itens a seguir. 51 No gerenciamento de um projeto, deve-se utilizar não apenas as ferramentas

Leia mais

BANCO DE DADOS CONCEITOS BÁSICOS

BANCO DE DADOS CONCEITOS BÁSICOS Universidade Federal da Paraíba UFPB Centro de Energias Alternativas e Renováveis - CEAR Departamento de Eng. Elétrica DEE BANCO DE DADOS CONCEITOS BÁSICOS Isaac Maia Pessoa Introdução O que é um BD? Operações

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

Introdução a Informática. Prof.: Roberto Franciscatto

Introdução a Informática. Prof.: Roberto Franciscatto Introdução a Informática Prof.: Roberto Franciscatto 6.1 ARQUIVOS E REGISTROS De um modo geral os dados estão organizados em arquivos. Define-se arquivo como um conjunto de informações referentes aos elementos

Leia mais

Simulação Computacional de Sistemas, ou simplesmente Simulação

Simulação Computacional de Sistemas, ou simplesmente Simulação Simulação Computacional de Sistemas, ou simplesmente Simulação Utilização de métodos matemáticos & estatísticos em programas computacionais visando imitar o comportamento de algum processo do mundo real.

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Disciplina - Sistemas Distribuídos Prof. Andrey Halysson Lima Barbosa Aula 12 Computação em Nuvem Sumário Introdução Arquitetura Provedores

Leia mais

Bem-vindo à apresentação do SAP Business One.

Bem-vindo à apresentação do SAP Business One. Bem-vindo à apresentação do SAP Business One. Neste tópico, responderemos à pergunta: O que é o Business One? Definiremos o SAP Business One e discutiremos as opções e as plataformas disponíveis para executar

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos O gerenciamento de informações é crucial para o sucesso de qualquer organização.

Leia mais

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos O gerenciamento de informações é crucial para o sucesso de qualquer organização.

Leia mais

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini Banco de Dados Conceitos e Arquitetura de Sistemas de Banco de Dados Profa. Flávia Cristina Bernardini Relembrando... Vantagens da Utilização de SGBD Redundância controlada Consistência dos dados armazenados

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

imited Edition IMULADO

imited Edition IMULADO J tudent 1 Exame Simulado imited Edition IMULADO 1. Identifique as características da computação em nuvem? a) A computação em nuvem entrega uma ampla gama de serviços. b) A computação em nuvem é adquirida

Leia mais

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados. BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br INTRODUÇÃO Hoje é

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Luciana da Silva Almendra Gomes. Proveniência para Workflows de Bioinformática

Luciana da Silva Almendra Gomes. Proveniência para Workflows de Bioinformática Luciana da Silva Almendra Gomes Proveniência para Workflows de Bioinformática Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós-

Leia mais

monitoramento unificado

monitoramento unificado DOCUMENTAÇÃO TÉCNICA monitoramento unificado uma perspectiva de negócios agility made possible sumário resumo executivo 3 Introdução 3 Seção 1: ambientes de computação emergentes atuais 4 Seção 2: desafios

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Conceitos básicos de Banco de Dados

Conceitos básicos de Banco de Dados Modelagem de Banco de Dados Conceitos básicos de Banco de Dados Professor: Anderson D. Moura Março, 2009 Banco de Dados Bancos de dados, (ou bases de dados), são conjuntos de dados com uma estrutura regular

Leia mais

OCEL001 Comércio Eletrônico Módulo 9_4: OpenStack

OCEL001 Comércio Eletrônico Módulo 9_4: OpenStack OCEL001 Comércio Eletrônico Módulo 9_4: OpenStack Prof. Charles Christian Miers e-mail: charles.miers@udesc.br OpenStack OpenStack é um projeto de computação em nuvem criado em julho de 2010, fruto de

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Cloud. Tudo o que um CEO precisa saber, mas o TI não teve paciência para explicar. {/} CLOUD SOLUTIONS

Cloud. Tudo o que um CEO precisa saber, mas o TI não teve paciência para explicar. {/} CLOUD SOLUTIONS Cloud Tudo o que um CEO precisa saber, mas o TI não teve paciência para explicar. {/} CLOUD SOLUTIONS Cloud Computing: O que é. O que faz. As vantagens. E tudo o que um CEO precisa saber, mas o TI não

Leia mais

REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL SERVER

REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL SERVER FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE FANESE NÚCLEO DE PÓS-GRADUAÇÃO E EXTENSÃO NPGE CURSO DE PÓS-GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO EM BANCO DE DADOS REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL

Leia mais

Guia de instalação e configuração do Alteryx Server

Guia de instalação e configuração do Alteryx Server Guia de referência Guia de instalação e configuração do Alteryx Server v 1.5, novembro de 2015 Sumário Guia de instalação e configuração do Alteryx Server Sumário Capítulo 1 Visão geral do sistema... 5

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

Sumário Agradecimentos... 19 Sobre.o.autor... 20 Prefácio... 21 Capítulo.1..Bem-vindo.ao.MySQL... 22

Sumário Agradecimentos... 19 Sobre.o.autor... 20 Prefácio... 21 Capítulo.1..Bem-vindo.ao.MySQL... 22 Sumário Agradecimentos... 19 Sobre o autor... 20 Prefácio... 21 Capítulo 1 Bem-vindo ao MySQL... 22 1.1 O que é o MySQL?...22 1.1.1 História do MySQL...23 1.1.2 Licença de uso...23 1.2 Utilizações recomendadas...24

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com

Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Introdução a Banco de Dados Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com 12/06/2013 Sumário Motivação da Disciplina

Leia mais

Guia Técnicas de Teste Metodologia Celepar

Guia Técnicas de Teste Metodologia Celepar Guia Técnicas de Teste Metodologia Celepar Agosto de 2009 Sumário de Informações do Documento Documento: guiatecnicasteste.odt Número de páginas: 22 Versão Data Mudanças Autor 1.0 17/09/07 Criação. Ariel

Leia mais

Faculdade Lourenço Filho - ENADE 2011-1

Faculdade Lourenço Filho - ENADE 2011-1 1. Quando se constrói um banco de dados, define-se o modelo de entidade e relacionamento (MER), que é a representação abstrata das estruturas de dados do banco e seus relacionamentos. Cada entidade pode

Leia mais

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS CLAUDIO RIBEIRO DA SILVA MARÇO 1997 2 1 - CONCEITOS GERAIS DE 1.1 - Conceitos Banco de Dados - Representa

Leia mais

ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS

ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS ADAPTANDO UMA APLICAÇÃO PARA CLOUD: UMA ANÁLISE ENTRE OS ESFORÇOS UTILIZADOS Cleverson Nascimento de Mello¹, Claudete Werner¹, Gabriel Costa Silva² ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 3 Virtualização de Sistemas 1. Conceito Virtualização pode ser definida

Leia mais

Uso de SGBDs NoSQL na Gerência da Proveniência Distribuída em Workflows Científicos

Uso de SGBDs NoSQL na Gerência da Proveniência Distribuída em Workflows Científicos Uso de SGBDs NoSQL na Gerência da Proveniência Distribuída em Workflows Científicos Guilherme R. Ferreira, Carlos Filipe Jr. e Daniel de Oliveira Instituto de Computação Universidade Federal Fluminense

Leia mais