nosql-expert

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

概要

このスキルは、分散型のワイドカラムストアおよびキーバリューストア（具体的には Apache Cassandra と Amazon DynamoDB）に関する、実践的なメンタルモデルと設計パターンを提供します。

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

使用するタイミング

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

考え方の転換: SQL と分散 NoSQL の違い

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

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

主要な設計パターン

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

マイグレーションや新しいテーブル・インデックスの作成なしに、後から「クエリを追加する」ことは通常できません。

手順:

1. すべてのエンティティを列挙する（User、Order、Product など）。
2. すべてのアクセスパターンを列挙する（「メールアドレスで User を取得」「User ごとの Order を日付順に取得」など）。
3. それらのパターンを単一のルックアップで処理できるよう、テーブルを設計する。

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

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

• 目標: データとトラフィックを均等に分散すること。
• アンチパターン: カーディナリティの低い PK（例: status="active" や gender="m"）を使用すると ホットパーティション が発生し、スループットが単一ノードの能力に制限されます。
• ベストプラクティス: カーディナリティの高いキー（User ID、Device 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"
• 結果: ユーザープロファイルとすべての Order を 1 回のネットワークリクエスト で取得します。

5. 非正規化と重複

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

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

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

個別のガイダンス

Apache Cassandra / ScyllaDB

• 主キーの構造: ((パーティションキー), クラスタリングカラム)
• JOIN も集計もない: JOIN や GROUP BY を使おうとしないでください。集計値は別のカウンターテーブルで事前に計算してください。
• ALLOW FILTERING を避ける: 本番環境でこれを見かけた場合、データモデルに問題があります。クラスター全体のフルスキャンが発生していることを意味します。
• 書き込みは低コスト: INSERT と UPDATE は LSM ツリーへの追記に過ぎません。書き込み量よりも読み取りの効率を重視してください。
• トゥームストーン: DELETE は高コストなマーカーです。標準テーブルでは、キューのような頻繁な削除パターンを避けてください。

AWS DynamoDB

• GSI (グローバルセカンダリインデックス): GSI を使うと、データの別のビューを作成できます(例: ユーザーごとではなく「日付で注文を検索」)。
  • 注: GSI は結果整合性です。
• LSI (ローカルセカンダリインデックス): 同じパーティション内でデータを別の順序で並べ替えます。テーブル作成時に作成する必要があります。
• WCU / RCU: キャパシティモードを理解してください。シングルテーブル設計は、消費されるキャパシティユニットの最適化に役立ちます。
• TTL: Time-To-Live 属性を使うと、トゥームストーンを作成せずに古いデータを自動的に期限切れにできます(削除コストなし)。

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

NoSQL スキーマを確定する前に:

• アクセスパターンのカバー: すべてのクエリパターンが、特定のテーブルまたはインデックスに対応していますか？
• カーディナリティの確認: トラフィックを均等に分散できるだけの、十分な数の一意な値をパーティションキーが持っていますか？
• パーティション分割のリスク: 単一のパーティション(例: 1 ユーザーの注文)が無制限に増え続けませんか？(10GB を超える場合は、例えば USER#123#2024-01 のように、パーティションを「シャード」する必要があります。)
• 整合性の要件: このリード パターンでアプリケーションは結果整合性を許容できますか？

よくあるアンチパターン

❌ Scatter-Gather: 1 件のアイテムを探すためにすべてのパーティションをクエリする(スキャン)。 ❌ ホットキー: 「月曜日」のデータをすべて 1 つのパーティションに入れる。 ❌ リレーショナルなモデリング: Author と Book のテーブルを作成し、アプリケーションコードで結合しようとする。(代わりに、Author に Book の要約を埋め込むか、Books に Author の情報を複製してください。)