You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2015/09/17 14:01:04 UTC

[jira] [Updated] (TINKERPOP3-846) General In-Memory GraphComputer

     [ https://issues.apache.org/jira/browse/TINKERPOP3-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stephen mallette updated TINKERPOP3-846:
----------------------------------------
             Assignee: Marko A. Rodriguez
    Affects Version/s: 3.0.1-incubating
          Component/s: process
           Issue Type: Improvement  (was: Bug)

> General In-Memory GraphComputer
> -------------------------------
>
>                 Key: TINKERPOP3-846
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-846
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.1-incubating
>            Reporter: Matthias Broecheler
>            Assignee: Marko A. Rodriguez
>
> Implement a generalized In-Memory GraphComputer that can be utilized by any vendor for use cases of small graphs and where performance isn't critical.
> This GraphComputer would, similar to the one for TinkerGraph, keep everything in memory. It would rely on the {{graph.vertices()}} method of the underlying graph for access to the data.
> Note, this looks likes a duplicate of TINKERPOP3-42. However, the motivation for this ticket is not to develop an efficient GraphComputer or one that can deal with large graphs - just a default implementation. Also, it is not clear why the view would need to copy the entire graph or cache. The view would only need to hold the delta that is being modified by the GraphComputer.
> This would be incredibly useful as a utility for vendors to use for small scale graphs where hassle of setting up Hadoop or Spark is just too much.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)