ゲームを題材に学ぶ 内部構造から理解するMySQL
第5回 DB側でやること、アプリ側でやることを見極めよう
本記事は,
本記事のテーマを,
「JOINはDBサーバの負荷が高くなる」は本当か?
「JOINは複雑なので,
JOINした
リスト1 JOINを使った一発系SQL
SELECT * FROM country INNER JOIN city ON country.Code = city.CountryCode;
リスト2 「JOINを使った一発系SQL」
for(Row rowCountry:country){ rowKeys = city.Indices.CountryCode.getRangeKeys(rowCountry.code); for(RowID rowID:rowKeys){ // SELECT句の処理があれば行う retRows.add(rowCountry, city.getRow(rowID)); } } // ORDER BY句があればソート return retRows;
ぐるぐる系のリスト3を手続き型言語に直してみると,リスト4になります。
リスト3 ぐるぐる系のSQL
SELECT * FROM country; -- 以下をcountryの件数回問合せる SELECT * FROM city WHERE CountryCode = ?;
リスト4 「ぐるぐる系のSQL」
for(Row rowCountry:country){ retRows.add(rowCountry); } return retRows; // APサーバからcountryの件数回呼び出される rowKeys = city.Indices.CountryCode.getRangeKeys(?); for(RowID rowID:rowKeys){ retRows.add(rowCountry, city.getRow(rowID)); } return retRows;
見比べてみると,
第4回の図2と第3回の
APサーバで肩代わりできる処理
APサーバで処理することによってDBサーバの負荷が下がるということは,
- マスタ類のキャッシュ → APサーバの同期が取れれば有効
- SELECT句の処理 → SELECT句でソートするWindow関数以外は誤差
- ループのブレイク処理 → 誤差
- ソート処理 → DBサーバの負荷を下げるには有効
DBサーバの負荷をどうしても下げたいのであれば,
SQLでどこまで処理すべきか
C言語やアセンブリ言語の経験がないエンジニアが増えています。そのため,
SQLはRDBMSのインプロセスで動作します。インプロセスとはRDBMSのメモリ空間内で処理されるという意味で,
ここで第1回の図1で解説したページ単位でのI/
設計時に
「そんな極端な」
記事中で紹介した書籍
-
SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる
本書は,SQLの文法は学んだもののSQLに苦手意識を持っているITエンジニアのための書籍です。 複雑なSQLを読める/書けるようになるには,データベースの表をカタマリで...