今回はデータ量が多くなりそうなテーブルの設計について
考える
負荷をへらすために考慮すべき項目をあげてみる
１．想定されるデータの量(レコードの数、サイズ)
２．テーブルに貼るインデックス
３．テーブルを分割する
４．テーブルをパーティショニングする
１．
レコードの数については設計段階で想定できるだろう
ユーザーが何ユーザーいて、一日何回ユーザーによって実行されるかと考えよう
レコードのサイズについては作ってみないとわからないことも多い
textカラムなど一度に多くのデータを保存しない場合は大きなサイズとなるだろう
レコードのサイズつまりテーブルのサイズについては作ってみないとわからないかも
２．
インデックスを適切に貼るとselectが高速になる
しかしデータの量が多いとインデックスを貼るだけでもデータサイズを食う
またデータが更新されるたびにインデックスを貼り直すため更新速度が遅くなったりする
むやみやたらにインデックスを貼りまくればいいというものでもない
３．
テーブルのサイズが多くなりそうならテーブルを分割するという方法もある
ユーザーIDの末尾で１０個に分けたり月の1~12月で１２個に分けたりして一月ごとに分けたりと
ただユーザー10の履歴テーブルにユーザー10がプレゼントを送ったユーザー11というユーザー情報が入っていた場合にユーザー11が誰からプレゼントをもらったかということはselectできない
こういう場合は分割ができなかったりする
４．
３とは違い物理的にテーブルを分けるのではなく、１つのテーブルを分割するというパーティショニング
こちらの記事がわかりやすいです
以下のようなデータの分け方があります
RANGE ・・・ パーティションごとに範囲を指定して振り分ける
LIST ・・・ パーティションごとに格納する値で振り分ける
HASH ・・・ 1つのカラムの値を式の結果で振り分ける
KEY ・・・ １つ以上のカラムの値をMD5関数等で評価して分割する
メリットとしてはselectが高速になります
オプティマイザーを利用するため対象のパーティションのみを参照するらしい
ただし注意点があります
パーティショニングはユニークなキーを含めていなければなりません
オートインクリメントで作成したIDとかユニークだと思うのですがそのカラムをパーティショニングに設定なんて意味ないことはできませんね…
以上、負荷を考慮するときに考えることをあげてみました
検討の流れとしては
作られるデータ量(レコード数、サイズ)を考えそのテストデータを作成
→
さすがに多いとわかればテーブルを分けたりパーティショニングしたり、そうでないなら一つのテーブルで作成
→
テーブルに適切なインデックスを貼ってみる
→
テストデータを突っ込む
→
explainでインデックスをしっかり利用しているか確認
→
selectを投げて、実行速度を見てみる
という感じ
とはいえ実際にリリースしてみないとわからないこともあります
想定外のデータ量の増え方をするとか
社内の知見のある方曰く、「経験が大事」とおっしゃってました
コメント