nosql-expert

NoSQL のエキスパート向けパターン（Cassandra と DynamoDB）

概要

このスキルでは、分散型ワイドカラムストアおよびキーバリューストア（具体的には Apache Cassandra と Amazon DynamoDB）向けの、専門的なメンタルモデルと設計パターンを紹介します。

データエンティティをモデル化する SQL や、MongoDB のようなドキュメントストアとは異なり、これらの分散システムでは、まずクエリをモデル化する必要があります。

使用する場面

• スケールを考慮した設計：シンプルな単一ノードデータベースから分散クラスターへ移行する場合。
• テクノロジーの選定：Cassandra、ScyllaDB、DynamoDB を評価または使用する場合。
• パフォーマンスの調整：既存の NoSQL システムで「ホットパーティション」や高レイテンシの問題を調査する場合。
• マイクロサービス：高度に最適化された読み取りが必要な、「サービスごとのデータベース」パターンを実装する場合。

メンタルモデルの転換：SQL と分散 NoSQL

特徴	SQL（リレーショナル）	分散 NoSQL（Cassandra/DynamoDB）
データモデリング	エンティティとリレーションシップをモデル化	クエリ（アクセスパターン）をモデル化
結合	読み取り時に CPU 負荷が高い	書き込み時に事前計算（非正規化）
ストレージコスト	高い（重複を最小限にする）	低い（読み取り速度のためにデータを複製する）
一貫性	ACID（強い一貫性）	BASE（結果整合性）／調整可能
スケーラビリティ	垂直（より高性能なマシン）	水平（ノード／シャードを増やす）

黄金律： SQL では、あらゆるクエリに答えられるようにデータモデルを設計します。NoSQL では、特定のクエリに効率よく答えられるようにデータモデルを設計します。

主要な設計パターン

1. クエリファーストのモデリング（アクセスパターン）

移行するか、新しいテーブル／インデックスを作成しない限り、後から「クエリを追加する」ことは通常できません。

手順：

1. すべてのエンティティを列挙する（ユーザー、注文、商品）。
2. すべてのアクセスパターンを列挙する（「メールアドレスでユーザーを取得する」、「ユーザーの注文を日付順で取得する」）。
3. 1 回の検索で各パターンに対応できるよう、専用のテーブルを設計する。

2. パーティションキーが最重要

データは**パーティションキー（PK）**に基づいて物理ノード間で分散されます。

• 目標： データとトラフィックを均等に分散すること。
• アンチパターン： カーディナリティの低い PK（例：status="active" または gender="m"）を使うと、ホットパーティションが発生し、スループットが単一ノードの処理能力に制限されます。
• ベストプラクティス： カーディナリティの高いキー（ユーザー ID、デバイス ID、複合キー）を使用すること。

3. クラスタリングキー／ソートキー

パーティション内では、データは**クラスタリングキー（Cassandra）またはソートキー（DynamoDB）**によってディスク上でソートされます。

• 効率的な範囲クエリ（例：WHERE user_id=X AND date > Y）が可能になります。
• 特定の取得要件に合わせて、データを事前にソートする効果があります。

4. シングルテーブル設計（隣接リスト）

主な用途：DynamoDB（ただし、概念は他の環境にも適用できます）

複数のエンティティタイプを 1 つのテーブルに格納し、事前に結合された読み取りを可能にします。

PK（パーティション）	SK（ソート）	データフィールド...
USER#123	PROFILE	{ name: "Ian", email: "..." }
USER#123	ORDER#998	{ total: 50.00, status: "shipped" }
USER#123	ORDER#999	{ total: 12.00, status: "pending" }

• クエリ： PK="USER#123"
• 結果： そのパーティションキーの下にあるプロフィールと注文を取得します。1 回の応答ですべて収まると想定せず、LastEvaluatedKey が存在しなくなるまでページネーションします。

5. 非正規化とデータの複製

異なるクエリパターンに対応するため、同じデータを複数のテーブルに保存することをためらわないでください。

• テーブル A： users_by_id（PK：uuid）
• テーブル B： users_by_email（PK：email）

トレードオフ：テーブル間のデータの一貫性を管理する必要があります（多くの場合、結果整合性またはバッチ書き込みを使用します）。

各製品に関するガイダンス

Apache Cassandra / ScyllaDB

• 主キー構造： ((Partition Key), Clustering Columns)
• 結合なし。集計には制約があります： CQL では、許可された主キーのプレフィックスに対して集計関数と GROUP BY を使用できます。スキャンのコストが上限内に収まるか確認してください。アクセスパターン上のメリットが一貫性や修復とのトレードオフを正当化する場合に限り、事前計算を行ってください。
• ALLOW FILTERING を避ける： 本番環境でこれを見かけたら、データモデルに問題があります。これはクラスター全体のスキャンを意味します。
• 書き込みコストは低い： 挿入と更新は、LSM ツリーへの追記にすぎません。書き込み量よりも読み取り効率を重視してください。
• トゥームストーン： 削除はコストの高いマーカーです。標準テーブルでは、キューのような削除頻度の高いパターンを避けてください。

AWS DynamoDB

• GSI（グローバルセカンダリインデックス）： GSI を使用して、データの別のビューを作成します（例：「ユーザー別に注文を検索」する代わりに「日付別に注文を検索」する）。
  • 注： GSI は結果整合性です。
• LSI（ローカルセカンダリインデックス）： 同じパーティション内のデータを別の順序でソートします。テーブルの作成時に作成する必要があります。
• WCU / RCU： キャパシティーモードを理解してください。シングルテーブル設計は、消費キャパシティーユニットの最適化に役立ちます。
• TTL： 有効期限切れの処理は非同期です。必要に応じてアプリケーションの読み取り時に期限切れアイテムを除外し、レプリケーション料金を確認してください。TTL を正確な削除時刻の保証として使用したり、DynamoDB に Cassandra のトゥームストーンのセマンティクスを適用したりしないでください。

エキスパート向けチェックリスト

NoSQL スキーマを確定する前に、以下を確認してください。

• アクセスパターンの網羅性： 各クエリパターンは、特定のテーブルまたはインデックスに対応していますか？
• カーディナリティの確認： トラフィックを均等に分散できるだけの一意な値が、パーティションキーにありますか？
• パーティション肥大化のリスク： ある単一のパーティション（例：単一ユーザーの注文）は、際限なく増加しますか？（DynamoDB の 10 GB のアイテムコレクション上限は LSI が存在する場合に適用されます。他のエンジンや構成には異なる制約があります。時間単位のバケット化やシャーディングは、クエリとキャパシティーの計画がある場合に限って行ってください。）
• 一貫性要件： この読み取りパターンについて、アプリケーションは結果整合性を許容できますか？

よくあるアンチパターン

❌ Scatter-Gather： 1 つのアイテムを探すために、すべてのパーティションをクエリする（スキャン）。 ❌ ホットキー： すべての「月曜日」のデータを 1 つのパーティションに格納する。 ❌ リレーショナルモデリング： Author テーブルと Book テーブルを作成し、コード内で結合しようとする。（代わりに、Book の概要を Author に埋め込むか、Author の情報を Books に複製します。）

例

ユーザーのリクエスト：

このタスクでは @nosql-expert を使用してください：分散 NoSQL データベース（Cassandra、DynamoDB）に関するエキスパートのガイダンス。

制限事項

• このスキルは、タスクが上記の説明された範囲に明確に当てはまる場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、またはエキスパートレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。