要約 (TL;DR)

2017年6月3日更新

Redis は memcached よりも強力で、人気があり、サポートも充実しています。Memcached で実行できるのは、Redis で実行できる機能のほんの一部だけです。機能が重複している場合でも、Redis の方が優れています。

新しいものには、Redis を使用してください。

Memcached と Redis: 直接比較

どちらのツールも、キャッシュとして役立つ、強力で高速なメモリ内データ ストアです。どちらも、データベースの結果、HTML フラグメント、または生成にコストがかかる可能性のあるその他のものをキャッシュすることで、アプリケーションの速度向上に役立ちます。

考慮すべき点

同じことに使用する場合、元の質問の「考慮すべき点」を使用して比較すると次のようになります。

• 読み取り/書き込み速度: どちらも非常に高速です。ベンチマークはワークロード、バージョン、その他多くの要因によって異なりますが、一般的には redis は memcached と同等か、ほぼ同等の速度です。私は redis を推奨しますが、それは memcached が遅いからではありません。そうではありません。
• メモリ使用量: Redis の方が優れています。
  • memcached: キャッシュ サイズを指定し、アイテムを挿入するとデーモンのサイズはすぐにこのサイズより少し大きくなります。memcached を再起動する以外に、そのスペースを再利用する方法はありません。すべてのキーが期限切れになったり、データベースをフラッシュしたりしても、設定した RAM のチャンク全体が引き続き使用されます。
  • redis: 最大サイズの設定はあなた次第です。Redis は必要以上にメモリを使用することはなく、使用しなくなったメモリを返却します。
  • ランダムな文章の約 2 KB の文字列 (約 200 MB) を 100,000 個、両方に保存しました。Memcached の RAM 使用量は約 225 MB に増加しました。Redis の RAM 使用量は約 228 MB に増加しました。両方をフラッシュした後、redis は約 29 MB に減少し、memcached は約 225 MB のままでした。どちらもデータの保存方法は同様に効率的ですが、データを再利用できるのは 1 つだけです。
• ディスク I/O ダンプ: Redis はデフォルトでこれを実行し、永続性も非常に設定しやすいため、明らかに有利です。Memcached には、サードパーティのツールなしでディスクにダンプするメカニズムがありません。
• スケーリング: どちらも、キャッシュとして 1 つ以上のインスタンスが必要になる前に、十分な余裕を提供します。Redis には、それ以上のことをするのに役立つツールが含まれていますが、memcached には含まれていません。

メモリキャッシュ

Memcached は、シンプルな揮発性キャッシュ サーバーです。キーと値のペアを保存できますが、値は最大 1 MB の文字列に制限されます。

これはこれで優れていますが、それだけです。キーによってこれらの値に非常に高速にアクセスできるため、利用可能なネットワークやメモリ帯域幅が飽和してしまうことがよくあります。

memcached を再起動すると、データは消えます。キャッシュとしては問題ありません。重要なものをそこに保存すべきではありません。

高パフォーマンスや高可用性が必要な場合は、サードパーティのツール、製品、サービスが利用できます。

レディス

Redis は memcached と同じジョブを実行でき、さらにそれをより優れた方法で実行できます。

Redisはキャッシュとして機能する同様に、キー/値のペアも保存できます。Redis では最大 512 MB まで保存できます。

永続性をオフにすると、再起動時にデータも失われます。再起動後もキャッシュを保持したい場合は、それも可能です。実際、これがデフォルトです。

非常に高速ですが、ネットワークやメモリの帯域幅によって制限されることがよくあります。

もし、1つのredis/memcachedインスタンスではワークロードのパフォーマンスが不十分な場合は、redisが最適な選択肢です。Redisにはクラスターサポート高可用性ツールが付属しています（レディスセンチネル) が「箱の中に」入っています。過去数年間、Redis はサードパーティ ツールの明確なリーダーとしても浮上してきました。Redis Labs、Amazon などの企業は、多くの便利な Redis ツールとサービスを提供しています。Redis を取り巻くエコシステムははるかに大きくなっています。大規模な導入の数は、現在では memcached よりも多くなっている可能性があります。

Redis スーパーセット

Redis は単なるキャッシュではありません。メモリ内データ構造サーバーです。以下では、memcached のような単純なキー/値キャッシュ以外に、Redis で実行できることの概要を簡単に説明します。Redisの機能のほとんどは、memcached では実行できないものです。

ドキュメンテーション

Redis は memcached よりもドキュメントが充実しています。これは主観的なものかもしれませんが、常に真実であるように思われます。

レディス簡単にナビゲートできる素晴らしいリソースです。ブラウザでRedisを試すまた、ドキュメントでは各コマンドのライブインタラクティブな例も提供されます。

現在、Redis の StackOverflow の結果は Memcached の 2 倍あります。Google の結果も 2 倍あります。より多くの言語で、より容易にアクセスできる例があります。よりアクティブな開発。よりアクティブなクライアント開発。これらの測定値は個別には大きな意味を持たないかもしれませんが、組み合わせると、Redis のサポートとドキュメントがより充実し、より最新のものであることが明確にわかります。

持続性

デフォルトでは、Redis はスナップショットと呼ばれるメカニズムを使用してデータをディスクに保存します。十分な RAM があれば、パフォーマンスの低下をほとんど起こさずにすべてのデータをディスクに書き込むことができます。ほぼ無料です!

スナップショット モードでは、突然のクラッシュにより少量のデータが失われる可能性があります。絶対にデータが失われないようにする必要がある場合でも、心配はいりません。Redis は AOF (Append Only File) モードでその点もサポートします。この永続モードでは、データは書き込まれるとディスクに同期されます。これにより、最大書き込みスループットがディスクの書き込み速度に応じて低下する可能性がありますが、それでもかなり高速になるはずです。

必要に応じて永続性を微調整するための設定オプションは多数ありますが、デフォルト設定は非常に合理的です。これらのオプションにより、Redis を安全で冗長性のあるデータ保存場所として簡単に設定できます。これは本物のデータベースです。

多様なデータタイプ

Memcached は文字列に限定されていますが、Redis はさまざまなデータ型に対応できるデータ構造サーバーです。また、これらのデータ型を最大限に活用するために必要なコマンドも提供します。

文字列（コマンド）

最大 512 MB のサイズの単純なテキストまたはバイナリ値。これは、Redis と memcached が共有する唯一のデータ型ですが、memcached 文字列は 1 MB に制限されています。

Redis は、ビット単位の操作、ビットレベルの操作、浮動小数点の増分/減分のサポート、範囲クエリ、および複数キー操作のコマンドを提供することで、このデータ型を活用するためのより多くのツールを提供します。Memcached はこれらをいずれもサポートしていません。

文字列はあらゆるユースケースで役立ちます。そのため、memcached はこのデータ型だけでも非常に役立ちます。

ハッシュ（コマンド）

ハッシュは、キー値ストア内のキー値ストアのようなものです。文字列フィールドと文字列値の間でマップします。ハッシュを使用するフィールド -> 値マップは、通常の文字列を使用するキー -> 値マップよりもわずかにスペース効率が高くなります。

ハッシュは、名前空間として使用したり、多数のキーを論理的にグループ化したい場合に便利です。ハッシュを使用すると、すべてのメンバーを効率的に取得したり、すべてのメンバーをまとめて期限切れにしたり、すべてのメンバーをまとめて削除したりできます。グループ化する必要がある複数のキー/値ペアがあるユースケースに最適です。

ハッシュの使用例の 1 つは、アプリケーション間でユーザー プロファイルを保存することです。ユーザー ID をキーとして保存された Redis ハッシュを使用すると、ユーザーに関するデータを必要なだけ保存でき、それらを 1 つのキーで保存できます。プロファイルを文字列にシリアル化するのではなくハッシュを使用する利点は、1 つのアプリケーションが他のアプリケーションによる変更を上書きする心配をせずに、異なるアプリケーションでユーザー プロファイル内の異なるフィールドを読み取り/書き込みできることです (古いデータをシリアル化すると、このようなことが発生する可能性があります)。

リスト (コマンド）

Redis リストは、順序付けられた文字列のコレクションです。リストの上部または下部 (つまり、左側または右側) から値を挿入、読み取り、または削除するように最適化されています。

Redisは多くのコマンドリストを活用するためのもので、アイテムのプッシュ/ポップ、リスト間のプッシュ/ポップ、リストの切り捨て、範囲クエリの実行などのコマンドが含まれます。

リストは、耐久性があり、アトミックなキューに最適です。これらは、ジョブ キュー、ログ、バッファー、その他多くのユース ケースに最適です。

セット（コマンド）

セットは、順序付けられていない一意の値のコレクションです。セットは、値がセット内にあるかどうかをすばやく確認したり、値をすばやく追加/削除したり、他のセットとの重複を測定できるように最適化されています。

これらは、アクセス制御リスト、ユニーク ビジター トラッカー、その他多くの用途に最適です。ほとんどのプログラミング言語には、同様の機能 (通常は Set と呼ばれます) があります。これはそれに似ていますが、分散型です。

Redisはいくつかのコマンド to manage sets. Obvious ones like adding, removing, and checking the set are present. So are less obvious commands like popping/reading a random item and commands for performing unions and intersections with other sets.

Sorted Sets (commands)

Sorted Sets are also collections of unique values. These ones, as the name implies, are ordered. They are ordered by a score, then lexicographically.

This data type is optimized for quick lookups by score. Getting the highest, lowest, or any range of values in between is extremely fast.

If you add users to a sorted set along with their high score, you have yourself a perfect leader-board. As new high scores come in, just add them to the set again with their high score and it will re-order your leader-board. Also great for keeping track of the last time users visited and who is active in your application.

Storing values with the same score causes them to be ordered lexicographically (think alphabetically). This can be useful for things like auto-complete features.

Many of the sorted set commands are similar to commands for sets, sometimes with an additional score parameter. Also included are commands for managing scores and querying by score.

Geo

Redis has several commands for storing, retrieving, and measuring geographic data. This includes radius queries and measuring distances between points.

Technically geographic data in redis is stored within sorted sets, so this isn't a truly separate data type. It is more of an extension on top of sorted sets.

Bitmap and HyperLogLog

Like geo, these aren't completely separate data types. These are commands that allow you to treat string data as if it's either a bitmap or a hyperloglog.

Bitmaps are what the bit-level operators I referenced under Strings are for. This data type was the basic building block for reddit's recent collaborative art project: r/Place.

HyperLogLog allows you to use a constant extremely small amount of space to count almost unlimited unique values with shocking accuracy. Using only ~16KB you could efficiently count the number of unique visitors to your site, even if that number is in the millions.

Transactions and Atomicity

Commands in redis are atomic, meaning you can be sure that as soon as you write a value to redis that value is visible to all clients connected to redis. There is no wait for that value to propagate. Technically memcached is atomic as well, but with redis adding all this functionality beyond memcached it is worth noting and somewhat impressive that all these additional data types and features are also atomic.

While not quite the same as transactions in relational databases, redis also has transactions that use "optimistic locking" (WATCH/MULTI/EXEC).

Pipelining

Redis provides a feature called 'pipelining'. If you have many redis commands you want to execute you can use pipelining to send them to redis all-at-once instead of one-at-a-time.

通常、redis または memcached に対してコマンドを実行する場合、各コマンドは個別の要求/応答サイクルになります。パイプラインを使用すると、redis は複数のコマンドをバッファリングして一度にすべて実行し、すべてのコマンドに対するすべての応答を 1 回の応答で返します。

これにより、一括インポートや多数のコマンドを伴うその他のアクションで、さらに高いスループットを実現できます。

パブリッシュ/サブスクライブ

Redisはコマンド専用のパブリッシュ/サブスクライブ機能これにより、Redis は高速メッセージ ブロードキャスターとして機能できるようになります。これにより、単一のクライアントが、チャネルに接続されている他の多くのクライアントにメッセージを公開できるようになります。

Redisは、他のほとんどのツールと同様にpub/subを実行します。専用のメッセージブローカーは、ラビットMQ特定の領域では利点があるかもしれませんが、同じサーバーで永続的な耐久性のあるキューや、pub/sub ワークロードに必要なその他のデータ構造も提供できるため、Redis は多くの場合、この作業に最適で最もシンプルなツールであることがわかります。

Lua スクリプト

考えてみるとlua スクリプトRedis 独自の SQL やストアド プロシージャなどです。それ以上のこともあればそれ以下もありますが、この類推はほぼ当てはまります。

複雑な計算を Redis で実行したい場合があります。トランザクションをロールバックする余裕がなく、複雑なプロセスのすべてのステップがアトミックに実行されることを保証する必要がある場合があります。これらの問題やその他の多くの問題は、Lua スクリプトで解決できます。

スクリプト全体はアトミックに実行されるため、ロジックを Lua スクリプトに組み込むことができれば、多くの場合、楽観的ロック トランザクションを煩わせる必要がありません。

スケーリング

前述のように、Redis にはクラスタリングのサポートが組み込まれており、と呼ばれる独自の高可用性ツールがバンドルされていますredis-sentinel。

結論

新しいプロジェクト、または memcached を使用していない既存のプロジェクトには、ためらうことなく memcached よりも redis をお勧めします。

上記を読むと、私が memcached を好んでいないと思われるかもしれません。しかし、それとは逆に、memcached は強力で、シンプルで、安定しており、成熟した、堅牢なツールです。redis よりも少し速いユースケースさえあります。私は memcached が大好きです。ただ、将来の開発にはあまり意味がないと思います。

Redis は memcached ができることすべてを、多くの場合より良く実行します。memcached のパフォーマンス上の利点はわずかで、ワークロードによって異なります。また、redis の方が高速になるワークロードもあります。また、redis で実行できて memcached では実行できないワークロードも多数あります。機能上の大きな隔たりと、両方のツールが非常に高速で効率的であるという事実を考えると、わずかなパフォーマンスの違いは些細なことに思えます。そのため、スケーリングについて心配する必要のあるインフラストラクチャの最後の部分になる可能性があります。

memcached がより適しているシナリオは 1 つだけです。それは、memcached がすでにキャッシュとして使用されている場合です。すでに memcached を使用してキャッシュしている場合は、ニーズを満たしている限り、そのまま使用してください。redis に移行するのはおそらく労力に見合う価値がなく、redis をキャッシュのためだけに使用する場合は、時間をかけるだけのメリットが得られない可能性があります。memcached がニーズを満たしていない場合は、おそらく redis に移行する必要があります。これは、memcached を超えて拡張する必要がある場合でも、追加の機能が必要な場合でも同様です。