Redis（高速データベース）のモデル設計に関する基本的なガイダンス — 適切なデータ構造（文字列、ハッシュ、リスト、セット、ソート済みセット、JSON、ストリーム、ベクトルセット）を選択し、コロン区切りの一貫性のあるキー名を使用する。 **次のような場合に使用:** - Redis のデータモデルを設計するとき - オブジェクトをキャッシュ（一時保存）するとき - ハッシュと JSON のどちらを使うかを判断するとき - カウンターを構築するとき - ランキング機能を作成するとき - メンバーシップセット（グループ管理用の集合）を管理するとき - セッションストア（ユーザーの一時情報の保存場所）を構築するとき - Redis のキー名を見直したり整理したりするとき
Core Redis modeling guidance — choose the right data structure (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set) and use consistent colon-separated key names. Use when designing a Redis data model, caching objects, deciding between Hash and JSON, building counters, leaderboards, membership sets, or session stores, or when reviewing/cleaning up Redis key naming.
Redisでデータをモデル化するための基本的なガイダンスです。データ型の選択とキー名の命名規則の2つの決定について説明しており、この2つがメモリ使用量、処理速度、保守性に最も直接的な影響を与えます。
データの形だけでなく、実際のアクセス方法に合ったデータ型を選んでください。
| 用途 | 推奨型 | 理由 |
|---|---|---|
| シンプルな値、カウンター | String（文字列） | INCR/DECR、SET/GETが原子的（確実に完了） |
| フィールドを個別に更新するオブジェクト | Hash（ハッシュ） | フィールド単位での読み書きが可能、全体の書き直し不要 |
| キュー、最新N件のアイテム | List（リスト） | 先頭と末尾への追加・削除が高速（O(1)） |
| ユニークなアイテム、メンバーシップ確認 | Set（集合） | 追加・確認・個数カウントが高速（O(1)） |
| ランキング、スコアに基づく範囲検索 | Sorted Set（スコア付き集合） | スコア順に整列、スコアに基づく検索が可能 |
| ネストされた・階層的なデータ | JSON | 経路単位での更新、ネストした配列、インデックス機能 |
| イベントログ、ファンアウト（複数への一括配信） | Stream（ストリーム） | 永続化、コンシューマーグループ対応 |
| ベクトル類似度検索 | Vector Set（ベクトル集合） | ネイティブなベクトル保存、高速近傍探索 |
よくある落とし穴： フラットなオブジェクトを文字列にシリアライズして保存することです。1つのフィールドを更新するたびに、取得→解析→変更→保存という4つのステップが必要になります。代わりにハッシュを使いましょう。
詳しい説明とPython/Javaの例についてはreferences/choose-data-structure.mdを参照してください。
コロン区切りのセグメントで安定した階層構造を作ります：
{エンティティ}:{ID}:{属性}
user:1001:profile
user:1001:settings
order:2024:items
session:abc123
article:987:likes
game:space-invaders:leaderboard
ポイント：
User_1001_Profileなど）は避けてください。tenant:42:user:7:cartなど）。これにより、スキャンやアクセス制御をテナント単位で制御できます。クリーンアップ例とエッジケースについてはreferences/key-naming.mdを参照してください。
Foundational guidance for modeling data in Redis. Covers data-type selection and key-name conventions — the two decisions that most directly drive memory, performance, and maintainability.
Pick the type that matches the access pattern, not just the shape of the data.
| Use case | Recommended type | Why |
|---|---|---|
| Simple values, counters | String | Atomic INCR/DECR, SET/GET |
| Object with independently updated fields | Hash | Per-field reads/writes, no whole-object rewrite |
| Queue, recent-N items | List | O(1) push/pop at ends |
| Unique items, membership checks | Set | O(1) SADD/SISMEMBER/SCARD |
| Rankings, score-based ranges | Sorted Set | Score-ordered; ZADD/ZRANGE/ZRANK |
| Nested / hierarchical data | JSON | Path-level updates, nested arrays, RQE indexing |
| Event log, fan-out messaging | Stream | Persistent, consumer groups |
| Vector similarity | Vector Set | Native vector storage with HNSW |
Common anti-pattern: stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead.
See references/choose-data-structure.md for full rationale and Python/Java examples.
Use colon-separated segments with a stable hierarchy:
{entity}:{id}:{attribute}
user:1001:profile
user:1001:settings
order:2024:items
session:abc123
article:987:likes
game:space-invaders:leaderboard
Rules of thumb:
User_1001_Profile is bad).tenant:42:user:7:cart) so scans and ACLs can target a tenant cleanly.See references/key-naming.md for cleanup examples and edge cases.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。