Kyoto Tycoon is a key-value store built upon Kyoto Cabinet, a dbm rehash by a guy who loves doing dbm rehashes, Mikio Hirabayashi. He has done three so far. Three separate rewrites of the same idea! This is a direct descendant of Tokyo Tyrant / Cabinet written in C++ to hopefully support non-POSIX (read non-Unix) systems. While the Cabinet portion of the Kyoto pairing is to this level of compatibility, the network bindings that turn it into a server (the Tycoon portion) are not. I tried compiling it with Cygwin, but there were some library dependencies that were missing that I did not want to have to compile, so I ran it on my handy-dandy Ubuntu 10.10 server VM.

Why Kyoto Tycoon? If you haven’t already gathered, I am trying to experiment with a broad spectrum of data storage technologies at least once. Data is really one of the hardest parts of developing good software, with the other large barrier being UI / UX. I am trying to find if there are better implemented solutions to two problems: ability to handle lots of data quickly and easy development. After working out client issues, KV stores are really quite easy to develop for, and most have small footprints and low latency. I was hoping that Kyoto would provide both of these features, and I wasn’t too disappointed, but I also was not incredibly impressed.

The Installation

As mentioned before, I tried installing on Windows first. I was not successful. I am sure that had I persisted, I could have finished, but really, I just wanted a taste, not a feast. After struggling with that for a couple of hours, I switched over to Linux, specifically Ubuntu. There was nothing magical about that, and it took 15 minutes to do the whole thing following the instructions under “Fundamental Instructions” on the FAL labs website. One caution to the reader would be to make sure to add /usr/local/lib to LD_LIBRARY_PATH, as doing anything otherwise will result in an error.

The Client

One of the first things I do when evaluating a new datastore is look for a client, specifically a Java client. Clients are hard to implement, and potentially take up more time than writing the specific database code for your application. Strangely, I have never had to think about clients before I started this NoSQL survey as most SQL servers have clients in every big language, and they are tested and production-proven.

I wanted to avoid creating my own and trials therein. I searched and searched, and found no fully functional projects, but I did find one that had a good start ( I had to modify it slightly and then implement more of the API, but it worked. I also used Apache Commons pooling to add in connection pooling, something very important for multi-threaded apps. As with all other KV stores, I merely serialize objects in JSON, and then use the ID as the key.


The DAL for using Kyoto was very similar to Riak and to Redis, and so I adopted very similar practices. The whole Kyoto-specific logic was actually rather tiny as would be expected with a KV store.

The Test

After working out the difficulties with the client, I ran my standard set of tests, and all was good. The results, which I will publish when I get around to it, showed that it was fast, but not as fast as Redis or Riak.


Kyoto works, but two things bother me: not being able to run on Cygwin and the lack of community support as evidenced by the lack of a Java client. Eventually, I hope to publish my Java client, which is just a bare-minimum improvement on Mr. Park’s client. I think that given the performance and great community around Redis and Riak, as well as the availability of Berkeley DB, Kyoto Tycoon and its base Cabinet might be forgotten. However, check it out for yourself and see.