I've knocked up a quick prototype ruby client library for redis. So far it supports GET, SET, EXISTS, DELETE and KEYS. Should be able to have a fully compliant library in a few days.
Thanks! your implementation is cool and if you agree will just be the Ruby implementation distributed with Redis. INCRBY/DECRBY are still missing but in a week I plan to have this, all the Set operations inside and release another beta. Then will be the time of replication and compression. And finally I plan to write a fail-over daemon that will handle masters and slaves, check who is running and who appears to be down and act accordingly.
Nice project, I already read about it. Still note that one of the major points of Redis is to support more complex types as values. Tokyo Cabinet is basically an on-disk hash table library, with an optional networking server using this lib to export the functionality.
For example if you want to use Redis in order to store logs from a lot of different computers, and you want to only take the last 1000 entries for every computer, all you need to do is for every computer something like this:
RPUSH computer_5 "... your log line ..."
LTRIM computer_5 0 999
Redis offers atomic LPOP/RPOP too, this makes pretty easy to create queues where different computers can pop/push values with the guarantee the operation is atomic.
Another trivial example: think about implementing something like YC with a key-value DB. Support for lists and sets will make your life much easier :)
Have not got around to doing performance tests, but based on general AppEngine performance, I guess it will not come close to a dedicated Memcache machine. Should be good for everything else.
Just to give you some rough range, Redis is in the range of 10k query/second on an entry level laptop. As you can guess the main bottleneck is the networking I/O with things like Memcached or Redis.
About the speed of dumping the DB. 1 million keys DB with 16 bytes string inside every key takes something like 1 second to be saved on the same HW. For the next release I hope to have replication and LZO compression of (compressible) big values working.
Since it's in C, it probably has an edge, but as I've mentioned to antirez a couple of times, I'd love to see someone take a crack at this in Erlang - this is exactly the kind of thing it was built for.
Apart from speed what I like of C for this kind of projects is the self-contain-ness and the fact that most developers that may help in the development are probably able to read/write C but not Erlang.
