caching - MemcachedとRedis？

Question

キャッシュにRedisサーバーでRubyWebアプリを使用しています。代わりにMemcachedをテストするポイントはありますか？

何が私たちにより良いパフォーマンスを与えるでしょうか？RedisとMemcachedの長所と短所はありますか？

考慮すべきポイント：

読み取り/書き込み速度。
メモリ使用量。
ディスクI/Oダンプ。
スケーリング。

score 2140 · Accepted Answer

要約（TL; DR）

2017年6月3日更新

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

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

MemcachedとRedis：直接比較

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

考慮すべきポイント

同じ目的で使用する場合、元の質問の「考慮事項」を使用して比較する方法は次のとおりです。

読み取り/書き込み速度：どちらも非常に高速です。ベンチマークは、ワークロード、バージョン、およびその他の多くの要因によって異なりますが、通常、redisはmemcachedと同じかほぼ同じ速度であることが示されています。redisをお勧めしますが、memcachedが遅いためではありません。そうではありません。
メモリ使用量：Redisの方が優れています。
- memcached：キャッシュサイズを指定すると、アイテムを挿入すると、デーモンがこのサイズより少し大きくなります。memcachedを再起動する以外に、そのスペースを再利用する方法は実際にはありません。すべてのキーの有効期限が切れたり、データベースをフラッシュしたりしても、構成したRAMのチャンク全体が使用されます。
- redis：最大サイズの設定はあなた次第です。Redisは必要以上に使用することはなく、使用しなくなったメモリを返します。
- ランダムな文の100,000〜2KBの文字列（〜200MB）を両方に保存しました。MemcachedRAMの使用量は約225MBに増加しました。RedisRAMの使用量は約228MBに増加しました。両方をフラッシュした後、redisは約29MBに低下し、memcachedは約225MBのままでした。データの保存方法も同様に効率的ですが、データを再利用できるのは1つだけです。
ディスクI/Oダンピング：デフォルトでこれを実行し、非常に構成可能な永続性を備えているため、redisの明確な利点があります。Memcachedには、サードパーティのツールなしでディスクにダンプするメカニズムがありません。
スケーリング：どちらも、キャッシュとして複数のインスタンスが必要になる前に、大量のヘッドルームを提供します。Redisには、memcachedにはないツールが含まれていますが、それを超えるのに役立ちます。

memcached

Memcachedは、単純な揮発性キャッシュサーバーです。これにより、値が最大1MBの文字列に制限されているキーと値のペアを格納できます。

これは得意ですが、それだけです。これらの値には、キーによって非常に高速にアクセスでき、多くの場合、利用可能なネットワークやメモリ帯域幅が飽和状態になります。

memcachedを再起動すると、データが失われます。これはキャッシュには問題ありません。重要なものはそこに保管しないでください。

高性能または高可用性が必要な場合は、サードパーティのツール、製品、およびサービスを利用できます。

redis

Redisは、memcachedと同じジョブを実行でき、より適切に実行できます。

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

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

それも超高速で、多くの場合、ネットワークまたはメモリ帯域幅によって制限されます。

redis / memcachedの1つのインスタンスがワークロードに対して十分なパフォーマンスではない場合は、redisが明確な選択です。Redisにはクラスターのサポートが含まれており、高可用性ツール（redis-sentinel）が「同梱」されています。過去数年間で、redisはサードパーティツールの明確なリーダーとしても浮上してきました。Redis Labs、Amazonなどの企業は、多くの便利なRedisツールとサービスを提供しています。redis周辺のエコシステムははるかに大きいです。大規模なデプロイの数は、memcachedの場合よりも多くなる可能性があります。

Redisスーパーセット

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

ドキュメンテーション

Redisは、memcachedよりも文書化されています。これは主観的なこともありますが、常に真実であるように思われます。

redis.ioは、簡単にナビゲートできる素晴らしいリソースです。ブラウザでredisを試すことができ、ドキュメントの各コマンドを使用してインタラクティブなライブ例を提供することもできます。

現在、redisのstackoverflowの結果はmemcachedの2倍です。Googleの結果の2倍。より多くの言語でより簡単にアクセスできる例。より積極的な開発。より積極的なクライアント開発。これらの測定値は、個別にはあまり意味がないかもしれませんが、組み合わせることで、redisのサポートとドキュメントがより優れており、はるかに最新であるという明確な図が描かれます。

永続性

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

スナップショットモードでは、突然のクラッシュによって少量のデータが失われる可能性があります。データが失われないようにする必要がある場合でも、心配しないでください。AOF（ファイルのみを追加）モードを使用すると、redisにもデータが失われます。この永続モードでは、データが書き込まれるときにデータをディスクに同期できます。これにより、最大書き込みスループットがディスクの書き込み速度まで低下する可能性がありますが、それでもかなり高速である必要があります。

必要に応じて永続性を微調整するための多くの構成オプションがありますが、デフォルトは非常に賢明です。これらのオプションを使用すると、データを保存するための安全で冗長な場所としてredisを簡単にセットアップできます。それは実際のデータベースです。

多くのデータ型

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

文字列（コマンド）

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

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

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

ハッシュ（コマンド）

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

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

ハッシュの使用例の1つは、アプリケーション間でユーザープロファイルを保存することです。ユーザーIDをキーとして保存されたredisハッシュを使用すると、ユーザーに関するデータを1つのキーに保存しながら、必要な数のデータを保存できます。プロファイルを文字列にシリアル化する代わりにハッシュを使用する利点は、あるアプリが他のアプリによって行われた変更をオーバーライドすることを心配することなく、ユーザープロファイル内のさまざまなフィールドをさまざまなアプリケーションに読み取り/書き込みさせることができることです（これは、古いものをシリアル化した場合に発生する可能性があります）データ）。

リスト（コマンド）

Redisリストは、文字列の順序付けられたコレクションです。これらは、リストの上部または下部（別名：左または右）から値を挿入、読み取り、または削除するために最適化されています。

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

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

セット（コマンド）

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

これらは、アクセス制御リスト、一意の訪問者トラッカー、および他の多くのものなどに最適です。ほとんどのプログラミング言語には似たようなものがあります（通常はセットと呼ばれます）。これはそのようなもので、配布されるだけです。

Redisは、セットを管理するためのいくつかのコマンドを提供します。セットの追加、削除、チェックなどの明らかなものが存在します。したがって、ランダムなアイテムのポップ/読み取りや、他のセットとの和集合や交差を実行するためのコマンドなど、あまり目立たないコマンドもあります。

ソートされたセット（コマンド）

並べ替えられたセットは、一意の値のコレクションでもあります。これらは、その名前が示すように、順序付けられています。それらはスコア順に並べられ、次に辞書式に並べられます。

このデータ型は、スコアによるクイックルックアップ用に最適化されています。最高値、最低値、またはその間の任意の範囲の値を取得するのは非常に高速です。

ソートされたセットにユーザーをハイスコアとともに追加すると、完璧なリーダーボードになります。新しいハイスコアが入ったら、ハイスコアでセットに再度追加するだけで、リーダーボードが並べ替えられます。また、ユーザーが最後にアクセスした時間と、アプリケーションでアクティブなユーザーを追跡するのにも最適です。

同じスコアの値を保存すると、辞書式順序になります（アルファベット順に考えてください）。これは、オートコンプリート機能などに役立ちます。

ソートされたセットコマンドの多くは、セットのコマンドに似ていますが、スコアパラメータが追加されている場合があります。スコアを管理し、スコアごとにクエリを実行するためのコマンドも含まれています。

ジオ

Redisには、地理データを保存、取得、測定するためのコマンドがいくつかあります。これには、半径クエリとポイント間の距離の測定が含まれます。

技術的には、redisの地理データは並べ替えられたセット内に保存されるため、これは完全に別個のデータ型ではありません。これは、ソートされたセットに加えて、より多くの拡張機能です。

ビットマップとHyperLogLog

geoのように、これらは完全に別個のデータ型ではありません。これらは、文字列データをビットマップまたはハイパーログログのように扱うことができるコマンドです。

ビットマップは、私が参照したビットレベルの演算子のStrings目的です。このデータ型は、redditの最近のコラボレーティブアートプロジェクトであるr/Placeの基本的な構成要素でした。

HyperLogLogを使用すると、一定の非常に少量のスペースを使用して、ほぼ無制限の一意の値を驚異的な精度でカウントできます。わずか16KBを使用すると、たとえその数が数百万であっても、サイトへのユニークな訪問者の数を効率的に数えることができます。

トランザクションと原子性

redisのコマンドはアトミックです。つまり、redisに値を書き込むとすぐに、その値がredisに接続されているすべてのクライアントに表示されるようになります。その値が伝播するのを待つ必要はありません。技術的にはmemcachedもアトミックですが、redisがmemcached以外にこのすべての機能を追加することで、これらの追加のデータ型と機能もすべてアトミックであることは注目に値し、いくぶん印象的です。

リレーショナルデータベースのトランザクションとはまったく同じではありませんが、redisには「楽観的ロック」（WATCH / MULTI / EXEC ）を使用するトランザクションもあります。

パイプライン

Redisは「パイプライン」と呼ばれる機能を提供します。実行したいredisコマンドが多数ある場合は、パイプラインを使用して、一度に1つずつではなく、一度にredisに送信できます。

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

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

Pub / Sub

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

Redisは、ほとんどすべてのツールと同様にpub/subを実行します。RabbitMQのような専用のメッセージブローカーは特定の分野で利点があるかもしれませんが、同じサーバーが永続的な耐久性のあるキューや、pub / subワークロードが必要とする可能性のある他のデータ構造を提供できるという事実により、Redisは多くの場合最良かつ最も単純なツールであることが証明されます仕事で。

Luaスクリプティング

redis独自のSQLやストアドプロシージャのようなluaスクリプトを考えることができます。それはそれよりも多いことも少ないこともありますが、類推はほとんど機能します。

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

スクリプト全体がアトミックに実行されるため、ロジックをluaスクリプトに適合させることができれば、楽観的ロックトランザクションを台無しにすることを回避できることがよくあります。

スケーリング

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

結論

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

上記は、memcachedが好きではないように聞こえるかもしれません。それどころか、それは強力で、シンプルで、安定していて、成熟していて、強化されたツールです。redisよりも少し速いユースケースもあります。memcachedが大好きです。将来の開発にはあまり意味がないと思います。

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

memcachedがより理にかなっているシナリオは1つだけです。つまり、memcachedがすでにキャッシュとして使用されている場合です。すでにmemcachedでキャッシュしている場合は、ニーズに合っていれば、引き続き使用してください。redisに移行する価値はない可能性があり、キャッシュのためだけにredisを使用する場合は、時間の価値がある十分なメリットが得られない可能性があります。memcachedがニーズを満たしていない場合は、おそらくredisに移行する必要があります。これは、memcachedを超えてスケーリングする必要がある場合でも、追加機能が必要な場合でも当てはまります。

score 142 · Accepted Answer

次の場合はRedisを使用します

キャッシュ内のアイテムを選択的に削除/期限切れにする必要があります。（あなたはこれを必要とします）
特定のタイプのキーを照会する機能が必要です。eq。'blog1：posts：*'、'blog2：categories：xyz：posts：*'。そうそう！これは非常に重要です。これを使用して、特定のタイプのキャッシュされたアイテムを選択的に無効にします。これを使用して、フラグメントキャッシュ、ページキャッシュ、特定のタイプのARオブジェクトのみを無効にすることもできます。
永続性（再起動するたびにキャッシュをウォームアップする必要がある場合を除いて、これも必要になります。ほとんど変更されないオブジェクトには非常に重要です）

次の場合はmemcachedを使用します

Memcachedはあなたに頭を悩ませます！
うーん...クラスタリング？まあ。ここまで進む場合は、フラグメントとARオブジェクトのキャッシュにVarnishとRedisを使用します。

私の経験から、Redisの安定性はMemcachedよりもはるかに優れています。

score 109 · Accepted Answer

Memcachedはマルチスレッドで高速です。

Redisには多くの機能があり、非常に高速ですが、イベントループに基づいているため、完全に1つのコアに制限されています。

両方を使用します。Memcachedはオブジェクトのキャッシュに使用され、主にデータベースの読み取り負荷を軽減します。Redisは、時系列データをロールアップするのに便利なソート済みセットなどに使用されます。

score 92 · Accepted Answer

これは、すでに受け入れられている回答へのコメントとして投稿するには長すぎるため、別の回答として配置します

また、考慮すべきことの1つは、キャッシュインスタンスにハードメモリの上限があると予想されるかどうかです。

redisは多くの機能を備えたnosqlデータベースであり、キャッシュは使用できるオプションの1つにすぎないため、必要に応じてメモリを割り当てます。オブジェクトを追加するほど、使用するメモリも多くなります。このmaxmemoryオプションは、メモリの上限使用量を厳密に強制するものではありません。キャッシュを操作すると、キーが削除されて期限切れになります。キーがすべて同じサイズではない可能性があるため、内部メモリの断片化が発生します。

デフォルトでは、redisはjemallocメモリアロケータを使用します。これは、メモリコンパクトと高速の両方を実現するために最善を尽くしますが、汎用メモリアロケータであり、大量の割り当てと高速で発生するオブジェクトのパージに対応できません。このため、一部のロードパターンでは、内部の断片化が原因で、redisプロセスが明らかにメモリをリークする可能性があります。たとえば、7 Gb RAMを搭載したサーバーがあり、redisを非永続LRUキャッシュとして使用する場合、maxmemory時間の経過とともに5Gbに設定されたredisプロセスはますます多くのメモリを使用し、最終的にはRAMの合計制限に達する可能性があります。メモリ不足のキラーが干渉します。

memcachedは、まったく異なる方法でメモリを管理するため、上記のシナリオにより適しています。memcachedは、メモリの1つの大きなチャンク（必要なものすべて）を割り当て、独自に実装されたスラブアロケーターを使用してこのメモリを単独で管理します。さらに、memcachedは、オブジェクトサイズを考慮してLRUの削除が行われる場合、実際にはスラブごとのLRUアルゴリズムを使用するため、内部の断片化を低く抑えるように努めます。

そうは言っても、memcachedは、メモリ使用量を強制したり予測したりする必要がある環境で、依然として強力な位置を占めています。10〜15k op / sのワークロードで、ドロップインの非永続的なLRUベースのmemcached置換として、最新の安定したredis（2.8.19）を使用しようとしましたが、メモリリークが大量に発生しました。同じ理由で、同じワークロードが1日かそこらでAmazonのElastiCacheredisインスタンスをクラッシュさせていました。

score 46 · Accepted Answer

Memcachedは、単純なキー/値ストアであることに長けており、key=>STRINGを実行するのに長けています。これにより、セッションストレージに非常に適しています。

Redisはkey=>SOME_OBJECTを実行するのが得意です。

それは本当にあなたがそこに何を入れようとしているのかに依存します。私の理解では、パフォーマンスの点では、それらはかなり均一です。

また、客観的なベンチマークを見つけて頑張ってください。もしあなたが親切にそれらを私の方法で送ってくれるのを見つけたら。

score 37 · Accepted Answer

ひどい書き方を気にしないのであれば、SystoiletブログのRedis vs Memcachedは使いやすさの観点から読む価値がありますが、パフォーマンスについて結論を出す前に、コメントを前後に読んでください。いくつかの方法論的な問題（シングルスレッドのビジーループテスト）があり、記事が書かれて以来、Redisはいくつかの改善を行いました。

そして、少し混乱することなく完全なベンチマークリンクはないので、DormondoのLiveJournalとAntirezWeblogでいくつかの矛盾するベンチマークもチェックしてください。

編集-アンティレスが指摘しているように、システイル分析はかなり誤解されています。シングルスレッドの不足を超えても、これらのベンチマークのパフォーマンスの不一致の多くは、サーバーのスループットではなくクライアントライブラリに起因する可能性があります。Antirezウェブログのベンチマークは、実際、はるかに多くのリンゴとリンゴ（同じ口で）の比較を示しています。

score 24 · Accepted Answer

memcachedとredisの両方を、私が取り組んだキャッシングプロキシで一緒に使用する機会を得ました。正確に、同じ背後にあるものと理由を使用した場所を共有しましょう。

Redis>

1）クラスター上でキャッシュコンテンツのインデックスを作成するために使用されます。私はredisクラスター全体に10億を超えるキーを持っていますが、redisの応答時間はかなり短く安定しています。

2）基本的に、そのキー/値ストアなので、アプリケーションのどこにでも似たようなものがある場合は、非常に面倒なことにredisを使用できます。

3）Redisの永続性、フェイルオーバー、およびバックアップ（AOF）により、作業が容易になります。

Memcache>

1）はい、キャッシュとして使用できる最適化されたメモリ。サイズが1MB未満で非常に頻繁に（50ヒット/秒で）アクセスされるキャッシュコンテンツを保存するために使用しました。

2）単一のコンテンツサイズが1MBを超える場合も、16GBのうち2GBのみをmemcachedに割り当てました。

3）コンテンツが制限に近づくにつれて、統計で応答時間が長くなることがあります（redisの場合はそうではありません）。

全体的なエクスペリエンスを求める場合、Redisは構成が簡単で、安定した堅牢な機能を備えた柔軟性が高いため、非常に環境に配慮しています。

さらに、このリンクで利用可能なベンチマーク結果があります。以下は同じものからのいくつかのハイライトです、

お役に立てれば！！

score 15 · Accepted Answer

テスト。いくつかの簡単なベンチマークを実行します。私は主にmemcachedを使用し、Redisを新しい子供と見なしていたため、長い間、自分は古い学校のサイだと思っていました。

私の現在の会社では、Redisがメインキャッシュとして使用されていました。いくつかのパフォーマンス統計を掘り下げてテストを開始したとき、Redisはパフォーマンスの点で、MySQLと同等か、最小限の速度でした。

Memcachedは単純ですが、Redisを完全に水から吹き飛ばしました。それははるかに良くスケーリングしました：

より大きな値の場合（スラブサイズの変更が必要ですが、機能しました）
複数の同時リクエストの場合

また、memcached evictionポリシーは私の見解では、はるかに適切に実装されており、キャッシュが処理できるよりも多くのデータを処理しながら、全体的に安定した平均応答時間を実現しています。

いくつかのベンチマークでは、Redisのパフォーマンスが非常に低いことが明らかになりました。これは多くの変数と関係があると私は信じています：

Redisを実行するハードウェアの種類
保存するデータの種類
ゲットとセットの量
アプリの同時実行性
データ構造ストレージが必要ですか

個人的には、Redisの作成者が並行性とマルチスレッドについて持っている見解を共有していません。

score 13 · Accepted Answer

もう1つの利点は、キャッシュシナリオでmemcacheがどのように動作するかを非常に明確にできることです。一方、redisは一般に永続データストアとして使用されますが、memcachedと同じように動作するように構成できます。容量。

私が取り組んできたいくつかのアプリは、データがどのように動作するかを明確にするために両方を使用しています-memcacheにあるもの、データがない場合を処理するコードを記述します-redisにあるもの、そこにあることに依存しています。

それ以外のRedisは、ほとんどのユースケースで優れていると一般に見なされており、機能が豊富で柔軟性があります。

score 10 · Accepted Answer

redisは（キャッシュ+データ構造）の組み合わせであり、memcachedは単なるキャッシュであると言えば、間違いではありません。

score 9 · Accepted Answer

redis-2.2.2およびmemcachedに対して100kの一意のキーと値を設定および取得するための非常に簡単なテスト。どちらもLinuxVM（CentOS）で実行されており、私のクライアントコード（以下に貼り付けられています）はWindowsデスクトップで実行されています。

Redis

100000個の値を保存するのにかかる時間は=18954msです
100000個の値をロードするのにかかる時間は=18328msです

Memcached

100000個の値を保存するのにかかる時間は=797msです
100000個の値を取得するのにかかる時間は=38984msです

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

score 7 · Accepted Answer

ここで指摘されていない大きな違いの1つは、Memcacheには常に上限メモリがあるのに対し、Redisにはデフォルトではない（ただし、設定できる）ことです。キー/値を一定期間保存したい場合（そしてメモリが少ないためにそれを削除したくない場合）は、Redisを使用します。もちろん、メモリ不足の問題も発生する可能性があります...

score 7 · Accepted Answer

Redisにネットワーク（TCP呼び出し）が含まれている場合でも、パフォーマンスに関心がある場合は、Memcachedの方が高速になります。また、内部的にはMemcacheの方が高速です。

Redisには、他の回答で言及されているように、より多くの機能があります。

score 6 · Accepted Answer

私たちは、Redisを、作業中のプロジェクトのロードテイクオフと考えました。nginxと呼ばれるものなどでモジュールを使用することで、HttpRedis2Module驚くほどの速度が得られると思いましたが、ABテストでテストすると間違っていることがわかりました。

モジュールが悪かったか、レイアウトが悪かったかもしれませんが、それは非常に単純なタスクであり、phpを使用してデータを取得し、それをMongoDBに詰め込む方がさらに高速でした。キャッシュシステムとしてAPCを使用しており、そのphpとMongoDBを使用しています。nginxRedisモジュールよりもはるかに高速でした。

私のヒントは、自分でテストすることです。テストすると、環境の結果が表示されます。私たちのプロジェクトでは、意味がないため、Redisを使用する必要はないと判断しました。

score 6 · Accepted Answer

残っている最大の理由は専門化です。

Redisはさまざまなことを実行できますが、その1つの副作用として、開発者は同じインスタンスでさまざまな機能セットを使い始める可能性があります。LRUではないハードデータストレージと一緒にキャッシュにRedisのLRU機能を使用している場合、メモリが不足する可能性があります。

その特定のシナリオを回避するためにLRUインスタンスとしてのみ使用される専用のRedisインスタンスをセットアップする場合、MemcachedではなくRedisを使用する理由は実際にはありません。

信頼性の高い「ダウンしない」LRUキャッシュが必要な場合...Memcachedは、設計上メモリが不足することは不可能であり、特殊な機能により、開発者がそれを危険にさらす可能性のあるものにしようとするのを防ぐため、問題に適合します。関心の分離。

score 1 · Accepted Answer

Redisの方が優れています。

の長所Redisは、

文字列、セット、ソートされたセット、ハッシュ、ビットマップなどの多くのデータストレージオプションがあります
レコードのディスク永続性
ストアドプロシージャ（LUAスクリプト）のサポート
PUB/SUBを使用してメッセージブローカーとして機能できます

一方Memcache、はメモリ内のキー値キャッシュタイプのシステムです。

リスト、redisのようなセットなどのさまざまなデータ型ストレージはサポートされていません。
主な欠点は、Memcacheにディスクの永続性がないことです。

score 0 · Accepted Answer

これがAmazonが提供する本当に素晴らしい記事/違いです

Redisは、memcachedと比較して明らかに勝者です。

Memcachedのプラスポイントは1つだけ です。マルチスレッドで高速です。Redisには多くの優れた機能があり、非常に高速ですが、1つのコアに制限されています。

MemcachedでサポートされていないRedisの優れた点

スナップショット-ユーザーはRedisキャッシュのスナップショットを取得し、いつでもセカンダリストレージに保持できます。
Set、Map、SortedSet、List、BitMapsなどの多くのデータ構造の組み込みサポート。
redisでのLuaスクリプトのサポート