• ActiveRecord の TC/TT アダプタ
• AR 上で動作するので全てのAPIが利用可能

インストール

shell>>
% gem install activetokyocabinet
<<--

サーバの起動

shell>>
% ttserver -port 11114 db.tct &
<<--

• ポート(11114)は何でもよい
• ファイル名も何でもよい (拡張子はtct)

セットアップ

ruby>>
require 'active_tokyocabinet/tdb'

ActiveRecord::Base.establish_connection(
:adapter => 'tokyotyrant',
:database => {
:englishes => {:host => 'localhost', :port => 11114},
}
);
<<--

• adapter 名は 'tokyotyrant'
• database で利用するテーブル名と参照するTTの設定を指定する
• 以下で Englishモデルを使うので "englishes" を定義している
• 複数のモデルを使うときはやっぱりTTが複数必要？

使い方

ruby>>
class English < ActiveRecord::Base
include ActiveTokyoCabinet::TDB

string :word
int :length

validates_presence_of :word, :length

def validate
self[:length] ||= word.to_s.size
end
end
<<--

• ARなので validate でも何でも思い通り
• カラム定義は string, int, float (date/datetimeはない？)

ruby>>

/usr/share/dict/words を流し込み

buf = File.read("/usr/share/dict/words")
buf.scan(/^([a-z]+)$/) {
English.create!(:word=>$1)
}

English.count
=> 64024

English.all(:conditions=>["word regexp ? and length > ?", '^mai', 12])
[#<English id: 33247, word: "mainstreaming", length: "13">,
#<English id: 33250, word: "maintainability", length: "15">]
<<--

• 正規表現の検索も可能

ruby>>
e = English.first
e.delete
ActiveRecord::StatementInvalid: NoMethodError: undefined method values_at' for 1:Fixnum: DELETE FROM englishes WHERE (id IN (1)) from /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract_adapter.rb:219:in log'
<<--

あれ！？あれ？

まとめ

• ARで稼動する上に正規表現による検索も可能
• 削除(delete, destroy)ができないのはご愛嬌

で、一番驚いたのは、実装方法。
普通なら、ARの各メソッドをTT化していきそうなものだが、

1. ARにSQLを作成させて
2. そのSQLをパーズして
3. TTに翻訳する

その発想はなかった。目から鱗です。
というか、SQLのparserは実用性が高いのでまず、
それをgem化希望！激しく希望！！

参考

• 解説 http://d.hatena.ne.jp/winebarrel/20100106/p1

TokyoTyrant を ActiveRecord 風のAPIで利用するライブラリ

インストール

shell>>
% gem install miyazakiresistance
<<--

セットアップ

適当なポートで TT を起動。(テーブルデータベースを利用するので *.tct)

shell>>
% ttserver -port 11114 services.tct &
<<--

使用例

ruby>>
require 'rubygems'
require 'miyazakiresistance'

class Service < MiyazakiResistance::Base
set_server "localhost", 11114, :write
set_timeout 1

set_column :name , :string
set_column :port , :integer
set_column :proto, :string
end

buf = File.read("/etc/services")
buf.scan(%r{^(\w+)\s+(\d+)/(udp|tcp)}) {
Service.create(:name=>$1, :port=>$2, :proto=>$3)
}

Service.count
=> 373

Service.first
=> #<Service:... @id=1, @port=1, @proto="tcp", @name="tcpmux">

Service.find_all_by_port(80)
=> [#<Service:... @id=40, @port=80, @proto="tcp", @name="www">,
#<Service:... @id=41, @port=80, @proto="udp", @name="www">]
<<--

• データ型は :string, :integer, :date, :datetime
• master/slave, dual master をサポート
• ARのdynamic finderもサポート
• (created|updated)_(on|at) は magic column
• TTへの保存キーは id の値 (数字の連番が自動付与)

欠点

• スキーマを途中で変更するとエラー (DB内は同じスキーマのデータが必要)
• 1モデル毎にTTサーバが1つ必要になる？
• :date, :datetime を空にできない (Time.at(0) になる)
• "set_" prefix が冗長

という実装を見る限り、想定されたユースケースは、

• 任意のドキュメントを格納

ではなく、

• 固定されたスキーマ定義によってTTをRDB的に利用

のようだ。
ARもASも必要としないので、「TTを手軽に便利にCRUDしたい」
という用途にはピッタリだろう。

参考

• github http://github.com/tsukasaoishi/miyazakiresistance
• 解説 http://www.kaeruspoon.net/articles/706

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。

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

namurokさんの発言を偶然見つけて、TokyoCabinetというものを知りました。Rubyからも使えるということなので、RailsPluginとかもあるのかなぁ。使ってみたいですね。
この話をしたら、瀧内さんがS3, BigTableにこれ、RDBはスケールできないってことですかねーと言っていた。ふむふむ。

mamoruk: @akf TokyoCabinet は Python, Perl, Ruby バインディングありますよ。8000万レコードまでは普通に使っています(億の単位のレコード入れるには少しパラメータの調整が必要)。メモリに乗れば引くのも速いです。
http://twitter.com/mamoruk/statuses/785574490

ぐぐた。

オープンソース・ソフトウェアはTokyo Cabinet、日本発のDBM実装だ。(中略)
Tokyo CabinetはあのHyper Estraierの作者である平林幹雄氏（以下mikio氏）によるソフトウェアで、Hyper Estraierの内部で利用されているQDBMよりも高速に動作するらしい。前方一致や数値の範囲検索、さらにトランザクションも利用できる。
http://www.moongift.jp/2007/11/tokyo_cabinet/