YAPC::Asia Tokyo 2010 1日目

gihyo.jpさん(http://gihyo.jp/news/report/01/yapcasia2010/0001)さんでのレポートの下書きをおいておきます。

Kazutake Hiramatsuさん「Modern Perl Web Development on Amazon EC2」

  • Plackを使ったPSGIなWebアプリの作り方
    • PSGIって何？ Perl Web Server Gateway Interface。
    • PSGIアプリケーションとは？PSGIの使用に従ったWebアプリケーション。本体は単なるPerlのCode Reference。CGIの環境変数ライクなハッシュを受け取って、Array refを返すという仕様。
  • Plackについて
  • plackupの使い方
    • app.psgiを指定してkidou
    • -sでサーバとして使うモジュールを指定。これでサーバ実装を変更できる。-s Starmanと指定するとPlack::Handler::Starman
    • -Lでpsgiアイルをロードする方法を指定
    • plackup -s Starman -L Delay app.psgi
    • 本番運用するならStarmanかStarlet
  • StarmanとStarletの違い
    • Starman Graceful restart with HUP (No hutdown with QUIT yet)
  • Startlet
    • Graceful restart, Graceful Shutdown
    • miyagawaさんのwiki
  • -LでPlack::Loaderの指定
  • DelayedとShotgunの番
    • -L Delayed 最初のリクエスト時に子プロセスでpsgiをロード
    • -L Shutgun Copy on Writeが有効になって効率的？。でも実際にはかるとDelayedのほうが速かった
  • Server::Starter
    • SIGHUPによるGracefu restartをサポートするサーバプログラム
    • plackupをstart_serveｒで起動するとgraceful restartがサポートされる
    • start_serverのintervalオプション。SIGHUPを受け取った後respawnするまでに要する時間（秒）。shutdownに1秒以上かかるサーバの場合この値の調整が必要
  • PSGIアプリの書き方
    • おすすめは、自分で簡単なフレームワークを作ること
    • CPANモジュールを使えば容易。そのほうが挙動を把握できる
  • おすすめモジュール Plack::Request
    • リクエストパラメータの取得に仕様
    • そのまま使うのではなく、継承して拡張
    • Object::Applyというモジュールを使って、flagged utf8へdecodeする
  • DBIx::Skinny
    • 軽くて速い
    • SKINNY_TRACE=1でSQLを出力してくれる
    • connect_options => [ mysql_enable_utf8 => 1 ]でDBから取得した値をflagged utf8へ
  • Router::Simple
    • URLからコントローラへのディスパッチ
    • WEB APIつくるときとか
  • JSON::XS
    • JSON出力で使う
  • daemontoolsを使ったwebサーバの運用
    • デーモンを制御するためのツール
    • /service配下にサービス用のディレクトリを作成し、直下にrunファイルを置くと、runファイルに書かれたサービスをデーモン化してくれる
    • start_serverをdaemontools経由で使用
    • コンパイルエラーになるので、src/error.hの書き換えが必要
    • svcコマンドがわかれば十分。-u:でサービス起動、-d:サービスの終了 -h:サービスへのSIGHUP送信
    • runスクリプトは普通のシェルスクリプト。execでプログラムを起動するのがポイント
  • cpanmを使ったCPANモジュールのインストール
    • CPANモジュールは全てcpanm管理
    • root権限いらずで、ホームディレクトリにインストールしやすい
    • -lオプションでディレクトリを指定してモジュールをインストールできる
    • 環境変数PERL5LIBを追加
  • Amazon EC2上でのWebアプリ構築、運用
    • Amazon EC2といっても、アプリケーションレベルの構築方法に大きな違いはない
  • AmazonEC2のサーバ環境
    • Small Instance メモリ1.7G
    • CentOS 5.4(32bit)
  • DBサーバ
    • Large Instance メモリ7G
  • 構築に関しての疑問
    • サーバのIPアドレス変わるって本当？
    • DISK内容が保持されないって本当？
    • 負荷分散は？
    • アプリケーションのデプロイは？
  • サーバのIPアドレス変わるって本当？
    • インスタンスをTerminateしたときなど、IPだけでなく、DNS名も変わる（可能性がある）
    • WEBアプリケーションで、DBサーバだと致命的
  • Elastic IPを使って、DNS,Global IPを固定化できる
    • 内部からのDNS問い合わせはPrivate IPを返す
    • Webサーバに関しては使っていない（オートスケールを使いたいので）
  • DISK内容が保持されないって本当？
    • インスタンそのTerminateで、破棄される
    • EBSかS3を使う
    • DBサーバはEBSブートを使ってインスタンスを起動
  • 負荷分散は？
  • アプリケーションのデプロイは？
    • オートスケールを利用していなければ特に困らない
    • オートスケールを利用している場合、インスタンスがイメージから起動されるので、元となるイメージを最新化しておく必要がある
  • デプロイ方法
    • Elastic IPを余分にひとつとっておく
    • テスト用のFQDNを登録し、Elastic IPで取得したDNS名に向けてCNAME登録する
    • テスト用インスタンスを起動し、そこへファイルをアップ
    • Elasticで取得したDNS名をテスト用インスタンスに結びつける
    • テスト用のURLでテスト
    • 問題なければイメージ化して、順次差し替える
    • ソースをNASやNFSに置く方法をとっているところもある
  • その他の注意点
    • amazon EC2でオートスケールを使う場合、IPアドレスが固定化されないので、任意のIPでlisten出来る必要がある
  • Amazon EC２の感想
    • 本質的な開発作業に大きな差はない
    • daemontools + Server::Starter + Starmanで問題なく動いている
    • Elastic IPを利用
    • オートスケールは便利
  • まとめ
    • Plackを使うとPSGIなアプリを簡単につくれる
    • StarmanやServer::Starterは本番サービスに投入できる品質
    • CPANモジュールの管理はcpanmを使おう
    • サービスの管理にはdaemontoolsを使おう
    • amaozon EC2上で運用する際は、amazon特有の環境に注意
  • 質疑応答
    • Q. daemontoolsのログの保存はどうする？
    • A. EBSなりに持っていかないとだめ。

Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」

  • Perl5をつかったウェブアプリの開発についてがメイン
  • Perl5のバージョン
    • いままではperl5.8系がメインだった。今は5.12まで出ている。それらの使い分けは？
    • system perl sucks。OS標準のperlを使うのは良くないと思っている。コンパイルオプションが一般的すぎる。threadが有効になっているとか。
    • ithreads sucks. no "-Dusethreads"。Webアプリケーションを書くときはthreadをoffにしておくほうがよい。これによりインタプリタの速度が15%程度高速化される
    • perl 5.10.0は良くない。正規表現使ったときにmemory leakするなどbugがある
    • perl 5.x.0は全体的に良くない。
    • perl 5.12.2が一番いいと思う
    • 安定志向ならperl5.8.9でもよい
    • 5.10以降の方がgiven/when, say, smart match, defined or (//), naped captureなど便利な機能が使える。smart matchは速度がでないなど良くない面もあるけど便利。//は地味だけど便利。0とか空文字列に起因するバグが減る。
  • perlbrew - 好きなバージョンのperlを使うために
    • perlbrew install perl-5.12.2
    • perlbrew switch perl-5.12.2 でバージョンを変更できる
    • 簡単にインストールできて、なにも考えなくてもいい。お手軽
    • ./Configure -des --Dprefix=/path/to/perl-5.12.2/ && make && make installでもそんなに変わらない
    • CPANモジュールはperl-5.12.2/lib/site_perl以下に入る。local::libを使う必要がない
    • こうやって作ったperl5をrsyncでばらまくだけ
    • gitで管理するのもあり
  • cpanm
    • From cpan to cpanm
    • 同期はCPANはメモリ使用料が多いのでvpsで動かなかった。
    • 今は使わない理由がない。no configuration, no relad
    • cpanm Acme::Damn
    • 依存モジュールをインストール cpanm --installdeps .
    • cpanm -l extlib/ Acme::Damn
    • cpanm -l extlib/ --installdeps .
  • cpan-outdated
    • インストールしたモジュールが古くなってしまう
    • cpanm App::Cpanoutdated
    • cpan-outdated で古いモジュールがリストされる
    • cpan-outdated | cpanm で一括最新化
    • cpan-outdated -l extlib/ | cpanm -l extlib/でローカルモジュールの更新もできる
    • cronで自動更新、自動テストもできる
  • cpanf
    • CPANモジュール、なおしてもらったけど、ミラーに反映されてないことがある
    • cpanm App::CPAN::Fresh 最新のミラーから取得できる。
    • cpanf -m Acme::Damnでcpanm経由でインストールされる
  • pm-uninstall
    • pm-uninstall Acme::Damn でモジュールをアンインストールできる
    • pm-uninstall -l extlib/ Acme::Damn でローカルモジュールにも対応
  • deployment
    • Perl5のディレクトリをrsyncするのがオススメ
    • アプリケーション特有のやつは、extlib/にいれておいてrsyncしよう
    • no rpm; no deb;
  • CPANモジュールの選び方
    • 8万モジュール以上ある。
    • 日付の処理をしよう。'Date'で検索 -> 3000package以上
    • 答え「みんながつかってるモジュールをつかう」
    • #perl-casual@irc.freenode.org で聞いたら教えてくれる
    • Twitterボット @perlism by @lestrrat
    • 答え「有名なPerl Hackerがつかってるモジュールを使う」
    • Task::BeLike::XXを使う。Task::BeLike::Tokuhirom githubにあります。
    • 自分で選ばないといけないとき。http://d.hatena.ne.jp/tokuhirom/20080520/1211292598
    • 2004年より前とかはかなり危険なかおり（枯れているものも中にはある）
    • Testがこけたまま放置されているのはメンテナンスされていない可能性が高い
    • t/以下を見て、テストの充実度を見る
    • Dependencies 依存モジュールがみれる。"D"を選ぶと依存しているモジュールも見れるので、どの程度使われているかもわかる
    • 有名な作者が作っているモジュールは安心
  • まとめ
    • みんなで使いやすくしているのでどんどん使いましょう
    • Perl is undead!
  • 質疑応答
    • Q. CPANモジュールをアップデートする際にunstableを見分ける方法は？
    • A. 基本的にはCPANには安定版しか上がらない。開発中はどんどんアップロードしてしまう。リリース後は気になったものだけアップデートしている。
    • Q. perlbrewを使っているときに、システムのperlとバージョン不整合になる時があるが、どうしたらよいか？
    • A. そういったケースに出会ったことはない。おそらくPATHなど環境系の問題ではないか。

Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術

  • mixiについて
    • 多様なデバイスに多様なユーザを
    • 2000万ユーザ。300億/PV
  • mixi development
    • 歴史の長いコード
    • 機能間連携多い
  • テーマ：二つのスケーラビリティ
    • Performance : アクセス数の増加や変動に耐える
    • Development : 機能追加や他人数開発に耐える
  • memcached
    • 揮発性KVS
    • 汎用キャッシュ機構
    • LRU
    • 願い事 - memcachedが落ちませんように
  • Cacheとは
    • 更新に対して、参照が多いデータの参照を高速に
    • いつ入れるか、いつ更新されるか
    • なにを入れるか
    • データ参照のホットスポットを発見して適応
  • 通常データ
    • keyからketamaで一意のノードから読み書き
  • 参照料の多いデータ
    • 同時に複数ノードに書き込み。読み込みを分散
  • Cache方式 リードスルー
    • 読み込み時にキャッシュに追加。実装が簡単。Aspect, Moose::Role、Class::Method::Modifierなどで透過的に実装できる
  • Cache方式 ライトスルー
    • 書き込み時にデータソースとキャッシュに書き込む。
    • memcachedは揮発するのでリードスルーと併用が必要。
    • 書き込み粒度と読み込み粒度を一致させる必要がある
  • Cache方式 変速的なライトスロー
    • DBに書き込んでから、マスターを読み出す
    • 読み込み時は、リードスルーと同様の実装
    • incrをうまく使い数を管理する
  • Cache対象レイヤ - カラム単位キャッシュ
    • 個別に参照頻度が高いデータ
    • get_multiなどで必要なカラムを収集して柔軟に使いたいケース
    • set_by_keyなど使えると局所性もコントロールできて高速にできるかもしれないが、利用はしていない
    • 削除タイミング。該当カラムが更新。データソース系モジュールで更新
  • Cache対象レイヤ - 行単位キャッシュ
    • レコード単位でキャッシュ
    • 該当レコード更新、データソース系モジュールで更新
    • 行単位キャッシュなら、handle socket pluginなどで置き換えたほうがよいかもしれない
  • Cache対象レイヤ - ドメイン単位のキャッシュ
    • サービス上のモデル分析の妥当性が重要
    • 大きすぎる粒度に注意
    • その範囲では仕様変更につよい
  • Cache対象レイヤ - サービス単位
    • 参照データ頻度が大きく、キャッシュやDBを複数個経由して出来上がるデータ。日記サービス、通知履歴など
    • 削除タイミングが難しい
    • Expireのみを期待する。ドメインごとの更新タイミングにフックポイントを仕込む
  • 粒度と抽象化
    • アクセス数や更新頻度に応じて適切に選択が重要
  • memcachedをキャシュ以外に仕様
  • memcached以外のキャッシュ
    • デーモン
    • プロセス間
    • プロセス内
    • リクエスト - mod_perl pnote
    • スコープ内 - sesshon
  • コードの複雑さを防ぐ
    • MVCの重要性。さまざまなデバイスに展開するとき。Controllerが肥大化していると苦しい
    • 複雑に各コンポーネントが依存しあうサービス要件
    • 広告やカスタマーサポートなど、色々なところに使われるサービスがある
    • 凝集度を高く結合度を低く
  • コンポーネント間の連携を定義する原則
    • 基礎ライブラリ、フレームワーク、サービス、アプリケーションを定義。レイヤ間の依存関係を決定。レイヤごとに品質規準を定める
  • システムコンポーネント
  • JobQueueサーバを利用してユーザの行動をフック
    • シェーピング - 突発的な負荷を緩衝して、スパイクを避ける
    • Joinの代替 論理／物理 - 複数ソースにまたがっている関連情報を一貫させる
    • 副次的な要件の処理 - 異なる責務領域で必要になる処理
  • JobQueueでPublisher-Subscriber
    • add_daily日記作成時に、 イベントを作成。関連するモジュールがそれぞれ非同期に処理。
  • ModelのCRUDにフック
    • 個別コードの事情や構成に詳しくなくても利用できる
  • CRUDを補足したサービス
    • 日記コメント、日記イイネ！
  • まとめ
    • 二つのスケーラビリティ
    • 両方共最終的には似てくる
    • 責務の分散構成と負荷の分散構成は似てくる

Lyo Katoさん「DataPortability and SocialWeb Protocols」

  • DataPortability - http://dataportability.org
  • SocialWeb界隈
  • Others
    • Atompub - RSSのように記事を決まった形で表示するだけではなく、RESTfulにデータ交換ができる
    • Salmon - Aggregateされた先で付けられたコメントでデータ提供元にもどってくる
    • oEmbed - URLが画像だとその場に展開
    • Pubsubhubbeb - Web Hook。HTTPでリアルタイムのプッシュを実現
    • SAML - エンタープライズ領域での認証技術基盤。OpenIDやOAuthより機能豊富。その分複雑
  • OpenID/OAuth
    • Service Ecosystem。IdPとSPにわけて考えることができる。IdPを持たないサービスは、OpenIDを利用できる
    • smartfmがたくさんのOpenIDプロバイダに対応している
    • OpenIDのクライアントはIDを取得できる。拡張を使えばプロフィール情報などの属性も取得できる
    • 他のサービスの機能を、認証情報をわたさずに使うのがOAuth
  • Access Token
    • 誰がどのサービスに何のデータをいつまで使わせるかという委任状のようなもの
    • OAuth::Lite - mixi, DeNA, モバゲーでも使われている
  • SGP(Social Graph Provider)が出てきた
    • Social Graphの部分をかりてサービスを作る > OpenSocial
  • OpenSocial
    • 大きく分けて、Gadget APIとRestful APIがある
    • opensocial公式ページでPerlライブラリがない
    • Net::OpenSocial::Clientを作った。RESTful APIに対応しているところが少ないため、使いどころが少ない。
  • OpenIDとOAuthの相違点
    • OpenID - 認証をOPに移譲
    • OAuth - OPに認証を移譲しているといえなくもない
    • IDの取得、OpenIDでは仕様で定義されているが、OAuthでは定義されていない。だがOAuthでは認可後にプロフィールとして提供は可能
  • 認可
    • OpenID - AX, SREGなどの拡張でユーザ属性の取得は可能
    • OAuth - トークンの認証方法は仕様で定義。ユーザデータのフォーマットは未定義
  • Fedaration
  • OAuth2.0
    • SSL必須（署名がなくなった？)
    • session, scopeの標準化
    • Request Tokenがなくなった
    • Web以外での利用も？
  • Profiles
    • WebServer Profile - Webを使った３者間の認証
    • UserAgent Profile - デスクトップアプリケーションなど
    • Username and Password Profile - XAuth
  • OAuth::Lite2
    • OAuth2.0対応(draft10)
    • Plack対応(Server側)
    • クライアント側は署名がなくなればライブラリいらないかも
    • サーバ側はOAtuth::Lite2::Server::Handlerを継承して実装する。プロトコルを熟知していないとかけない
  • OAuth on Native App
    • HTML5, CSS3
    • Bluetooth, GPS, APNS, C2DM
    • カメラ、マイク
    • AppStore, android market
    • デバイスとサーバ間の連携にOAuthが要求されるシーンが増えてくる
  • tips and traps
  • Twitter OAuth事例
    • secret埋め込み問題 - OAuth for OpenSource
    • サービス間連携 - OAuth Echo
    • その他 - XAuth
  • OAuth for OpenSocial
    • 最初にKeyを与えると、keyとsecretなどが帰ってくる。最初にkeyはsecretがないので詐称される可能性はある
  • xAuth
    • usernameとpasswordを直接わたして、Access Tokenを返してもらう
  • tips
    • カスタムURIを使う
    • application:handleOpenURL
  • Tokenのセキュアな保存
    • ローカルマシンへの保存を気をつける
    • 暗号化
    • アクセスコントロール
  • Adobe AIR
    • SharedObjectは使わない
  • android
    • Shared Preference
    • Account Manager - OSがアカウント情報を統合管理する仕組みを持っている
    • new Contacts API
  • まとめ
    • OAuthはそろそろ必須技術
    • nativeアプリを作るときはいろいろ注意が必要

Jiro Nishiguchiさん「Write Good Parser in Perl」

  • パーサとは
    • なんらかの意味をもったテキストを、その後の処理に適した形にする
    • 「正しく」「動作」して「あたりまえ」という期待
    • 重要なのに、空気なような存在
    • ベンチはとられまくりでかわいそうな子
  • Kind of parser
  • Perlでよく使われているパーサ
    • HTML::Parser
    • XML::LibXML
    • JSON, JSON::XS
    • HTTP::Parser::XS
    • Template-Toolkit
    • Cache::Memcached - getリクエストのあとにもどってくるレスポンスのパーサ
  • HTML::Parser
    • Since 1996
    • Depended on by 408 modules (HTML::FillInFormなど)
    • Written in XS
    • 手書き（自前で１バイトずつ進めている
  • XML::LibXML
    • Perl binding for libxml2
    • XMLの代表的なパーサ
    • Depended on by 267 modules (Plaggerなど)
  • JSON(::PP)
    • Standard JSON module
    • Wrapper of JOSN::PP and JSON::XS
    • Pure Perlで手書き
  • JSON::XS
    • 高速なJSONパーサ
    • 手書き
  • HTTP::Paraser::XXS
    • Plackで使われている
    • Writtern in XS
    • 手書き
  • Template-Toolkit
    • Pure Perl
    • Based on Parser::Yapp
  • Cache::Memcached
    • getコマンドのパーサ (::GetParser, ::GetParserXSもある）
    • 手書き
  • Why XS?
    • Perlのテキスト処理は遅い（Cに比べて）。とはいえ正規表現など非常に高速なので普段は問題ないことが多い
    • 1バイトずつ読み進める処理はCが高速。perlだとsubstrなどでオーバーヘッドが大きいため
  • How to write - 手書き？
    • 自由度は最も高い
    • プログラムの腕によっては最高速になることも
    • 怠惰なプログラマには向かない
  • How to write - 既存モジュールを使う
    • 可能な限り新しいフォーマットを作らないのが重要
    • 既知のフォーマットを自作するといいことはない。バグを生みやすい
  • How to write - 正規表現ベース
    • 書き捨てに、小規模に便利
    • 十分に速い
    • 規模が大きくなってくるとメンテナンスが大変
    • Regexp::Assembleを使えばかなり頑張れる
  • Parser generatorとは
    • 文法などの定義情報からパーサを生成する
    • 怠惰なプログラマにうってつけ
    • yacc(bison)
    • Parser::Yapp, Perse::Eyapp( Exteded yapp), Parse::RecDecent, Pege, Ragel
  • Ragel
  • Ragel + XS
    • ステートマシンの定義を書く
    • パースする関数をCセクションに書く
    • 分かりやすく宣言的に書ける
  • XSいやなんですけど・・・
    • データ構造を作って返すだけ
    • 文字列結合や配列、ハッシュが触れればOK
  • (例)ログ解析
    • Benchmark 5倍ぐらい速くなった
  • まとめ
    • ログ解析などあまり変更しなさそうなものは、パーサジェネレータとXSで高速するといいかも
    • 保守性と速度のトレードオフ

Seiji Haradaさん「mixi チェックインの裏側」

  • mixiチェックインについて
    • 「mixiチェックイン」は、携帯電話のGPS機能を利用して、今いる場所やお店（スポット）を簡単に友人・知人に共有できる『mixi』の新しいコミュニケーション機能です。
  • スポットの絞り込み方法
    • geohashの前方一致。geohashとは緯度経度の範囲を文字列で表す仕組み。
    • geohash表現をbase32して、2進化。奇数番目が経度、偶数番目が緯度となる
    • geohashが短いと範囲が広がる
    • 落とし穴。矩形の端っこの場合。桁数を削って範囲を広げると無駄になるので、周りの部分を矩形をとってきて処理する。
  • 高速化
    • geohash - 計算処理が多いので早くしたい
    • mysqlで無駄なクエリを減らしたい
  • 高速化 - Geo::Hash::XS
    • Geo::Hash -> Geo::Hash::XS ベンチマークとったら140倍〜200倍速かった
    • 隣接するgeoashを求めるadjacentメソッドもある。
  • 高速化 - mysql
    • キャッシュ化- スポット情報が頻繁に変わらない
    • 検索は６文字のgeohash -> 6文字のgeohashをキーにしてMemcachedに積んでいる
    • スポットの多い関東と関西をキャッシュ
  • まとめ
    • 6文字のgeohashによる前方一致で絞り込み
    • GPSの精度があがれば７文字もあり
    • 最小で１つ、最大で４つのキーで検索
    • 検索範囲は半径250mでキーの平均値は2.66個 ( 実機で実際はかったときの最大ズレ幅 )
    • 位置情報を楽しもう！

keroyonnさん「非同期タスクの通知処理 with Tatsumaki」

  • 月々7000円の小遣いでコツコツと旅費をためてきた
  • Web越しにガンガン登録される重いタスクを
    • リアルタイムに
    • 待ち時間を感じさせずに
    • リソースを食いつぶさずに処理したい
  • 解決策 - みんな大好きCGI
    • ブロッキング、ストリーミング
    • Ajaxとか使わないのでUIがブロックされる
    • コード的には$=1を指定してprintでちょっとずつ出力
    • ブラウザがずっとローディングになる
  • クライアント側を非同期化してみる
    • multipart/mixed, boundary = "ABC"
    • CGI側でboundaryを出力しながらコンテンツを出力する
    • クライアントDUI.jsで処理
    • １プロセス１処理なのでC10K問題をもろに受ける
    • ストリーミングはC10K問題の影響を受けすぎる
  • PSGI/Plackストリーミング
  • PPSGI/Plackストリーミングの弱点
    • 同期IO処理ができない
    • CPU使う処理ができない
    • multipart/mixedとか面倒
  • 解決策その１ Tastumakiを使う
  • 解決策その２ Gearmanを使う
    • 重いCPU処理が苦手という欠点を補うジョブキューサーバ
    • クライアントからはAnyEvent::Gearman::Clientでブロックしないように
  • 解決策その３ WebService::Async
    • keroyonnさん作のモジュール
    • 非同期処理が簡単に書ける
  • まとめ Tatsumaki, Gearman, WebService::Asyncを使えば非同期処理も恐れることはない

吉見 圭司(walf443)さん「Webサービスのページング処理について」

  • RDBMSからデータを取得して、それを出す際の話
  • ページングとは、１ページに収まらない結果をわけること
  • 典型的なやりかた
    • 典型的なページング方法 limit 50 offset 10;
    • トータル件数はcount文で
  • 利点
    • たいていの場合に使える
  • 欠点
    • Group byでうまくいかない
  • 時間がかかるクエリの場合の対策
    • インデックス効くように
    • memcachedでキャッシュ - 結構面倒なことが多い
  • 別のやり方
    • MySQLのCALC_FOUND_ROWSを使うと、その直後にselect FoundRows()を実行するとトータル件数が取れる
    • 二度計算しないので、Countよりはマシ
    • limitによるmysqlの処理打ち切りが動作しなくなる
  • 次のページがあるかどうかだけを調べる方法
    • １件余分にとれば判断できる。
  • perlでページング処理するのはData::Pageが一般的
  • 一般的な一番コストがかかるのは、「トータルな件数」を求める処理
  • DBIx::Skinny::Pager
  • ページング周りの小技
    • データのないページにアクセスしてくるユーザ対策
  • あまり軽くできないSQL
    • 全文検索ページとかどうしても速度がでないところでは、10000件とか多めに取得しておいて、cacheに突っ込む
  • 質疑応答
    • Q. ページング処理中にデータが増えた場合表示がずれる可能性があるがどう対処するか
    • A. タイムスタンプなどを保持しておいてページングすれば解決できるのでは