Return-Path: X-Original-To: apmail-giraph-user-archive@www.apache.org Delivered-To: apmail-giraph-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C0BBACDE8 for ; Thu, 4 Jul 2013 10:00:52 +0000 (UTC) Received: (qmail 71096 invoked by uid 500); 4 Jul 2013 10:00:51 -0000 Delivered-To: apmail-giraph-user-archive@giraph.apache.org Received: (qmail 71032 invoked by uid 500); 4 Jul 2013 10:00:51 -0000 Mailing-List: contact user-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@giraph.apache.org Delivered-To: mailing list user@giraph.apache.org Received: (qmail 71018 invoked by uid 99); 4 Jul 2013 10:00:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jul 2013 10:00:49 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pradeepg26@gmail.com designates 209.85.215.47 as permitted sender) Received: from [209.85.215.47] (HELO mail-la0-f47.google.com) (209.85.215.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jul 2013 10:00:44 +0000 Received: by mail-la0-f47.google.com with SMTP id fe20so1056740lab.34 for ; Thu, 04 Jul 2013 03:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DVu4S7t6gJnBEuidkn2x73VTt+gV78TBkakpxItHv8k=; b=tuNh3QLBAfayPs+dq7VdYj661tMiKJ9S3rl0ZEk9j70pidHW7BvjG4GO5IKtT2bHkR o8yWVenDhDMPJNda/imAu/ncEKrrrL/Su/38lkyKx7KnENanqCNfNtH4npPHRBJzP0Yo i9Fxopve5o86s2QqqO1LpujbAYrUAl1XaHBumBDTChARSxBCbiZWaHui+ezwg5gmfpzL W3fJ7FV2dovEhG7Ky0bo3lUM/ucZIJ/EwkUI5r9zSTg/Dwyqq9wL/RgVEyrSaNs6vzF0 7hDfjao23/VFG4AuF5ABo8M+/sgn2fHfPS8IQpbRZioAEN/NgwpoJF21LStGGc5E8A1R hYEQ== MIME-Version: 1.0 X-Received: by 10.152.1.134 with SMTP id 6mr2539408lam.16.1372932023175; Thu, 04 Jul 2013 03:00:23 -0700 (PDT) Received: by 10.112.149.199 with HTTP; Thu, 4 Jul 2013 03:00:23 -0700 (PDT) Received: by 10.112.149.199 with HTTP; Thu, 4 Jul 2013 03:00:23 -0700 (PDT) In-Reply-To: References: <51CFE7A7.8010605@ckrause.org> <51D47237.20105@apache.org> Date: Thu, 4 Jul 2013 06:00:23 -0400 Message-ID: Subject: Re: Global factory for vertex IDs? From: Pradeep Gollakota To: user@giraph.apache.org Content-Type: multipart/alternative; boundary=e89a8f234e858acf2804e0aca570 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f234e858acf2804e0aca570 Content-Type: text/plain; charset=ISO-8859-1 If you don't care about reproducibility of the vertex ids you could probably use UUID class from java to create random UUIDs On Jul 4, 2013 2:19 AM, "Christian Krause" wrote: > Yes, that would be perfectly fine. How can I do this? Specifically, how do > I get the ID of the worker? And can I then just use a counter field in my > computation which I increase whenever I need a new ID? > > (So my global ID would be a pair of the worker ID and the number I derived > from incrementing the counter). > > Cheers, > Christian > > > 2013/7/3 Avery Ching > >> What are the requirements of your global ids? If they simply need to be >> unique, you can split the id space across workers and assign them >> incrementally. >> >> >> On 6/30/13 1:09 AM, Christian Krause wrote: >> >>> Hi, >>> >>> I was wondering if there is a way to register a global factory for new >>> vertex IDs. Currently, I have to come up with new IDs in my compute method >>> which does work, but with the penality that the required memory for vertex >>> IDs is unnecessarily high. If there was a global vertex ID factory I could >>> just keep a global counter and increase it by one when I need a new ID. Is >>> something like that possible, or does it conflict with the BSP computation >>> model? The thing is, in the end vertex ID collisions are detected by >>> Giraph, so why not allow also a global vertex ID factory... >>> >>> Cheers, >>> Christian >>> >> >> > --e89a8f234e858acf2804e0aca570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If you don't care about reproducibility of the vertex id= s you could probably use UUID class from java to create random UUIDs

On Jul 4, 2013 2:19 AM, "Christian Krause&q= uot; <me@ckrause.org> wrote:
Yes, that would be perfectly fine. How can I do this?= Specifically, how do I get the ID of the worker? And can I then just use a= counter field in my computation which I increase whenever I need a new ID?= =A0

(So my global ID would be a pair of the worker ID= and the number I derived from incrementing the counter).

Cheers,
Christian


2013/7/3 Avery Ching &= lt;aching@apache.org= >
What are the requirements of your global ids? =A0If they simply need to be = unique, you can split the id space across workers and assign them increment= ally.


On 6/30/13 1:09 AM, Christian Krause wrote:
Hi,

I was wondering if there is a way to register a global factory for new vert= ex IDs. Currently, I have to come up with new IDs in my compute method whic= h does work, but with the penality that the required memory for vertex IDs = is unnecessarily high. If there was a global vertex ID factory I could just= keep a global counter and increase it by one when I need a new ID. Is some= thing like that possible, or does it conflict with the BSP computation mode= l? The thing is, in the end vertex ID collisions are detected by Giraph, so= why not allow also a global vertex ID factory...

Cheers,
Christian


--e89a8f234e858acf2804e0aca570--