Key-Valueデータベース(Redis、Memcachedなど)の仕組み
フロントエンドアプリケーションは高速に感じられます。ユーザーがクリックすると、データが表示され、ページが瞬時に読み込まれます。その体験の背後には、多くの場合、key-valueデータベースが重労働を担っています。リクエストがメインデータベースに到達する前にキャッチしているのです。これらのシステムの仕組みを理解することで、キャッシング、セッション、バックエンドアーキテクチャについて、より賢明な判断ができるようになります。
重要なポイント
- Key-valueデータベースは、一意のキーと値のペアを使用してデータを保存・取得し、クエリの柔軟性と引き換えに卓越した速度を実現します。
- インメモリストレージ(RAM)により、ハッシュテーブルを介した定数時間のルックアップが可能になり、ディスクベースの読み取りよりも100〜1000倍高速です。
- Redisは豊富なデータ構造、オプションの永続化、組み込みクラスタリングを提供し、Memcachedはシンプルでマルチスレッド対応の専用キャッシュとして優れています。
- 一般的なユースケースには、セッション管理、APIレスポンスのキャッシング、レート制限など、低レイテンシが最も重要なシナリオが含まれます。
- Key-valueストアはリレーショナルデータベースを置き換えるのではなく、補完します。プライマリデータストアではなく、パフォーマンス層として使用してください。
Key-Valueデータベースとは?
Key-valueデータベースは、シンプルな2部構造(一意のキーとそれに関連付けられた値)を使用してデータを保存・取得するNoSQLデータストアの一種です。
JavaScriptのオブジェクトやハッシュマップのようなものと考えてください:
"session:user:4821" → { userId: 4821, role: "admin", expires: 1720000000 }
"product:sku:9001" → { name: "Wireless Keyboard", price: 49.99 }キーでデータを検索します。それだけです。クエリ言語も、JOINも、スキーマもありません。この制約こそが、key-valueストアを非常に高速にしている理由です。
インメモリストレージがルックアップを高速化する仕組み
RedisやMemcachedを含むほとんどのkey-valueデータベースは、ディスクではなくRAM上にデータを保存します。ディスク読み取りはミリ秒単位で測定されます。メモリ読み取りはマイクロ秒単位で行われ、多くの場合100〜1000倍高速です。
内部的には、これらのシステムはハッシュテーブルを使用します。キーがメモリアドレスにハッシュ化され、値が直接取得されます。スキャンも、インデックス作成も、クエリプランニングもありません。ルックアップ時間は実質的にO(1)、つまりデータセットのサイズに関係なく一定です。
これが、key-valueストアがキャッシング層、セッションストレージ、およびレスポンスタイムがユーザー体験に直接影響するあらゆるバックエンドサービスのデフォルトの選択肢となっている理由です。
基本操作:SET、GET、有効期限
基本的な操作は設計上最小限です:
- SET
key value— 値を保存 - GET
key— 値を取得 - DEL
key— 値を削除 - EXPIRE
key seconds— 有効期限(TTL)後に自動削除
TTLは特にキャッシングに便利です。APIレスポンスやレンダリングされたHTMLフラグメントを60秒の有効期限で保存します。アプリケーションは最初にキャッシュから読み取ります。キーが存在しないか期限切れの場合、データベースにフォールバックしてキャッシュを再構築します。このパターン(cache-aside)は、Webアーキテクチャで最も一般的なパターンの1つです。
Discover how at OpenReplay.com.
RedisとMemcached:主なアーキテクチャの違い
どちらもインメモリのkey-valueストアです。どちらもサブミリ秒のパフォーマンスを提供します。しかし、異なるトレードオフを行っています。
| 機能 | Redis | Memcached |
|---|---|---|
| データ型 | 文字列、リスト、セット、ハッシュ、ソート済みセット、ストリームなど | 文字列のみ |
| 値のサイズ制限 | 最大512 MB | 最大1 MB |
| 永続化 | オプション(RDBスナップショットまたはappend-onlyファイル) | なし — 完全に揮発性 |
| マルチスレッド | シングルスレッドイベントループ(6.0+でI/Oスレッディング追加) | 完全なマルチスレッド |
| メモリ回収 | 解放されたメモリをOSに返す | スラブアロケータを介して割り当てられたメモリを再起動まで保持 |
| 組み込みクラスタリング | あり(Redis Cluster、Sentinel) | クライアント側シャーディングが必要 |
Memcachedは専用のキャッシュです。シンプルで、高速で、予測可能です。スラブベースのメモリアロケータは断片化を低く抑え、メモリ使用量を非常に一貫性のあるものにします。これは、厳密なメモリ上限が必要な場合に便利です。プレーンな文字列をキャッシュし、それ以上何も必要としない場合に最適です。
Redisは、より広範なインメモリデータ構造ストアです。キャッシング以外にも、リーダーボード用のソート済みセット、pub/subメッセージング、アトミックカウンター、オプションの永続化をサポートしています。現代のRedisは、キャッシュ、セッションストア、メッセージブローカー、軽量データベースとして使用されています。時にはこれらすべてを同時に使用することもあります。注目すべき点として、Redisのライセンスは2024年から変更され、一部のチームはLinux Foundationによって寛容なライセンスの下で維持されている互換性のあるオープンソースフォークであるValkeyを評価するようになりました。
フロントエンド向けシステムにおけるKey-Valueデータベースの位置づけ
フロントエンド開発者の観点から見ると、key-valueストレージは通常3つの場所に現れます:
- セッション管理 — 認証トークン、ユーザー状態、設定をサーバー側に保存
- APIレスポンスのキャッシング — データベース負荷を軽減し、繰り返しリクエストを高速化
- レート制限 — アトミックインクリメント操作を使用してユーザーまたはIPごとのリクエスト数を追跡
これらはすべて、key-valueデータベースが最も得意とすること、つまり高速な読み取り、高速な書き込み、シンプルな有効期限ロジックから直接恩恵を受けます。
Key-Valueストアを使用すべきでない場合
Key-valueデータベースはリレーショナルデータベースの代替ではありません。実際の制限があります:
- ほとんどのクエリはキーベースで、リレーショナルデータベースと比較してフィルタリングやソートのサポートが限定的です。
- レコード間の組み込みリレーションシップがない
- 複雑なレポートや分析には適していない
- データモデリングには事前に慎重なキー設計が必要
データにリレーションシップがある場合や柔軟なクエリが必要な場合は、代わりにPostgreSQLやドキュメントデータベースを選択してください。Key-valueストレージは、プライマリデータストアの代替としてではなく、その上のパフォーマンス層として使用してください。
まとめ
Key-valueデータベースが機能するのは、複雑さと速度をトレードオフしているためです。1つのこと、つまり主にメモリ内でキーによって値を保存・取得することを行い、それを非常にうまく行います。柔軟性を求めてRedisを選択するか、シンプルさを求めてMemcachedを選択するかにかかわらず、基礎となるモデルを理解することで、これらのツールを実際に適した場所、つまりアプリケーションの応答性を維持する高速で焦点を絞った層として使用できるようになります。
よくある質問
Redisは2つのオプションの永続化メカニズムをサポートしています:設定された間隔でデータセットを保存するRDBスナップショットと、すべての書き込み操作をログに記録するappend-onlyファイル(AOF)です。どちらか一方または両方を使用できます。永続化を有効にしない場合、Memcachedと同様に、再起動時にデータは失われます。純粋なキャッシングの場合、永続化は多くの場合不要です。
Memcachedは、シンプルな文字列値のための直感的でマルチスレッド対応のキャッシュが必要で、最小限の設定で予測可能なメモリ使用量を求める場合に適しています。豊富なデータ構造、永続化、または組み込みクラスタリングが不要な場合、Memcachedのシンプルさと効率的なスラブベースのメモリアロケータは、信頼性の高い軽量なオプションとなります。
RedisとMemcachedの両方は、メモリ制限を処理するために退避ポリシーを使用します。MemcachedはデフォルトでLRU(最も最近使用されていない)退避を使用します。Redisは、LRU、LFU(最も使用頻度が低い)、ランダム退避、およびメモリが満杯のときに書き込み時にエラーを返すno-evictionモードを含む、いくつかの設定可能なポリシーを提供します。
Redisは、特に永続化を有効にした場合、セッション管理、カウンター、リアルタイムリーダーボードなどの特定のユースケースでプライマリデータストアとして機能できます。ただし、リレーショナルクエリ、強制されたスキーマ、成熟したトランザクションサポートが欠けています。ほとんどのアプリケーションでは、リレーショナルデータベースまたはドキュメントデータベースと並行して補完的なパフォーマンス層として最も効果的に機能します。
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
