Embedded below are the slides of Florent Solt (@florentsolt) Tokyo Cabinet / Tyrant presented at Nosql Paris.

Florent seems to be working at Netvibes and his slides are presenting briefly how and what kind of Tokyo Cabinet setup is in use there.

I also liked the Tokyo Cabinet / Tyrant strength and weaknesses slides:

Tokyo Cabinet / Tyrant Weaknesses

• No bug tracker, no public code repository

  Note: not so long ago, I’ve posted about these concerns in the Tokyo Cabinet community

• The documentation is not good enough

  Note: I’m might have some good news here. Stay tuned!

• Under heavy load, master-master replication can fail
• Databases can be corrupted

  Note: you might find Tokyo Cabinet database recovery useful for such unwanted situations

• With big tables, queries need a lot of RAM and time
• Tables seem slow & their configuration is not so clear

  Note: you can learn more about the different Tokyo Cabinet database types and their configuration options

• No live backup, the copy function locks the database

Tokyo Cabinet / Tyrant Strenghts

• Easy to deploy and setup
• Easy to use
• It’s not a black box
• Good to very good performance for most of the time
• Small memory footprint
• A single Tokyo Tyrant process can handle thousands of connections
• Many command line tools
• Lua extensions

I’d definitely be interested to hear much more about how Netvibes is using Tokyo Cabinet / Tyrant, so ping me if you are ready to share more with the Tokyo Cabinet community.

I’ve just discovered these slides introducing Kyoto products, the successors of Tokyo products. The slides author is Mikio Hirabayashi, the creator and maintainer of Tokyo Cabinet, Tokyo Tyrant, Tokyo Promenade, Kyoto Cabinet, etc.

Now, what I have found really interesting is comparing these slides with some two years old slides authored by the same Mikio Hirabayashi about the Tokyo products.

If you thought we’re running out of NoSQL Twitter apps, you were definitely wrong because I’ve just got a few more.

Twidoop ☞

A Clojure-based solution to write the Twitter stream to Hadoop (by @ieure)

simple-messaging-service ☞

A simple Twitter clone in Python and using MongoDB by Michael Dirolf (@mdirolf). Michael has been featured on MyNoSQL a couple of times already:

• An Interview with Michael Dirolf
• Introduction to MongoDB
• SQL vs NoSQL Panel

Swordfish Twitter Clone ☞

Swordfish — a key-value store built on top of Tokyo Cabinet and offering a RESTful HTTP interface — comes with a Twitter clone based on Django.

tweetarium.com ☞

Another Tokyo Cabinet based Twitter app. There don’t seem to be many details about the project though. (via Matthew Ford)

Last, but not least, don’t forget to check the first series of NoSQL Twitter apps.

I didn’t know that Mikio Hirabayashi, the creator of Tokyo Cabinet and Kyoto Cabinet, the successor of Tokyo Cabinet is also offering GNU licensed content management system: ☞ Tokyo Promenade that runs on top of Tokyo Cabinet.

According to the main page, Tokyo Promenade offers the following features:

• simple and logical user interface : aims at conciseness like LaTeX
• high accessibility : complying with XHTML 1.0 and considering WCAG 1.0
• hybrid data structure : available as BBS, blog, and Wiki
• sufficient functionality : supports user management and file management
• high performance : uses embedded database, Tokyo Cabinet
• lightweight : implemented by C99 and without any dependency on other libraries

Now I don’t know how many would still be willing to run CGI based content management systems, but they”ll at least have Tokyo Cabinet as its storage.

It looks like Mikio Hirabayashi, the author of Tokyo Cabinet is moving along and started developing the successor of Tokyo Cabinet. The name of the new project is Kyoto Cabinet. The project web page ^[1] looks extremely similar to the one of Tokyo Cabinet ^[2].

By comparing the declared goals of the two projects and the rest of the (scarce) documentation, the only major differences I could find are that Kyoto Cabinet is written in C++ and that it aims of supporting non-POSIX systems.

While Kyoto Cabinet is still in alpha, I cannot wonder what is the future of Tokyo Cabinet. Is there a community behind it to at least take care of any major bugs and help with the migration when Kyoto becomes more solid? (note: I tried to contact Mikio Hirabayashi but I haven’t heard back).

If you are somehow familiar with Erlang you already know that Mnesia is a distributed database system that was designed with the following goals in mind:

• Fast real-time key/value lookup
• Complicated non real-time queries mainly for operation and maintenance
• Distributed data due to distributed applications
• High fault tolerance
• Dynamic re-configuration
• Complex objects

Even if the presentation is not so great (see below), Rickard Cardell’s experiments of using Tokyo Cabinet and CouchDB as Mnesia backends sound like a new and interesting usecase for NoSQL solutions.

A lot of people say that location-enabled services will be the #### [*] of tomorrow, so is there any Geo NoSQL?

Populating a MongoDB with POIs ☞

What I especially liked is the flexibility you get from this kind of databases (nb MongoDB) and the ease of installation and use. The downside for geographic applications is that at the moment there is no built-in support for geometries.

Using MongoDB to Store Geographic Data ☞

Managing GIS data with NoSQL in circumstances where performances and scalability are a major issue could be the way for the win.

GeoCouch: The future ☞

What I call “complex analytics” is things like: “return all apple trees that are located with a 10km range around buildings that have are over 100m high, but only in countries with a population over 50 million people” is not possible with GeoCouch as you would need the attribute values as well. Those are stored in CouchDB, so you would need to request them. What GeoCouch only supports is a simple: give me all IDs within a bounding box/polygon/radius.

Tokyo Cabinet: Loading and querying point data ☞

I’m going to load 500.000 POIs in a database and query them with a bounding box query. I will use the table database from Tokyo Cabinet because it supports the most querying facilities. With a table database you can query numbers with full matched and range queries and for strings you can do full matching, forward matching, regular expression matching,…

And so the answer is: yes, we do have some Geo NoSQL!