Home | About | Sematext search-lucene.com search-hadoop.com
 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.


On Tue, Apr 3, 2012 at 11:03 PM, Vladimir Rodionov

> 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
> ________________________________________
> From: Enis Söztutar [[EMAIL PROTECTED]]
> Sent: Tuesday, April 03, 2012 3:34 PM
> 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.