CODEWITHSUNDEEP
cachingnosqlredismemcachedcouchdb
Juan Antonio Gomez Moriano
Juan Antonio Gomez Moriano

Reputation: 13833

NoSQL replacement for memcache

We are having a situation in which the values we store on memcache are bigger than 1MB.

It is not possible to make such values smaller, and even if there was a way, we need to persist them to disk.

One solution would be to recompile the memcache server to allow say 2MB values, but this is either not clean nor a complete solution (again, we need to persist the values).

Good news is that

  1. We can predict quite acurately how many key/values pair we are going to have
  2. We can also predict the total size we will need.

A key feature for us is the speed of memcache.

So question is: is there any noSQL replacement for memcache which will allow us to have values longer than 1MB AND store them in disk without loss of speed?

In the past I have used tokyotyrant/cabinet but seems to be deprecated now.

Any idea?

Upvotes: 2

Views: 692

Answers (5)

Daniel
Daniel

Reputation: 8398

You also have Couchbase which is compatible with the Memcache API and allows you to either only store your data in Memcache or in a persisted cluster.

Upvotes: 2

ideawu
ideawu

Reputation: 2337

Redis is fine if the total ammount of your data will not exceed the size of you physical memory. If the total ammount of your data is too much to fit the memmory, you will need to install more Redis instances on different servers.

Or you may try SSDB(https://github.com/ideawu/ssdb), which will automatically migrate cold data into disk, so you will get more storage capacity with SSDB.

Upvotes: 1

scalabilitysolved
scalabilitysolved

Reputation: 2474

I would go with couchbase, it can support up to 20mb for a document, it's possible to run a bucket as either memcache or couchbase protocol, the latter providing persistence.

Take a look at the other limits for keys/metadata here: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-server-limits.html

And a presentation on how mongodb/cassandra and couchbase stack up on throughput/operations a second. http://www.slideshare.net/renatko/couchbase-performance-benchmarking

I've used both redis and couchbase in production, for a persistent sit in replacement for memcache its hard to argue against a nosql db that is built upon the protocol.

Upvotes: 0

synhershko
synhershko

Reputation: 4492

Any key/value store will do, really. See this list for example: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores

Also take a look at MongoDB - durability doesn't seem to be an issue for you, and that's basically where Mongo sucks, so you can get fast document-database (key/value store on steroids, basically) with indexes for free. At least until you grow too large.

Upvotes: 0

raffian
raffian

Reputation: 32086

I'd use redis.

Redis addresses the issues you've listed, supports keys up to 512Mb, and values up to 2Gb.

You can persist data to disc using AOF snap-shotting given a frequency, 1s, 5s, etc., although RDB persistence provides maximum performance over AOF, in most cases.

We use redis for caching json documents. We've learned that, for maximum performance, deploy redis on physical hardware, if you can; virtual machines dramatically impacts redis network performance.

Upvotes: 3

Related Questions