Hmmm, have you run benchmarks? For reads, it's going to be "fast": faster, I'd expect, than BerkleyDB, and more or less as fast as MySQL if indeed the queries are for simple indexed keys, significantly faster otherwise. I don't know anything about Cache::FastMap. (But I'll read up on it; sounds interesting!)
If you have lots of RAM, and your data is big, too, memcached will outperform MySQL because you can run several daemons and circumvent the process size limit problem. (Talking 32-bit here.) | [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] |
Thanks for the very interesting benchmarks. I didn't realize BerkeleyDB was so fast.
If you mentioned striping in response to my point about huge data, then note that you can get the benefits even on a single machine. If, for example, you have 8GB of RAM, you can run several memcached instances on the same machine, all under 2GB in size, but still have an effective cache size that is close to your potential maximum. Of course in a few years when 64-bit machines become common this advantage goes away, but in the meanwhile memcached works around it pretty much transparently.
But yes, this is not necessarily as useful for the OP's needs as it was for the designers of memcached.
| [reply] [Watch: Dir/Any] |