Processamento de Dados Massivos/Projeto e implementação de aplicações Big Data/Mineração de Itemsets Frequentes: diferenças entre revisões

[edição não verificada][edição não verificada]
Conteúdo apagado Conteúdo adicionado
Linha 409:
|}
 
Também foi coletado o tempo de execução e Speedupo speedup para a segunda categoria de bases de teste, onde variou-se o número de itens por transação. Os resultados são apresentados nos gráficos a seguir. Note que nesse caso o speedup obtido não é tão bom. Esse fato é previsto e discutido na seção "Projeto", ao aumentar o número de transações aumenta-se também a dependabilidade entre os dados (intrínseca ao Princípio Apriori) durante o primeiro mapeamento. Trata-se de uma dependabilidade intra-nó, durante a geração de itemsets frequentes na primeira etapa de mapeamento.
 
{|
Linha 421:
==== Análise Crítica ====
 
Na grande maioria dos casos práticos, o número de transações é muito maior que o número de itens por transação. Resultados para esse cenário são apresentados no conjunto de testes correspondentes à Categoria 1, como definido na seção "Carga de Trabalho", cujos gráficos de SpeedUpspeedup e Tempotempo de Execuçãoexecução são os primeiros mostrados na seção anterior.
 
Nesse sentido, os resultados indicam que a abordagem aqui desenvolvida para mineração de itemsets frequentes é escalável em contextos práticos. Essa conclusão vem do fato de que o Speedupspeedup aumenta com o aumento da base de dados, quase chegando quase ao Speedupspeedup linear -- caso ideal. Outro fato que reforça essa conclusão é que as maiores bases usadas nesse trabalho ainda são bem muito pequenas se comparadas às bases práticas atuais.
 
Portanto, os resultados levam a crer que, ao aumentar o número de transações (e consequentemente o tamanho) da base de dados para dimensões compatíveis com aplicações reais, o speedup seria ainda melhor, isto é, ainda mais próximo do linear. Obviamente isso não pode ser tomado como verdadeiro sem a execussão de testes adequados que comprovem essa conclusão. Afinal, ao se aumentar a base em tais proporções, aspectos até então ignorados, como a fragmentação de pacotes que carregam mensagens pela rede que interconecta os nós do cluster, poderiam gerar algum overhead interferindo no tempo de execução.
 
{{AutoCat}}