今回はWebサイトを製作する上で欠かせないデータベース(DB)のお話です。Linux、Apache,MySQL,PHPを組み合わせたLAMPという言葉が登場して久しいですが、Webサービスを構築する上で欠かせないのがDBの存在ですね。
運用後Webサイトが順調に拡大し規模も大きくなってきた頃、パフォーマンスに悩むことも出てくるものです。
ハードウェアや構成に問題がある場合、ロジックに問題がある場合など様々ですが、DBを見直してみるのも手かもしれません。
銀行の預金残高などのようにミッションクリティカルである場合や、ともかくパフォーマンス性を求められるなど様々あり、一概に言えるものでもありませんが、 Webサービスにおいては有名な8秒ルールも、最近では6秒、3秒、1秒と求められるパフォーマンスはどんどん短くなって来ています。
パフォーマンスだけでなく、メンテナンスコストやスケーラビリティなどすべてに大きく関わり、システム的な面においてはDBが大部分を握っていると言っても過言ではありません。
設計時点で悩むDBですが、ただ正規化すればよいというものでもなく、どのような場面で利用され、また最も多くアクセスが発生するかなどを考慮する必要が出てきます。
今回はMySQLを例に取り上げますが、それぞれの性質を考慮した上で判断していくことが重要になってきます。
とはいえ、MySQL自体の設定を変更できない場合などもあるので、一般的な注目・改善点をご紹介します。
- MyISAM、InnoDBなどテーブルタイプ
- トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。
- 更新(update)・削除(delete)のフラグ化
- 一概には言えませんが、レコード数が大きくなるとコストが上がってきます。整合性などの注意点もあるので慎重に行いましょう。
- レコード数などの参照は非正規化してみる
- 都度レコード数を集計するのではなく、一部非正規化して持つなど。問い合わせ発行数を減らすのも改善案のひとつです。
- indexが適切かどうか
- 無駄なindexはないかどうかを調査してみましょう。かえって遅くなったりしているかもしれません。
- 利用範囲を考慮する
- データが利用される場面を想定し、リアルタイム性を求められなかったり、冗長性がないかどうかを調べてみましょう。場合によってはログテーブルなどを利用するのもいいかもしれません。
- サマリテーブルの導入を検討する
- ランキングなど集計処理はコストが高くつきがちなので、リクエスト毎に生成する必要があるかを検討する。
- explain で参照処理を検証する
- 適切なindexが利用されているか、filesortが発生していないか、オーバーヘッドが大きくないかなどの情報を見ることが出来ます。
- そもそも必要な処理・問い合わせなのかを見極める
- 別テーブルや静的ファイルで代用可能かどうかなど、意外な盲点があるかもしれません。
このtipsはもちろんすべてに応用できるものではなく、個々の場合に応じて最適解は異なって来ます。(特に更新・削除フラグなど)
自サービスに合うかどうか、そもそも設計時点で無理はないかなど、多角的に見る事が重要です。