［データベース設計編］安易なパーティション分割をしてはいけない

　主要なRDBMS製品には「パーティション分割機能」が備わっている。この機能は性能向上に効果的な半面，作業を煩雑にするケースもあるので，安易な利用は禁物である。

　テーブルのパーティション分割とは，一つのテーブルを，物理的に「パーティション・テーブル1」「パーティション・テーブル2」のように複数に分割する機能である。テーブルを分割したとしても，アプリケーションからは元の一つのテーブル（論理的なテーブル）に見えるので，そのテーブルにアクセスするSQL文を変更する必要はない。

　検索条件によっては，特定のパーティション・テーブルだけを検索するだけで済む。大きな（論理的な）テーブルを検索しなくてもよいので，レコード数が多数ある場合，うまく分割すれば性能向上を期待できる。また，パーティション単位でデータを削除したり，バックアップしたりすることが可能なので，運用の効率化を図ることが可能になる。

　パーティションの分割方法は，RDBMSによってさまざまである。主流は，テーブル内のカラム値の大小によって分割する「キーレンジ方式」と，カラム値のハッシュ値によって分割する「ハッシュ方式」である。

　一つの例を紹介しよう。ある販売管理システムで，直近12カ月の販売実績データを一つのテーブル（販売実績テーブル）に格納しようとしていた。そのテーブルのレコード件数を想定すると，1000万件を超えることが予想された。こうしたケースでは，月別（2009年5月，2009年6月，など）に販売実績テーブルをパーティション分割することがよく行われる。これは，キーレンジ方式の典型的な例である。この例の場合，テーブルの日付カラムの値を使用し，「2009年4月＝＜日付カラム＜2009年5月」のようなパーティションの定義を行うことになる。

毎月末に煩雑な作業が…

　月別パーティション分割を行ったことにより，毎月末に次の月のレコードを格納するための新規パーティションを作成しなければならない。もしその作業を忘れると，どうなるだろうか。例えば，直近月のパーティションを「2009年5月＝＜日付カラム」と定義していた場合，本来ならこのパーティションには2009年5月のレコードだけを格納したいところだが，2009年6月以降のデータもこのパーティションに格納されることになる。また，「2009年5月＝＜日付カラム＜2009年6月」と定義していた場合，2009年6月以降のデータを格納するパーティションは存在しないことになる。

　新規パーティションを作成するには，その時点でのディスク使用状況を把握し，適切な配置を考えなければならない。月ごとに必要とされるディスク容量が異なっていたりすると，その設計は容易ではない。

　直近12カ月分のデータのみ対象とするなら，最古の1カ月分のデータを削除しなければならない。その作業は，該当パーティションのデータをバックアップした上で，そのパーティションを削除する。パーティションは物理的に別テーブルとして実装されるので，ほかのパーティションに処理性能の面で影響を与えない。この作業は比較的容易とはいえ，毎月末にこうした作業が必要になる。

　パーティション分割していなかったらどうだろうか。月末に新規のパーティションを作成する作業は不要である。最古の1カ月分のデータは，毎月末に，条件に該当するレコードのみを削除する処理を実行することになる。この処理の実行に伴う，性能低下への配慮が欠かせない。

　パーティション分割を行うことにより，運用作業は大きく変わってくる。ここで紹介した以外にも必要な作業があるだろう。運用作業の細部まで検討した上で，パーティション分割するかどうかを判断しなければならない。