9 October 2010

KyotoTycoon is Mikio’s first release on top of the new KyotoCabinet library. He started the Kyoto series, in part, because he said he wanted something that would be easier to maintain

Compared with Tokyo Cabinet, KC is superior in concurrency, usability, and portability. Although time efficiency for single-thread is better in TC, I recommend KC from now on because multi-core/many-core CPU has been popular. However, I will keep on maintaining TC and fix bugs if they are found.

Also whereas TokyoCabinet was an interface to Hash/Btree DB, KyotoCabinet is more of a database platform. The current release of KC boasts eight different DB implementations.

KyotoTycoon’s cousin, TokyoTyrant included some impressive features, but the biggest hole was any sort of expiration. Based on the fact that CacheDB was one of the initial KyotoCabinet implementations, it was no surprise that KT finally made expiration a first class feature (it was implemented in TT via Lua scripting interface).

So how does the expiration work? Is it lazy expiration like Memcache or active expiration like Redis? The docs are blank on this so I tested it out … 

It appears that keys stick around after expiration and are purged only when a max-memory (msiz=) condition is reached. The ‘list’ command clearly hides any expired keys, but ‘inform’ reveals they remain. Next tests will include how quickly and efficiently KyotoTycoon can reclaim memory once the store has filled its allotted storage.


Mikio was kind enough to clarify in the comments:

As you indicated, KT implements “lazy expiration”. That is, each record has its own expiration time and every operation of a record checks the time stamp and simulates record missing if it has been expired. However, GC is also supported. Every operation inserting a record has the “GC cursor” walk in the database and eliminate expired regions gradually.

← Read More