SDN
← 概念一覧へ
データベース

キー・バリュー ストア

Key-Value Store

『キーを渡すと値が返る』という最もシンプルなNoSQL。ハッシュテーブルが抽象モデルで、O(1)の超高速な読み書きができる。キャッシュやセッション保存の定番。

キーポイント
  • 抽象モデルはハッシュテーブル。キー→値の単純な対応。
  • O(1)(一定時間)で読み書きできる。メモリやSSDに支えられて非常に高速。
  • キーを辞書順(lexicographic)に並べて範囲取得もできる。
  • 向き: 単純なデータ、急に変化するデータ、インメモリキャッシュ層。
  • 短所: 操作が限定的(基本はget/put/delete)。複雑なクエリはできず、複雑さがアプリ層に移る。
トレードオフ

ハッシュテーブルなのでキー指定の読み書きは最速(O(1))。一方、できる操作が『キーで取る/入れる/消す』に限られ、『値の中身で検索』『範囲集計』のような複雑なクエリは苦手。その複雑さはアプリ側で実装することになる。シンプルさと速度を、機能の豊富さと引き換えに得る。

たとえ話: コインロッカー

キー・バリューストアはコインロッカーそのものです。番号(=キー)を指定すれば、中身(=値)を一瞬で出し入れできます。何番のロッカーに何を入れるかさえ覚えていれば、超高速。

ただしロッカーは『中身が赤い荷物を全部出して』のような検索はできません。番号でしかアクセスできない。これがキー・バリューの長所(速い)と短所(キー以外で探せない)です。

図を描画中...

なぜO(1)で速いのか

ハッシュテーブルは、キーをハッシュ関数で『場所(アドレス)』に変換します。だからキーが分かれば、データ量がどれだけあっても一発でその場所に飛べる(平均O(1))。100万件でも10億件でも、1件取る速さはほぼ変わりません。これがキー・バリューの圧倒的な強みです。

何に使うか

  • インメモリキャッシュ: Redis / Memcached(『キャッシュ』の章で詳述)。
  • セッション保存: ログイン状態を session:abc → ユーザー情報 で保存。
  • 急に変化するデータ: カウンタ、一時データなど。

つまずきポイント

  • 『キーで取る』以外が苦手。『年齢が30以上のユーザー全員』のような条件検索はできない(値の中身は基本見ない)。そういう検索が必要なら別の仕組みを併用する。
  • 機能が最小限な分、複雑な処理はアプリ側で書くことになる。シンプルさの代償。
  • 他の3つのNoSQL(document, wide-column)も、根っこはこのキー・バリューの発展形と考えると理解しやすい。

📊 図解

図解: ハッシュテーブル構造のイメージ

キーをハッシュ関数でバケット位置に変換し、その場所の値へ一発でアクセスする(平均O(1))。逆に、キー以外の条件では中身を探せない。

図を描画中...

関連する概念

この概念で腕試し

関連する 0 問のクイズに挑戦できます。

クイズを解く