こんにちは！データベースの世界へようこそ。
今日は、PostgreSQLの「パーティショニング」という、ちょっとカッコよくて便利なテクニックについてお話ししますね。
「データベースが大きくなると動きが重くなる……」というのは、エンジニアなら誰もが一度はぶつかる壁です。そんなとき、このパーティショニングという技を知っているだけで、システムをまるで魔法のように軽くできることがあるんです。
専門用語を並べるのは一旦置いておいて、まずは日常の「ある光景」から想像してみましょう。
—
本棚を整理する「魔法の仕分け術」
想像してみてください。あなたは、何万冊もの本が積み上げられた巨大な図書館の司書さんです。
誰かが「あの本、どこにある？」と聞きに来たとき、適当に積み上げられた山から探すのは至難の業ですよね？探すだけで日が暮れてしまいます。
そこで、あなたは本棚を整理することにしました。
1. 「出版年」で分ける（RANGEパーティショニング）
「2020年〜2023年の棚」「2024年の棚」のように、時期で区切ります。最新の資料が読みたい人は、迷わず「2024年の棚」に行けばいいですよね。
2. 「ジャンル」で分ける（LISTパーティショニング）
「技術書」「小説」「漫画」のように、カテゴリーで棚を分けます。「小説が読みたい！」と言われたら、小説の棚に直行すればOK。
3. 「背表紙の番号」で分ける（HASHパーティショニング）
これはちょっと特殊ですが、本に書かれた番号を一定のルールで計算して、機械的に棚を割り振ります。「均等に分散させる」のが目的ですね。
これが、データベースにおける「パーティショニング」の正体です。巨大な一つのテーブルを、管理しやすい小さな「棚（パーティション）」に切り分けることなんです。
—
なぜ、これで速くなるの？「パーティションプルーニング」
さて、ここからが本題です。「棚を分けただけじゃ、結局全部の棚を探すんじゃないの？」と思いますよね。
ここで登場するのが「パーティションプルーニング」という賢い機能です。
「プルーニング」とは、園芸用語で「枝の剪定」という意味。つまり、「不要な棚をバッサリ切り捨てる」ことなんです。
例えば、「2024年の本」を探すとき、PostgreSQLはこう考えます。
「あ、ユーザーは2024年の本が欲しいんだな。じゃあ、2020年〜2023年の棚は一切見なくていいや！」
この「見なくていい場所を無視する」動きのおかげで、データベースは無駄な探索をせずに、必要なデータに最短距離でたどり着けるんです。これが、クエリが劇的に速くなる秘密ですよ。
—
PostgreSQLで実際に書いてみよう
PostgreSQLでは、親テーブルを先に作って、そこに「子テーブル（棚）」をぶら下げるイメージで書きます。
1. RANGEパーティショニング（時期などで区切る）
— 親テーブル（棚の設計図）
CREATE TABLE logs (
id serial,
created_at timestamp,
message text
) PARTITION BY RANGE (created_at);
— 子テーブル（具体的な棚）
CREATE TABLE logs_2023 PARTITION OF logs
FOR VALUES FROM (‘2023-01-01’) TO (‘2024-01-01’);
2. LISTパーティショニング（分類で区切る）
CREATE TABLE users (
id serial,
region text,
name text
) PARTITION BY LIST (region);
— 「東京」と「大阪」で棚を分ける
CREATE TABLE users_tokyo PARTITION OF users FOR VALUES IN (‘Tokyo’);
CREATE TABLE users_osaka PARTITION OF users FOR VALUES IN (‘Osaka’);
—
最後に：使いどきの見極め
ここまで聞くと「全部パーティショニングすれば最強じゃん！」と思うかもしれませんが、ちょっと待ってくださいね。
この技は、「データが数百万件、数千万件と増えてきて、検索が遅いなと感じたとき」に初めて輝くものです。数千件しかないデータでやってしまうと、逆に管理が面倒になるだけかもしれません。
「おっ、うちのデータベース、最近ちょっとお疲れ気味かな？」と思ったら、ぜひこの「本棚の整理術」を思い出してみてください。
データベースの設計は、まるで家の片付けや模様替えに似ています。少しずつ整理整頓をしていくことで、システムはもっと長く、快適に走り続けてくれますよ。
また次の記事でお会いしましょう！応援しています！
コメント