TokyoCabin etとは
- 高速な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_condit ion 'minor', :numge, '1' 11 } 12 # => [{"name"=>"sinatra", :pk=>"gem1", "minor"=>"9"}] 13 14 t.close
直接ハッシュを扱うため、ORMというよりHVM(Hash-Value
- 全体的に記述が Ruby ぽい (エラー処理とか)
- transactio
n サポート (ブロックで記述できる)
あたりだろうか?
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_m