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 # dev >> keyvalue cache


Copy link to this message
-
Re: keyvalue cache
As you said, caching the entire row does not make much sense, given that
the families are by contract the access boundaries. But caching column
families might be a good trade of for dealing with the per-item overhead.

Also agreed on cache being configurable at the table or better cf level. I
think we can do something like enable_block_cache = true,
enable_kv_cache=false, per column family.

Enis

On Tue, Apr 3, 2012 at 11:03 PM, Vladimir Rodionov
<[EMAIL PROTECTED]>wrote:

> Usually make sense for tables with random mostly access (point queries)
> For short-long scans block cache is preferable.
> Cassandra has it (Row cache) but as since they cache the whole row (which
> can be very large) in many cases
> it has sub par performance. Make sense to make caching configurable: table
> can use key-value cache and do not use block cache
> and vice verse.
>
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: [EMAIL PROTECTED]
>
> ________________________________________
> From: Enis Söztutar [[EMAIL PROTECTED]]
> Sent: Tuesday, April 03, 2012 3:34 PM
> To: [EMAIL PROTECTED]
> Subject: keyvalue cache
>
> Hi,
>
> Before opening the issue, I though I should ask around first. What do you
> think about a keyvalue cache sitting on top of the block cache? It is
> mentioned in the big table paper, and it seems that zipfian kv access
> patterns might benefit from something like this a lot. I could not find
> anybody who proposed that before.
>
> What do you guys think? Should we pursue a kv query-cache. My gut feeling
> says that especially for some workloads we might gain significant
> performance improvements, but we cannot verify it, until we implement and
> profile it, right?
>
> Thanks,
> Enis
>
> Confidentiality Notice:  The information contained in this message,
> including any attachments hereto, may be confidential and is intended to be
> read only by the individual or entity to whom this message is addressed. If
> the reader of this message is not the intended recipient or an agent or
> designee of the intended recipient, please note that any review, use,
> disclosure or distribution of this message or its attachments, in any form,
> is strictly prohibited.  If you have received this message in error, please
> immediately notify the sender and/or [EMAIL PROTECTED] and
> delete or destroy any copy of this message and its attachments.
>
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