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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM

CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM CONCEITOS E APLICAÇÕES DA COMPUTAÇÃO EM NUVEM Rogério Schueroff Vandresen¹, Willian Barbosa Magalhães¹ ¹Universidade Paranaense(UNIPAR) Paranavaí-PR-Brasil rogeriovandresen@gmail.com, wmagalhaes@unipar.br

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

MSc. Daniele Carvalho Oliveira

MSc. Daniele Carvalho Oliveira MSc. Daniele Carvalho Oliveira AULA 2 Administração de Banco de Dados: MSc. Daniele Oliveira 2 CONCEITOS FUNDAMENTAIS DE BANCO DE DADOS Administração de Banco de Dados: MSc. Daniele Oliveira 3 Conceitos

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

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

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

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

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

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

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

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

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

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

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

Seminário: Google File System (GFS)

Seminário: Google File System (GFS) UNIVERSIDADE FEDERAL DE SANTA CATARINA UFSC Disciplina: Sistemas Operacionais I INE5355 Alunos: Armando Fracalossi 06132008 Maurílio Tiago Brüning Schmitt 06132033 Ricardo Vieira Fritsche 06132044 Seminário:

Leia mais

Como a nuvem mudará as operações de liberação de aplicativos

Como a nuvem mudará as operações de liberação de aplicativos DOCUMENTAÇÃO TÉCNICA Junho de 2013 Como a nuvem mudará as operações de liberação de aplicativos Jacob Ukelson Entrega de aplicativos Sumário Resumo executivo 3 Seção 1: 4 Mudando o cenário de automação

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

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

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

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

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

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

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

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

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos

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

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

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

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas

ATIVIDADE 1 MÁQUINAS VIRTUAIS. 1.1 Arquiteturas não virtualizadas ATIVIDADE 1 MÁQUINAS VIRTUAIS Existem hoje diversas tecnologias e produtos para virtualização de computadores e ambientes de execução, o que pode gerar uma certa confusão de conceitos. Apesar disso, cada

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

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

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

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

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

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

Banco de Dados I Introdução

Banco de Dados I Introdução Banco de Dados I Introdução Prof. Moser Fagundes Curso Técnico em Informática (Modalidade Integrada) IFSul Campus Charqueadas Sumário da aula Avaliações Visão geral da disciplina Introdução Histórico Porque

Leia mais

Gestão de Armazenamento

Gestão de Armazenamento Gestão de Armazenamento 1. Introdução As organizações estão se deparando com o desafio de gerenciar com eficiência uma quantidade extraordinária de dados comerciais gerados por aplicativos e transações

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

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

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

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

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

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

COMPUTAÇÃO EM NUVEM: UM FUTURO PRESENTE

COMPUTAÇÃO EM NUVEM: UM FUTURO PRESENTE COMPUTAÇÃO EM NUVEM: UM FUTURO PRESENTE Andressa T.R. Fenilli 1, Késsia R.C.Marchi 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil andressa.trf@gmail.com, kessia@unipar.br Resumo. Computação em

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Análise de Desempenho de um SGBD para Aglomerado de Computadores

Análise de Desempenho de um SGBD para Aglomerado de Computadores Análise de Desempenho de um SGBD para Aglomerado de Computadores Diego Luís Kreutz, Gabriela Jacques da Silva, Hélio Antônio Miranda da Silva, João Carlos Damasceno Lima Curso de Ciência da Computação

Leia mais

Arquitetura de Banco de Dados

Arquitetura de Banco de Dados Arquitetura de Banco de Dados Daniela Barreiro Claro MAT A60 DCC/IM/UFBA Arquitetura de Banco de dados Final de 1972, ANSI/X3/SPARC estabeleceram o relatório final do STUDY GROUP Objetivos do Study Group

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

TRIBUTAÇÃO NA NUVEM. Tax Friday 21 de outubro de 2011 AMCHAM - RJ

TRIBUTAÇÃO NA NUVEM. Tax Friday 21 de outubro de 2011 AMCHAM - RJ TRIBUTAÇÃO NA NUVEM Tax Friday 21 de outubro de 2011 AMCHAM - RJ PROGRAMA 1. INTRODUÇÃO À COMPUTAÇÃO EM NUVEM CONCEITOS APLICÁVEIS 2. PRINCIPAIS OPERAÇÕES E ASPECTOS TRIBUTÁRIOS POLÊMICOS INTRODUÇÃO À

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

Fundamentos de Banco de Dados

Fundamentos de Banco de Dados Fundamentos de Banco de Dados SISTEMAS BASEADOS NO PROCESSAMENTO DE ARQUIVOS Sistema A Funcionário Pagamento Cargo Sistema B Funcionário Projeto SISTEMAS GERENCIADORES DE BANCO DE DADOS (SGBD) Sistema

Leia mais

Soluções em Software para Medicina Diagnóstica. www.digitalmed.com.br

Soluções em Software para Medicina Diagnóstica. www.digitalmed.com.br Soluções em Software para Medicina Diagnóstica www.digitalmed.com.br NOTA DE AGRADECIMENTO Primeiramente, agradecemos pela sua receptividade em conhecer as nossas soluções, afinal, é sempre uma imensa

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados

Leia mais

15 Conceitos de Bancos de Dados com o LibreOffice Base

15 Conceitos de Bancos de Dados com o LibreOffice Base Introdução a Informática - 1º semestre AULA 14 Prof. André Moraes Objetivos desta aula: Explorar as propriedades na criação de bancos de dados no LibreOffice Base; Criar e explorar tabelas; Criar e explorar

Leia mais

SQL APOSTILA INTRODUÇÃO A LINGUAGEM SQL

SQL APOSTILA INTRODUÇÃO A LINGUAGEM SQL SQL APOSTILA INTRODUÇÃO Uma linguagem de consulta é a linguagem por meio da qual os usuários obtêm informações do banco de dados. Essas linguagens são, tipicamente, de nível mais alto que as linguagens

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Conceitos e Arquitetura Vantagens das Arquiteturas C/S (em relação

Leia mais

Universidade Utiliza Virtualização para Criar Data Center Com Melhor Custo-Benefício e Desempenho

Universidade Utiliza Virtualização para Criar Data Center Com Melhor Custo-Benefício e Desempenho Virtualização Microsoft: Data Center a Estação de Trabalho Estudo de Caso de Solução para Cliente Universidade Utiliza Virtualização para Criar Data Center Com Melhor Custo-Benefício e Desempenho Visão

Leia mais

Como usar a nuvem para continuidade dos negócios e recuperação de desastres

Como usar a nuvem para continuidade dos negócios e recuperação de desastres Como usar a nuvem para continuidade dos negócios e recuperação de desastres Há diversos motivos para as empresas de hoje enxergarem o valor de um serviço de nuvem, seja uma nuvem privada oferecida por

Leia mais

4 Desenvolvimento da ferramenta

4 Desenvolvimento da ferramenta direcionados por comportamento 38 4 Desenvolvimento da ferramenta Visando facilitar a tarefa de documentar requisitos funcionais e de gerar testes automáticos em uma única ferramenta para proporcionar

Leia mais

XXV Encontro Nac. de Eng. de Produção Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

XXV Encontro Nac. de Eng. de Produção Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005 Modelo de integração de sistemas de gestão erp com a produção lexandre ugusto Massote (FEI) massote@fei.edu.br Guilherme Braga guiar De Maria (FEI) guibraga@terra.com.br Vanessa Takagochi (FEI) vanessa_takagochi@yahoo.com.br

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

O que é Grid Computing

O que é Grid Computing Grid Computing Agenda O que é Grid Computing Grid vs Cluster Benefícios Tipos de Grid Aplicações Ferramentas e padrões Exemplos no mundo Exemplos no Brasil Grid no mundo dos negócios Futuro O que é Grid

Leia mais

Consolidação inteligente de servidores com o System Center

Consolidação inteligente de servidores com o System Center Consolidação de servidores por meio da virtualização Determinação do local dos sistemas convidados: a necessidade de determinar o melhor host de virtualização que possa lidar com os requisitos do sistema

Leia mais

Proteção de ambientes Citrix XenServer com Arcserve

Proteção de ambientes Citrix XenServer com Arcserve Proteção de ambientes Citrix XenServer com Arcserve Desafios do cliente Hoje em dia, você enfrenta desafios como acordos de nível de serviço exigentes e limitações de equipe e orçamento. Você procura maneiras

Leia mais

TRIBUTAÇÃO NAS NUVENS Uma Regulação em Debate

TRIBUTAÇÃO NAS NUVENS Uma Regulação em Debate TRIBUTAÇÃO NAS NUVENS Uma Regulação em Debate Workshop Divisão Tributária 18.04.2013 CIESP - CAMPINAS PROGRAMA 1. BREVE INTRODUÇÃO À COMPUTAÇÃO EM NUVEM 2. PRINCIPAIS OPERAÇÕES E ASPECTOS TRIBUTÁRIOS POLÊMICOS

Leia mais

Bancos de Dados em Clouds

Bancos de Dados em Clouds Bancos de Dados em Clouds Bancos de Dados em Clouds Erik Williams Zirke Osta Rafael Brundo Uriarte Agenda Introdução; Fundamentos; Estudo comparativo das Ferramentas; Conclusões e Trabalhos Futuros. Agenda

Leia mais

ATIVIDADES PRÁTICAS SUPERVISIONADAS

ATIVIDADES PRÁTICAS SUPERVISIONADAS ATIVIDADES PRÁTICAS SUPERVISIONADAS Ciência da Computação 5ª série Sistemas Operacionais A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem desenvolvido por meio de um conjunto

Leia mais

Sistemas de Informação Geográfica Prof. Tiago Eugenio de Melo, MSc.

Sistemas de Informação Geográfica Prof. Tiago Eugenio de Melo, MSc. Sistemas de Informação Geográfica Prof. Tiago Eugenio de Melo, MSc. SUMÁRIO Apresentação da ementa Introdução Conceitos Básicos de Geoinformação Arquitetura de SIGs Referências Bibliográficas APRESENTAÇÃO

Leia mais

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados.

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Histórico Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Sistemas Integrados: racionalização de processos, manutenção dos

Leia mais

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Introdução BD desempenha papel crítico em todas as áreas em que computadores são utilizados: Banco: Depositar ou retirar

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

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 Consistência e Replicação Capítulo 7 Agenda Razões para Replicação Replicação como técnica de escalabilidade Modelos de Consistência centrados

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais