Redis has a different use case then tokyo does. I think tokyo is beter for long term persistent data storage. But redis is much better as a state/data structure server.
Redis is faster then tokyo by quite a bit but is not immediately durable as in the writes to disk happen in the background at certain trigger points so it is possible to lose a little bit of data if the server crashes.
But the power of redis comes in its data types. Having LISTS and SETS as well as string values for keys means you can do O(1) push/pop/shift/unshift as well as indexing/slicing into lists. And with the SET data type you can do set intersection in the server. This allows for very cool thigs like storing a set of tags for each key and then querying for the intersection of the set of tags of multiple keys to find out the common set of tags.
I'm using this in nanite(an agent based messaging system) for the persistent storage of agent state and routing info. Using the SET data types makes this faster then keeping the state in memory in my ruby processes since can do the SEt intersection routing inside opf redis rather then iterating and comparing in ruby:
You can also use redis LISTS as a queue to distribute work between multiple processes. Since pushing and popping are atomic you can use it as a shared tuple space. Also you can use a LIST as a circular log buffer by pushing to the end of a list and then doing an LTRIM to trim the list to the max size:
That will keep your circular log buffer at a max of 100 items.
With tokyo you can store lists if you use lua on the server, but to push or pop from a list you have to pull the entire list down, alter it and then push it back up to the server. There is no atomic push/pop of just a single item because tokyo canot store real lists as values so you have to do marhaling of your list to/from a string.
The most important part for the lazy guys: So what is Redis really about? The User interface with the programmer. Redis aims to export to the programmer the right tools needed to model a wide range of problems. Sets, Lists with O(1) push operation, lrange and ltrim, server-side fast intersection between sets, are primitives that allow to model complex problems with a key value database.
As a proof try to play and download the source of our small twitter clone at http://retwis.antirez.com and imagine to write it with a plain key-value DB: it's much harder, and slower.
Before the next beta I've to select a license among GPL, LGPL, and BSD. Please help me if you have some idea about it. I always liked more BSD because there is more freedom, but for a project like Redis that is used like a 'service' maybe the BSD is not that useful and the GPL instead works as a protection. But I'm not that sure.
Even under the less restrictive licenses like BSD/Apache/MIT, there is a strong incentive to contribute private changes back to the project. If you don't, then the public version and your private version start to diverge and it takes more and more work to take advantage of fixes and new features as the public version progresses.
BSD, MIT or Apachev2 is my preference. I really don't like the GPL and it does tend to turn off some folks from using open source projects. I would not be too concerned about someone taking the work closed source even if you do go BSD.
Ok everybody want BSD, so it's the way to go. About someone closing the source in a proprietary application, who cares as long as we can still access and hack on our source BSD-licensed? Ok we have a license :) Thanks
