hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: keyvalue cache
Date Wed, 04 Apr 2012 17:35:17 GMT
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
<vrodionov@carrieriq.com>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: vrodionov@carrieriq.com
>
> ________________________________________
> From: Enis Söztutar [enis@apache.org]
> Sent: Tuesday, April 03, 2012 3:34 PM
> To: dev@hbase.apache.org
> 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 Notifications@carrieriq.com and
> delete or destroy any copy of this message and its attachments.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message