Hi Bob, I think it depends on what you want to do and what you need. For example, vanilla memcached is not persistent - if your server goes down, you lost your data and you'll have to load it into the cache again (or just populate it lazily). With HBase replication that shouldn't happen. On the other hand, memcached is older, got a LOT more action over the years, and I have instances whose uptime is measured in *years*. Memcached is lean and mean. From your description, it doesn't sound like you need anything more than 1+ memcached instances.
Otis -- Sematext is hiring -- http://sematext.com/about/jobs.html?mls Lucene, Solr, Nutch, Katta, Hadoop, HBase, UIMA, NLP, NER, IR ----- Original Message ---- > From: Bob Schulze <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Wed, October 7, 2009 5:58:16 AM > Subject: memcached or existing hbase ? > > I need a cache, that is read by many nodes often, written by a few nodes > rarely. Its not too big in size (200.000-2Mio records/1Gb), but may be > too big to fit into one node (so keeping local caches -or zookeeper- is > not an option). > > There is hbase in place already for other applications, do I have a > further benefit (faster?) using memcached (instead, not on top of > course) or would it only be one more piece of software to maintain? > > I read the memcache docs&wiki and are reasonable familiar with hbase but > would appreciate a good reason to use this or that. I am asking in the > hadoop list, because I think also M/R jobs need this for joins > occationally, and memchache is recommended often. > > Thx for any tips, > > Bob
