こんにちは！データベースの世界へようこそ。
今日は、PostgreSQLを触っていると一度は耳にする（そして、多くのエンジニアを悩ませる）「work_mem（ワークメモリ）」という設定についてお話しします。
「メモリ？設定？なんだか難しそう……」と思った方も安心してください。難しい専門用語はなるべく置いておいて、まずは日常の「ある作業」に例えて考えてみましょう。
—
料理で例える「work_mem」の正体
想像してみてください。あなたは今、キッチンで大勢のパーティー料理を作っているとします。
- メインメモリ（RAM）：広々とした「作業台」
- ディスク（HDD/SSD）：キッチンから遠く離れた「パントリー（貯蔵庫）」
- work_mem：まな板の上で一度に広げられる「スペースの広さ」
PostgreSQLが「データの並べ替え」や「結合」を行うとき、この「まな板の上（work_mem）」で作業をします。
もし、100人分の野菜を刻むのに、まな板が十分な広さ（work_memが適切）なら、あなたは一気に野菜を広げて、テキパキと調理できますよね。これが理想の状態です。
でも、もしまな板が小さすぎたらどうなるでしょう？
一度に全部広げられないので、半分はキッチンから遠い「パントリー（ディスク）」に置きに行き、また戻ってきて残りを……という作業を繰り返すことになります。
これ、めちゃくちゃ時間がかかりますよね？
PostgreSQLの世界でも全く同じことが起きています。「work_mem」が足りないと、データベースはわざわざ遅いディスクにデータを一時的に書き出し（一時ファイル）、読み込み直すという「お使い」を繰り返すことになります。これが、クエリが遅くなる大きな原因の一つなんです。
—
どんなときに「メモリ不足」を感じるの？
PostgreSQLは、普段はとても賢いので、自動でいい感じに動いてくれます。でも、以下のような場面で「まな板が足りないよ！」という悲鳴を上げることがあります。
- ものすごく巨大なデータを並べ替えるとき（ORDER BYなど）
- 複雑な条件でテーブル同士をくっつけるとき（JOINなど）
もし、システムを使っていて「特定の検索だけやたらと時間がかかるな？」と感じたら、それはデータベースがディスクという名の遠いパントリーに何度も走らされている証拠かもしれません。
—
じゃあ、work_memを大きくすればいいの？
「じゃあ、まな板（work_mem）を無限に大きくすれば解決じゃん！」と思いますよね。
ここが落とし穴なんです。
キッチン（サーバー）の広さ（物理メモリ）には限界があります。
全員分のまな板を巨大にしすぎると、キッチンがまな板で埋め尽くされて、食材を置く場所も、動くスペースもなくなってしまいますよね。これと同じで、work_memを大きくしすぎると、最悪の場合「メモリ不足」でサーバー自体がダウンしてしまいます。
大切なのは、「自分のキッチン（サーバー）の広さと、一度に何人が料理（クエリ）をするか」のバランスを見ることです。
—
最初の第一歩：まずは「知る」ことから
いきなり設定値をいじる必要はありません。まずは、自分のデータベースが「お使い」に走っていないかを確認してみましょう。
PostgreSQLには、実行したクエリが「一時ファイル（ディスク）を使ったかどうか」を教えてくれる便利な機能があります。
— クエリの実行計画を見てみましょう
EXPLAIN ANALYZE SELECT … (あなたのクエリ);
この結果の中に「Disk: …kB」といった表記が出てきたら、それが「パントリーまで走った証拠」です。
—
最後に：焦らず、少しずつ
データベースのチューニングは、料理の味付けと同じです。一気に大量の塩を入れるのではなく、少しずつ調整して、味（性能）の変化を見守るのがコツですよ。
最初は「work_memって、作業台の広さのことなんだな」とイメージするだけで十分です。そこから少しずつ、「今のクエリは重いかな？」「メモリは足りているかな？」と想像を巡らせるだけで、あなたのデータベースエンジニアとしての視点は格段に鋭くなっています。
もし今、クエリの遅さに悩んでいるなら、まずはそのクエリが「どこでつまずいているのか」を調べてみてくださいね。応援しています！
それでは、また次回の記事でお会いしましょう！
コメント