タグ

dbとPerlに関するpoppenのブックマーク (5)

  • Introduction to DBIx::MoCo - naoyaのはてなダイアリー

    YAPC::Asia 2008 で OR マッパの DBIx::MoCo について発表しました。DBIx::MoCo は最近のはてなのサービスで利用しているバックエンドのソフトウェアで、Ruby 風のリスト操作や memcached による透過的なキャッシュなどをサポートしています。 http://bloghackers.net/~naoya/ppt/080516introduction_to_dbix_moco.ppt にて発表資料を公開しています。

    Introduction to DBIx::MoCo - naoyaのはてなダイアリー
  • Filter::SQLが使いやすくてしかたがない

    Filter::SQL 作った - id:kazuhookuのメモ置き場にある、Filter::SQLが使いやすくて仕方がないという話。 前にも書いたけれど私はPerlのデータベースプログラミングに苦手意識がある。SQLPerlも人並みにはできるけれど、その両方がまざったのはどうもだめだ。 だいたい、こちらはSELECTだけをすればいいのに use 5.010; use DBI; my $dbh = DBI->connect("dbi:SQLite:dbname=foo.db"); my $sth = $dbh->prepare("SELECT * FROM table WHERE bar > 1"); $sth->execute; while ( my $row = $sth->fetch ) { say join "\t", @$row; }のような呪文を書かなくてはならないのは苦痛

  • DBIx::Classでスレーブに接続する - libnitsuji.so

    レプリケーション環境で、更新系クエリはマスター、参照系クエリはスレーブに振り分けるというのはよくあることだと思います。 PerlのO/RマッパーであるDBIx::ClassにはDBIx::Class::Storage::DBI::Replicationというのがあって、これを使うと利用側で接続先を意識することなくクエリを振り分けることができそうです。しかし、どうやら参照系は必ずスレーブへ振り分けてしまうようなので、トランザクションの中ではマスターを参照したいといった場合に対応できないんじゃないかと思いました。 そこで、明示的にスレーブの接続を取得する方法がないかなーと思ったんですが見当たらなかったので書いてみました。 実装するにあたり以下のClass::DBI用に書かれたコードを参考にしてみました。 http://d.hatena.ne.jp/tokuhirom/20060713/1152

    DBIx::Classでスレーブに接続する - libnitsuji.so
  • DBIx::Class::Schema::Loaderの手動スキーマ生成、初心者向けチュートリアル - Yet Another Hackadelic

    と言う訳で自分なりに色々調べてみた。 テスト用データベース定義 CREATE TABLE `User` ( `user_id` bigint(20) NOT NULL auto_increment, `name` varchar(255) character set latin1 default NULL, `created_on` datetime default NULL, `updated_on` datetime default NULL, PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `Book` ( `book_id` bigint(20) NOT NULL auto_increment, `name` varchar(255) character set latin1 de

    DBIx::Class::Schema::Loaderの手動スキーマ生成、初心者向けチュートリアル - Yet Another Hackadelic
    poppen
    poppen 2008/03/19
  • ワンランク上の負荷対策を Web アプリに実装するには・・・(Sledge編)

    最近、お仕事で悩ましいのがデータベース負荷。結局のところ、Web サービスでボトルネックになるのは、バックグラウンドの DB 処理。特にどうしようもないのが、更新系リクエスト。つまりはマスターDB。 既に多くのところが採用している構成と思いますが、MySQL とかでよくやる手段といえば、 参照系は、レプリケーション機能を使って参照系DBを用意して負荷分散。マシンを増やせば負荷に対応可能。 更新系のクエリーだけは、できる限り高スペックなマシンを用意してマスターDBを構築して一手に引き受ける。増設困難で悩ましい。 もうちょい頭をひねれば、機能毎にマスターDBを分散させたり、ユーザ ID とかでパーティショニングしたりと、アプリ層で振り分ける。MySQL に限らず、Oracle とかでも同じようなことが言えます。 で、マシン負荷を監視という運用業務が必須な日々を送っていた(いや、実際にはPJのメ

  • 1