▼大規模データベースでは，テーブルとインデックスのパーティション分割が，パフォーマンスと管理しやすさの改善に利用されてきた。SQL Server 2005では，その設計を容易にする機能が追加される。
▼テーブル・ベースの新しいパーティション分割機能によって，パフォーマンスが向上するとともに，パーティション分割されたテーブルの設計と管理が大幅に簡略化される。設計，実装，チューニング，運用や保守などをより簡単に行うために管理ツール群も大幅に機能が拡張された。
データベース（DB）で，購入履歴を格納するテーブルを設計するとしよう。テーブルには，購入年月や購入品目と購入金額などを記録して，蓄積していくことになる。これらが単一のテーブルに格納できれば購入履歴DBとして利用しやすい。
しかし，パフォーマンスやスケーラビリティを考慮すると常にそれが最良とはいえない。特にテーブルに格納するデータ量が膨大になると検索や削除のような基本的な処理はもちろん，バックアップやリストアなどの管理作業にも時間がかかるようになる（図1[拡大表示]）。
DBの合計サイズが数百GバイトまたはTバイト単位に及ぶものはVLDB（ベリー・ラージ・データベース）と呼ばれる。それぐらいになるとパフォーマンスや管理性の低下が目立つようになる。
そのサイズに達していなくても，要求した応答時間のうちに検索結果が返って来ないテーブルや保守があらかじめ定義された期間・コストを超えるテーブルは，十分大規模といえるだろう。
大容量テーブルでは，実質的な可用性が低下する。サーバーが稼働していても，バックアップなどの保守作業に1日当たり何時間もかかって，その間はテーブルにアクセスできない場合，DBが利用可能とはいえない。
大規模テーブルを分割して扱う
このような場合，一般にはテーブルやインデックス＊をパーティションに分割することで，大容量テーブルやインデックスのスケーラビリティを向上させる。データ変更時に広範なデータ（データの大きなかたまり）を簡単に追加または削除できるようになる。
複数のCPUを備えたサーバーに大容量テーブルがある場合は，テーブルをパーティションに分割すれば，並列処理によるパフォーマンス改善も可能だ。
SQL Server 2000にもパーティション分割の仕組みは備わる。具体的には単一の大容量テーブルを集計する代わりに，まず個別のパーティションに見立てたテーブルをそれぞれ処理し，その後でその結果を見かけ上のテーブルであるビューとして集計できる。これを「分割ビュー」や「パーティション・ビュー」と呼ぶ。ただし，巨大なテーブル同士を結合＊（ジョイン）したり，フル・スキャンやインデックス検索をしたりするとパフォーマンスが落ちる場合があった（図2[拡大表示]）。
また，パーティション分割に対応したスキーマ＊作成および保守の支援機能がなかった。そのため，パーティションは扱いにくく，ユーザーや開発者が正しく特性を理解しなければ，利点を生かせなかったのである。パーティション分割を効率的に支援
これがSQL Server 2005では大幅に改善される。例えば，パーティションは結合などの新しい操作に適用できる。関連するテーブルが同一のパーティション・キーでパーティションに分割された場合，これをテーブルの「連結」という。
連結されたテーブルを結合する場合，SQL Server 2005では，最初にパーティションを結合してから，その処理結果を組み合わせられる。これによって大規模なシステムで複数のCPUが動作するマシンを効率的に使用できる。
しかもパーティション分割はあらかじめ定義した情報に基づき自動的に行われる。タイプとしては「行方向の分割」と呼ばれるもので，個々のパーティションには，それぞれまとまった大きさの行がオブジェクトとして格納される。
パーティションは，自由に定義できる。例えば，「2004年12月の購入履歴」はパーティションAに，「2005年1月の購入履歴」はパーティションBに格納する——などが可能だ（図3[拡大表示]）。
SQL Server 2005では，定義済みの範囲を使用してデータの詳細な用途をもとにテーブルをパーティション化することも可能である。同製品には長期間蓄積するデータの管理に関して多数のオプションが用意されている。
簡単に設計して性能が向上
パーティション分割機能を使用することで得られるメリットは，（1）大容量テーブルの設計および実装の簡略化，（2）大規模テーブルに対する検索性能の向上，（3）管理コストの軽減，（4）可用性の向上——である。
まず，SQL Server 2005のパーティション・テーブルでは，追加のパーティションが必要になった場合やデータの用途が将来変わった場合などでも設計や実装が簡単にできる。検索時もパーティションを意識する必要はない。常にテーブル全体に対するTransact-SQL＊文で検索でき，アプリケーション側のクエリー変更は不要である。例えば，分割ビューのときのような複雑なTransact-SQL文を書くことはない。SQL Serverの内部では自動的にアクセス先パーティションを判断し，必要なパーティションにアクセスする。これによりフル・スキャンの性能が向上する（図4[拡大表示]）。
管理コストも下がる。例えば，大規模なテーブルで大量のデータを高速に削除可能だ。長期間データを蓄積したテーブルから一部のデータを削除する場合，一般的には時間がかかる。しかし，パーティション分割されたテーブルでは，パーティションを削除単位に設定すれば，パーティション・テーブルの切り替えで高速にデータを削除可能だ。同様の仕組みで大量データのロード＊も高速になる。
例えば1カ月単位でパーティション分割すると，直近12カ月のデータを持つテーブルを容易に管理可能だ。月が変わったら不要になった最も古い月次のパーティションを別のテーブルに分離するだけで瞬時に終わる（図5[拡大表示]）。バックアップやリストアはもちろんパーティション単位で可能だ。さらにパーティションの一部のパックアップや一部のリストアに対応している。バックアップ時間の短縮やピン・ポイントのリストアが容易である。
大規模テーブルに対して効率的にインデックスを作成することもできる。パーティション分割してあれば新たに追加されたパーティションに対してのみインデックスを作成すれば済む。これは高速で実行され，インデックスのフラグメンテーションの発生も最小化できる（図6[拡大表示]）。
さらにパーティション分割は可用性の向上に役立つ。1つのパーティションに障害が発生しても，他のパーティションにアクセス可能だからだ。
笹瀬 行弘
マイクロソフト SQL Server日本語版の開発を担当。SQL Serverの機能強化と品質向上を目指し，日本のユーザーの皆様のご要望が製品に反映されるように，日々活動中です。 |
