Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> on the impact of incremental counters


Copy link to this message
-
Re: on the impact of incremental counters
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB