redis-core

Redis Core

Redis でデータをモデル化するための基本的なガイダンスです。データ型の選択とキー名の規約を扱います。これらはメモリ、パフォーマンス、保守性に最も直接的な影響を与える 2 つの決定事項です。

適用する場面

• オブジェクト、セッション、ユーザーごとの状態をキャッシュする場合。
• カウンター、ランキング、最近のアイテム一覧、一意のメンバーシップを持つセットを扱う場合。
• Redis のキー名をレビューまたはリファクタリングする場合。
• エンティティに Redis Hash と JSON ドキュメントのどちらを使うか決める場合。

1. 適切なデータ構造を選択する

データの形状だけでなく、アクセスパターンに合った型を選択してください。

ユースケース	推奨される型	理由
単純な値、カウンター	String	アトミックな INCR／DECR、SET／GET
フィールドを個別に更新するオブジェクト	Hash	フィールド単位で読み書きでき、オブジェクト全体を書き換える必要がない
キュー、直近 N 件のアイテム	List	両端で O(1) のプッシュ／ポップ
一意のアイテム、メンバーシップの確認	Set	O(1) の SADD／SISMEMBER／SCARD
ランキング、スコアベースの範囲検索	Sorted Set	スコア順。ZADD／ZRANGE／ZRANK
ネストされたデータ／階層データ	JSON	パス単位の更新、ネストされた配列、RQE インデックス作成
イベントログ、ファンアウトメッセージング	Stream	永続性があり、コンシューマーグループに対応
ベクトル類似検索	Vector Set	HNSW によるネイティブなベクトルストレージ

**よくあるアンチパターン：**フラットなオブジェクトをシリアライズした文字列に詰め込むことです。フィールドを 1 つ更新するにも、取得＋解析＋変更＋書き戻しが必要になります。代わりに Hash を使ってください。

詳しい理由と Python／Java の例については、references/choose-data-structure.md を参照してください。

2. 一貫性のあるキー名を使う

安定した階層で、colon-separated のセグメントを使います。

{entity}:{id}:{attribute}
user:1001:profile
user:1001:settings
order:2024:items
session:abc123
article:987:likes
game:space-invaders:leaderboard

目安：

• **小文字で、コロン区切りにします。**スペースや大文字・小文字の混在は避けます（User_1001_Profile は不適切です）。
• **短く、読みやすいキーにします。**キーはメモリ上に保存され、すべてのコマンドに表示されます。
• **URL 全体や長い文字列をキーに使わないでください。**短い識別子を取り出すか、URL のハッシュダイジェストを使います。
• マルチテナントではプレフィックスを付けます（tenant:42:user:7:cart）。スキャンや ACL でテナントを簡単に対象にできます。
• **一貫性を保ちます。**サービスごとに 1 つの規約を選び、すべてのキーに適用します。

クリーンアップの例や特殊なケースについては、references/key-naming.md を参照してください。

参考資料

• Redis：適切なデータ型の選択
• Redis：キー