こんにちわ！こんにちわ！nekokakです！

アドベントカレーンダー達成しました！

ありがとうございます。

これでかんかんに焼肉をおごってもらえます！

本日はアドベントカレンダー最終日ということで、コードレベルの話から離れて

総括的な話をしてみようかと思います。

まず、今回のアドベントカレンダーでDBIx::Skinnyに興味を持った方は

ぜひ一度試してみてください！

わからないことはメールでもircでも可能な限り手厚くフォローします。

irc: dbix-skinny@irc.perl.org

mail: nekokak+skinny _at_ gmail.com

どうぞよろしくです。

いままでDBIx::Skinnyの話しをするときに引き合いでDBIx::Classを出すことが多かったです。

（DBICはパフォーマンスがでないとか）

DBICを比較対象に出すことが多かったのは私がもともとDBICを使い倒していたユーザで、

色々と不満に思うことがおおかったからです。

ただ、DBICは素晴らしいORMだと思っています。それはDBIx::Skinnyを作った今でも思っています。

DBICのドキュメントの充実ぶりや、世界のPerlHackerによるメンテナスが行われており

多くのユーザがいます。これはある種の安心感があります。

もし今あなたが、DBICを仕事でつかっており、仕事上でDBICに問題点を感じないのであれば

無理にDBIx::Skinnyを使う必要はないと思っています。

もちろん試してみては欲しいところですが、無理やり切り替えてやろうとかは考えない方が良いでしょう。

(DBIx::Skinnyがすごすぎてつかいたい！とか思ってる場合は別ですが）

DBICの問題点を感じないのにDBIx::Skinnyに切り替えるメリットはあまりありませんよ！

移行コストが高く付くだけです！

Perlには他にも素晴らしいORMがあります。

Data::Model Rose::DB::Object Class::DBI Data::ObjectDriver Fey::ORM etc...

その他の素晴らしいORMも色々使ってみてください。

それぞれに特徴があります。

その特徴を見極めた上であなたが本当に必要なORMを選択すればよいと思います。

ORMが必要ないと判断する人もいるでしょう。

ORMは必要ないけどSQLジェネレータは必要だから FeyはつかうとかRose::DBはつかうとかSQL::Abstractはつかうとか

そういう選択肢もありえます。

もっともDBI直接でいいじゃないかと言う人もいると思います。

DBI自体がORMだ！と言う人もいます。

CPANをめくればこんなに素晴らしプロダクトが一杯あります。

それをつまみ食いせずに眺めてるだけなんてもったいなくないですか？

ぜひ色々ためして、あなたが本当に必要とするプロダクトを選んでください。

そして、あなたがDBIx::Skinnyを選んでくれたらそれはとても素晴らしい私へのクリスマスプレゼントになるでしょう。

25日間ありがとうございました。

JPerl Advent Calendar 2009の発起人id:tokuhirom

JPerl Advent Calendarのコンテンツを置くサバーを用意してくれたid:yappo

DBIx::Skinnyのアドベントカレンダーを実行するきっかけになったのもyappoさんのおかげです。

また、DBIx::Skinnyのアドベントカレンダーを手伝ってくれた

id:walf443 id:daijirow id:studio-m(nekoya)

のみなさん。

本当にありがとうございました！

Merry Christmas

have a nice skinny days!:)

昨日に続きましてnekoyaがお送りします。

今日もSkinny関連モジュールの紹介です。DBIx::Skinny::InflateColumn::DateTimeという名前だけで何をするかだいたい理解できそうな小物モジュールとなっております。

インストールは、CPANから

cpan DBIx::Skinny::InflateColumn::DateTime

するか、githubからどうぞ。

これも昨日のSchema::Loaderと同じく、DBIx::Skinny本体のバージョンが古いと動きません。0.05以上にアップデートしておいてください。

利用方法は、Schemaクラスで

package Your::DB::Schema;
use DBIx::Skinny::Schema;
use DBIx::Skinny::InflateColumn::DateTime;

のように、useするだけです。

useすると、XXXX_at, XXXX_onなカラムが自動的にDateTimeオブジェクトにinflate/deflateされます。

実際にやっていることも、このAdvent Calenderの4日目でnekokakさんが紹介したサンプルとほぼ同等のごくシンプルなモジュールです。

と、これだけで終わると寂しいので、もう一つおまけを紹介します。

package Your::DB::Schema;
use DBIx::Skinny::Schema;
use DBIx::Skinny::InflateColumn::DateTime::Auto;

のように、DBI::Skinny::InflateColumn::DateTime::Auto（Inflate::DateTimeに同梱されています）をuseすると、insert/update時に特定のカラムに操作時刻を自動設定してくれます。

設定されるtriggerと対象カラムは以下になります。

こうしたカラムの操作はDBの機能を使ってすることも可能ですが、DBに依存せずにアプリケーション側で処理したい場合は使ってみてください。

この機能は、hidekさんの

• DBIx::Classでauto insert/update datetime - hide-k.net#blog

にインスパイアされて盛り込みました。hidek++

実は、4日目に紹介されたcommon_triggerの機能は、このモジュールを作るのに欲しかったので追加したという経緯があります。あなたも周辺モジュールを書いていて「本体にこんな機能が欲しい」と思ったら、パッチを送ったり、IRCやブログで話を投げてみてください。

明日はいよいよ最終日。nakokakさんの大団円エンディングにご期待ください。

have a nice skinny days!:)

nekokakさんと名前が紛らわしいと評判のnekoyaです。

今日はSkinny本体ではなく、関連モジュールとしてDBIx::Skinny::Schema::Loaderを紹介します。

インストールは、ふつうにCPANから

cpan DBIx::Skinny::Schema::Loader

するか、githubからcloneしてください。

DBIx::Skinny本体のバージョンが古いと動きません。CPANから0.05を入れるか、あるいはgithubの最新版を入れてください。

DBIx::Skinny::Schema::Loaderは名前から想像できるように、Skinnyで使用するSchemaを自動設定するモジュールです。

その場でinstall_tableを実行する動的生成の他に、Schemaクラスのファイルを書き出す静的生成にも対応しています。

対応DBはSQLite, MySQL, Postgresqlです。Skinny本体はOracleにも対応していますが、Schema::Loaderでは今のところサポートしていません。

package Your::DB::Schema;
use base qw/DBIx::Skinny::Schema::Loader/;

__PACKAGE__->load_schema;

1;

package Your::DB::Schema;
use base qw/DBIx::Skinny::Schema::Loader/;

install_table users => schema {
    trigger pre_insert => sub {
        my ($class, $args) = @_;
        $args->{ status } = 'hooked';
    };
};

__PACKAGE__->load_schema;

1;

use DBIx::Skinny::Schema::Loader qw/make_schema_at/;
print make_schema_at(
  'Your::DB::Schema',
  {},
  [ 'dbi:SQLite:test.db', '', '' ]
);

perl publich_schema.pl > lib/You/DB/Schema.pm

use DBIx::Skinny::Schema::Loader qw/make_schema_at/;

my $before = << '...';
install_table users => schema {
    trigger pre_insert => sub {
        my ($class, $args) = @_;
        $args->{ status } = 'hooked';
    };
};
...

print make_schema_at(
  'Your::DB::Schema',
  {
    before_template => $before,
  },
  [ 'dbi:SQLite:test.db', '', '' ]
);

こんにちわ！こんにちわ！nekokakです！

☆４ついただきました！

http://cpanratings.perl.org/dist/DBIx-Skinny

ということで、本日は久々に俺のターンということで

今までで説明しきれなかったDBIx::Skinnyの各種メソッドを紹介してみようと思います。

# もともとの処理でDBIを使っているとする
my $dbh = DBI->connect(...);
# このコネクションをDBIx::Skinnyに渡す。
Proj::DB->set_dbh($dbh);
# あとはいつも通りにDBIx::Skinnyを使う
Proj::DB->single('user', {name => 'nekokak'});

Proj::DB->dbd->sql_for_unixtime;
Proj::DB->dbh->selectrow_array("SELECT $unixtime_sql")

こんにちは。walf443の443はSSLのポート番号のことですか?とよく聞かれるよしみです。

21日目は、Rowの拡張についてもうちょっとツッコんで話をしてみようと思います。

Proj::DBをDBIx::Skinnyのベースクラスとした場合に、Proj::DB::Row::TableNameみたいなクラスを作れば、singleやsearchなどの結果でjoinしていないときは、

Rowクラスが自動で適用されるようになるというのは前回お話したとおりかと思います。

Skinnyの思想的にはなるべくSQLをチューニングして書くことを意識しているので、CDBIや、DBICでやられているようなhas_a, has_manyみたいなものはあえて実装されていません。

とはいえ、アプリケーションの全ての箇所をカリカリにチューニングする必要はないと思いますし、チューニングと開発速度はトレードオフになることもあるので、

できるだけ早く新サービスをリリースしたいときのような開初初期段階にはお手軽なhas_aなどを使いたいといったこともあるかと思います。

というわけで、そういうのをRowに生やしたいときの例を示してみようかと思います。

package MyTest::Model::Schema;
use DBIx::Skinny::Schema;

install_table user => schema {
    pk 'id';
    columns qw/
        id
        name
        leader_user_id
        /;
};

1;

package MyTest::Model::Mixin::Row::HasA;
use strict;
use warnings;

sub import {
    my $pkg = caller;
    my $code_hasa = sub {
        my ($class, $method, $table, $column) = @_;

        my $code = sub {
            my $self = $_[0];
            $self->{"__cached_$column"} ||= $self->{skinny}->single($table, +{ id => $self->$column });
        };
        {
            no strict 'refs';
            no warnings 'redefine';
            *{"${pkg}::$method" } = $code; ## no critic
        }
    };

    {
        no strict 'refs';
        no warnings 'redefine';
        *{"${pkg}::has_a"} = $code_hasa; ## no critic
    }

}

1;

package MyTest::Model::Row::User;
use base qw(DBIx::Skinny::Row);
use MyTest::Model::Mixin::Row::HasA;

BEGIN {
    __PACKAGE__->has_a('leader', 'user', 'leader_user_id');
}

1;

みたいにしておくと、

use strict;
use warnings;
use Test::More;

my $db = MyTest::Model->new;

$db->create('user', {id => 1, name => 'alice'});
$db->create('user', {id => 2, name => 'bob', leader_user_id => 1 });
my $user = $db->single('user',{ id => 2});
my $leader = $user->leader;
is $leader->id, 1;
is $leader->name, 'alice';

みたいな感じにできます。

あまりRowにメソッドを増やしすぎると、column名と被ったりするとハマってしまいそうではありますが、

1プロジェクト内でRowにメソッドを増やすような場合は、テーブル名とかメソッド名やらに規約があったりして、

こういう仕組みを作っておくと、Row間で似たような処理を何度も書かなくてもよいよというお話でした。

これはあくまで例なので、お手軽に試せるように直接Rowから引けるskinnyを見にいっていますが、

あとからmemcachedやKVSから引くようにしたりしやすいので、Skinnyやcache処理などをwrapしたModel層を呼び出すような仕組みにしておくとよいでしょう。

have a nice skinny days!:)

こんにちは。モバイルファクトリーのよしみ、こと、id:walf443です。

20日目は、DBIx::SkinnyのSchemaファイルのメンテナンスについてです。

DBIx::Skinnyで共同開発してるときに、他の人がschemaが変わるような変更をあげたときに、手元のソースを最新にすると、

Schemaファイルは新しいのに、開発用のDBのSchemaが古いままということがままあります。

どこが変わったかは、コミットログを追えばだいたいはわかるんですが、ちゃんと直ったか確認するのはめんどうです。

ということでテストを書きましょう。

私はMySQLを使っているので、こんな感じでチェックするテストスクリプトを書いてます。

use strict;
use warnings;
use Proj::DB; # is a DBIx::Skinny.
use Data::Dumper;
use Test::More;
use YAML::XS;
use Text::Diff;

# SkinnyのSchemaとDBのSchemaの整合性をチェックするやつ

my $base = Proj::DB;
my $skinny_schema = $base->schema->schema_info;
my $skinny_table = {};
{
    for my $table ( sort keys %{ $skinny_schema } ) {
        $skinny_table->{$table} = [ sort @{ $skinny_schema->{$table}->{columns} } ];
    }
}

$base->connect;
my $dbh = $base->dbh;
my $db_table = {};
{
    for my $table ( $dbh->tables ) {
        # $table is like "table`.`column`".
        $table =~ s/^.+\.`(.+)`$/$1/;

        my $sth = $dbh->prepare(qq{ SHOW COLUMNS FROM $table });
        $sth->execute();
        my @columns;
        while ( my $row = $sth->fetchrow_hashref ) {
            push @columns, $row->{Field};
        }
        $db_table->{$table} = [ sort @columns ];
    }

}

for my $table ( keys %{ $skinny_schema }) {
    my $result = Text::Diff::diff(\YAML::XS::Dump($db_table->{$table}), \YAML::XS::Dump($skinny_table->{$table}) , {
        FILENAME_A => "db schema", FILENAME_B => "skinny schema",
    });
    ok(!$result, "$base schema $table table test" )
        or diag($result);
}

done_testing();

他には、DBIx::Skinny::Schema::Loaderというやつを使う方法もありますが、それはまた別の回があるそうです。

have a nice skinny days!:)

こんにちわ！nekokakです！

十九日目はデータのページングについてです。

webの開発をしていると一度に大量のデータを表示させるのではなく、

１０件ずつデータを表示させ、画面には次のデータへアクセスするためのリンクを用意する

いわゆるページングの処理を入れることが良くあります。

例えば、DBICを使っている場合は、

my $itr = $rs->search(...);
my $pager = $itr->pager;

のように、DBIC側でData::Pageのオブジェクトを生成して、

データのページングをしやすいように提供してくれます。

DBICで開発している方は良く使われていることでしょう。

ただ、DBIx::Skinnyではこのような機能を提供していません。

理由としては、Data::Pageのオブジェクトを作成する為には、

検索対象となるデータが全部で何件存在するかを知る必要があるからです。

DBICの場合は、pagerメソッドを呼び出すと内部でcountクエリを発行し、

検索対象の全体件数を取得しています。

しかし、DBIx::Skinnyはsearch_by_sqlのように生のSQLを自分で書く事を前提としたORMなので

利用者が書いた任意のSQLを解析して同じ条件のcountクエリを発行することは

とても難しいことです。

なので、実装していません。

また、個人的にはDBICが内部で勝手にcountクエリを発行するのは嫌です。

というのも、あまり意識せずに使っていると想定しているよりも多くSQLが実行されてしまい

パフォーマンスに影響が出てくることが多いからです。

普段DBICを使って開発されている方は、DBICのクエリログ機能を使って、

発行しているSQLを一度全部見てみることをおすすめします。

もしかすると、想定異常にcountメソッドを発行しているかもしれませんよ。

（最近のDBICでは改善されているかもしれませんが）

じゃぁDBIx::Skinnyでデータのページングはどうすんだよ！

って思う人もいるとおもいますが、

http://d.hatena.ne.jp/nekokak/20090924/1253761408

こちらに以前まとめた記事があるので、参考にしてみてください。

今日はここまで。

明日はid:walf443先生が書いてくれます。

お楽しみに。

have a nice skinny days!:)

こんにちは。モバイルファクトリーの千葉と申します。

今回DBIx::Skinnyを仕事で使わせてもらっている縁でエントリを担当させていただくことになりました。

18日目はDBIx::Skinnyでテーブルを動的に扱う方法について説明します。

DBの分割をする際などに、テーブルの構成は固定されているが、テーブル名は動的に指定したいという場合があると思います。

しかしDBIx::Skinnyでは使用するテーブルの名前や構成をあらかじめスキーマで定義しておく必要があるため、標準では未定義のテーブルに対して問い合わせをすることはできません（search_by_sqlについてはその限りではありませんが）。

そんなときは共通のスキーマをあらかじめ定義しておいて、実行時にそれを関連付けるという方法をとることができます。

package Proj::DB;
use DBIx::Skinny setup => +{
   dsn => 'dbi:SQLite:',
   username => '',
   password => '',
};

package Proj::DB::Schema;
use DBIx::Skinny::Schema;

# 共通スキーマの定義
install_table 'access_log' => schema {
   pk 'id';
   columns qw/id domain remote_host request status created_at/;
};

package main;

my $db = Proj::DB->new;

# テーブル作成
$db->do(q{ CREATE TABLE IF NOT EXISTS access_log_20091218 LIKE access_log });

# 作成したテーブルに共通スキーマの適用
$db->schema->schema_info->{access_log_20091218} = $db->schema->schema_info->{access_log};

# 通常のテーブルと同じように扱うことができる
$db->create('access_log_20091218', { id => 1, domain => 'example.com',
remote_host => '127.0.0.1', request => '/', status => 200 });
$db->update('access_log_20091218', { status => 500 }, { id => 1 });
$db->search('access_log_20091218', { id => 1 });
$db->delete('access_log_20091218', { id => 1 });

さらにこのテーブルのRowクラスも指定したいという場合はこのようにすることができます。

my $db = Proj::DB->new;

# あらかじめ定義しておいた共通Rowクラスと作成したテーブルをマッピング
$db->{row_class_map}->{access_log_20091218} = 'Proj::DB::Row::AccessLog';

my $row = $db->search('access_log_20091218', { id => 1 })->first;
print ref $row #=> 'Proj::DB::Row::AccessLog'

現在これらの処理をまとめたDBIx::Skinny::Mixin::ProxyTableというモジュールを開発中ですのでよろしくお願いします。

http://github.com/daijirow/p5-dbix-skinny-mixin-proxy_table

以上、簡単ですがDBIx::Skinnyでテーブルを動的に扱う方法について説明しました。

ありがとうございました。

こんにちわ！秘密主義のnekokakです！

十七日目は昨日のDBIx::SkinnyでのDB Shardingについての続きです。

昨日はミドルウェアでShardingして、アプリケーション側では楽をしようと言うお話でした。

しかし、私はミドルウェア屋さんではないので、ミドルウェアの細かいところまで面倒みれません。

面倒みれないので、ミドルウェアに頼らずに、アプリケーション側で何とかしようと考えてしまいます。

そこで今日は私が今まで試したことのあるDB Shardingの方法を紹介してみたいと思います。

関連記事としては、

http://d.hatena.ne.jp/nekokak/20090917/1253119002

こちらを見ていただけると良いかと思います。

この記事で紹介した方法は、考察であって実際に運用で使ったことはありません。

では本題。

今回紹介するshardingの方法は以前WEB+DBの記事で紹介されたMixiさんでつかわれているというshardingの方法を参考にしたやり方です。

sharding管理用のmaster tableを作成します。

CREATE TABLE db_node (
  id     int(10) unsigned NOT NULL AUTO_INCREMENT,
  number int(10) unsigned NOT NULL、
  host   varchar(20) NOT NULL COMMENT 'DB接続先Host名',
  role   enum('master','slave') NOT NULL COMMENT 'nodeの用途',
  status enum('ok','down','wait') NOT NULL COMMENT 'nodeの状態',
  type   varchar(20) NOT NULL COMMENT '何に使うnodeなのかex)message',
  timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  KEY db_node_idx (type,role,status)
) ENGINE=InnoDB COMMENT='DB接続先マスター情報';

CREATE TABLE db_node_map (
  id     int(10) unsigned NOT NULL AUTO_INCREMENT,
  db_node_id int(10) unsigned NOT NULL,
  type_key varchar(30) NOT NULL,
  timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  UNIQUE KEY db_node_map (db_node_id,type_key),
  KEY db_node_id (db_node_id)
) ENGINE=InnoDB COMMENT='DB接続先管理テーブル';

db_nodeテーブルには、接続対象とできる、hostの管理をしています。

db_node_mapテーブルでは、db_nodeを任意のキーで割り振るマッピングをしています。

参考レコードとしては

> select id, number, host, role, status, type from db_node;
+----+--------+--------------+--------+--------+---------+
| id | number | host         | role   | status | type    |
+----+--------+-----------------+-----+--------+---------+
|  1 |      1 | 192.168.1.10 | master | ok     | message |
|  2 |      2 | 192.168.1.10 | master | ok     | message |
|  3 |      3 | 192.168.1.10 | master | ok     | message |
|  4 |      4 | 192.168.1.10 | master | ok     | message |
|  5 |      5 | 192.168.1.10 | master | ok     | message |
+----+--------+-----------------+-----+--------+---------+

このようになります。

また、db_node_mapの参考レコードとしては

> select id, db_node_id, type_key from db_node_map;
+----+------------+------------+
| id | db_node_id | type_key   |
+----+------------+------------+
|  1 |          1 | nekokak    |
|  2 |          2 | yappo      |
|  3 |          3 | nekoya     |
|  4 |          4 | walf443    |
|  5 |          5 | kan        |
+----+------------+------------+

このようになります。

db_node_mapは必要に応じて自動でレコードが追加されるようにしますが、

db_nodeは事前にレコードを作成しておく必要があります。

さて、このデータをどのようにDBIx::Skinnyで使うかです。

db_node/db_node_mapのデータを管理利用するmodelを作成します。

このmodelではuserテーブルのnameをキーに使ってどのdb_node/db_node_mapを使うかを決めます。

package Proj::Model::DBShardManager;
use strict;
use warnings;
use Proj::DB;

sub new {
    my $class = shift;
    bless {
        # db_node/db_node_mapの入っているdatabaseに接続する
        db => Proj::DB->new(....),
    }, $class;
}

# db_node_mapに$user_nameに対応するレコードを登録する
sub setup_handler_setting {
    my ($self, $user_name) = @_;
    die "user_name is not defined!" unless $user_name;

    # db_node_mapにすでに登録されている場合はスルー
    return if $self->{db}->single('db_node_map',{type_key => $user_name});

    # 使える全masterノード取得
    my @db_node_ids = map { $_->id } $self->{db}->search_by_sql(
        q{
            SELECT id
            FROM   db_node
            WHERE  type   = 'message'
            AND    role   = 'master'
            AND    status = 'ok'
        }, [], 'db_node'
    );
    die 'undefined db_node!!!' unless @db_node_ids;

    # 既に使用されているノードを取得
    my %list = map { $_->db_node_id => $_->count } $self->{db}->search_by_sql(
        q{
            SELECT db_node_map.db_node_id, count(db_node_map.db_node_id) AS count
            FROM db_node, db_node_map
            WHERE db_node.id   = db_node_map.db_node_id
            AND   db_node.type = 'message'
            GROUP BY db_node_map.db_node_id
            ORDER BY count ASC
        }, [], 'db_node_map'
    );

    my $use_db_node = +{};
    for my $db_node_id (@db_node_ids) {
        next if defined $use_db_node->{count} && ($use_db_node->{count} <= ($list{$db_node_id}||0));
        $use_db_node = +{
            count      => $list{$db_node_id}||0,
            db_node_id => $db_node_id,
        };
    }

    $self->{db}->insert('db_node_map',
        {
            db_node_id => $use_db_node->{db_node_id},
            type_key   => $user_name,
        }
    );
}

my $datasource = +{
    dsn      => '',
    username => 'user',
    password => 'password',
};
sub handler_for {
    my ($self, $user_name) = @_;
    die "user_name is not defined!" unless $user_name;

    my $row = $self->{db}->search_by_sql(
        q{
            SELECT db_node.id, db_node.number, db_node.host, db_node.type
            FROM   db_node, db_node_map
            WHERE  db_node.id = db_node_map.db_node_id
            AND    db_node.type         = 'message'
            AND    db_node.role         = 'master'
            AND    db_node_map.type_key = ?
            LIMIT 1
        }, [$user_name], 'db_node'
    )->first;

    if ($row) {
        $datasource->{dsn} = $row->gen_dsn;
    } else {
        $datasource->{dsn} = $self->setup_handler_setting($user_name)->gen_dsn;
    }

    my $db = Proj::DB->new($datasource);
    # 必要であればset namesを打つ
    $db->do(q{SET NAMES utf8});
    $db;
}

このProj::Model::DBShardManagerをつかうことで、

dbの接続先を変えたDBIx::Skinnyのインスタンスを取得することができるようになります。

use strict;
use warnings;
use Proj::Model::DBShardManager;

my $sm = Proj::Model::DBShardManager->new;
# user_name: nekokakをキーにしたDBIx::Skinnyのインスタンスを取得
my $db = $sm->handler_for('nekokak');
# DBIx::Skinnyのインスタンス取得後は普通のDBIx::Skinnyの操作を行うのみ

このようになります。

Proj::Model::DBShardManagerをもう少し工夫すれば、

slaveへの接続をとりだしたりすることもできますね。

駆け足の説明なので、わかりにくいこともあるかと思いますが

わからないことはどんどんircで質問してみてください。

他にもshardingの方法はあるので、また別の機会にでも。

というかこの方法は特別DBIx::Skinnyに特化しているわけではないので

何かの参考にしていただければと思います。

今日はここまで。

have a nice skinny days!:)

こんにちわ！nekokakです！

十六日目はDB ShardingとShardingしたDBにどのようにDBIx::Skinnyからアクセスするかについてです。

DBのShardingの方法は色々あります。

RDBMS側で提供される機能をつかうのも良いでしょう。

アプリケーションがわで任意の方法でShardingするのも良いでしょう。

ご自分の得意分野を活かしてShardingするといいと思います。

私は普段MySQLしか使わないので、今回はMySQLに限ったお話になりますが、参考にしていただければと思います。

こんにちわ！nekokakです！

十伍日目はDBIx::SkinnyでDB意外のデータを使う方法についてです。

DBIx::SkinnyはDBIxとついているように、DBIを拡張するモジュールです。

しかし、データのイテレーションはDBのデータ意外でも使いたい場合があると思います。

そこで、今日は、DBのデータ意外でのIteratorの使い方についてです。

と、その前に、DBIx::Skinny::Iteratorの使い方をざっくり説明しましょう。

DBIx::Skinny::IteratorはDB検索結果のレコードを取りまとめるオブジェクトとなります。

複数のレコードを取りまとめて、データをイテレーションさせるためのクラスです。

itaratorではnext/first/reset/count/allというメソッドがあります。

nextメソッドを使うと、１行ずつデータを取得して、処理を行うことができます。

my $itr = $db->search('user');
while (my $row = $itr->next) {
    # some process....
}

allメソッドを使うと、一気に配列に行データを格納することができます。

my $itr = $db->search('user');
my @users = $itr->all;

firstメソッドを使うと、イテレータから１行だけデータを取得することができます。

my $itr = $db->search('user');
my $user = $itr->first;

countメソッドを使うと、現在イテレータが保持しているデータのレコード数を取得することができます。

my $itr = $db->search('user');
my $count = $itr->count;

resetメソッドを使うと、途中まで進めたイテレータのポジションをはじめに戻すことができます。

下の例の場合、resetメソッドを呼び出さないと、allメソッドでは２行目以降のデータしか取得できません。

my $itr = $db->search('user');
# １行目を取得（イテレータのポジションが一個進む）
my $user = $itr->first;
# イテレータのポジションをリセットする
$itr->reset;
# 全行を取得する
my @users = $itr->all;

no_cacheメソッドというのがgithubの最新バージョンに存在します。

これはDBIx::Skinny::IteratorがDBから取り出した行データをインスタンスにキャッシュしているのをやめるものです。

resetメソッドを組み合わせて、同じSQLの実行結果を使いまわす場合は、

インスタンスにキャッシュされたデータをつかいまわすと、DBに余計なクエリを発行擦る必要がなく、

負荷軽減になるのですが、同じSQLの実行結果を使いまわさない場合で、

１クエリで大量のレコードが取得される場合、インスタンスにキャッシュしてしまうと

メモリの無駄遣いになるので、そういった場合に使用します。

my $itr = $db->search('user');
# itratorインスタンスにrowデータをキャッシュしないことを指示
$itr->no_cache;
my @users = $itr->all;

DBIx::Skinny::Itaratorの使い方としてはこんな感じです。

DBIx::Classを普段使っている人は特に違和感なく使えると思います。

さて、本日の本題である、DB意外のデータをDBIx::Skinny::Itaratorで扱う方法ですが、

例えば、

my @users = (
    {name => 'nekokak'},
    {name => 'yappo'},
    {name => 'nekoya'},
);
my $itr = Proj::DB->data2itr('user', \@users);
while (my $row = $itr->next) {
    warn $row->name;
}

このような使い方が可能です。

data2itrメソッドを使うと、ある、hashrefが格納されてるarrayrefをわたすと、

DBIx::Skinny::Iteratorのオブジェクトにしてくれます。

#14で説明した、memcachedから取得したデータをitaratorに戻すのと同じです。

itaratorに戻した後に取得される１データはDBIx::SkinnyのRowクラスでオブジェクト化されていますので、

あたかもDBから取得したデータのように扱うことが可能です。

本題がめっちゃ短いですが、simple is bestということで。

明日はDBIx::Skinnyを使った場合のdb shardingについて書いてみようかと思います。

have a nice skinny days!:)

こんにちわ！nekokakです！

十四日目はDBIx::Skinnyでどのようにデータをキャッシュし、

キャッシュしたデータをどう扱うかについてです。

アプリケーションの負荷軽減策の一つとしてデータをmemcachedにキャッシュしてしまい、

DBアクセスをすくなくすることで、レスポンスを早くする手法はみなさん良く使われていると思います。

DBIx::SkinnyではSkinny自体の機能として、データを透過キャッシュするなどの便利機能は存在していません。

そこで、いろいろ工夫擦る必要があります。

なぜ、DBIx::Skinnyにデータの透過キャッシュする便利機能がないんだと思う人もいるかも知れません。

しかしDBIx::Skinnyの思想としてはDBIへのシンプルなwrapperなので、それ以上のことがしたければ、

DBIx::Skinny自体をラップしてくくださいと言う方針です。

また、データのキャッシュについても、DBIx::Skinny側でキャッシュ方法を明確に決めてしまわず、

ユーザの必要なケースに応じてキャッシュしてもらった方が効率が良いと考えたからです。

では、早速データのキャッシュ方法についてみていきましょう。

# キャッシュしたいユーザ情報を取得
my $user = $db->single('user', {name => 'nekokak'});
my $row = $user->get_columns; # get_columnsメソッドでデータをhashref化
my $cache = Cache::Memcached::Fast->new(....); # memcachedに接続
$cache->set('nekokak' => $row); # データをmemcachedにset

これだけです。

これでnekokakというキーでuserデータがmemcachedにキャッシュされました。

簡単ですよね。

次に、memcachedにキャッシュしたデータをどのように扱うかです。

my $cache = Cache::Memcached::Fast->new(....); # memcachedに接続
my $row = $cache->get('nekokak'); # memcachedからデータを取得
# memcachedから取得したデータをDBIx::SkinnyのRowオブジェクトにもどす
my $user = $db->data2itr('user', [$row])->first;

memcachedに入っているデータをDBIx::SkinnyのRowにもどしてしまえば、

あとはそのデータがDBから取得したものなのか、DBから取得したものなのかを気にする必要は全くありません。

簡単ですね。

明日は、今回でてきたdata2itrメソッドについて掘り下げていこうかと思います。

have a nice skinny days!:)

こんにちわ！nekokakです！

十三日目はDBIx::SkinnyのRowクラスの拡張についてです。

Rowクラスとは、DB検索結果のレコードをオブジェクト化するクラスになります。

DBIx::Skinnyでは基本的にユーザがRowクラスを定義する必要がありません。

Rowクラスは自動で生成されるからです。

たとえば、

my $row = $db->singe('user', {name => 'nekokak'});

このような処理を行った場合、Rowクラスが自動で生成されますが、

Rowクラスのパッケージ名は、

DBIx::Skinny::Row::Cdb3ee45d06b8098ef489e14b9bbb801741e549c8

という名前になっています。

これは発行するSQLに応じたRowクラスを生成するため、

発行するSQLをsha1hashした値をベースにクラスを作り利用しています。

基本RowクラスにはSELECTしたカラム名をアクセサにしたメソッドのみが設定されていますので

$row->name; # nekokak

といった形でデータにアクセスすることが可能です。

基本的には取得したカラムにアクセスできれば十分だとはおもいますが、

Rowクラスを拡張したくなることもあるでしょう。

例えば、userテーブルにはfirst_name / last_nameというカラムが別々で存在している場合に、

いちいち

prit $row->first_name . ' ' . $row->last_name;

というようなことをあちこち書いて回るのは面倒ですよね？

そのような場合に、

print $row->full_name;

と、アクセスできれば良いようにしたいとします。

このような場合に、Rowクラスを拡張します。

今回の場合、userテーブルに対して検索をおこなっているので、

Proj::DB::Row::UserというRowクラスをつくりましょう。

package Proj::DB::Row::User;
use strict;
use warnings;
use base 'DBIx::Skinny::Row';
sub full_name {
    my $self = shift;
    return $self->first_name . ' ' . $self->last_name;
}
1;

このようにuserテーブルに対応するRowクラスを作成し、

必要なメソッドを定義するだけです。

簡単ですね！

おっと、はじめに、RowクラスはSQLをsha1hashした値をつかって自動で作ったクラスをつかうって言ったじゃないかといわれそうですが、

DBIx::Skinnyでは対応するRowクラスが存在する場合は、そのRowクラスを使います。

対応するRowクラスがない場合や、search_by_sqlメソッドなどをつかって、このクエリはどのRowクラスに対応させればよいか分からない場合に、

自動で生成したRowクラスをつかうようになります。

なれるまではこの独自Rowクラスと自動Rowクラスの使い分けが難しいこともあるかもしれませんが、

なれれば、必要に応じてRowクラスを拡張できるようになるでしょう。

明日はDBIx::Skinnyで取得したデータのキャッシュ方法などについてです。

have a nice skinny days!:)

こんにちわ！nekokakです！

十二日目はDBIx::SkinnyでのMixinについてです。

DBIx::Skinnyにはsearch/create/update/delete...などの基本的なメソッドが提供されています。

特定のプロジェクトでDBIx::Skinnyが提供していないようなメソッドを定義したい場合もあるかとおもいます。

その場合は以下のように書くことでメソッドを定義できます。

package Proj::DB;
use DBIx::Skinny;
sub some_method { 'somesome' }
1;

このようにDBIx::Skinnyをuseしているモジュール内でメソッドを定義するだけです。

そのプロジェクトでしか使わないようなメソッドであればこれでもいいとおもいますが、

よく使うようなメソッドを毎回このように定義するのはだるいですよね。

コピペはよくありません。

そこでDBIx::Skinny::Mixinの登場です。

DBIx::Skinny::Mixinをつかえば、よく使うメソッドを別パッケージで定義しておき、

必要に応じてmixinさせることが可能になります。

たとえば、よく使うsome_methodというメソッドでためしてみましょう。

package Your::Mixin;
use strict;
use warnings;
sub register_method {
    +{
        some_method => sub { 'somesome' },
    };
}

Your::Mixinというパッケージを用意しました。

Your::Mixinの中でregister_methodを定義します。

register_method は HASH リファレンスを返して、

key が生やしたいメソッド名 value は、そのメソッドのコードリファレンスを渡します。

mixin で追加したメソッドの第一引数にはDBIx::Skinnyのオブジェクトが渡され、

第二引数以降はユーザによって渡された引数がそのまま入ります。

mixinを作ったらそれをProj::DBで使えるようにしてみましょう。

package Proj::DB;
use DBIx::Skinny;
use DBIx::Skinny::Mixin modules => ['+Your::Mixin'];
1;

このようにDBIx::Skinny::Mixinの１行を追加するだけです。

こうすることで今回指定したYour::Mixinのregister_methodで定義されたmethodが

Proj::DBでつかえるようになります。

Mixin機能を使えばDBIx::Skinnyを簡単に拡張することができますので

つかってみてください。

明日はRowクラスの拡張について書きます。

have a nice skinny days!:)

こんにちわ！nekokakです！

十一日目はDBIx::SkinnyでのSQLプロファイリングにつての考察です。

DBIx::Skinnyではsearch_by_sqlメソッドなどで複雑なSQLは生で書くことを推奨しています。

ORMの機能で複雑なhashrefをくみたてたり、

いろいろメソッドを呼び出して値を設定していく方法よりも、

生でSQLが書かれている方が可読性が上がるからです。

私はそう考えます。

ORMの利点としてはバックエンドのRDBMSを意識しなくていいというのがあげられますが、

ぶっちゃけそんなことたーどうでもいいです。

MySQLを使ってる人が急にポスグレでいくぜ！となって、

MySQL依存なクエリを生で書いてるから動かねーとかないですよね？

そんな酔っぱらいはどうでもいいです。

という冗談はさておき、search_by_sqlで生SQLを各場合は、クエリの最適化を行うのは用意ですね。

$db->search_by_sql('SELECT * FROM user');

と、SQLがみえてるので、ちゃちゃっとEXPLAINなどをかければいいと思います。

問題はormで生成したSQLをどのようにプロファイリングするかチューニングするかです。

まぁ、チューニングが必要なクエリはormで発行しないように。

で終わりでもいいんですが、１つの処理でどれだけのクエリが発行されるかのクエリ発行回数はみたかったりするでしょう。

またresultsetメソッドを使う場合なんかはインクリメンタルにクエリをくみたてるのであとで実際にどのようなクエリを実行したかをみたくなるでしょう。

DBIx::Skinnyでは発行したクエリを後から参照することができますので

その機能をつかうといいでしょう。

# 実験なので実際にファイルをつくらずメモリ上で試す
# DBコネクションの作成
my $db = Proj::DB->new({dsn => 'dbi:SQLite:'});
# 実験用テーブルを作成
$db->do(q{
    create table user (
        id       INTEGER PRIMARY KEY AUTOINCREMENT,
        name     TEXT    NOT NULL,
        birth_on DATE
    )
});
my $row = $db->create('user',{name => 'nekokak'});
$db->update('user',{name => 'yappo'}, {id => $row->id});
$row = $db->search('user', {name => 'yappo'})->first;
$row = $db->single('user', {id => 1});
$db->delete('user',{id =>1});

# query log を出力する
use Data::Dumper;
warn Dumper $db->profiler->{query_log};

このようなrun.plというプログラムがあるとします。これを、

SKINNY_PROFILE=1 perl ./run.pl

と実行するだけです。

すると以下のように出力されます。

$VAR1 = [
          'create table user ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, birth_on DATE )',
          'INSERT INTO user (`name`) VALUES (?) :binds nekokak',
          'SELECT id, name, birth_on FROM user WHERE (id = ?) :binds 1',
          'UPDATE user SET `name` = ? WHERE (id = ?) :binds yappo, 1',
          'SELECT id, name, birth_on FROM user WHERE (name = ?) :binds yappo',
          'SELECT id, name, birth_on FROM user WHERE (id = ?) LIMIT 1 :binds 1',
          'DELETE FROM user WHERE (id = ?) :binds 1'
        ];

発行したSQLとbindした値が一緒にでます。

こうすればどのようなSQLを実際に実行したのかわかるようになるので、

無駄をさがしやすいですね！

明日はDBIx:Skinny::Mixinについてやろうとおもいます。

have a nice skinny days!:)