As can be seen, whether the off-host process that manages the cache-data is MongoD or MemcacheD or Terracotta-Server, architecturally they all look equivalent - i.e. a pure-L2 with no-L1 - so that all data needs to be retrieved from over the network and then massaged into a POJO for consumption by the application.

When speaking about caching systems, I’d also include criteria like:

• warm up strategy
• locking strategy
• single-machine memory spill strategy

Original title and link: MongoDB, memcached, EHCache: Compared as Distributed L2 Caches (NoSQL databases © myNoSQL)

via: http://javamuse.blogspot.com/2011/03/nosql-document-based-or-distributed.html

I love how this sounds in French:

Après 3 ans d’une histoire d’amour fidèle avec Memcached; le serveur de cache notamment utilisé par Facebook, Youtube ou Twitter; je suis au bord de la rupture après avoir rencontré redis.

The author, Julien Crouzet, mentions three key features of Redis:

• non-volatile data
• performance
• support for data types

On these points:

• MemcacheDB and Membase are just two solutions that have solved the memcached data volatility.

• Benchmarking Redis and memcached performance has resulted in a heated conversation:

  • Redis vs Memcached
  • On Redis, Memcached, Speed, Benchmarks and The Toilet
  • Redis vs Memcached (slightly better bench)
  • An update on the Memcached/Redis benchmark

But Redis’ support for data types (lists, sets, sorted sets, and hashes) is not up for debate.

Original title and link: redis : Le système de cache parfait (NoSQL databases © myNoSQL)

via: http://blog.juliencrouzet.fr/484/redis-le-systeme-de-cache-parfait/

Could you imagine a solution for storing a set into memcached satisfying these requirements:

• must minimize round trips to the servers
• O(1) add (for both current size and new items coming in)
• O(1) remove (for both current size and items being removed)
• O(1) fetch
• lock and wait free
• easy to use
• easy to understand
• no required explicit maintenance

Dustin Sallings describes how to achieve it using just three memcached operations and some clever but artificial data encoding.

Nuno Job suggests the right answer is using Redis.

Original title and link: How to Maintain a Set in Memcached (NoSQL databases © myNoSQL)

via: http://dustin.github.com/2011/02/17/memcached-set.html

Jason Sirota is telling the story of how The Knot (a media company) went from no cache to Membase passing through memcached and Gear6.

In talking to Membase and through our own research, we found that Membase solved all of our original problems, plus our new problems with Gear6.

1. Membase provides a rich set of both GUI and programmatic tools to manage and monitor the cache.

2. Membase not only runs on multiple physical nodes but balances keys across those nodes using the vBuckets

3. Membase runs on Windows and can handle quite a bit more capacity (evidenced by Zynga) than we could possibly use.

4. Membase uses both HA replication and distributed nodes for different solutions, in our case, it easily supports the 5 node-configuration

5. Membase provides Buckets that can be configured by Port to allow different teams to have a set amount of space

6. Hardware can be added both horizontally and vertically to a Membase cluster. However, one limitation is that all nodes have to run the same cache limit so you do need to think carefully about your node size

7. No company is immune to going under but, in addition to their strong financial state, the risk for Membase is mitigated by two factors:

If you want the simplified version:

• a typical story where to maintain the quality of the service, caching had to used
• a typical story where with scale came also the need for better administration and monitoring tool
• a typical story where op costs should be kept as much under control and even reduced if possible

What made Membase the winning solution for The Knot?

Some would say the feature set, which I’ll probably agree — pointing out though that such features can be found in other NoSQL databases too.

I’d say it’s Membase usage of a well-established protocol. That didn’t require The Knot to completely rewrite the whole persistence layer. Even if Membase would not have had all required features, using the memcached protocol made it the easiest solution to try out as no application changes were needed.

Original title and link: From No Cache to Membase: The Knot (NoSQL databases © myNoSQL)

via: http://jasonsirota.com/the-knot-cache-architecture-part-i-choosing-a?c=1

The Register writing about Microsoft initiative to bring NoSQL databases to the Azure cloud, Membase and MongoDB being mentioned in the article^[1]:

The addition of NoSQL suits Microsoft - by bringing more people to Azure - and it suits the NoSQLers, because they get more Windows devs to support.

You can run NoSQL options like Mongo and Memcached on Azure after some fiddling and configuring. The goal now is to deliver a development, deployment, and management experience already familiar to those on Windows, SQL Server, and Visual Basic.

Is VMWare/Spring making the same bet for the Java world? Judging by the Spring Data initiative, plus Grails support for Redis, Grails support for MongoDB, I’d say they are.

A question that I’d like to clarify to myself is how popular is memcached in the Java world? My impression is that Java people have stayed away from memcached so far, using Java based solutions like EHCache or Terracotta, but I might be completely wrong.

Original title and link: Microsoft coaches NoSQL options for Azure cloud (NoSQL databases © myNoSQL)

via: http://www.theregister.co.uk/2010/11/12/windows_azure_nosql/

Why do we keep jumping from one storage engine to another? Can’t we make up our minds already and settle with the “best” storage engine that meets our needs?

In short, No.

A common misconception is the belief that all storage engines are created equal, all designed to simply “store stuff” and provide fast access to your data. Unless your application performs one clearly defined simple task, it is a dire mistake to expect a single storage engine will effectively fulfill all of your data warehousing and processing needs.

I don’t think I need to say that I’m a proponent of polyglot persistence. And that I believe in Unix tools philosophy. But while adding more components to your system, you should realize that such a system complexity is “exploding” and so will operational costs grow too (nb: do you remember why Twitter started to into using Cassandra?) . Not to mention that the more components your system has the more attention and care must be invested figuring out critical aspects like overall system availability, latency, throughput, and consistency.

Original title and link: Why Redis? And Memcached, Cassandra, Lucene, ElasticSearch (NoSQL databases © myNoSQL)

via: http://www.softwareprojects.com/resources/programming/t-redis-a-persistent-key-value-store-2021.html

Not sure how many will need to implement their own storage engine, but knowing there’re a couple of projects that support pluggable engines (Project Voldemort, Riak) it might be that for special scenarios special engines could perform better. Now you can learn how to do it for Membase:

Right now we’ve got an engine capable of running get and set load, but it is doing synchronous filesystem IO. We can’t serve our client faster than we can read the item from disk, but we might serve other connections while we’re reading the item off disk.

Original title and link: Memcached/Membase: Writing Your Own Storage Engine (NoSQL databases © myNoSQL)

via: http://blog.membase.com/writing-your-own-storage-engine-memcached-part-3

Currently we are using PHP, MySQL, Sphinx, and Memcached to serve up pages so quick. […]

[…] Our (MY) final decision was to use Terrastore. I’m not sure if it is the fastest, but it is fast. The main reason is how easy it is to scale with growth, how well it protects the data and keeps multiple copies always available, and the fast release cycle which means it is always improving.

As a replacement for Sphinx , we have considered many, but have landed on ElasticSearch, which just so happens to have a direct integration with Terrastore. A no-brainer for us to choose ElasticSearch for our search and ranking algorithms.

While each piece is important, sometimes it is also about the combo.

Original title and link: Terrastore and ElasticSearch to Replace MySQL, Memcached and Sphinx (NoSQL databases © myNoSQL)

via: http://blog.blogreaction.com/terrastorephp-a-lightweight-php5-class-interfacing-terrastore,15759/

The forth beta release of Membase, the scalable Memcached big brother, featuring a memcached buckets:

You now can create buckets in your Membase Server cluster that behave exactly like memcached, which means you can use Membase Server as a drop-in replacement for your existing memcached setup. In a single cluster you can now share the resources between memcached buckets and membase buckets.

The compatibility with memcached is a clear statement that Membase is after memcached users. But so is Redis!

Original title and link: Membase Releases the 4th Beta, Featuring Memcached Buckets (NoSQL databases © myNoSQL)

via: http://blog.northscale.com/northscale-blog/2010/09/membase-server-beta4-with-memcached-buckets.html