JustTechTalk#06 参加メモ(1/3)「スマイルゼミの裏側:データベース編」
JustTechTalk#06 スマイルゼミの裏側(DB編)とRDBMS最新動向に参加してきました。 タイトルにもある通り、今回はDB関連の話がメインで以下の3つの発表がありました。
全部まとめると長々とした内容になってしまうので、今回は発表内容ごとにブログの記事を分けてみます。 (一つにまとめると後から自分で見返す時も大変ということに今更ながら気がついたのです...)
スマイルゼミの裏側:データベース編
ジャストシステムが運営する「スマイルゼミ」のサービスの裏側に関する内容でした。 スマイルゼミのサービスはTomcat+PostgreSQL 9.3で構築されており、今回はDB的な意味でやらかしてしまった話を聞くことができました。
スマイルゼミについて
- スマイルゼミは小学生と中学生でニーズが異なる
- サーバとクライアントの構成も小、中学生向けで別物というくらい異なっている
- アクセスのピーク時間にも違いがあり、基本的に朝と夜にピークの山がある
- 小学生向けのサーバでは朝の6:00〜8:00前くらい、中学生だと夜にピークがある
DBでやらかしてしまった話
DBでやらかしてしまった話として、unionにまつわる2つのケースが解説されていました。
viewの中のunionが悪さをしていた話
- ある日のこと、平日のピークではない時間帯に負荷が急上昇した
- 前日にhotfixを当てており、これが問題の引き金になった模様
- 内部のバッチ処理で1300万行のシーケンシャルスキャンが発生していた
- 調べてみると怪しいviewがあった。
- 対策として、前日の学習結果の集計をview定義の段階で学習日で絞った
(今度は逆に)unionで問題解消できた話
- スマイルゼミのサービスとして、「みまもるトーク」というLINE的(?)なサービスがあるとのこと
- これを中学生向けにも展開するため、ユーザ認証関連のSQLを修正した
- WHERE句に小学生、中学生、親の条件を追加する形での修正
- すると実行計画が狂ってしまい、インデックスが使用されなくなりシーケンシャルスキャンが発生
- 対策として、小学生、中学生、親のそれぞれで行を絞り込んでからunionする方法で問題解消
得られた教訓
- unionしている箇所の変更は慎重に行う必要がある
- また、unionしてもよいのは中間結果が小さい場合のみ
- viewの中でのunionは危険
まとめ
JustTechTalk#06 参加メモを書いてみました。他の2つの発表についても順次メモをまとめてみます。 DB関連のやらかしはケーススタディとして聞いた瞬間は「なるほど、自分も気をつけよう」と思うのですが、やはり実際にハマってみないと身につかないため、view+unionで実際に性能劣化が発生する様を手元の環境で試してみようと思います。