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

インストール

   1  % gem install activetokyocabinet

サーバの起動

   1  % ttserver -port 11114 db.tct &

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

セットアップ

   1  require 'active_tokyocabinet/tdb'
   2  
   3  ActiveRecord::Base.establish_connection(
   4    :adapter  => 'tokyotyrant',
   5    :database => {
   6      :englishes => {:host => 'localhost', :port => 11114},
   7    }
   8  );

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

使い方

   1  class English < ActiveRecord::Base
   2    include ActiveTokyoCabinet::TDB
   3  
   4    string :word
   5    int    :length
   6  
   7    validates_presence_of :word, :length
   8  
   9    def validate
  10      self[:length] ||= word.to_s.size
  11    end
  12  end

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

   1  # /usr/share/dict/words を流し込み
   2  buf = File.read("/usr/share/dict/words")
   3  buf.scan(/^([a-z]+)$/) {
   4    English.create!(:word=>$1)
   5  }
   6  
   7  English.count
   8  => 64024
   9  
  10  English.all(:conditions=>["word regexp ? and length > ?", '^mai', 12])
  11  [#<English id: 33247, word: "mainstreaming", length: "13">,
  12   #<English id: 33250, word: "maintainability", length: "15">]

• 正規表現の検索も可能

   1  e = English.first
   2  e.delete
   3  ActiveRecord::StatementInvalid: NoMethodError: undefined method `values_at' for 1:Fixnum: DELETE FROM englishes WHERE (id IN (1))
   4          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で利用するライブラリ

インストール

   1  % gem install miyazakiresistance

セットアップ

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

   1  % ttserver -port 11114 services.tct &

使用例

   1  require 'rubygems'
   2  require 'miyazakiresistance'
   3  
   4  class Service < MiyazakiResistance::Base
   5    set_server "localhost", 11114, :write
   6    set_timeout 1
   7  
   8    set_column :name , :string
   9    set_column :port , :integer
  10    set_column :proto, :string
  11  end
  12  
  13  buf = File.read("/etc/services")
  14  buf.scan(%r{^(\w+)\s+(\d+)/(udp|tcp)}) {
  15    Service.create(:name=>$1, :port=>$2, :proto=>$3)
  16  }
  17  
  18  Service.count
  19  => 373
  20  
  21  Service.first
  22  => #<Service:... @id=1, @port=1, @proto="tcp", @name="tcpmux">
  23  
  24  Service.find_all_by_port(80)
  25  => [#<Service:... @id=40, @port=80, @proto="tcp", @name="www">,
  26      #<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)を使うことになる。 （以上、全て推測）

インストール

   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

redis とは

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

インストール

   1  % gem install ohm

セットアップ

   1  require 'ohm'
   2  Ohm.connect(:port=>6379)

モデル

   1  class Video < Ohm::Model
   2    attribute :url
   3    attribute :created_at
   4    set :tags
   5  
   6    index :url    # 検索対象には全てindexを作成する
   7    index :tags   # 検索対象には全てindexを作成する
   8  end

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

使用例

   1  video = Video.new(:url=>"http://www.you...", :tags=>"愛理")
   2  video.save
   3  video.tags << "cute"
   4  
   5  Video.find(:tags=>"cute")
   6  => #<Index: ["1", "2"]>
   7  
   8  Video.find(:tags=>"cute").last.tags
   9  => #<Set: ["cute", "愛理"]>

低レベルAPI

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

   1  Ohm.redis.get "Foo"         # => nil
   2  Ohm.redis.set "Foo", "xxx"  # => "OK"
   3  Ohm.redis.get "Foo"         # => "xxx"

長所

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

短所(redis)

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

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

短所(Ohm)

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

など使い辛い

インストール

   1  % gem install mongo_mapper

mongomapper (古いバージョンのgem)も存在するので注意

セットアップ

   1  require 'mongo_mapper'
   2  MongoMapper.database = "app1"  # DB名

• 各モデル内で明示されない場合に利用されるデフォルトのDB名

モデル

   1  class Player
   2    include MongoMapper::Document
   3    key :name,   String, :required => true
   4    key :policy, Integer
   5    key :renkei, String
   6    key :note,   String
   7    timestamps!
   8  
   9    validates_uniqueness_of :name
  10  end

• pkeyのidが勝手に定義される
• 文字列は長さに制限がないので全てString

検索

   1  Player.count
   2  => 822
   3  
   4  Player.count(:renkei=>'萩原型')
   5  => 135
   6  
   7  Player.first
   8  => #<Player label: "萩原 忠志" ... >
   9  
  10  Player.all(:label=>/^河本/).map{|p| [p.pos, p.label]}
  11  => [["FW", "河本 鬼茂"], ["GK", "河本 龍将"]]

高度な設定

• ARで言うテーブルをMongoDBではコレクションと呼ぶ
• table を collection に変えるだけでAR風のAPIが使える

   1  class Pref
   2    include MongoMapper::Document
   3  
   4    set_database_name "usei"  # app1でなく usei DBを利用
   5    set_collection_name "zip" # prefs でなく zip コレクションを利用
   6  ...

長所

• MongoDB自体の性能がよい
• インタフェースが AR と DM のよい点を取り込み (CRUDはAR, SearchはDM)
• バリデーションや関連もサポート
• 正規表現による検索

短所

• サーバ(MongoDB)への再接続などのコネクション機能が弱い(mongo_mapper でなく mongo の問題かも)

答え

"!=", "!==" を使う

詳細

文字列のHTMLエスケープはRailsやRack::Utilによって hヘルパメソッドとして提供されており、 ユーザはエスケープ処理を「hの有無」によって調整します。

自動エスケープモード

上記のようなユーザ駆動のエスケープ処理では100%の安全性を保証できないため、 hamlでは「デフォルトでエスケープする」というオプションが存在します。

   1  Haml::Template.options[:escape_html] = true

これにより常時エスケープされるようになるのですが、 今度はh の逆とも言うべき「エスケープしない」方法が必要になります。 これがずっとわからなくて困っていたのですが、 「ドキュメントを見る」という手段を思い出して解決しました。 "!=" を使えばよいようです。

link_to 等のヘルパメソッドは sinatra 本体には含まれていませんが、 sinatra_more という gem が用意されています。

install

   1  % gem install sinatra_more

standalone 利用の場合

直接 Sinatra::Base に register してしまいましょう。

   1  require 'sinatra'
   2  ...
   3  require 'sinatra_more/markup_plugin'
   4  Sinatra::Base.register SinatraMore::MarkupPlugin
   5  ...
   6  get '/' do
   7    ...

クラス利用の場合

該当クラスで register します。

   1  require 'sinatra_more/markup_plugin'
   2  
   3  class Application < Sinatra::Base
   4    register SinatraMore::MarkupPlugin
   5  end

MarkupPlugin

link_to だけでなく、全56種(ver 0.3.33 現在)ものヘルパメソッドが利用できるようになります。 以下に、よく使いそうなものを抜粋します。

   1  link_to(*args, &block)
   2  stylesheet_link_tag(*sources)
   3  javascript_include_tag(*sources)
   4  image_tag(url, options={})
   5  image_path(src)
   6  escape_html(text)
   7  h!(text, blank_text = ' ')
   8  content_tag(*args, &block)
   9  tag(name, options={})
  10  input_tag(type, options = {})
  11  form_for(object, url, settings={}, &block)
  12  text_field_tag(name, options={})

詳細は lib/sinatra_more/markup_plugin/*.rb を確認して下さい。

その他のPlugin

sinatra_more gem には、 MarkupPlugin 以外にも RenderPlugin、WardenPlugin、MailerPlugin、RoutingPlugin といったプラグインが用意されています。 利用方法は MarkupPlugin の場合と同じで、 利用したいプラグイン名を列挙していきます。

   1  require 'sinatra_more/markup_plugin'
   2  require 'sinatra_more/render_plugin'
   3  Sinatra::Base.register SinatraMore::MarkupPlugin
   4  Sinatra::Base.register SinatraMore::RenderPlugin
   5  ...

各プラグインの代表的なメソッドを記載します。 例えば、RenderPlugin にはみんな大好きな "partial" が入ってたりしますので、しっかりチェック&register しましょう。

RenderPlugin

描画系プラグイン

   1  partial(template, options={})
   2  erb_template(template_path, options={})
   3  haml_template(template_path, options={})
   4  render_template(template_path, options={})

WardenPlugin

認証系プラグイン

   1  current_user
   2  authenticate_user!
   3  logged_in?
   4  authenticated?(&block)

MailerPlugin

メール関係？(使わないので未調査)

RoutingPlugin

ルーティング系プラグイン (named route?)

   1  map(*args, &block)
   2    # map(:accounts).to('/accounts/url')
   3    # map(:admin, :show).to('/admin/show/:id')
   4    # map(:admin) { |namespace| namespace.map(:show).to('/admin/show/:id') }