NoSQL Expert Patterns (Cassandra & DynamoDB)

概要

このスキルは、分散ワイドカラムおよびキーバリューストア（特に Apache Cassandra と Amazon DynamoDB）向けのプロフェッショナルなメンタルモデルとデザインパターンを提供します。

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

使用場面

• スケール向けの設計：シングルノードデータベースから分散クラスタへの移行。
• 技術選定：Cassandra、ScyllaDB、または DynamoDB の評価または使用。
• パフォーマンスチューニング：既存 NoSQL システムの「ホットパーティション」または高レイテンシーのトラブルシューティング。
• マイクロサービス：高度に最適化された読み込みが必要な「サービスごとのデータベース」パターンの実装。

メンタルシフト：SQL vs. 分散 NoSQL

項目	SQL（リレーショナル）	分散 NoSQL（Cassandra/DynamoDB）
データモデリング	エンティティ + リレーションシップをモデル化	クエリ（アクセスパターン）をモデル化
結合	CPU 集約的、読み込み時に実行	事前計算（非正規化）、書き込み時に実行
ストレージコスト	高い（重複を最小化）	安い（読み込み速度のためにデータを重複）
一貫性	ACID（強い一貫性）	BASE（結果整合性）／チューニング可能
スケーラビリティ	垂直（より大きなマシン）	水平（より多くのノード/シャード）

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

コアデザインパターン

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

後からクエリを追加することは通常できず、マイグレーションまたは新しいテーブル/インデックスの作成が必要になります。

プロセス：

1. すべてのエンティティをリストアップ（User、Order、Product）。
2. すべてのアクセスパターンをリストアップ（「メールでユーザーを取得」、「ユーザーの注文を日付でソートして取得」）。
3. テーブルを設計し、単一のルックアップでそのパターンに対応できるようにします。

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 つのネットワークリクエストで取得。

5. 非正規化と重複

異なるクエリパターンに対応するために、同じデータを複数のテーブルに格納することを躊躇しないでください。

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

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

具体的なガイダンス

Apache Cassandra / ScyllaDB

• 主キー構造： ((Partition Key), Clustering Columns)
• 結合なし、集約なし： JOIN や GROUP BY を試みないでください。別のカウンターテーブルで集約を事前計算してください。
• ALLOW FILTERING を避ける： 本番環境でこれを見かけたら、データモデルが間違っています。クラスタ全体スキャンを意味します。
• 書き込みは安い： 挿入と更新は単に LSM ツリーへの追記です。読み込み効率ほど書き込みボリュームについて心配する必要はありません。
• 墓石（Tombstones）： 削除はコストのかかるマーカーです。標準テーブルでの高速削除パターン（キューなど）は避けてください。

AWS DynamoDB

• GSI（グローバルセカンダリインデックス）： GSI を使用してデータの代替ビューを作成します（例：ユーザーではなく日付で注文を検索）。
  • 注記： GSI は結果整合性です。
• LSI（ローカルセカンダリインデックス）： 同じパーティション内でデータを異なる方法でソートします。テーブル作成時に作成する必要があります。
• WCU / RCU： キャパシティモードを理解してください。シングルテーブル設計は消費キャパシティユニットの最適化に役立ちます。
• TTL： Time-To-Live 属性を使用して古いデータを自動的に期限切れにします（無料削除）。墓石を作成しません。

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

NoSQL スキーマを最終化する前に：

• アクセスパターンカバレッジ： すべてのクエリパターンが特定のテーブルまたはインデックスにマップされていますか？
• カーディナリティチェック： パーティションキーに十分なユニーク値があり、トラフィックを均等に分散していますか？
• パーティション分割リスク： 単一パーティション（例：単一ユーザーの注文）は無期限に成長しますか？（> 10GB の場合、パーティションを「シャード」する必要があります。例：USER#123#2024-01）。
• 一貫性要件： アプリケーションはこの読み込みパターンに対して結果整合性を許容できますか？

一般的なアンチパターン

❌ スキャッタ・ギャザー： 1 つのアイテムを見つけるためにすべてのパーティションにクエリを実行（Scan）。 ❌ ホットキー： すべての「月曜日」データを 1 つのパーティションに入れる。 ❌ リレーショナルモデリング： Author と Book テーブルを作成し、コードでそれらを結合しようとする。（代わりに、Book 概要を Author に埋め込むか、Books に Author 情報を重複させます）。

制限事項

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