こんにちは、かつコーチです。
これまで5回にわたって、Redisの基本・データ構造・キャッシュ戦略・セッション管理とPub/Subを解説してきました。
Redisシリーズの最終回となる今回は、キャッシュ用途でよく比較されるMemcachedとの違いを整理し、どちらを選ぶべきかの判断軸を示します。
そして、この記事をもってSQL/DBシリーズ全体の完結でもあります。
RDBMS（MySQL・PostgreSQL・SQLite・MongoDB・Oracle Database）からインメモリKVS（Redis）まで、幅広いデータベース技術を扱ってきたシリーズの締めくくりとして、じっくり比較していきましょう。
Memcachedとは何か
シンプルな分散キャッシュシステム
Memcached（メムキャッシュディー）は、Redisと同じくインメモリ（メモリ上でデータを管理する）のキー・バリュー型キャッシュシステムです。
歴史的にはMemcachedの方が先に登場し、LiveJournalのDB負荷対策として2003年に開発されました。
「データベースへの問い合わせ結果を一時的にメモリに置いておき、同じ問い合わせが来たら高速に返す」というキャッシュの基本発想は、RedisともMemcachedとも共通しています。
Memcachedの基本コマンド
Memcachedにもredis-cliに相当するmemcachedのクライアントツールがあり、telnetや専用CLIで操作できます。
# telnetでMemcachedに接続する（ポート11211がデフォルト）
telnet localhost 11211
# キーに値を保存する（フラグ、TTL秒数、データ長を明示的に指定する）
set product:1001 0 600 8
商品Aです
STORED
# キーから値を取得する
get product:1001
VALUE product:1001 0 8
商品Aです
END
RedisのSET key value EX 600と比べると、setコマンドにフラグやデータ長を明示的に渡す必要があり、やや低レベルな操作感があります。
近年はmemcached-toolや各言語のクライアントライブラリ経由で操作するのが一般的で、直接telnetで叩く機会は限られますが、プロトコルのシンプルさそのものがMemcachedの設計思想を表しています。
RedisとMemcachedの機能比較
データ構造の違い
最も大きな違いが、扱えるデータ構造の豊富さです。
| 観点 | Redis | Memcached |
|---|---|---|
| データ構造 | String・List・Hash・Set・Sorted Set等、多様 | Stringのみ（単純なキー・バリュー） |
| 永続化 | RDB/AOFでディスクに保存可能 | 基本的に永続化しない（純粋なキャッシュ） |
| レプリケーション | 標準でサポート | 標準ではサポートしない（外部ツールが必要） |
| Pub/Sub | サポートあり | サポートなし |
| マルチスレッド | 主にシングルスレッド（7.x系で一部I/Oはマルチスレッド化） | マルチスレッドが基本 |
| データサイズの上限 | 1つの値で最大512MB | 1つの値で最大1MB（デフォルト設定） |
Memcachedは意図的に機能を絞り込み、「シンプルな文字列キャッシュ」に特化して設計されています。
このシリーズのR03で扱ったList・Hash・Set・Sorted Setのような多様なデータ構造も、R05で扱ったPub/Subも、Memcachedには存在しません。
対してRedisは、キャッシュだけでなくセッションストア・メッセージング基盤・ランキング機能まで、幅広い用途に対応できる汎用性を持っています。
パフォーマンス特性の違い
両者ともにインメモリという点は共通しており、単純な文字列の読み書きに限れば、パフォーマンスに決定的な差はないとされています。
違いが出やすいのはアーキテクチャです。
Memcachedはマルチスレッドで設計されており、大量の小さな値を、多数のCPUコアで並列に処理する用途に強みがあります。
一方Redisは伝統的にシングルスレッドで動作し（Redis 6以降、ネットワークI/O部分は一部マルチスレッド化されていますが、コマンド実行自体は依然としてシングルスレッドが基本です）、1つのコマンドが確実に処理し終わるまで次のコマンドを待たせる設計になっています。
このシングルスレッドという特性は弱点に見えますが、実は複数のコマンドが同時に同じデータを書き換えて競合するという問題が起きにくいという利点でもあります。
例えばSorted Setを使ったランキング更新（R03で扱ったZADD）のように、複数のクライアントから同時に更新が入る場面でも、Redisはコマンド単位でのアトミック性（処理が中断されず完全に実行される性質）を保証しやすい設計になっています。
永続化・可用性の違い
キャッシュとしての用途に限定すれば、データが消えても「DBから再取得すればいい」だけなので、永続化の有無はさほど問題になりません。
しかしR01・R04で扱った通り、Redisはセッションデータのように「消えると困るデータ」も扱う場面があります。
Memcachedにはそもそも永続化の仕組みがなく、再起動すればすべてのデータが失われます。
Redisであれば、RDB（スナップショット）やAOF（コマンドログ）による永続化、さらにレプリケーション（複製）による冗長化まで標準機能でカバーできます。
「純粋なキャッシュとしてしか使わない」と割り切れるならMemcachedの選択肢もありますが、「セッションや準永続的なデータも扱いたい」場合は、この時点でRedis一択に近くなります。
どちらを選ぶべきか：判断軸
Memcachedが向いているケース
- キャッシュ用途に限定され、多様なデータ構造やPub/Subが不要
- 大量の小さな値（数KB程度）を、非常に高いスループットで処理したい
- 複数コアを活かしたマルチスレッド処理を最大限使いたい
- 運用をできる限りシンプルに保ちたい（機能が少ない分、考慮事項も少ない）
Redisが向いているケース
- キャッシュだけでなく、セッション管理・ランキング・Pub/Subなど複数用途で使いたい
- List・Hash・Set・Sorted Setのような多様なデータ構造が必要
- 永続化やレプリケーションによるデータの保全・可用性が必要
- 将来的な機能追加（メッセージング基盤化など）の余地を残しておきたい
実務上の結論
私自身、実際のプロジェクトでMemcachedの採用を検討したことが何度かありますが、最終的にほぼすべてのケースでRedisを選んでいます。
理由はシンプルで、「最初は単純なキャッシュ用途のつもりでも、後からセッション管理やランキング機能の要件が追加されるケースが非常に多い」からです。
Memcachedを選んで後からRedisに移行するコストと、最初からRedisを選んでおくコストを比較すると、多くのプロジェクトでは後者の方が合理的だと感じています。
一方で、「純粋に大量の小さなキャッシュを、極限まで高スループットでさばきたい」という明確な要件がある大規模サービスでは、今でもMemcachedが選ばれる場面があります。
実際、FacebookやWikipediaのような超大規模サービスでは、Memcachedの単純さとマルチスレッド性能を活かした構成が採用された事例が知られています。
「機能の豊富さのRedis」か「単純さと処理性能特化のMemcached」か、という構図で理解しておくと判断しやすくなります。
まとめ
この記事のポイント
- RedisとMemcachedはどちらもインメモリのキー・バリュー型キャッシュシステムだが、設計思想が異なる
- Memcachedはシンプルな文字列キャッシュに特化し、マルチスレッドで高スループットを実現する
- Redisは多様なデータ構造・永続化・レプリケーション・Pub/Subまで幅広くサポートする汎用データストア
- 用途がキャッシュに限定されるならMemcached、複数用途や将来の拡張を見込むならRedisが基本の判断軸
- 迷った場合は、後からの用途拡張に対応しやすいRedisを選んでおくのが実務上のリスクが低い
これでRedis編（全6本）は完結です。これでSQL/DBシリーズ（全105本）も完結です。
MySQL・PostgreSQL・SQLite・MongoDB・Oracle Database・Redisと、RDBMSからNoSQL、インメモリKVSまで幅広く扱ってきました。
それぞれの技術が「何が得意で、何が苦手か」を理解した上で、実際のプロジェクトで適材適所に使い分けていただければと思います。
次に読むべき記事
- Redisとは？インメモリKVSを初心者向けに解説
- Redisをキャッシュとして使う：TTL戦略の基本
- Redisをセッション管理・Pub/Subに使う
タグ: Redis, 中級者向け, 比較検証
