Memcached will not only bring you the distribution, it will also allow you to share your cache. With a local applicative cache, each node will do the query once before storing it in its cache, wasting both DB performances (in particular if you have an important number of applicative nodes) and memory on applicative nodes. The overhead on data is small (56 bytes per value if I remember well), even though not negligible when storing a few byte per key !
The big question is, what is the best way to integrate memcached in your application. Most applications will go for a simple replacement of some SQL queries by a call to the cache (1), which is often not the best solution if you have a relational data model. You generally have some data decoding / formatting / aggregation to operate on what is stored on the database. If you store the result of this in memcached (2), you will not only release pressure on your DB, but also reduce applicative CPU and significantly improve your response time. User Query ----> App Interface ----> App Algorithm --(2)--> App Data --(1)--> DB Query ----> DB Storage The way your application is designed can make (2) a solution easy to implement, or can make it so hard you will rather choose (1). If you have a clean applicative data layer defining a small set of objects used in all your application above the DB layer, plug-in memcached there will be easy. This digression is here to point the fact that often, you don't have a key-value model for part of your data when you look at (1), but you have one when you're at (2). The only drawback of memcached compared to a local full-memory cache will be the remaining network round-trip, but it is generally not a problem (it is much lower than a call to the DB). 2009/5/12 JonB <[email protected]>: > > Hi All, > > I've recently been looking at memcached for use in a project here - > I've looked at the site, read the FAQ, and whatnot - but still have a > couple of questions... > > At this point in the project - we need to cache reads to a MySQL > server. I'm faced with a choice of either writing our own caching > layer - or going with memcached. > > The system has a number of front end machines, which at the moment all > query a single back end MySQL server. The machines are predominately > doing read queries, and largely for the same data (i.e. Machine 'A' > will query for 'x' - Machine 'B' is then also likely to query the same > 'x' - and that same query may get run a few hundred to a few thousand > times in a row). > > Most of the queries are relatively 'cheap' on the SQL side - a few are > quite expensive. At this stage we're more concerned with the volume of > queries (several hundred a second) and would rather see the SQL server > just handling predominately writes. > > This kind of tips the balance in favour of memcached (as our own > caching layer won't spread between machines). > > My only concern is the queries we're dealing with generate tiny result > sets. Sometimes it's literally a query that returns a single 'true/ > false' value, other times, it's queries that return a couple of > hundred bytes - max. > > Whilst I realise, running this through memcached will 'work' (and > alleviate the load on the MySQL server for repetative reads) - I'm not > sure how 'efficient' it's going to be? > > In this case do you think/guesstimate we'd be better with local > application caching - or is the overhead on memcached sufficiently > small that using it for tiny data sets is worth while? (considering > it'll 'spread' the cache between machines - which ours won't). > > -Jon
