takc-tech 共有

データベースの処理が遅いときに考える事

作成日時：2024-08-27
更新日時：2024-08-27

概要

DB起因でシステムの処理が遅いときに私が考える事を一覧化した記事。
ほぼ自分用のメモ。

システムが遅いのは大体DBのせい(暴論)。
処理が遅かったらor非機能要件満たせていないならDB周りを確認してみよう。

注意点

RDBMSの種別を考慮せずに書いたから、RDBMSによっては機能しない。
面倒で「何故そうするか」とか用語の説明を書いていない。気になったらググって。気が向いたら追記する。
メリット/デメリットは書いてない

原因解明編

処理が遅かったらまずログを見ろ。APログとかスロークエリログとか。
- APの処理が遅すぎてコネクション取得に詰まってたりしてないか
- 処理が遅いのはAPかDBのどちらか(大体DB)
クエリが遅いなら実行計画を取れ。
- コストが高くなってたりしてないか。
- FULL(SEQ) SCAN/ NESTEDLOOPはしていないか。(レコード数が少ないならよし)
- 想定していた通りのインデックスを使ってるか。
- 駆動表はちゃんと小さいか。(今はオプティマイザが選択してくれる)

インデックス編

検索が遅いなら検索条件に使ってるカラム / 結合対象カラムへインデックスを貼れ。
貼ったとしてもインデックスが効くようなクエリを書いているか
- 書き方によってはインデックスが使われないぞ
  - 詳細はググれ。
  - クエリを書いたら実行計画を取って、想定通りのインデックスが使われているか確認しろ。
- ほぼ無いけど、思った通りのインデックスが使われない場合もある。
  - 統計情報をロックしろ。
  - オプティマイザヒントを使え。
逆にインデックスを貼りすぎて更新速度が下がってないか
適切な種別のインデックスを貼れ。
- 大体B-Treeで何とかなる。
  - カーディナリティが小さいカラムに貼るな。(場合による)
- 完全一致ならハッシュインデックス
  - キー値は一様でランダムであること。
- ビットマップインデックス
- 複合インデックス
  - 列の定義順に注意しろ。
- カバリングインデックス
インデックスが断片化していないか。再構築 / 再構成しろ。
大量にデータを突っ込むなら一旦インデックスを外せ。
レコード数が少ないならインデックスを貼るな。(場合による)
カバリングインデックスはセカンダリインデックスで効果を発揮する
- PKのインデックスを見る必要が無いから

ロック編

ロックするとパフォーマンスが落ちるから貼るな(暴論)。
整合性とのトレードオフ。分離性とかOCCとかも考えろ。
ロックするなら粒度は小さく、ロック待ちタイムアウト時間も適切な長さに。
2PL

アプリ(コード)側編

コネクションプーリングの設定は適切か
- DB側の最大接続数よりだいぶ小さい値を設定していたりしていないか
DBへのアクセスはまとめてやれ。
- N+ 1をやめろ。
- ループの中で1件ずつDBにアクセスすんな。
- 仮にループの中で1件ずつ検索しなければならないのなら、同じ値は二度とDBから取得するな。
  - メモリが許す範囲でPKをキーとしたMapに突っ込んどいて取得済みならMapからデータを取れ。
- バルクインサートしろ。
最小原則。
- 1回のアクションにおけるDBへのアクセス回数は最小にしろ。
- DBから取得する値も必要最小限にしろ。アスタ使うな。(ORM使ってるなら仕方ないけど)
ちゃんとコネクションクローズしてるか。

諸々の構成編

データ件数が多すぎ → パーティショニング
結合に時間かかる → サマリテーブル / マテビュー
負荷分散 → リードレプリカ
キャッシュをかましてDBにアクセスさせない(Redis/ Memcached)
金があるならスケールアウト / スケールアップ。手っ取り早い。
その正規化は本当に必要か。無駄に結合処理を走らせることにならないか。
本当にそのシステムはRDBで無ければならないか
- NoSQLが最適だったりしないか
- NewSQLとかはどうか
エッジロケーションにDB分散させる

記事にあまり関係ないけど、リリースまでに非機能要件を満たせない場合の対応

顧客想定規模のリクエスト(サービス開始Xヵ月後の最大想定数)が飛んできた場合、非機能要件(応答時間)を満たせないことがリリース前に判明して、顧客に怒られた。
- 時間稼げ。
- 「サービス開始初期はアクセス数が少ないので、顧客想定規模のアクセスが来るXか月後までは現状の構成で問題ないです。それまでに対応します。」とか。
- その間になんとかしろ。