14

I have a Debian server with about 16GB RAM that I'm using with nginx and several heavy mysql databases, and some custom php apps. I'd like to implement a memory cache between Mysql and PHP, but the databases are too large to store everything in RAM. I'm thinking a LRU cache may be better so far as I research. Does this rule out Redis? Couchbase is also a consideration.

Didier Spezia
  • 70,911
  • 12
  • 189
  • 154
Poe
  • 2,971
  • 6
  • 30
  • 38

4 Answers4

17

Supposing there is a unique server running nginx + php + mysql instances with some remaining free RAM, the easiest way to use that RAM to cache data is simply to increase the buffer caches of the mysql instances. Databases already use LRU-like mechanisms to handle their buffers.

Now, if you need to move part of the processing away from the databases, then pre-caching may be an option. Before talking about memcached/redis, a shared memory cache integrated with php such as APC will be efficient provided only one server is considered (actually more efficient than redis/memcached).

Both memcached and redis can be considered to perform remote caching (i.e. to share the cache between various nodes). I would not rule out redis for this: it can easily be configured for this purpose. Both will allow to define a memory limit, and handle the cache with LRU-like behavior.

However, I would not use couchbase here, which is an elastic (i.e. supposed to be used on several nodes) NoSQL key/value store (i.e. not a cache). You could probably move some data from your mysql instances to a couchbase cluster, but using it just for caching is over-engineering IMO.

Didier Spezia
  • 70,911
  • 12
  • 189
  • 154
  • I have used APC, but the php cli scripts we're using with the web app can't access the same data. That's where memcached became the first next logical step. I was looking at couchbase because I read it was a nonvolatile (if needed) drop-in replacement for memcached more or less. – Poe Feb 10 '12 at 12:04
  • 21
    Couchbase should be considered since it has a plain-old-memcached mode of operation (called a bucket) but makes management easier, manages stats, etc. Full disclosure: I work for Couchbase. – Matt Ingenthron Mar 09 '12 at 01:54
2

We used memcached initially to cache data. In memcached partitioning data for different applications under different bucket was a real issue.Also we have a requirement to flush data from one bucket alone. Monitoring data is another requirement. We moved to Couchbase and use the memcache-style bucket. I guess its much more flexible and efficient to use Couchbase memcache-style bucket for caching rather than using memcached.

DaveR
  • 9,540
  • 3
  • 39
  • 58
Hari
  • 29
  • 1
  • This is a common use case for cache/memcache users to move to Couchbase (with memcache bucket, and sometimes with Couchbase one). I invite you to look at http://www.couchbase.com/memcached – Tug Grall Jan 17 '13 at 09:27
2

As Matt Ingenthron pointed out and Hari noted that Couchbase supports working as a direct Memcached replacement. Couchbase utilizes memcached in a non-elastic way, as in each node participating in the memcache cluster is discreet with no persistence, i.e. just a cache but couchbase also offers "Couchbase" bucket types which do provide persistence. Membase is part of the code as well so Couchbase not only serve data from disk but also from RAM and persists it there while replicating to other nodes and persisting to disk as changes are applied. I would highly recommend Couchbase 3.x for both caching and persistence in one footprint, or multiple footprints if you just wanted only a caching layer separate from your persistence layer.

Austin Gonyou
  • 252
  • 2
  • 5
1

Have you ever considered to move your databases totally to RAM using one of the in-memory NoSQL solutions with persistence? It could take less storage than your original MySQL database, because many NoSQL solutions usually have less footprint than SQL databases. Besides, if server side logic is very important for you, then try Tarantool as it has Lua scripting onboard and should have a quite small memory footprint. In my cases the same data in Tarantool occupied twice less than in MySQL. This is because they have small overhead per row and per field and use messagepack for data storing.

Dennis Anikin
  • 961
  • 5
  • 7