【テクニカル・上級編】 Citusによる分散テーブル – PostgreSQL

PostgreSQLを愛するエンジニア諸氏にとって、「単一インスタンスの限界」というのは、一度は直面する、あるいはいつか必ず訪れる必然的な壁ですよね。垂直スケール（スケールアップ）に限界を感じ、いよいよシャーディングを検討し始めたとき、真っ先に候補に挙がるのが『Citus』でしょう。

PostgreSQLの拡張機能として、クエリエンジンをそのままに分散環境を実現するCitusは非常に強力です。しかし、Citusを導入すれば「魔法のように全てが解決する」わけではありません。むしろ、分散データベースの世界では、設計の良し悪しがシステムの生死を分けることになります。

今日は、私がこれまで多くの現場で見てきた「Citusにおける分散テーブル設計の勘所」について、少し深い話をしようと思います。

—

Citusにおいて最も重要な決定事項、それは間違いなく「ディストリビューションカラム（シャードキー）」の選定です。ここを間違えると、どんなに強力なインフラを組んでも、システムは悲鳴を上げます。

シャードキーとして「不適切なカラム」を選んでしまうと、特定のノードにデータが集中する「データスキュー」が発生します。例えば、`tenant_id`が特定の巨大企業に偏っている場合、そのノードだけがディスクI/OとCPUでパンクします。

教訓： Cardinality（値の多様性）が高いカラムを選ぶのが鉄則です。もし特定のキーに負荷が偏ることが避けられないのであれば、ハッシュ分散の特性を活かしつつ、アプリケーション層でのハッシュ化や、複数のカラムを組み合わせた複合キーの検討も視野に入れるべきです。

Citusの真骨頂は、分散ノード間でネットワークトラフィックを発生させずに結合を行う「コ・ロケーション（Co-location）」です。

もし`orders`テーブルと`line_items`テーブルを結合する頻度が高いなら、両者を`order_id`で同じシャードキーとして分散させる必要があります。これが揃っていないと、クエリのたびにワーカーノード間でデータを転送し合う「ネットワークシャッフル」が発生し、レイテンシは目に見えて跳ね上がります。

—

Citusのクエリ実行エンジンは、基本的にはPostgreSQLのExecutorを拡張したものです。しかし、分散環境特有の「オーケストレーション」には注意が必要です。

Citusは、ユーザーが投げたクエリを解析し、ワーカーノードへプッシュダウン可能なクエリに変換します。ここで厄介なのが、複雑な副問い合わせやJOINが含まれる場合です。

トラブルシューティングのヒント： `EXPLAIN`コマンドを叩いて、実行計画が「どのノードで何が行われているか」を詳細に追ってください。特に `Distributed Query` や `Remote Scan` と表示されている箇所は要注意です。ここで発生するネットワークコストを甘く見てはいけません。
インデックスの最適化： 当然ですが、ワーカーノード上の各ローカルテーブルに対して、適切なインデックスが貼られているかを確認してください。分散環境といえど、結局は各ノードのPostgreSQLがフルスキャンを避けるよう設計しなければ、分散の意味がありません。

—

分散データベースの運用でよくある失敗は、「PostgreSQLと同じ感覚で運用してしまう」ことです。

統計情報の更新： `ANALYZE`は、分散されたテーブルそれぞれに対して適切に行われる必要があります。統計情報が古いと、Citusのクエリオプティマイザが誤った実行計画を選択し、壊滅的な性能劣化を招きます。
コネクション管理： Citusはワーカーノードに対して接続を張ります。マスターノード側の `max_connections` だけでなく、ワーカーノード側の接続数も考慮したコネクションプーリング（pgbouncerの活用など）は必須です。

—

Citusで分散テーブルを設計する際、最初から「完璧なスキーマ」を作るのは極めて困難です。まずは「どのクエリが最も頻繁に走り、どの結合がボトルネックになっているか」という、地に足の着いた観察から始めてください。

PostgreSQLという偉大な基盤の上に、Citusという翼を授ける。その設計の過程で、皆さんがデータの流れをより深く理解し、システムをより洗練されたものへと昇華させることを楽しみにしています。

技術の深淵は常に足元にあります。さあ、次はどのクエリを最適化しましょうか？