Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase, mail # user - on the impact of incremental counters


+
Claudio Martella 2011-06-18, 16:00
+
Andrew Purtell 2011-06-18, 19:24
+
Claudio Martella 2011-06-20, 12:58
+
Andrew Purtell 2011-06-20, 15:14
+
Joey Echeverria 2011-06-20, 15:23
+
Ted Yu 2011-06-20, 15:36
+
Ted Dunning 2011-06-20, 15:50
+
Joe Pallas 2011-06-20, 17:27
Copy link to this message
-
Re: on the impact of incremental counters
Joey Echeverria 2011-06-20, 18:03
Ah, I didn't realize that increment returns the value. Yes, the
current behavior is required in that case. I was thinking of a use
case more like the one Ted described, where you're keeping metrics,
but don't read the values that frequently. Maybe this should be a new
API call.

If no one objects, I'll file a JIRA.

-Joey

On Mon, Jun 20, 2011 at 1:27 PM, Joe Pallas <[EMAIL PROTECTED]> wrote:
>
> On Jun 20, 2011, at 8:50 AM, Ted Dunning wrote:
>
>> Lazy increment on read causes the read to be expensive.  That might be a win
>> if the work load has lots of data that is never read.
>>
>> This could be a good idea on average because my impression is that increment
>> is usually used for metric sorts of data which are often only read in detail
>> in diagnostic post mortem use cases.
>
> Just so we're clear, we'd be talking about a new operation, right?  Because today's increment returns the incremented value, and some uses (like generating unique values) do require that.
>
> joe
>
>

--
Joseph Echeverria
Cloudera, Inc.
443.305.9434
+
Jeff Whiting 2011-06-20, 18:28