MemcachedとRedis？

概要（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はサードパーティツールの明確なリーダーとしても浮上してきました。 Redis Labs、Amazonなどの企業は、多くの便利なRedisツールとサービスを提供しています。 redis周辺のエコシステムははるかに大きいです。大規模なデプロイの数は、memcachedの場合よりも多くなる可能性があります。

Redisスーパーセット

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

ドキュメント

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

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

現在、redisのスタックオーバーフローの結果は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回の応答で応答できます。

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

パブ/サブ

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

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を超えてスケ​​ーリングする必要がある場合でも、追加機能が必要な場合でも当てはまります。