• 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

redis とは

• Cで書かれた超高速なKVS
• オンメモリなので超高速 (約10万件操作/秒 @Xeon 2.5Ghz)
• 定期的に自動保存する永続化機能 (memcached に対する利点)
• 文字列以外にも集合型を扱える (TokyoCabinet に対する利点)
• 公式 http://code.google.com/p/redis/
• ベンチ http://code.google.com/p/redis/wiki/Benchmarks

インストール

shell>>
% gem install ohm
<<--

セットアップ

ruby>>
require 'ohm'
Ohm.connect(:port=>6379)
<<--

モデル

ruby>>
class Video < Ohm::Model
attribute :url
attribute :created_at
set :tags

index :url # 検索対象には全てindexを作成する
index :tags # 検索対象には全てindexを作成する
end
<<--

• pkeyのidが勝手に定義される
• redisで利用可能なvalueの型は、文字列と集合
• Ohmでは文字列型を attribute で定義する
• Ohmでは集合型を set で定義する
• Ohmではさらに独自の list(順序付き集合), counter(増減のみ操作可能な数値) 型が利用可能

使用例

ruby>>
video = Video.new(:url=>"http://www.you...", :tags=>"愛理")
video.save
video.tags << "cute"

Video.find(:tags=>"cute")
=> #<Index: ["1", "2"]>

Video.find(:tags=>"cute").last.tags
=> #<Set: ["cute", "愛理"]>
<<--

低レベルAPI

Object-Hash ではなく、純粋に redis の KVS 用 API として利用する場合。

ruby>>
Ohm.redis.get "Foo" # => nil
Ohm.redis.set "Foo", "xxx" # => "OK"
Ohm.redis.get "Foo" # => "xxx"
<<--

長所

• redisのKVS性能が高いので単純レコードへの参照・記録は超高速
• 集合型を持つのでタグの扱いなどが凄く便利
• スキーマレスでとっつきやすい
• 各操作がアトミックなのでロックがない

短所(redis)

• 文字列型のみ(数値や日付を入れても範囲検索できないので実用的ではない)
• 検索機能が貧弱 (文字列の完全一致のみ)
• データ保存が async
• もちろんトランザクション処理もなし

保存時間の間隔を設定できるとは言え、基本 async なのでクラッシュによるデータ損失の危険性が常にある。
その意味では、RDBのようなしっかりとしたデータストレージでなく、
前回の状態を(運が良ければ)そのまま再開してくれる memcached
という認識(利用)がよさそう。

短所(Ohm)

• 予約語チェックがなく、id 属性を指定すると謎の挙動でハマる
• new record 時に集合型を参照するとエラー

など使い辛い