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 >> blockcache 101


Copy link to this message
-
Re: blockcache 101
On Wed, Apr 9, 2014 at 10:24 AM, Nick Dimiduk <[EMAIL PROTECTED]> wrote:
Was referring to these graphs:
http://www.n10k.com/assets/perfeval_blockcache_v2.pdf

And yep, I think straight lines between the points (or just the points
themselves) might be more accurate.

Hmm... in "v2.pdf" here you're looking at different ratios of DB size to
cache size, but there's also the secondary cache on the system (the OS
block cache), right? So when you say only 20GB "memory under management",
in fact you're still probably getting 100% hit rate on the case where the
DB is bigger than RAM, right?

I guess I just find the graphs a little hard to understand what they're
trying to demonstrate. Maybe would be better to have each graph show the
different cache implementations overlaid, rather than the different ratios
overlaid? That would better differentiate the scaling behavior of the
implementations vs each other. As you've got it, the results seem somewhat
obvious ("as the hit ratio gets worse, it gets slower").

Todd Lipcon
Software Engineer, Cloudera

 
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