技術解説 パーティショニング採用で大企業に対応するSQL Server 2005 1．パーティショニング機能の実際 Chris Alliegro 2006/03/23 Copyright (C) 2005, Redmond Communications Inc. and Mediaselect Inc.

ローカル・パーティショニングの効果

　SQL Server 2005には、ローカル・パーティショニングのための新機能（パーティションド・テーブル）が搭載される。これにより、Microsoftは機能面でIBMやOracleに一歩近づくことになる。パーティションド・テーブルを利用すれば、データベースの管理者や設計者は、大きなデータベース・テーブルを小さなパーティションに分割できる。すべてのパーティションは、比較的小さなベース・テーブルという形で1つのデータベースを構成する（パーティションド・テーブルの仕組みについては、図「テーブル・パーティショニングの概念」を参照）。

テーブル・パーティショニングの概念

パーティションド・テーブルを利用すれば、大きなデータベース・テーブルを比較的小さな複数のベース・テーブル（パーティション）に分割できる。図の左側のテーブル（「オーダー・テーブル」）は、全国の小売りチェーンから年間を通して送られてきた受注記録だ。「日付」カラムにはトランザクションの日付、「オーダーの詳細」カラムには製品番号や注文数など、トランザクションの詳細が記録されている。 　「オーダーの詳細」は大きくなり、管理が大変になってきたので、管理者は月別に12の小さなテーブル（パーティション）に分割した。パーティション機能が、パーティションを切り、特定のカラム（パーティショニング・カラムと呼ばれる）のデータを取り込み、パーティション間でデータをどのように分散するか決める。図の例では、「日付」カラムがパーティショニング・カラムとして機能する。そしてパーティショニング機能は、2004年1月のすべての受注記録を「1月のオーダー・パーティション」に、2004年2月のすべての記録を「2月のオーダー・パーティション」に、というようにデータを分配していく。そしてパーティション・スキームが、パーティションド・テーブルを構成する個々のパーティションをデータベース・サーバの物理的なファイルおよびディスクにどのようにマップするかを定義する。図では、月別のパーティションがそれぞれ対応するデータベース・ファイルに格納され、データベース・サーバに接続した物理ディスクに置かれている。図は、テーブルを行で分割する水平パーティショニング（SQL Serverのすべてのバージョンで用いられるパーティショニング・メカニズム）の一例だ。

　SQL Server 2005はパーティションド・テーブルとその定義を、1つの論理エンティティとしてデータベースに格納する。開発者や管理者、ユーザーは、一般的なデータベース・テーブルと同じようにパーティションド・テーブルのデータを照会、更新、修正することができる。SQL Server 2005はパーティションド・テーブルの物理的実装の詳細をデータベース・ユーザーから隠すため、ユーザーはデータがパーティションド・テーブルを構成するベース・テーブルに、どのように分散されているかを知る必要はない。

パーティションド・テーブルの管理

　この新しい機能は、SQL Server 2000に搭載された機能、ローカル・パーティションド・ビューが進化したものだ（ローカル・パーティションド・ビューはSQL Server 2005でも引き続きサポートされる）。新旧2つの機能は、開発者や管理者、ユーザーに同様の利便性を提供するが、パーティションド・テーブルはSQL Server 2000の機能より、構築、管理がはるかに容易になっている。

　例えば、SQL Server 2005の管理者は、パーティションド・テーブルのパーティション数と、データがそれらのパーティション間でどのように分散されるか指定できる。それらを指定すると、SQL Server 2005は自動的にベース・テーブルを作成し、それ以降、クエリやアップデートを適切なベース・テーブルへ転送する。対照的に、SQL Server 2000の場合、管理者は個別にベース・テーブルを作成し、それぞれのベース・テーブルで、どういったタイプのデータが許されるか（あるいは許されないか）など、一連の制限を個別に指定しなければならなかった。

　さらに、SQL Server 2005の管理者は、保守作業（インデックスの再構築や一貫性チェックの実行など）をベース・テーブルに直接実行するのではなく、パーティションド・テーブルに対して実行することができる。SQL Server 2000の場合、管理作業はすべて個別のベース・テーブルに対して実行する必要があった。

データ・ウェアハウス・タスク向けの新しいコマンド

　SQL Server 2005では、パーティションド・テーブルを作成した後、それぞれのパーティションを管理するための新しいコマンドやコマンド・オプションが用意されている。例えば、単一のパーティションを2つに分割したり、複数のパーティションを統合するコマンド・オプションや、既存のパーティションド・テーブルからパーティションを切り替えてデータを追加したり、削除するコマンド・オプションなどがある。こうした新機能は、データ・ウェアハウスや分析用の大規模データベースの煩わしい保守作業を容易にするために追加されたものだ。

　例えば、企業はしばしば直近の販売データだけをオンラインにして、古いデータをアーカイブするなど、データ・ウェアハウスの中にデータの“スライディング・ウィンドウ（最新のデータだけが見えるようにした、移動する窓）”を置くことがある。毎月の保守手順としては、最新の月次販売データを追加し、代わりに古くなった月次データをアーカイブ、削除することになるだろう。綿密に設計されたパーティショニング・スキーム（各月の販売記録を格納する12のパーティション）があると仮定すると、SQL Server 2005のパーティションド・テーブルはそうした作業、すなわち管理者が新しいテーブルを作成し、直近の月次データを読み込み、そのテーブルを新しいパーティションとして挿入する一方、古い月次データを含むパーティションを削除する、といった作業をシンプルかつ迅速化する。

分散パーティショニングに変更なし

　パーティションド・テーブルは、単一のサーバ上にあるデータベースを分割して、保守作業の影響を低減したり、クエリ・パフォーマンスを改善するためのローカル・パーティショニングに限定されたりしている。SQL Server 2005でも複数のサーバに負荷を拡散させる分散パーティショニングには、SQL Server 2000で導入した分散パーティショニング・ビューが用いられる。この機能を利用する場合、管理者は複数のサーバ上に独立したベース・テーブルを作成する。分散パーティショニング・ビューは、ユーザーや開発者からベース・テーブルの実装の詳細（テーブルの名前やテーブル・データがどのように分散されているかなど）を見えなくして、実質的にベース・テーブルのエイリアスを提供する。

　しかし、SQL Server 2005は分散パーティション・ビューの管理を簡素化していない。管理者は、パーティション・ビューを構成する個別のテーブルごとに保守作業を実行しなければならず、1回の作業でビューの保守を行うことはできない。ビューのパーティショニングを変更する（例えば、サーバを2台から3台へ増やす）場合は、新しいテーブルを作成し、マニュアルでデータを移動して、分散データベース間にまたがるビューの定義を更新する必要がある。さらに、分散パーティションド・ビューは通常、特定のタイプのアプリケーションの場合にのみパフォーマンスが向上する。例えば、パーティションド・ビューを構成するサーバ1台以上からデータを収集する必要のないクエリを行うアプリケーションなどだ。

　恐らく企業などでは、パフォーマンスの向上が管理オーバーヘッドのコストを明確に上回る場合以外、SQL Server 2005で分散パーティショニングを利用することは避けるだろう。低コストの64bitやマルチプロセッサ・サーバが増えたことや保守の容易さなどから、多くの組織やアプリケーションにとっては、分散パーティションド・ビューよりもパーティションド・テーブルの方が魅力的で経済的な選択肢になるに違いない。

考慮すべき点

　SQL Server 2005のテーブル・パーティショニングは、SQL Server 2000のパーティションド・ビューと比較して、さまざまな面で大規模データベースの管理が容易になっている。しかしその一方で、アーキテクトや管理者、開発者がマスターしなければならない数々の新しいコンセプトやコマンドも導入されている。

　顧客はまた、次のような点についても考慮する必要があるだろう。

■自動移行機能の欠落
　基本的なコンセプトが大きく異なるため、SQL Server 2005には、パーティションド・ビューでパーティションが切られたテーブルをパーティションド・テーブルに移行するためのユーティリティが用意されていない。ただ、新しいテーブル・パーティショニング・コマンドを使って、SQL Server 2000のローカル・パーティションド・ビューのベース・テーブルをSQL Server 2005のパーティションに切り替えることは可能だ。

■慎重な設計が必要
　パーティショニングは大規模テーブルのパフォーマンスと管理性を向上させるが、実際に効果を上げるためには慎重にパーティショニング・スキームを設計しなければならない。開発者やアーキテクトは、データがどのようにユーザーやアプリケーションからアクセスできるか、および管理オペレーションのタイプ、頻度などを十分検討する必要がある。大きめのテーブルで、保守作業がユーザーのクエリに干渉することが明白になってきたものは、パーティショニングの候補といえるだろう。同じように、もしデータベース・クエリが簡単に特定できるサブセットや一定の範囲のデータに限られるような場合も、パーティショニングでクエリのパフォーマンスは向上する（例えば、ほとんどのクエリが月別データを目的とするような販売実績テーブルなど）。しかし、もしそうしたデータ・アクセス・パターンがないときは、パーティショニングを行っても、クエリ・パフォーマンスの悪化を招くだけに終わる。

　いずれにせよ、管理者もアーキテクトも、期待されるパフォーマンスや拡張性の向上に対して、パーティションド・データベースに内在する管理、保守の複雑さがどれほどの比重になるか、慎重に検討する必要がある。パーティションド・データベース・テーブルは、単一の巨大なテーブルより、はるかに複雑な構造を持つからだ。

■OracleやIBMにとっては古いニュース
　OracleとIBMは何世代も前のデータベース管理システムからテーブル・パーティショニングをサポートしてきた。従って、SQL Server 2005でパーティションド・テーブルのサポートを実現することは、そうした大規模データベース管理分野で先行するライバルたちに一歩近づくことになる。だが、機能面から見れば、必ずしもMicrosoftが優位に立ったとはいえないのだ。

　MicrosoftはSQL Server 2005の発表を2005年11月7日に予定している。コミュニティ・テクニカル･プレビュー（CTP）の最終版（第6版）は、2005年9月にリリースされた（CTPはベータ版などの主要なマイルストーンの中間にリリースされる製品。ただし、ベータ版レベルのテストは行われない）。パーティションド・テーブルは、SQL Server 2005 Enterprise EditionとDeveloper Editionのみでサポートされる。

参考資料

• Microsoft(R) SQL Server(TM) 2005、Visual Studio(R) 2005、BizTalk(R) Server 2006に、ISV、SIパートナー94社が対応を表明 （マイクロソフト）

• IDC Webサイト［英語］

• SQL Server 2005（マイクロソフト）

• SQL Server 2005の最新のパフォーマンス･ベンチマークを測定したTransaction Processing Performance Council（TPC）［英語］

• SQL Server 2005のパーティションド･テーブル（Microsoft）［英語］

• 月刊誌『Directions on Microsoft日本語版』2005年2月号「データ統合サービス検証」

• 月刊誌『Directions on Microsoft日本語版』2005年8月号「SQL Server 2005への移行を促進、Reporting Servicesを強化」

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

INDEX
	［技術解説]
	パーティショニング採用で大企業に対応するSQL Server 2005
	1．パーティショニング機能の実際

　

技術解説

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）