Return-Path: Delivered-To: apmail-hbase-user-archive@www.apache.org Received: (qmail 70112 invoked from network); 1 Dec 2010 08:24:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Dec 2010 08:24:59 -0000 Received: (qmail 33109 invoked by uid 500); 1 Dec 2010 08:24:58 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 33077 invoked by uid 500); 1 Dec 2010 08:24:58 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 33069 invoked by uid 99); 1 Dec 2010 08:24:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Dec 2010 08:24:57 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.214.169] (HELO mail-iw0-f169.google.com) (209.85.214.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Dec 2010 08:24:51 +0000 Received: by iwn42 with SMTP id 42so2418692iwn.14 for ; Wed, 01 Dec 2010 00:24:29 -0800 (PST) Received: by 10.231.173.138 with SMTP id p10mr8602198ibz.143.1291191868132; Wed, 01 Dec 2010 00:24:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.154.18 with HTTP; Wed, 1 Dec 2010 00:24:05 -0800 (PST) In-Reply-To: <4CF503DC.5070207@tis.bz.it> References: <4CF3C2E0.2070804@tis.bz.it> <2D6136772A13B84E95DF6DA79E85A9F00130CAD30930@NSPEXMBX-A.the-lab.llnl.gov> <4CF503DC.5070207@tis.bz.it> From: Todd Lipcon Date: Wed, 1 Dec 2010 00:24:05 -0800 Message-ID: Subject: Re: incremental counters and a global String->Long Dictionary To: user@hbase.apache.org Content-Type: multipart/alternative; boundary=0014853d202ea312b604965508c2 X-Virus-Checked: Checked by ClamAV on apache.org --0014853d202ea312b604965508c2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 30, 2010 at 6:02 AM, Claudio Martella < claudio.martella@tis.bz.it> wrote: > Lars, > > yes, that's exactly the problem, i also considered checkAndPut() but > that wouldn't work for two reasons: > > 1) i wouldn't atomically both insert the row AND increment the counter > To me, that seems fine - if you "waste" a counter value, is that really a problem? The race is rare, so it's only occasional that you will grab a counter value with the ICV and then end up losing the checkAndPut. When that happens, yes, you skip an identifier, but the goal here is just to compress the strings, and therefore there's no real serious benefit to keeping the range of identifiers completely contiguous. > 2) for what i can tell checkAndPut() doesn't work like existsOrPut(), > right? That would be a nice add to the API, i think. What do you guys > think? > As Ryan mentioned, you can do this with null and the current API. -Todd > > At this point i think, if i decide not to impleemnt Dave's idea, I'll > have to go for biglock. It's slow at the beginning, but the bottleneck > is negligible after a while. > > Thanks for your support. > > > On 11/30/10 2:18 AM, Lars George wrote: > > I like that idea Dave. > > > > As for the checkAndPut(), this will not work as Claudio intended? He > > wanted the counter and put to run together, so that former is only > > half the deal? Just wondering. > > > > Lars > > > > On Tue, Nov 30, 2010 at 1:43 AM, Buttler, David > wrote: > >> A while back I had a strange idea to bypass this problem: create a > 64-bit hash code for the word. Your word space should be significantly > smaller than 64 bits, so a good hash algorithm (the top 64 bits of sha1 say) > should make collisions extremely rare. And, if you can always check your > dictionary later for collisions if this feels wrong. > >> This should be a good deal simpler than trying to keep around an order > dependent integer mapping for your dictionary. And, it is somewhat > recoverable if you ever lose your dictionary for some reason. > >> > >> Dave > >> > >> -----Original Message----- > >> From: Claudio Martella [mailto:claudio.martella@tis.bz.it] > >> Sent: Monday, November 29, 2010 7:13 AM > >> To: user@hbase.apache.org > >> Subject: incremental counters and a global String->Long Dictionary > >> > >> Hello list, > >> > >> I'm kind of new to HBase, so I'll post this email with a request for > >> comment. > >> Very briefly, I do a lot of text processing with mapreduce, so it's very > >> useful for me to convert string to longs, so i can make my computations > >> faster. > >> > >> My corpus keeps on growing and I want this String->Long mapping to be > >> persistent and dynamical (i want to add new mappings when i find new > words). > >> At the moment i'm tackling the problem this way (pseudo-code): > >> > >> longvalue = convert(word) # gets from hbase > >> if longvalue == -1: > >> longvalue = insert(word) # puts in hbase > >> > >> longvalue now contains the new mapped value. This approach requires a > >> global counter that saves the latest mapped long and increments at every > >> insert. I can easily do this two ways. A special row in hbase "_counter" > >> that I increment through IncrementColumnValue, or creating a sequential > >> non-ephemeral znode in zookeeper and use the version as my counter. The > >> first one is of course faster. So the solution would be: > >> > >> insert(word): > >> longvalue = hbase.incrementColumnValue("_counter", "v") > >> hbase.put(word, longvalue) > >> return longvalue > >> > >> The problem is that between the time i realize there's no mapping for my > >> word and the time i insert the new longvalue, somebody else might have > >> done the same for me, so I have a corrupted dictionary. > >> > >> One possible solution would be to acquire a lock on the "_counter" row, > >> recheck for the presence of the mapping and then insert my new value: > >> > >> safe_insert(word): > >> lock("_counter") > >> longvalue = convert(word) > >> if longvalue == -1: #nobody inserted the mapping in the meantime > >> longvalue = insert(word) > >> unlock("_counter") > >> return longvalue > >> > >> This way the counter row, with its lock, would behave as a global lock. > >> This would solve my problems but would create a bottleneck (although > >> with time my inserts tend to get very rare as the dictionary grows). A > >> solution to this problem would be to have locks on zookeeper based on > words. > >> > >> ZKsafe_insert(word): > >> ZKlock("/words/"+ word) > >> longvalue = convert(word) > >> if longvalue == -1: #nobody inserted the mapping in the meantime > >> longvalue = insert(word) > >> ZKunlock("/words/"+word) > >> return longvalue > >> > >> This of course would allow me to have more finegrained locks and better > >> scalability, but I'd relay on a system with higher latency (ZK). > >> > >> Does anybody have a better solution with hbase? I guess using > >> hbase_transational would also be a possibility, but again, what about > >> speed and the actual issues with the package (like recovering in the > >> face of hregion failure). > >> > >> > >> Thank you, > >> > >> Claudio > >> > >> -- > >> Claudio Martella > >> Digital Technologies > >> Unit Research & Development - Analyst > >> > >> TIS innovation park > >> Via Siemens 19 | Siemensstr. 19 > >> 39100 Bolzano | 39100 Bozen > >> Tel. +39 0471 068 123 > >> Fax +39 0471 068 129 > >> claudio.martella@tis.bz.it http://www.tis.bz.it > >> > >> Short information regarding use of personal data. According to Section > 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that > we process your personal data in order to fulfil contractual and fiscal > obligations and also to send you information regarding our services and > events. Your personal data are processed with and without electronic means > and by respecting data subjects' rights, fundamental freedoms and dignity, > particularly with regard to confidentiality, personal identity and the right > to personal data protection. At any time and without formalities you can > write an e-mail to privacy@tis.bz.it in order to object the processing of > your personal data for the purpose of sending advertising materials and also > to exercise the right to access personal data and other rights referred to > in Section 7 of Decree 196/2003. The data controller is TIS Techno > Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the > complete information on the web site www.tis.bz.it. > >> > >> > >> > > > -- > Claudio Martella > Digital Technologies > Unit Research & Development - Analyst > > TIS innovation park > Via Siemens 19 | Siemensstr. 19 > 39100 Bolzano | 39100 Bozen > Tel. +39 0471 068 123 > Fax +39 0471 068 129 > claudio.martella@tis.bz.it http://www.tis.bz.it > > Short information regarding use of personal data. According to Section 13 > of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we > process your personal data in order to fulfil contractual and fiscal > obligations and also to send you information regarding our services and > events. Your personal data are processed with and without electronic means > and by respecting data subjects' rights, fundamental freedoms and dignity, > particularly with regard to confidentiality, personal identity and the right > to personal data protection. At any time and without formalities you can > write an e-mail to privacy@tis.bz.it in order to object the processing of > your personal data for the purpose of sending advertising materials and also > to exercise the right to access personal data and other rights referred to > in Section 7 of Decree 196/2003. The data controller is TIS Techno > Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the > complete information on the web site www.tis.bz.it. > > > -- Todd Lipcon Software Engineer, Cloudera --0014853d202ea312b604965508c2--