こんにちは！データベースの世界へようこそ。
普段、何気なく使っているデータベースですが、実はその中身が「どうやってデータを保管しているか」を少し覗いてみると、データの処理速度が劇的に変わる魔法のような仕組みが見えてくるんです。
今日は、PostgreSQLの話を交えながら、「行指向」と「列指向」というちょっと小難しい仕組みを、日常の例えで紐解いていこうと思います。
—
1. 毎日の買い出しで例えてみよう
みなさん、スーパーで買い物に行くときを想像してみてください。
行指向（Heap）は「お買い物カゴ」
行指向のストレージは、私たちが普段スーパーでするお買い物と同じです。
お菓子、洗剤、野菜……と、バラバラな商品を一つのカゴ（1行）にまとめてレジに持っていきますよね。
- メリット： 「特定の1人（1件）のデータ」を全部まとめて取り出すときは、このカゴごと取ればいいのでめちゃくちゃ速いんです。
- 苦手なこと： もし、「店内のすべてのお菓子の合計金額を知りたい」と思ったらどうでしょう？ 全てのカゴを一つずつ覗き込んで、お菓子を探し出さなきゃいけませんよね。これって、すごく時間がかかりませんか？
列指向（Columnar）は「専門の棚」
一方で列指向は、倉庫のような状態です。
「お菓子コーナー」「野菜コーナー」「洗剤コーナー」というふうに、同じ種類のものだけがずらーっと並んでいます。
- メリット： 「お菓子全部の金額を知りたい！」と思ったら、お菓子コーナーに行くだけで済みます。他の余計なもの（野菜や洗剤）を見る必要がないので、めちゃくちゃ効率がいいんです。
- 苦手なこと： 逆に、「田中さんの買い物カゴの中身を全部教えて」と言われたら、あちこちの棚を走り回って集めないといけないので、ちょっと大変ですよね。
—
2. なぜ「分析」には列指向が最強なの？
PostgreSQLのようなデータベースで、大量のデータを集計してグラフを作ったり、レポートを出したりする「分析クエリ」を実行するとき、なぜ列指向が有利なのか。そこには2つの大きな理由があります。
I/O（読み込み）のムダを省く
先ほどのお買い物で例えたように、列指向だと「必要なデータだけ」をピンポイントで読み込めます。
例えば、「売上」という列の合計を出したいだけなのに、関係のない「住所」や「名前」といったデータまで一緒に読み込むのは、電気代と時間のムダですよね。列指向なら、必要な列だけをサッと拾い上げるので、ディスクへの負担が驚くほど減るんです。
圧縮効率が段違い！
ここが一番面白いポイントです。
同じ種類のデータ（例えば「商品カテゴリ」の列など）が並んでいると、データには「似たような値」が多く含まれます。「お菓子、お菓子、お菓子、パン……」という並びなら、「お菓子が3回続く」と記録したほうが、ずっとコンパクトですよね。
このように、同じ性質のデータが並んでいると、ギュッと小さく圧縮できるんです。小さくなれば、それだけ運ぶのも速くなる。これが、分析クエリが爆速になるメカニズムです。
—
3. まとめ：使い分けがプロの腕の見せどころ
ここまで読んで、「じゃあ全部列指向にすればいいじゃん！」と思った方もいるかもしれません。でも、世の中そんなに甘くないのが面白いところ。
- 行指向： 1件ずつデータを追加したり、更新したり、特定のIDで検索したりする「日々の業務（トランザクション処理）」が得意。
- 列指向： 大量のデータをまとめて計算して、傾向を分析する「経営判断（分析処理）」が得意。
PostgreSQLは伝統的に「行指向」がメインですが、最近では拡張機能（citusなど）を使って、この「列指向」のいいとこ取りをできるようになっています。
「今扱っているデータは、1件ずつ丁寧に見たいものかな？ それとも、まとめて分析したいものかな？」
そうやってデータの性格を考えて設計できるようになると、データベースエンジニアとしての視界が一気に開けてきますよ。ぜひ、皆さんのプロジェクトでも意識してみてくださいね！
それでは、また次回のブログでお会いしましょう。ハッピー・クエリライフを！
コメント