前の記事に続いてSeasar Conferenceをレポートする。
- DB-sideのほうは「PostgreSQLによる、ORマッピングvs SQL+ストアド 性能と生産性の比較研究」
- Seasar-sideのほうは「JSFの波に乗れ！ TeedaではじめるJSF」
- ミニセッションのほうは「S2JMS」「DI事始め」「DIベースのWindowsアプリの作り方」「Maple or S2Mapleデモ」
Teedaの情報はまたWeb+DB Pressあたりが流してくれるだろうし、それよりはPostgreSQLのほうの熱いタイトルに魅力を感じて、私はPostgreSQLのほうへ行った。内容はちょっと期待外れ。
まずは、PostgreSQLとユーザー会(JPUG)についての概略説明。MySQLとの簡単な性能比較とか。概略といってもこれが長い。Teedaを捨ててまで敢えてこっちを聞きにくる人間なら、それぐらい知ってるって。勘弁して欲しい。
まぁ、雑誌にいくらでも載ってる情報だけど、一応、一部はメモ取った。
- 中心的コミッタが一度には失業しないように、コアメンバーは全員違う会社に所属するようになっている
- 基本的に、標準準拠指向かつ高機能指向なので、下記を除けば「これはできる?」と聞かれるようなことは大体できる。
- レプリケーション・クラスタ化。ただし、pgpoolとかslony-lとか外部ツールはある。
- ライブラリ動作モード。サポートするのはクライアント - サーバーモデルのみ。
- クエリキャッシュ
- トランザクションの隔離レベルは2つだけしか実装されていない。どれとどれだっけ。まぁ、調べればそこら中に書いてある。
- MySQLと比較して、
- SELECTは同じくらい
- コネクションを張るのが遅い。接続に対してMySQLがthreadを立ち上げるのに対し、PostgreSQLはプロセスを立ち上げるため。
- JOINが増える程、PostgreSQLが速い
- 全体としてあんまり変わりはない。あとはケースバイケース
- 8.0の見どころ
- 8.1の見どころ
- 2 phase commit
- SMP性能向上。従来はマルチCPUを有効に活用できていなかったが、ロックの粒度を細かくして対応した。
プロセス指向、データ指向、オブジェクト指向。関連する様々な分析法、設計法。それらの変遷、歴史について。これが10分。えーと、ここに来てる人なら知ってると思うよ。
ここから先の20分は面白かった。
何故インピーダンスミスマッチが発生するのか
- 10年前から決定打は無い
- 単にクラス図をテーブルに落とすなら、マッピング手法は確立されている
難しいのは、オブジェクトのライフサイクル、永続性分析。
- 「デザイン上こうするのが自然だよね」とはならない
- 極端な話、普通ならHTTPセッションに入れるような情報を全部DBに入れても良い筈。
- デザイン上の必然性は無いけれど、パフォーマンス面からあるものはDBに入れ、あるものは入れない。
- 決定材料が不足するところに判断を下さなければならないので難しい
- オブジェクト指向分析は完璧。自前のDAOを使用。
- メモリーを4GB積んでもWebSphereがメモリー不足で落ちる
オブジェクトが長く参照されるのに、テーブル単位で個々にDTOとしてアクセスして、それらをJavaプログラム側でいじくり回していた。所謂Bean Managed Joinsアンチパターン?
ORMは
- 曰く、インピーダンスミスマッチを吸収する
- 曰く、ロジックの中にSQLを混ぜ込まなくてよい
- 曰く、特定のDBMSへの依存性を吸収できる
- 曰く、Connectionの確立等の定型部をいちいち書かなくてよい
ここで疑問を提示する。
- それってDAOパターンの利点でないか?
- SQLが嫌いなだけじゃないか？
それに、DBプログラミングではトランザクション設計はテーブル設計と同じぐらい重要。
- どこまでが1トランザクション？
- ロックをどう掛ける？ 楽観的？ 悲観的？
- ...
こういう判断が必要。そして、
- これらがパフォーマンスに直結する。
- トランザクション回りの特性はDBMSごとに差異が大きい。
で、こういう問題をORMがどう解決してくれるって？
SQLは昔風に言えば第4世代言語な訳で、データを取り扱うことに関して生産性は高い。そもそも、ビジネスロジックというものはSQLで完結する筈だ。プログラム言語は、SQL発行に至るまでの外部インターフェースを整えるに過ぎない。
……だそうです。
歴史的にSQLこそがビジネスロジックであったのだと、その辺を語ってたのは羽生さんの本だっけか。
とりあえずの解決策として粒度大きめのDAOを使おう。
- DBアクセス部分を分離するという発想は良い
- メソッド1つが1トランザクション=1ビジネスロジックに対応。1トランザクションを発行して、一群のテーブルに働きかける。
また、プログラム言語へのHTMLへの混在をJSPが解消したように、テンプレートベースでSQL混在を解消すれば良い。
あとは、ビジネスロジックの記述にストアードプロシージャを使おう。
PL/pgSQLが7000行。このストアードプロシージャ群がクライアントとサーバーの間に入ってビジネスロジックを抽象化した。
- ストアードプロシージャは運用中に書き換えが効くのが役に立った
- PostgreSQLではストアードプロシージャはトランザクションを跨げないのがちょっと難点。
講演者の高塚さんは、Seasar歴1ヶ月弱だそうですが、ちょっと触ってみての感想とのことです。
- S2Daoは、メソッドに任意のSQLを割り当てられるのが良い。
- OR Mapperとしてだけでなく、SQLテンプレートフレームワークとしても使える
後半だけでいいよ。
セッション2
