LASSIC Media らしくメディア
テーブルパーティショニングとは｜大きな表を分割
「注文テーブルの行数が数億件に膨らみ、夜間の集計バッチが朝までに終わらない」「メンテナンス時間中にインデックスの再構築が終わらず、翌朝までシステムを止められない」——大規模なテーブルを抱えるシステムでは、こうした悩みが表面化してきます。原因の多くは、1枚の巨大なテーブルにすべての行を詰め込み続けている構造にあります。
そこで検討されるのが、テーブルパーティショニングです。1つのテーブルを複数の物理的な単位に分割して管理する仕組みで、大規模データベースの定番の打ち手のひとつです。本記事では、発注担当者やプロジェクトマネージャーに向けて、パーティショニングの仕組み・分割方式・よくある落とし穴を整理します。
目次
テーブルパーティショニングとは——1枚の巨大テーブルを物理的に分割する仕組み
テーブルパーティショニングとは、1つの論理的なテーブルを、内部的に複数の物理的な単位（パーティション）に分けて格納する仕組みです*1。アプリケーション側から見えるテーブルはひとつのままですが、データベースの内部では、日付や地域といったキーに沿って複数の実体に分かれて保存されます。
行数が数百万〜数億件に達し、テーブルのサイズがサーバーの搭載メモリを上回るような段階になると、パーティショニングの効果が表れやすくなります*1。逆に言えば、行数がさほど多くないうちに導入しても、複雑さが増すだけで恩恵は乏しいというのが実情です。
「テーブルが重いならインデックスを増やせばよいのでは」という声もよく聞きます。インデックスは特定の行を素早く探し当てるための仕組みであり、パーティショニングとは役割が異なるものです。テーブル自体の行数が膨大なままだと、インデックスの再構築や統計情報の更新といった保守作業そのものに時間がかかるようになり、インデックスを足すだけでは解決しない場面が出てきます。パーティショニングは、こうした「テーブルという入れ物そのものを小分けにする」発想でこの課題に対応します。
この記事のポイント
- テーブルパーティショニングは、1つのテーブルを複数の物理的な単位に分割して管理する仕組みです。
- 検索時に不要なパーティションを読み飛ばす「パーティションプルーニング」により、大規模テーブルでも検索範囲を絞り込めます*2。
- 複数のサーバーにデータを分散するシャーディングとは分割の単位が異なり、別レイヤの打ち手として扱います。
何が良くなるか——検索性能と保守性
パーティショニングを導入すると、主に次のような効果が期待できます。「速くなる」という一言で語られがちですが、実際には検索・削除・保守作業のそれぞれに、異なる角度で効果が及びます。
| 効果 | 内容 |
|---|---|
| 検索性能の向上 | 条件に合致するパーティションだけを読めばよくなり、無関係なパーティションの走査を避けられる*2。 |
| 削除・アーカイブの高速化 | 期間が過ぎたパーティションをまるごと切り離す操作は、行単位で削除するより短時間で終わる*1。 |
| 保守作業の分割 | インデックスの再構築や統計情報の更新を、パーティション単位で分けて進められる。 |
| ホット・コールドデータの分離 | 使用頻度の低い古いデータを、安価なストレージ層へ移す構成も取りやすくなる*1。 |
いずれも「テーブル全体を一度に扱わない」という発想が土台になっています。裏を返せば、検索条件が分割キーとかみ合っていない場合、得られる効果は限定的です。たとえば注文日を分割キーにしているのに、注文者IDだけで検索する処理が多いようなシステムでは、結局すべてのパーティションを読みに行くことになり、分割した恩恵をほとんど受けられません。分割キーは「どの列で分けられるか」ではなく「どの列で検索や削除をすることが多いか」を起点に決める視点が要ります。
分割方式——レンジ・リスト・ハッシュ
代表的な分割方式は、レンジ・リスト・ハッシュの3種類です*1*3。
| 方式 | 分け方 | 向くデータの例 |
|---|---|---|
| レンジ分割 | 値の範囲でパーティションを分ける | 注文日やログの発生日時など、時系列で増えていくデータ |
| リスト分割 | あらかじめ決めた値の集合でパーティションを分ける | 都道府県コードや契約プランなど、離散的な区分を持つデータ |
| ハッシュ分割 | キーの値をハッシュ関数にかけて機械的に振り分ける | 自然な範囲や区分がなく、書き込みを均等に分散させたいデータ |
どの方式にも共通するのは、「分割キーをどの列にするか」が設計の要になる点です。検索や集計でよく使われる条件の列を分割キーに選べば、次に説明するプルーニングの恩恵を受けやすくなります。MySQLも同様にレンジ・リスト・ハッシュに加えKEYパーティションといった方式を備えており、対応する分割方式は製品によって細部が異なります*3。
実務では、時系列で増え続けるログや取引データはレンジ分割、テナントや拠点ごとにデータを分けて管理したい場合はリスト分割、書き込みを均等にばらまきたいがレンジやリストで自然に分けられる列がない場合はハッシュ分割、というように選び分けるケースが多く見られます。レンジ分割は「古いパーティションをまるごと削除する」運用と相性がよい一方、ハッシュ分割は削除より分散そのものを目的にすることが多く、目的に応じて向き不向きが変わります。
図解：パーティションプルーニングの仕組み
パーティショニングの効果が分かりやすく体感できるのが、パーティションプルーニングです*2。クエリのWHERE句が分割キーに対する条件を含んでいると、データベースの実行計画はどのパーティションを読む必要があるかを判定し、対象外のパーティションを走査の計画から外します*2。
図のように、分割キーである注文日が2026年を指す条件のクエリは、2026年分のパーティションだけを読みに行き、2024年・2025年分のパーティションは走査の対象から外れます。テーブル全体を毎回なめるのに比べ、読み込む範囲を絞り込める分だけ検索の負荷が下がる、というのがプルーニングの基本的な考え方です。
シャーディングとの違い——分割の単位はテーブルか、サーバーか
パーティショニングとよく混同される仕組みに、シャーディングがあります。両者は「データを分割する」という発想は共通していますが、分割の単位が異なります。
| 観点 | パーティショニング | シャーディング |
|---|---|---|
| 分割の単位 | 1つのデータベースインスタンス内でテーブルを分割する | データそのものを複数の独立したデータベースサーバーに分散させる |
| 書き込みの負荷分散 | 単一インスタンスの範囲にとどまる | サーバーを増やすことで書き込みも含めて分散できる |
| 構成の複雑さ | 比較的小さな変更で導入しやすい | アプリケーション側の接続振り分けなど設計変更が広がりやすい |
読み取りの負荷分散であればリードレプリカ、書き込みも含めてサーバー単位で分散したい場合はシャーディング、1台のデータベースの中でテーブルの扱いを整理したい場合はパーティショニング——課題に応じてこう使い分けるのが基本の考え方です。実際のシステムでは、この3つは排他的な選択肢ではなく、組み合わせて使われることも珍しくありません。たとえば、シャーディングで複数のサーバーにデータを分散させたうえで、各サーバー内のテーブルをさらにパーティショニングで整理する、といった二段構えの構成も見られます。
どこまでの規模を見込むかによって、必要な打ち手は変わります。当面は1台のデータベースで十分見通せる規模であれば、まずはパーティショニングで整理し、将来的に書き込みの負荷がボトルネックになった段階でシャーディングを検討する、という段階的な進め方が現実的です。最初から複数サーバーへの分散を前提に設計を組み立てると、開発と運用の両面で負担が大きくなりやすい点には注意が要ります。
導入・運用の勘所と外注時の確認点
パーティショニングは効果の大きい打ち手ですが、設計を誤ると逆効果になることもあります。分割キーの選び方を誤ると特定のパーティションだけにデータが偏り、分割した意味合いが薄くなりがちです。パーティションの数を増やしすぎると、実行計画を組み立てる際の負担が増え、かえって性能が落ちる場合もあるので注意が要ります。既存の大規模テーブルを後からパーティション化する際は一括での移行が難しいことが多く、新しいテーブルへ段階的にデータを移し替える作業が発生しがちです。
運用に入ってからも気を配りたい点があります。レンジ分割で日付を分割キーにしている場合、将来の期間を受け止めるパーティションを事前に用意しておかないと、想定外の日付のデータが行き場を失ってエラーになることがあります。多くの現場では、月次や年次のバッチ処理で新しいパーティションを先回りして作成し、あわせて古くなったパーティションを切り離すといった運用の自動化が一般的です。手作業に頼る運用にしてしまうと、担当者の異動や引き継ぎ漏れをきっかけに、パーティションの追加が止まってしまうリスクも抱えることになります。
外部へ委託する場合は、次の点をすり合わせておくとよいでしょう。どの列を分割キーに選ぶか、想定する検索条件が分割キーとかみ合っているか、既存テーブルを移行する場合の手順と停止時間をどう見積もるか、そしてパーティション数が増えた際の運用（追加・削除の自動化を含む）をどう設計するか——このあたりを最初に整理しておくと、導入後の手戻りを防ぎやすくなります。
まとめ：パーティショニングで押さえる3つの判断軸
パーティショニングは、大規模テーブルの検索性能と保守性を両立させるための代表的な打ち手です。導入を検討する際は、3つの軸で整理すると判断しやすくなります。第一に、テーブルのサイズや行数が、分割を検討するに値する規模になっているかどうか。第二に、検索や削除の条件が分割キーとかみ合っているか。かみ合っていなければプルーニングの恩恵は限られます。第三に、シャーディングとの役割分担です。書き込みの負荷まで分散させたいのか、1台のデータベースの中で整理したいのかを切り分けます。この3点を押さえれば、パーティショニングは大規模データベースの運用を支える手段として機能します。
導入は一度きりの作業では終わりません。データが増え続ける限り、パーティションの追加や古いパーティションの整理といった運用がずっと続くものです。設計の段階で、誰がどのタイミングでこの運用を担うのかまで決めておくと、導入後に形骸化させずに済みます。テーブル設計や運用に迷いがあれば、現状整理の段階から外部の知見を借りるのもひとつの方法です。
よくある質問
パーティショニングを導入すれば、どんなテーブルでも速くなりますか。
いいえ。検索や削除の条件が分割キーとかみ合っている場合に効果が出ます。かみ合っていない条件で検索すると、多くのパーティションを読みに行くことになり、恩恵は限られます。
パーティションの数はどのくらいが目安ですか。
データの量や増え方によって変わり、一律の基準はありません。パーティションを増やしすぎると実行計画の負担が増えるため、分割キーの単位（月次・年次など）を検索パターンに合わせて決めることが現実的です。
既存の大きなテーブルを後からパーティション化できますか。
製品や状況によりますが、一括での変換が難しいことが多く、新しいパーティション構成のテーブルを用意してデータを段階的に移し替える手順を取るのが一般的です。移行中の停止時間や整合性の確保を事前に設計しておく必要があります。
シャーディングを導入すれば、パーティショニングは不要になりますか。
目的が異なるため、単純な置き換えにはなりません。書き込みも含めた負荷分散はシャーディングの役割ですが、1台のデータベースの中でテーブルを整理する用途ではパーティショニングが引き続き有効です。両方を組み合わせる構成も見られます。
外注する場合、何を確認すればよいですか。
分割キーの選び方、想定する検索条件との整合、既存テーブルを移行する場合の手順と停止時間、パーティション数が増えた際の運用設計——この4点を最初に確認しておくと、認識のずれを防ぎやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・データベース設計のご相談はLASSICへ
元請（プライムベンダー）として、負荷の切り分けから設計・実装・運用まで、貴社の課題に合わせてご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：PostgreSQL「Table Partitioning」（PostgreSQL Documentation）（https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-OVERVIEW）
- *2 出典：PostgreSQL「Partition Pruning」（PostgreSQL Documentation）（https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING）
- *3 出典：Oracle「MySQL 8.0 Reference Manual: Partitioning Types」（https://dev.mysql.com/doc/refman/8.0/en/partitioning-types.html）
