フェデレーション(機能別分割)

たとえ話: 部署ごとにファイルキャビネットを分ける

会社の書類を全部1つの巨大キャビネット(=1つのDB)に詰め込むと、誰かが開けるたびに混雑します。そこで人事の書類は人事のキャビネット、経理は経理のキャビネット…と機能ごとに分けます。

すると、人事と経理は別々のキャビネットを同時に使えて競合しません。各キャビネットは中身が減って探すのも速い。これがFederation(機能別分割)です。

図を描画中...

なぜ速くなるのか

• 各DBのデータ量が減る → インデックスが小さくなり検索が速い。
• 書き込みが分散 → ユーザー更新と商品更新が別DBで並行に走り、競合しない。
• 中央マスターがない → ボトルネックが消える。
• キャッシュの局所性 → 機能ごとにアクセスが集中するのでキャッシュが効きやすい。

Sharding との違い(混同注意)

ここは超重要な区別です。

	Federation	Sharding
分け方	機能(テーブルの種類)で分ける	同じテーブルを行で分ける
例	usersテーブルとproductsテーブルを別DBに	1つのusersテーブルを『A〜M』『N〜Z』で別DBに
効く相手	機能が複数あって偏っていない	1つのテーブルが巨大すぎる

Federationは『テーブルの種類』で縦に切り、Shardingは『同じテーブルの行』で横に切る、と覚えると整理できます。

つまずきポイント

• 1つの機能(例: usersテーブル)だけが巨大化している場合、Federationでは分割できない。そういうときはSharding。
• DBをまたぐJOIN(例: ユーザーと商品を結合)ができなくなる。アプリ側で2回問い合わせて結合する等の工夫が必要。

---

📊 図解

図解: 1つの巨大DBを機能別に分割

1つの巨大DBを users / products / forums のように機能(テーブルの種類)で縦に分割する。各DBが小さくなり、書き込みも分散して競合しにくくなる。

図を描画中...