« OSS-DB Exam Gold 技術解説無料セミナー@東京 | トップページ | PostgreSQLでDecode? »

2014.04.24

O/Rマッパーが惹き起こす性能劣化(N+1)回避策?

まあ、O/Rマッパーが単体で悪いわけじゃないんだけどね。

SQLの隠蔽ができるため、O/Rマッパーを便利に使っているプロジェクトは多いだろう。
しかし、何も考えずに使っていると性能劣化する可能性があるよ、という警告である。
ていうかSQLの隠蔽を目的にして使ったらあかんよ。

代表的なエラーは「N+1問題」であろう。
O/Rマッパーにもこの問題を回避する機能は存在するのだが、こうした問題が起こることを理解していない人間が実装すると、きさくに気楽にやってくるのがこいつだ。
端的に言うと、ある処理で数百行取得する主テーブルがあったとして、この主テーブルと連結する副テーブルについて1行ごとにSQLを発行してしまう事象だ。
直接SQLを書いていれば逆にこのような現象を起こすのは難しいw
SQL文中で顧客マスタともJOINするので、このデータ取得で発行されるSQLは1回である。

ところがO/Rマッパーの使い方が悪いと、500行の受注明細を取得したときに、顧客名もマスタから取得しているケースで、1回の受注明細取得SQLに対して、その1行ごとの結果に対して顧客名を検索しているというような形で現れる。
このため主テーブルの行数(N) + 主テーブル(1) 回だけSQLが発行されることから「N+1」と呼ぶわけである。実際には連結先テーブルがもっとたくさんあって、3N+1とか5N+1回SQLを発行することだってありえる。

で、少し昔の『日経システムズ』を読んでたらこれに類する記事があって"性能を担保するために、1画面当たりのSQL数を目標値として設定する"という対策をとるプロジェクトがある、とのことだった。
SQL数の計測なんてやったことないけども、外注に出す際にこの目標数を伝えることで、N+1を結果として抑制できる、ということらしい。

言いたいことはわかるけど、ストレートにN+1問題を起こさないこと、という要件じゃダメなのかな(^^;?

|

« OSS-DB Exam Gold 技術解説無料セミナー@東京 | トップページ | PostgreSQLでDecode? »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/59514984

この記事へのトラックバック一覧です: O/Rマッパーが惹き起こす性能劣化(N+1)回避策?:

« OSS-DB Exam Gold 技術解説無料セミナー@東京 | トップページ | PostgreSQLでDecode? »