It is conceivable that memcache would eventually have only or mostly active objects in memory while hbase might have active pages/tablets/groups of objects. That might give memcache a bit of an edge.
Another thing that happens with memcache is that memcache can hold the results of a complex join which some component views as a single object. The database doesn't normally view these as a single object and thus may not have as much locality. You might view memcache as an interesting transpose from column oriented data (hbase) to row oriented cache (memcache). That could easily result in interesting performance trade-offs. Hbase should be good for scanning, memcache might be better for single object access. On 12/4/07 9:05 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote: > >> 5. Memory caching: Instead of pinning a whole Hbase table in RAM, I'd >> recommend the use of memcached in front of Hbase to provide cached read >> access. > > Memcached is useful when many nodes need to access the same data. It > pools and shares memory across a cluster. In HBase, each node caches a > different portion of a table, no? So I don't see how memcached would > help there.
