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 <vrodio...@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: vrodio...@carrieriq.com > > ________________________________________ > From: Enis Söztutar [e...@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 notificati...@carrieriq.com and > delete or destroy any copy of this message and its attachments. >
