Yes thanks Claudio, that is what my impression is as well. Thanks for the confirmation.
-----Original Message----- From: Claudio Martella [mailto:[email protected]] Sent: Tuesday, 24 January 2012 8:38 AM To: [email protected] Subject: Re: How is this use case supported Hi Gavan, Giraph is a batch processing engine, no DB. What you would do is the same you would do with Mapreduce. As you said, you input a snapshot of your constantly changing graph to Giraph and work later with what's coming out in your pipeline. I personally I don't see space for transactions inside of Giraph, you'd have to manage it yourself from its output to update your DB. Does it help? Best, Claudio On Mon, Jan 23, 2012 at 11:29 PM, Gavan Hood <[email protected]> wrote: > Hi all, > > I have been wondering how Giraph can support a large graph that is constantly being updated by multiple jobs running simultaneously. > Output of jobs are continually adding extra and modifying edges / vertices in the graph. Some notion of transactional concurrency would be needed as well in this environment. > > From what I can see it appears that Giraph may be well suited to working with snapshots of such as system rather than the root implementation, but I feel that I might be missing a core design pattern. > > Regards > Gavan > > -- Claudio Martella [email protected]
