リアルタイム性が求められる部分とメッセージの永続化で異なるストアを使い分けることを検討しよう。

選定:

• メッセージ永続化: MongoDB（柔軟なスキーマ、大量書き込み）
• リアルタイム配信: Redis Pub/Sub（低レイテンシ通知）
• 既読管理: Redis Hash（高頻度更新）

MongoDBモデル:

// チャットルーム
{
  _id: ObjectId("room1"),
  type: "group",              // "direct" | "group"
  name: "開発チーム",
  members: [
    { userId: "user1", joinedAt: ISODate("2024-01-01"), role: "admin" },
    { userId: "user2", joinedAt: ISODate("2024-01-02"), role: "member" }
  ],
  lastMessage: {
    body: "了解です！",
    senderId: "user2",
    sentAt: ISODate("2024-03-15T10:30:00Z")
  },
  createdAt: ISODate("2024-01-01")
}

// メッセージ
{
  _id: ObjectId("msg1"),
  roomId: ObjectId("room1"),
  senderId: "user1",
  body: "ミーティング開始します",
  type: "text",               // "text" | "image" | "file"
  sentAt: ISODate("2024-03-15T10:00:00Z")
}

// インデックス
db.messages.createIndex({ roomId: 1, sentAt: -1 });
db.messages.createIndex({ body: "text" });  // 全文検索
db.rooms.createIndex({ "members.userId": 1 });

Redis（既読管理）:

HSET read:room1:user1 lastRead "2024-03-15T10:30:00Z"
HSET read:room1:user2 lastRead "2024-03-15T10:25:00Z"

選定理由: メッセージは構造が柔軟（テキスト、画像、ファイルなど）でJOINが少なく、大量書き込みが必要なためMongoDB。リアルタイム性はRedis Pub/Subで担保。

商品カタログと注文処理で求められる特性が異なることに注目しよう。

選定:

• 商品カタログ: MongoDB（柔軟な属性スキーマ）+ Redis（キャッシュ）
• 在庫・注文: PostgreSQL（トランザクション必須）

MongoDBモデル（商品カタログ）:

// 商品（カテゴリによって属性が異なる）
{
  _id: ObjectId("prod1"),
  name: "TypeScript入門Tシャツ",
  category: "clothing",
  price: 3500,
  images: ["/img/tshirt1.jpg", "/img/tshirt2.jpg"],
  attributes: {
    size: ["S", "M", "L", "XL"],
    color: ["white", "black", "navy"],
    material: "cotton"
  },
  description: "...",
  rating: { average: 4.5, count: 128 }
}

{
  _id: ObjectId("prod2"),
  name: "ゲーミングPC X1",
  category: "electronics",
  price: 250000,
  images: ["/img/pc1.jpg"],
  attributes: {
    cpu: "Intel i9-14900K",
    memory: "64GB DDR5",
    storage: "2TB NVMe SSD",
    gpu: "RTX 4090"
  },
  description: "...",
  rating: { average: 4.8, count: 42 }
}

// インデックス
db.products.createIndex({ category: 1, price: 1 });
db.products.createIndex({ "attributes.size": 1 });
db.products.createIndex({ "attributes.cpu": 1 });

PostgreSQL（在庫・注文）:

CREATE TABLE inventory (
  product_id VARCHAR(24) PRIMARY KEY,
  stock INT NOT NULL CHECK (stock >= 0),
  reserved INT NOT NULL DEFAULT 0
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT NOT NULL,
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  total DECIMAL(12,2) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

選定理由: 商品属性がカテゴリにより異なるためMongoDBが適切。在庫と注文はACIDトランザクションが必須なためPostgreSQL。

「友達の友達」のような多段の関係探索に強いデータストアを検討しよう。

選定:

• フォロー関係・推薦: Neo4j（グラフ探索に特化）
• フォロー数カウンター: Redis（高頻度更新）

Neo4jモデル:

// ノード: ユーザー
CREATE (u:User {id: "user1", name: "田中太郎"})
CREATE (u:User {id: "user2", name: "佐藤花子"})

// リレーション: フォロー
CREATE (u1)-[:FOLLOWS {since: datetime("2024-01-15")}]->(u2)

// フォロワー一覧
MATCH (u:User {id: "user1"})<-[:FOLLOWS]-(follower)
RETURN follower.name

// 友達の友達（推薦）
MATCH (me:User {id: "user1"})-[:FOLLOWS]->(friend)-[:FOLLOWS]->(suggestion)
WHERE NOT (me)-[:FOLLOWS]->(suggestion) AND suggestion <> me
RETURN suggestion.name, COUNT(friend) AS mutual_friends
ORDER BY mutual_friends DESC
LIMIT 10

// 共通のフォロワー
MATCH (u1:User {id: "user1"})<-[:FOLLOWS]-(common)-[:FOLLOWS]->(u2:User {id: "user2"})
RETURN common.name

Redis（カウンター）:

HSET user:user1:counts followers 1500 following 300
HINCRBY user:user1:counts followers 1  // フォローされた

選定理由: 「友達の友達」のような多段の関係トラバーサルはグラフDBが圧倒的に高速（RDBでは再帰CTE + 大量JOINが必要）。カウンターは高頻度更新のためRedis。

大量の時系列データの書き込みに強く、集計が効率的なデータストアを検討しよう。

選定:

• センサーデータ: TimescaleDB（PostgreSQL拡張、時系列特化）or Cassandra
• リアルタイムダッシュボード: Redis（直近データのキャッシュ）

TimescaleDBモデル:

-- ハイパーテーブル（自動パーティショニング）
CREATE TABLE sensor_readings (
  time TIMESTAMPTZ NOT NULL,
  device_id VARCHAR(50) NOT NULL,
  temperature DECIMAL(5,2),
  humidity DECIMAL(5,2),
  pressure DECIMAL(7,2)
);

SELECT create_hypertable('sensor_readings', 'time');

-- インデックス
CREATE INDEX idx_readings_device_time
  ON sensor_readings(device_id, time DESC);

-- 連続集計（自動集計）
CREATE MATERIALIZED VIEW hourly_stats
WITH (timescaledb.continuous) AS
SELECT
  time_bucket('1 hour', time) AS bucket,
  device_id,
  AVG(temperature) AS avg_temp,
  MAX(temperature) AS max_temp,
  MIN(temperature) AS min_temp,
  AVG(humidity) AS avg_humidity
FROM sensor_readings
GROUP BY bucket, device_id;

-- データ保持ポリシー（3年）
SELECT add_retention_policy('sensor_readings', INTERVAL '3 years');

Redis（リアルタイム）:

// 最新データをRedisに保持
await redis.hset(`sensor:device001:latest`, {
  temperature: '25.3',
  humidity: '60.1',
  pressure: '1013.2',
  timestamp: new Date().toISOString(),
});
await redis.expire(`sensor:device001:latest`, 120);

選定理由: 時系列データの大量書き込みと時間範囲での集計クエリに特化したTimescaleDBが最適。直近データはRedisで低レイテンシアクセス。書き込み規模が極めて大きい場合はCassandraも選択肢。

書き込み規模:

• 1万台 x 6回/分 = 6万回/分 = 1000回/秒
• 1日: 8,640万行
• 3年: 約946億行