TokyoCabinetとは

• 高速なKVS
• mixiの平林さんが作成
• mixiの高負荷で運用されている性能と実績
• 永続化機能あり (memcachedに対する利点)
• 効率的、並列可、単純なAPI
• 単純なKVS(hash)だけでなく、B+木、テーブル(hashを値に取る)も利用可能
• 仕様書: Tokyo Cabinet第1版基本仕様書

また親類が多く、用途に応じて使い分けることができる

• Tokyo Cabinet : KVSライブラリ
• Tokyo Tyrant : TCのネットワーク対応版
• Kyoto Cabinet : KVSライブラリ(TCとは別方向の実装)

開発順序も同じで、TCというKVSを作って、TTはそれをネットワークに対応させたもの。

TCとKCの違い (余談)

じゃあ、KCって何？何でまたKVSの作成に戻るの？後継なの？TCより強いの？ て気がするが、一言にすると、TCはシングルスレッドでの最速を追求した実装。 (汎用的だが若干速度面で甘さのある)既存のライブラリには一切頼らず、 TCのために最適化された部品を自作し、速度という神の一手を追求した「攻撃的な実装」。 言わば、一瞬の隙を見逃さない久保棋王の将棋。 でもそれは一人でやるには開発以上に保守が大変になってくる。 それに対して、KCは個々の部品レベルでの最善の一手の追求は少し緩めても、 マルチプロセスで性能が出るように再設計し、 既存のライブラリを使ってでも保守性を高めて、 結果的にトータルでの最速を目指した「負けない実装」。 言わば、渡辺竜王の将棋。 したがって、(まだ発展途上なせいもあって)シングルスレッドではTCの方が速いが、 将来を期待させてくれるツールになっている。 ということで、KCは暖かく見守りつつ、今はTC(TT)を使うことになる。 （以上、全て推測）

インストール

   1  % gem install rufus-tokyo

使用例 (TC)

   1  require 'rubygems'
   2  require 'rufus/tokyo'
   3  
   4  t = Rufus::Tokyo::Table.new("foo.tct")
   5  
   6  t['gem1'] = {:name=>'sinatra', :minor=>9}
   7  t['gem2'] = {:name=>'monk', :minor=>0}
   8  
   9  gems = t.query { |q|
  10    q.add_condition 'minor', :numge, '1'
  11  }
  12  # => [{"name"=>"sinatra", :pk=>"gem1", "minor"=>"9"}]
  13  
  14  t.close

直接ハッシュを扱うため、ORMというよりHVM(Hash-Value Mapping)。 というかそもそも tokyocabinet ライブラリを直接使うのと殆ど違いが見えない。 恐らく利点は

• 全体的に記述が Ruby ぽい (エラー処理とか)
• transaction サポート (ブロックで記述できる)

あたりだろうか？

   1  t.transaction do
   2    begin
   3      t['gem1']  = {:name=>'sinatra', :minor=>9, :author=>'user1'}
   4      t['user1'] = {:name=>'bmizerany'}
   5    rescue
   6      t.abort
   7    end
   8  end

うーん、なんか微妙かも。 やっぱりObjectに対してCRUDしたいよね。 とか思ってたら、作者(jmettraux)から 「oklahoma_mixerの方がいいよ」 とアドバイスを頂いた。ダメじゃん。 というか、tokyocabinet が撒いた種とは言え、 関連ライブラリの名前の弾け方が凄い＞oklahoma_mixer, miyazakiresistance。

• http://github.com/JEG2/oklahoma_mixer