2026.10.03 開発

KVS（キーバリューストア）とは：Redisで動かして分かる仕組みとRDBとの使い分け【2026年版】

Q: KVSに入れられる値の大きさに上限はありますか？

製品ごとに上限があります。 Redisの文字列型の解説 によると、1つの値は既定で最大512MBまで入りますが、実際には数KB程度に収めるのが無難です。大きな値は読み書きのたびにネットワークとメモリを占有し、ほかのリクエストを待たせます。画像やファイルはストレージに置き、KVSにはその保存先のパスだけを入れる設計にしてください。

KVS（キーバリューストア）とは：Redisで動かして分かる仕組みとRDBとの使い分け【2026年版】

KVS（Key-Value Store、キーバリューストア）は、「キー」と「値」の組だけでデータを保存し、キーを指定して値を出し入れするデータベースです。表の結合や複雑な検索をあきらめる代わりに、1件の読み書きを短い時間で返せる仕組みです。この記事では、KVSの仕組みとRDBとの違いを整理したうえで、代表製品のRedis 8.10系をDockerで起動し、redis-cliとPythonでキャッシュ・セッション・ロックを書く手順を示します。後半では永続化とメモリ上限の設定、Redis 8のライセンス変更とValkeyの選び方、KVSに置いてはいけないデータの判断までまとめます。

まとめ：KVSは1件をキーで引く処理に絞り、正本のデータはRDBに残す

KVSが速いのは、キーから値の場所を直接たどれるからです。その代わり、「価格が1万円以上の商品」のような値の中身を条件にした検索や、複数の表をまたぐ結合は苦手です。受託開発の現場では、KVSを単独のデータベースとして使うより、RDBの前段に置くキャッシュ、ログイン状態を持つセッション、APIの呼び出し回数を数えるカウンタとして組み込む形が大半を占めます。

2026年10月時点で選ぶなら、Redisは8.10系、ライセンスの制約を避けたいならBSDライセンスのValkey 9.1系が候補です。本番に出す前に、メモリ上限（maxmemory）とあふれたときの削除方針、永続化の方式の2点だけは必ず決めてください。ここを既定値のまま出すと、メモリ不足で書き込みが止まる、再起動でデータが消えるといった障害に直結します。

KVSの仕組みとRDB・ドキュメントDBとの違いを実装者向けに整理する基礎

手を動かす前に、KVSがどういうデータの持ち方をしているかを押さえます。

キーから値を1回で引くハッシュ構造とO(1)で読み書きできる理由

KVSの中身は、プログラミング言語の辞書型（Pythonのdict、JavaのHashMap）と同じ考え方です。キーをハッシュ関数に通して格納場所を決めるため、データが100件でも1億件でも、1件を探す手間はほぼ変わりません。RedisのSETコマンドの仕様にも計算量はO(1)と明記されています。

値の中身はKVSから見ると「ただのバイト列」です。JSON文字列を入れても、KVSはその中の項目を理解しません。読み出したアプリケーションが解釈します。この割り切りが速さの源で、同時に検索の弱さの原因でもあります。

RDBとKVSの違いを結合・制約・検索条件で比べた選定用の比較表

RDBとKVSの差は、速いか遅いかより「データベースが何を保証してくれるか」にあります。

観点	RDB（MySQL・PostgreSQLなど）	KVS（Redis・Valkeyなど）
データの形	列と型を決めた表	キーと値の組（値の形は自由）
取り出し方	SQLで任意の列を条件に検索	キーを指定して取得
表をまたぐ処理	JOINで結合できる	アプリ側で複数回取得して組み立てる
制約	一意制約・外部キー・NOT NULL	基本的になし
得意な処理	集計・帳票・整合性が要る更新	1件の高速な読み書き・期限付きデータ

RDBは登録時に制約を検査し、データの矛盾をデータベース側で止めます。KVSはその検査をしない分だけ速く、矛盾を防ぐ責任を担うのはアプリケーション側です。DB全体の種類と選び方はデータベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説で整理しています。

インメモリ型・分散型・エッジ型に分かれるKVS製品の種類と代表例

KVSと呼ばれる製品は、データをどこに置くかで性格が分かれます。実務でまず押さえるのは次の4系統です。

インメモリ型：Redis、Valkey、Memcached。メモリに置くため応答が速く、キャッシュやセッションの定番
マネージド分散型：Amazon DynamoDB。ディスクに永続化し、容量の上限を気にせず使える
エッジ型：Cloudflare Workers KV。世界中の拠点で読み出せるが、書き込みの反映は遅れる
設定保存型：etcd。Kubernetesのクラスタ状態を保存し、少量のデータを強い整合性で持つ

エッジ型の遅れは仕様です。Cloudflareの公式解説は、変更が他の拠点で見えるまで60秒以上かかる場合があると書いています。在庫数のように即時に揃える必要がある値には向きません。etcdは逆に整合性を優先した設計で、大量の業務データの置き場にはしません。DynamoDBのキー設計はAmazon DynamoDBとは：機能の全体像からローカル起動・キー設計・容量モード選定までで詳しく扱っています。

DockerでRedis 8.10系を起動してredis-cliでキーと値を操作する手順

ここからは、代表的なKVSであるRedisを手元で動かします。必要なのはDockerだけです。

docker runでRedisを起動しredis-cliから接続するまでのコマンド

GitHubのredis/redisによると、2026年10月3日時点の最新リリースは2026年9月17日公開の8.10.2です。Docker Hubの公式イメージにも8.10のタグがあります。

# ローカルの127.0.0.1だけに公開してRedis 8.10系を起動する
docker run -d --name kvs-redis -p 127.0.0.1:6379:6379 redis:8.10

# コンテナ内のredis-cliで接続し、疎通を確かめる
docker exec -it kvs-redis redis-cli
127.0.0.1:6379> PING
PONG

ポートの公開先を127.0.0.1に絞っている点に注意してください。公式イメージの説明には、-pでホストの外へポートを開けるとパスワードなしで誰でも接続できる状態になると明記されています。クラウドのサーバーで-p 6379:6379と書くと、そのままインターネットに公開されます。

SET・GET・EXで有効期限付きのキーを作り消える様子を確かめる

KVSの基本操作は、キーを指定して書く・読む・消すの3つです。Redisではキーに有効期限（TTL）を付けられ、期限が来ると自動で消えます。

127.0.0.1:6379> SET user:1001:name "Sato"
OK
127.0.0.1:6379> GET user:1001:name
"Sato"

# 60秒で消えるキー。TTLは残り秒数を返す（直後なら60か59）
127.0.0.1:6379> SET otp:1001 "482913" EX 60
OK
127.0.0.1:6379> TTL otp:1001
(integer) 60

# キーがまだ無いときだけ書く（NX）。既にあれば nil が返り上書きされない
127.0.0.1:6379> SET user:1001:name "Suzuki" NX
(nil)
127.0.0.1:6379> DEL user:1001:name
(integer) 1

キー名は種類:ID:項目のようにコロンで区切るのが慣例です。Redisはキーの階層を理解しませんが、命名をそろえておくと、どの機能のデータかが一目で分かり、後から削除対象を探すときに困りません。なお、SETは値を上書きした時点でそれまでのTTLを捨てます。期限を残したまま値だけ変えるならKEEPTTLを付けます。

Hash・List・Sorted Setで値に構造を持たせるデータ型の使い分け

Redisが単純なKVSと違うのは、値に構造を持たせられる点です。公式のデータ型一覧には、文字列（Strings）のほかHashes、Lists、Sets、Sorted sets、Streams、JSON、Vector setsなどが並びます。実務で最初に覚えるのは次の3つで足ります。

# Hash：1つのキーの中に項目と値を持つ。ユーザー情報のような小さなレコード向け
127.0.0.1:6379> HSET user:1001 name "Sato" plan "pro"
(integer) 2
127.0.0.1:6379> HGET user:1001 plan
"pro"

# List：入れた順に並ぶ。簡易なジョブキュー向け
127.0.0.1:6379> LPUSH jobs:mail "job-1" "job-2"
(integer) 2
127.0.0.1:6379> RPOP jobs:mail
"job-1"

# Sorted Set：スコア順に並ぶ。ランキング向け
127.0.0.1:6379> ZADD ranking 120 "user:1001" 300 "user:1002"
(integer) 2
127.0.0.1:6379> ZREVRANGE ranking 0 0 WITHSCORES
1) "user:1002"
2) "300"

JSON文字列を丸ごと文字列型に入れると、1項目を変えるたびに全体を読み書きし直すことになります。項目単位で更新するならHash、順番が意味を持つならListかSorted Set、と値の使われ方で型を決めてください。

PythonのredisクライアントでKVSをキャッシュとセッションに組み込む実装例

コマンドで感覚をつかんだら、アプリケーションから使う形に移します。ここではPythonの公式クライアントを使います。

redis-py 8.1系でキャッシュアサイドを書くときのTTLとキー命名

Python用の公式クライアントredis-pyは、2026年10月3日時点のPyPI最新版が8.1.0です。READMEによると6.2.0以降はPython 3.9以上が対象で、8.0からは通信プロトコルにRESP3を既定で使います。

KVSをRDBの前に置く定番の書き方が「キャッシュアサイド」です。まずKVSを見て、無ければRDBから読んでKVSに入れます。

# pip install "redis[hiredis]"
import json
import redis

r = redis.Redis(host="localhost", port=6379, db=0, decode_responses=True)

def get_product(product_id: int, db_conn) -> dict:
    key = f"cache:product:{product_id}"
    cached = r.get(key)
    if cached is not None:
        return json.loads(cached)          # キャッシュにあればRDBへ行かない

    row = db_conn.fetch_product(product_id)  # 無ければRDBから読む（正本はRDB）
    # 300秒で消える。期限を付けないとRDBの更新が永久に反映されない
    r.set(key, json.dumps(row, ensure_ascii=False), ex=300)
    return row

def update_product(product_id: int, data: dict, db_conn) -> None:
    db_conn.update_product(product_id, data)  # 先にRDBを更新する
    r.delete(f"cache:product:{product_id}")   # 次の読み込みで作り直させる

押さえどころは2つです。キャッシュには必ずTTLを付けること、更新時はキャッシュを書き換えずに削除することです。書き換えにすると、RDBの更新とKVSの更新の間で別のリクエストが割り込んだときに、古い値がキャッシュに残る場合があります。db_connの部分は、使っているORMやドライバの呼び出しに置き換えてください。

ログイン状態をKVSに置くセッション管理とフレームワーク側の設定

Webアプリのセッションは、KVSが最も得意とする用途です。セッションIDをキー、ログイン中のユーザー情報を値にして、最終アクセスからの有効期限をTTLで表せます。サーバーを複数台に増やしても、全台が同じRedisを見れば、どの台にリクエストが来てもログイン状態を共有できます。

多くのフレームワークは、設定の変更だけでセッションの保存先をRedisに切り替えられます。Djangoでの保存先の選び方とRedis構成の判断はDjangoのセッション設定：保存先5種の選び分けとRedis構成の判断にまとめました。注意点は、セッションを置くRedisではメモリ不足時の自動削除を慎重に選ぶことです。後述の削除方針しだいでは、利用者が突然ログアウトされます。

SET NXとEXで二重実行を防ぐロックを作るときの解除手順と注意点

バッチやWebhookの二重実行を防ぐために、KVSを簡易なロックとして使う場面もあります。SETのNX（無いときだけ書く）とEX（期限）を組み合わせます。

import uuid

def run_once(job_name: str, func) -> bool:
    lock_key = f"lock:{job_name}"
    token = str(uuid.uuid4())
    # 取れなければ None。60秒で自動解除されるので、処理は60秒以内に終える設計にする
    if not r.set(lock_key, token, nx=True, ex=60):
        return False
    try:
        func()
        return True
    finally:
        # 自分が取ったロックだけを消す（期限切れ後に他者が取ったロックを消さない）
        script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"
        r.eval(script, 1, lock_key, token)

解除時に値を照合しているのは、処理が期限を超えたあとに別のプロセスが取ったロックを誤って消さないためです。この手順はSETコマンドの公式ページに載っている方式に沿っていますが、同じページは、より強い保証が要る場面では複数ノードで合意を取るRedlockを勧めています。請求や在庫の確定のように二重実行が金銭に響く処理は、KVSのロックだけに頼らず、RDBの一意制約でも止めておくのが安全です。

本番運用で詰まる永続化・メモリ上限・ライセンスを決める設定の手順

手元で動いたKVSを本番に出すとき、既定値のままだと事故になる設定があります。順に決めていきます。

RedisのRDBとAOFの永続化方式と障害時に失うデータ量の目安

インメモリ型のKVSは、何もしなければ再起動でデータが消えます。Redisの永続化の公式解説は、方式を4つに分けています。

方式	仕組み	障害時に失うデータの目安
RDB	一定間隔でメモリ全体をファイルに保存	直近の数分ぶん
AOF（everysec）	書き込み命令をログに追記し、毎秒ディスクへ同期	最大1秒ぶん
RDB＋AOF	両方を併用し、再起動時はAOFから復元	最大1秒ぶん
永続化なし	メモリのみ	全件

AOFの同期間隔はappendfsync everysecが推奨かつ既定で、公式は失うのは1秒ぶんの書き込みと説明しています。キャッシュ専用なら永続化なしでも構いません。消えてもRDBから作り直せるからです。セッションやカウンタのように消えると利用者に影響が出るデータを置くなら、RDB＋AOFにします。

# redis.conf の例：セッションを置く構成
appendonly yes
appendfsync everysec
save 60 1000        # 60秒間に1000件以上の変更があればRDBも保存

8.10.0からは、書き込みを止めずに復元用のファイル一式を作るBACKUPコマンド群も加わりました。バックアップの手順を新しく組むなら、こちらを前提に設計できます。

maxmemoryとmaxmemory-policyを決めずに本番へ出すと起きる障害

メモリ上限の公式解説によると、64ビット環境のmaxmemoryの既定値は0、つまり上限なしです。この状態でデータが増え続けると、サーバーのメモリを使い切り、OSにプロセスを止められます。上限を設けたうえで、あふれたときにどのキーを消すかをmaxmemory-policyで選びます。

# キャッシュ専用：使われていないキーから消す
maxmemory 2gb
maxmemory-policy allkeys-lru

# セッションやロックも同居させる：TTL付きのキーだけを消す
# maxmemory-policy volatile-lru

選び方の目安は用途で決まります。キャッシュだけならallkeys-lruで十分です。セッションやロックが同じRedisにあるなら、allkeys-*はそれらも消してしまいます。公式も、キャッシュと消してはいけないキーを1台に混ぜるより、Redisを2台に分けることを勧めています。上限に達すると書き込みをエラーで拒むnoevictionは、データを失わない代わりにアプリ側でのエラー処理が必要です。8.6からは、最後に更新された時刻で消すallkeys-lrmも選べます。

Redis 8のAGPL追加とBSDのValkeyを比べて選ぶライセンスの判断

KVSの製品選びでは、ライセンスも確認が要ります。Redisのライセンスページによると、7.2以前はBSD-3-Clause、7.4系はRSALv2とSSPLv1の選択制、8.0以降はそこにAGPLv3が加わった3択です。

この変更を受けて、ライセンス変更の直前のRedisから分かれたのがValkeyです。BSD-3-Clauseのまま、Linux Foundation配下のLF Projectsが運営しており、2026年9月1日に9.1.2が出ています。自社の業務システムでRedisをそのまま使う分には、どちらでも問題になりにくいのが実情です。一方、KVSを組み込んだ製品やSaaSを他社に提供するなら、AGPLv3やSSPLの条件を法務と確かめるより、Valkeyを選ぶほうが判断が早く済みます。両者の機能差はValkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】で比較しています。

KVSを採用すべき処理と見送るべき処理を分ける受託開発の判断基準

最後に、どのデータをKVSに置き、どのデータを置かないかの線を引きます。

キャッシュ・セッション・回数制限ならKVSを採用してよい条件

次の条件をすべて満たすデータなら、KVSに置いてよいと判断できます。キーが決まっていて、そのキーで1件ずつ読み書きすること。消えても正本から作り直せるか、消えたときの影響が「再ログイン」程度で済むこと。値の中身を条件にした検索をしないことです。

これに当てはまるのが、RDBの前段のキャッシュ、ログインセッション、APIの回数制限のカウンタ、ワンタイムパスワードのような期限付きの値です。どれもTTLで自然に消える性質を持ち、KVSの得意分野と重なります。

集計・検索・整合性が要るデータをKVSに置かないと決める理由

反対に、受注・請求・在庫・会員情報の正本は、KVSに置かないと決めてください。「月別の売上を出したい」「住所に東京を含む会員を探したい」といった要求は、運用が始まってから必ず出てきます。KVSでは全キーを読み出してアプリ側で絞るしかなく、件数が増えるほど破綻します。外部キーや一意制約がないため、二重登録や参照先のない値もデータベースは止めてくれません。

KVSを導入して速度は出たものの、正本までKVSに寄せたためにデータの整合が取れなくなった、というのは移行相談でよく見る形です。正本はRDBに置き、KVSは読み込みの肩代わりに限定する設計が、後から集計や帳票の要件が増えても崩れません。RDBとKVSの役割分担を含めたデータベースの設計や、既存システムの性能改善・移行は、一創のデータベース設計・移行支援でご相談いただけます。

よくある質問

KVSを調べ始めた方からよく挙がる質問をまとめます。

KVSとNoSQLは同じ意味ですか？

同じではありません。NoSQLはRDB以外のデータベースの総称で、KVSはその中の1分類です。NoSQLには、JSONのような文書を単位に持つドキュメント型（MongoDBなど）、列の集まりで持つワイドカラム型（Cassandraなど）、ノードと関係で持つグラフ型も含まれます。KVSはその中で最も構造が単純で、キーによる1件の読み書きに特化した型です。

KVSとRDBのどちらを使うべきか迷ったらどう決めますか？

迷ったらRDBを選んでください。RDBは検索・集計・整合性をデータベース側で保証でき、後から要件が増えても対応できます。KVSは、RDBで速度が足りないと分かった処理に絞って足すものです。最初からKVSだけで業務データを組むと、検索や帳票の要件が出た時点で作り直しになります。

RedisとMemcachedの違いは何ですか？

どちらもインメモリ型のKVSですが、Memcachedは値を文字列として持つだけのキャッシュ専用です。RedisはHashやList、Sorted Setなどのデータ型、ディスクへの永続化、複製の仕組みを持ちます。キャッシュだけならどちらでも用は足りますが、セッションやランキング、キューにも使う予定があるならRedis系を選ぶほうが構成を1つにまとめられます。

KVSをサーバーなしで使う方法はありますか？

あります。AWSのElastiCache、AzureのManaged Redis、Google CloudのMemorystoreなど、クラウド各社がRedis互換のマネージドサービスを出しています。従量課金でサーバーの用意も不要なサービスもあり、使い方と料金はUpstashとは？サーバーレスRedisの料金・無料枠と使い方【2026年9月】で紹介しているので、サービスを選ぶ際の確認に使ってください。小規模なアプリなら、自前でRedisを運用するより安く済む場合があります。

KVSに入れられる値の大きさに上限はありますか？

製品ごとに上限があります。Redisの文字列型の解説によると、1つの値は既定で最大512MBまで入りますが、実際には数KB程度に収めるのが無難です。大きな値は読み書きのたびにネットワークとメモリを占有し、ほかのリクエストを待たせます。画像やファイルはストレージに置き、KVSにはその保存先のパスだけを入れる設計にしてください。