【入門編】 Citusによる分散テーブル – PostgreSQL

こんにちは！データベースの世界に飛び込んで、日夜クエリと格闘している皆さん、お疲れ様です。

今日は、PostgreSQLを「スーパーマシン」に変身させる強力な拡張機能「Citus（サイタス）」についてお話しします。名前は聞いたことがあるけれど、「分散とかシャードとか、なんだか難しそう……」と敬遠していませんか？

大丈夫です。今日は専門用語を置いておいて、ある「図書館」の話をしましょう。

—

想像してみてください。あなたは巨大な図書館の司書さんです。本は数百万冊、毎日何千人もの利用者がやってきます。

最初は一人の司書（PostgreSQL単体）が頑張って対応していました。でも、本が増えすぎて、司書さんが本を探すのに一日中走り回るようになり、ついにパンクしてしまいました。

そこで、「じゃあ、図書館を増築して、司書さんも増やそう！」と決めたのが「Citus」という考え方です。

複数の図書館（サーバー）を並べて、みんなで分担して作業する。これが「分散データベース」の基本です。でも、ここで一つ大きな問題が発生します。

「どの本を、どの図書館に置けばいいの？」

—

ここがCitusの腕の見せ所です。Citusでは、データをどの場所に振り分けるかを決めるための鍵、つまり「シャードキー」というものを設定します。

これは、図書館でいうところの「分類ルール」のようなものです。

例えば、図書館の利用者が「自分の借りている本」を検索するとき、もし「会員番号」というルールで本を振り分けていれば、司書さんは「会員番号がAの人は、あの図書館ね！」と一瞬で判断できますよね。

これが「理想的なシャードキー」です。

逆に、もし「本のタイトル」で適当に振り分けていたらどうでしょう？利用者が自分の本を探すたびに、司書さんは「えーっと、A館にあるかな？ B館かな？いや、C館かも…」と、すべての図書館に聞き込みに行かないといけません。これだと、せっかく図書館を増やしたのに、かえって遅くなってしまいますよね。

—

Citusでテーブルを設計するとき、この「仕分けルール（シャードキー）」をどう決めるか。現場でよく意識しているポイントを3つだけ紹介しますね。

例えば、「ユーザー」とそのユーザーの「注文履歴」は、いつもセットで検索しますよね。なら、両方とも「ユーザーID」で仕分けしておくと、一つの図書館だけで完結するのでめちゃくちゃ速いです。

特定の図書館ばかりにお客さんが殺到して、他の図書館がガラガラ……という状況は避けたいですよね。できるだけ均等にデータが散らばるようなキーを選ぶのがコツです。

一度「会員番号で分ける！」と決めたルールを後から「やっぱり本のジャンルで分ける！」と変えるのは、引っ越し作業と同じくらい大変です。設計段階で「このデータは将来、どう検索されることが多いかな？」と想像を膨らませておくのが、一番の近道ですよ。

—

データモデリングをしていると、「これで本当に正解かな？」と不安になることもあると思います。でも、最初は「まずはここを基準に振り分けてみよう」という仮説で全然OKなんです。

実際に運用してみて、「あれ、意外とこっちの検索が重いな」と気づいたら、そこから少しずつ最適化していけばいい。データベースは、皆さんの成長に合わせて一緒に育っていく生き物のようなものですから。

Citusは、皆さんの「データという名の本」を整理して、爆速で届けてくれる頼もしい相棒です。ぜひ、怖がらずにその扉を叩いてみてくださいね！

また次の記事でお会いしましょう！Happy Querying！