flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-1885) Bulk mode for gelly
Date Fri, 17 Apr 2015 15:24:58 GMT

    [ https://issues.apache.org/jira/browse/FLINK-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14500024#comment-14500024

ASF GitHub Bot commented on FLINK-1885:

Github user markus-h commented on the pull request:

    Hi @vasia,
    thanks for your comments! I thought about this extension in a different way. Whenever
you have a graph that is too big to process it with delta iteration you could just turn on
bulk mode to get the computation done. It will be a lot slower, but sometimes this might be
better then not getting any results.
    I dont think a dedicated bulk operator would be very useful. People can just use plain
Flink if they dont need the Pregel abstraction. And in most cases it would be much slower
then using the current solution.
    You know gelly and its usecases a lot better then me. If you dont think that a mode like
this might be userful I am totally find with that. It is a very small change anyway.

> Bulk mode for gelly
> -------------------
>                 Key: FLINK-1885
>                 URL: https://issues.apache.org/jira/browse/FLINK-1885
>             Project: Flink
>          Issue Type: Improvement
>          Components: Gelly
>            Reporter: Markus Holzemer
>            Assignee: Markus Holzemer
>            Priority: Minor
> For my research I need to execute graph algorithm with delta iterations and with bulk
iterations. So I added an execution mode to gelly that executes the vertex centric iteration
with a bulk iteration.
> Since gelly normally keeps the whole graph in the solution set of the delta iteration,
it can only handle graphs that fit into the distributed memory of ones nodes (correct me if
I am wrong). So a bulk mode could also be usefull for handling graphs that do not fit in memory.

This message was sent by Atlassian JIRA

View raw message