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)を使うことになる。
（以上、全て推測）
インストール
shell>>
% gem install rufus-tokyo
<<--
使用例 (TC)
ruby>>
require 'rubygems'
require 'rufus/tokyo'
t = Rufus::Tokyo::Table.new("foo.tct")
t['gem1'] = {:name=>'sinatra', :minor=>9}
t['gem2'] = {:name=>'monk', :minor=>0}
gems = t.query { |q|
q.add_condition 'minor', :numge, '1'
}
=> [{"name"=>"sinatra", :pk=>"gem1", "minor"=>"9"}]
t.close
<<--
直接ハッシュを扱うため、ORMというよりHVM(Hash-Value Mapping)。
というかそもそも tokyocabinet ライブラリを直接使うのと殆ど違いが見えない。
恐らく利点は
- 全体的に記述が Ruby ぽい (エラー処理とか)
- transaction サポート (ブロックで記述できる)
あたりだろうか？
ruby>>
t.transaction do
begin
t['gem1'] = {:name=>'sinatra', :minor=>9, :author=>'user1'}
t['user1'] = {:name=>'bmizerany'}
rescue
t.abort
end
end
<<--
うーん、なんか微妙かも。
やっぱりObjectに対してCRUDしたいよね。
とか思ってたら、作者(jmettraux)から
「oklahoma_mixerの方がいいよ」
とアドバイスを頂いた。ダメじゃん。
というか、tokyocabinet が撒いた種とは言え、
関連ライブラリの名前の弾け方が凄い＞oklahoma_mixer, miyazakiresistance。
