資料庫 Sharding 與讀寫分離
水平擴展的關鍵決策

單台 PostgreSQL 的極限（以中端伺服器為基準）：

  Write 瓶頸：約 10,000 TPS（transactions per second）
              超過後，磁碟 I/O 和鎖定競爭會讓效能斷崖式下滑

  Storage 瓶頸：單台伺服器磁碟大小
               即便用 NVMe SSD，單台通常也難超過 100TB
               且磁碟越大，備份與恢復時間越長

  Read 瓶頸：CPU 核心數與記憶體大小有限
             更多連線 → Context Switching 增加 → 整體吞吐量下降

  Connection 瓶頸：PostgreSQL 每個連線都是獨立 Process
                  超過 500 並發連線後，系統資源消耗顯著上升
                  （PgBouncer 可緩解，但不能根本解決）

Primary（主節點）→ 負責所有 Write（INSERT / UPDATE / DELETE）
    │
    └── 非同步複製（Async Replication）
        │
        ├── Replica 1（副節點）→ 處理 Read 請求
        ├── Replica 2（副節點）→ 處理 Read 請求
        └── Replica 3（副節點）→ 處理 Read 請求

80/20 法則：
  一般的 Web 應用，約 80% 的操作是讀取（查詢列表、取得詳情...）
  只有 20% 是寫入（建立帳號、下訂單、更新狀態...）

  → 把 80% 的流量分散到多個 Replica，主節點只承擔 20% 的寫入壓力
  → Read 效能可以近乎線性地水平擴展，只要加 Replica 即可

// lib/prisma.ts
import { PrismaClient } from '@prisma/client';

// Primary（寫入節點）
export const primaryDB = new PrismaClient({
  datasources: {
    db: { url: process.env.DATABASE_PRIMARY_URL },
  },
});

// Replica 連線池（多個副節點，可做 Round-Robin 負載均衡）
const replicas = [
  new PrismaClient({
    datasources: { db: { url: process.env.DATABASE_REPLICA_1_URL } },
  }),
  new PrismaClient({
    datasources: { db: { url: process.env.DATABASE_REPLICA_2_URL } },
  }),
  new PrismaClient({
    datasources: { db: { url: process.env.DATABASE_REPLICA_3_URL } },
  }),
];

let replicaIndex = 0;

// Round-Robin 選取 Replica
export function getReadDB(): PrismaClient {
  const db = replicas[replicaIndex % replicas.length];
  replicaIndex++;
  return db;
}

// ─── 使用方式 ───────────────────────────────────────────

// 寫入操作 → 一律走 primaryDB
export async function createUser(data: CreateUserInput) {
  return await primaryDB.user.create({ data });
}

export async function updateUserProfile(userId: string, data: UpdateUserInput) {
  return await primaryDB.user.update({
    where: { id: userId },
    data,
  });
}

// 讀取操作 → 走 Replica（getReadDB()）
export async function getActiveUsers() {
  return await getReadDB().user.findMany({
    where: { active: true },
    orderBy: { createdAt: 'desc' },
  });
}

export async function getUserById(id: string) {
  return await getReadDB().user.findUnique({
    where: { id },
  });
}

沒有 Sharding（單台 DB）：
  ┌─────────────────────────────────────┐
  │  users 表：1 億筆資料（全在一台機器）  │
  │  寫入壓力集中 → 成為系統瓶頸          │
  └─────────────────────────────────────┘

有 Sharding（4 個 Shard）：
  ┌──────────────────────┐
  │  Shard 0（DB 機器 0）  │  → userId % 4 == 0 的用戶（2,500 萬筆）
  └──────────────────────┘
  ┌──────────────────────┐
  │  Shard 1（DB 機器 1）  │  → userId % 4 == 1 的用戶（2,500 萬筆）
  └──────────────────────┘
  ┌──────────────────────┐
  │  Shard 2（DB 機器 2）  │  → userId % 4 == 2 的用戶（2,500 萬筆）
  └──────────────────────┘
  ┌──────────────────────┐
  │  Shard 3（DB 機器 3）  │  → userId % 4 == 3 的用戶（2,500 萬筆）
  └──────────────────────┘

效果：
  寫入壓力分散到 4 台機器 → 理論上 Write 吞吐量 ×4
  每台機器只存 1/4 的資料 → Storage 問題解決
  每個 Shard 可以再加 Replica → Read 進一步擴展

// lib/sharding.ts
import { PrismaClient } from '@prisma/client';

const NUM_SHARDS = 4;

// 每個 Shard 對應一台獨立的 DB 伺服器
const shards: PrismaClient[] = [
  new PrismaClient({ datasources: { db: { url: process.env.DB_SHARD_0_URL } } }),
  new PrismaClient({ datasources: { db: { url: process.env.DB_SHARD_1_URL } } }),
  new PrismaClient({ datasources: { db: { url: process.env.DB_SHARD_2_URL } } }),
  new PrismaClient({ datasources: { db: { url: process.env.DB_SHARD_3_URL } } }),
];

// Shard 路由：根據 userId 決定要查哪台 DB
export function getShardByUserId(userId: number): PrismaClient {
  const shardIndex = userId % NUM_SHARDS;
  return shards[shardIndex];
}

// 使用範例
export async function getUserById(userId: number) {
  const shard = getShardByUserId(userId);  // 自動路由到正確的 Shard
  return await shard.user.findUnique({ where: { id: userId } });
}

export async function createUser(data: CreateUserInput) {
  // 假設 userId 由應用層生成（Snowflake ID 或 UUID）
  const userId = generateUserId();
  const shard = getShardByUserId(userId);
  return await shard.user.create({ data: { ...data, id: userId } });
}

-- 在 Sharding 前，這個查詢很簡單、很正常
SELECT
  u.name,
  u.email,
  o.order_id,
  o.total_amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.id = 12345;

-- 在 Sharding 後...
-- users 表按 userId 分片：
--   userId 12345 → userId % 4 = 1 → 在 Shard 1
-- orders 表按 orderId 分片（不是 userId）：
--   orderId 的 Shard 可能是 0、1、2、3 都有...
--
-- → 你無法在單台 DB 上執行這個 JOIN！
-- → 跨 Shard JOIN 在分散式資料庫中幾乎不可能高效實作