キャッシュでRedisがMemcachedに勝る理由

MemcachedまたはRedis?これは、最新のデータベース駆動型Webアプリケーションからより多くのパフォーマンスを引き出すことについての議論で、ほとんど常に発生する質問です。パフォーマンスを改善する必要がある場合、多くの場合、キャッシュが最初のステップであり、MemcachedまたはRedisが最初に使用する場所です。

これらの有名なキャッシュエンジンには多くの類似点がありますが、重要な違いもあります。2つの中でより新しく、より用途の広いRedisは、ほとんどの場合、優れた選択肢です。

キャッシュ用のRedisとMemcached

類似点から始めましょう。 MemcachedとRedisはどちらも、メモリ内のKey-Valueデータストアとして機能しますが、Redisはデータ構造ストアとしてより正確に記述されています。 MemcachedとRedisはどちらもデータ管理ソリューションのNoSQLファミリーに属しており、どちらもKey-Valueデータモデルに基づいています。どちらもすべてのデータをRAMに保持するため、もちろんキャッシュレイヤーとして非常に便利です。パフォーマンスの点でも、2つのデータストアは非常に類似しており、スループットと遅延に関してほぼ同じ特性(およびメトリック)を示します。

MemcachedとRedisはどちらも成熟しており、非常に人気のあるオープンソースプロジェクトです。Memcachedは、2003年にLiveJournalWebサイト用にBradFitzpatrickによって開発されました。それ以来、MemcachedはCで書き直され(元の実装はPerlでした)、パブリックドメインに置かれ、最新のWebアプリケーションの基礎となっています。Memcachedの現在の開発は、新しい機能を追加するのではなく、安定性と最適化に重点を置いています。

Redisは2009年にSalvatoreSanfilippoによって作成され、Sanfilippoは現在もプロジェクトの主任開発者です。Redisは「ステロイドのMemcached」と呼ばれることもありますが、Memcachedの使用から学んだ教訓に基づいて、Redisの一部が構築されたことを考えると、驚くことではありません。RedisはMemcachedよりも多くの機能を備えているため、より強力で柔軟性があります。

多くの企業やミッションクリティカルな本番環境で使用されているMemcachedとRedisは、考えられるすべてのプログラミング言語のクライアントライブラリでサポートされており、開発者向けの多数のパッケージに含まれています。実際、これはMemcachedまたはRedisのいずれの組み込みサポートも含まれていないまれなWebスタックです。

MemcachedとRedisがそれほど人気が​​あるのはなぜですか?それらは非常に効果的であるだけでなく、比較的単純でもあります。MemcachedまたはRedisのいずれかを使い始めることは、開発者にとって簡単な作業と見なされます。セットアップしてアプリケーションで動作させるのに数分しかかかりません。したがって、わずかな時間と労力の投資が、パフォーマンスに即座に劇的な影響を与える可能性があります。通常は桁違いに影響します。大きなメリットがあるシンプルなソリューション。それはあなたが得ることができる限り魔法に近いです。

Memcachedを使用する場合

Memcachedは、HTMLコードフラグメントなどの比較的小さく静的なデータをキャッシュする場合に適しています。Memcachedの内部メモリ管理は、Redisほど洗練されていませんが、メタデータに消費するメモリリソースが比較的少ないため、最も単純なユースケースではより効率的です。文字列(Memcachedでサポートされている唯一のデータ型)は、文字列がそれ以上の処理を必要としないため、読み取られるだけのデータを格納するのに理想的です。

大規模なデータセットにはシリアル化されたデータが含まれることが多く、保存するためにより多くのスペースが常に必要になります。Memcachedは事実上、データをシリアル化された形式で保存するように制限されていますが、Redisのデータ構造はデータのあらゆる側面をネイティブに保存できるため、シリアル化のオーバーヘッドが削減されます。

MemcachedがRedisよりも優れている2番目のシナリオは、スケーリングです。Memcachedはマルチスレッドであるため、より多くの計算リソースを与えることで簡単にスケールアップできますが、キャッシュされたデータの一部またはすべてが失われます(コンシステントハッシュを使用するかどうかによって異なります)。ほとんどがシングルスレッドであるRedisは、データを失うことなく、クラスタリングを介して水平方向に拡張できます。クラスタリングは効果的なスケーリングソリューションですが、セットアップと操作は比較的複雑です。

Redisをいつ使用するか

データ構造のため、ほとんどの場合、Redisを使用することをお勧めします。Redisをキャッシュとして使用すると、多くのパワー(キャッシュの内容や耐久性を微調整する機能など)と全体的な効率が向上します。データ構造を使用すると、特定のアプリケーションシナリオで効率が大幅に向上します。

Redisの優位性は、キャッシュ管理のほぼすべての側面で明らかです。キャッシュは、データエビクションと呼ばれるメカニズムを採用して、メモリから古いデータを削除することにより、新しいデータ用のスペースを確保します。Memcachedのデータ排除メカニズムは、最近使用されていないアルゴリズムを採用しており、新しいデータとサイズが類似しているデータをいくらか任意に排除します。

対照的に、Redisでは、エビクションをきめ細かく制御できるため、6つの異なるエビクションポリシーから選択できます。Redisは、メモリ管理とエビクション候補の選択に対して、より高度なアプローチも採用しています。Redisは、レイジーエビクションとアクティブエビクションの両方をサポートします。この場合、データは、より多くのスペースが必要な場合、またはプロアクティブにのみエビクトされます。 

Redisを使用すると、キャッシュできるオブジェクトに関してはるかに高い柔軟性が得られます。Memcachedはキー名を250バイトに制限し、プレーンな文字列でのみ機能しますが、Redisではキー名と値をそれぞれ512MBまで大きくすることができ、バイナリセーフです。さらに、Redisには5つの主要なデータ構造から選択でき、インテリジェントなキャッシュとキャッシュされたデータの操作を通じて、アプリケーション開発者に可能性の世界を開きます。

データの永続性のためのRedis

Redisデータ構造を使用すると、キャッシュ中だけでなく、データを永続的に常に利用できるようにしたい場合でも、いくつかのタスクを簡素化および最適化できます。たとえば、オブジェクトをシリアル化された文字列として保存する代わりに、開発者はRedisハッシュを使用してオブジェクトのフィールドと値を保存し、単一のキーを使用してそれらを管理できます。 Redis Hashを使用すると、開発者は、文字列全体をフェッチして逆シリアル化し、値を更新し、オブジェクトを再シリアル化し、キャッシュ内の文字列全体を些細な更新ごとに新しい値に置き換える必要がなくなります。つまり、リソース消費量が少なくなり、パフォーマンスが向上します。

Redisが提供する他のデータ構造(リスト、セット、ソートされたセット、ハイパーログログ、ビットマップ、地理空間インデックスなど)を使用して、さらに複雑なシナリオを実装できます。時系列データの取り込みと分析のために並べ替えられたセットは、Redisデータ構造の別の例であり、複雑さを大幅に軽減し、帯域幅の消費を抑えます。

Redisのもう1つの重要な利点は、格納するデータが不透明ではないため、サーバーが直接操作できることです。Redisで利用可能な180以上のコマンドのかなりの部分は、サーバー側のLuaスクリプトを介して、データ処理操作とデータストア自体へのロジックの埋め込みに充てられています。これらの組み込みコマンドとユーザースクリプトにより、データをネットワーク経由で別のシステムに送信して処理することなく、Redisで直接データ処理タスクを処理できる柔軟性が得られます。

Redisは、計画的なシャットダウンまたは計画外の障害の後にキャッシュをブートストラップするように設計された、オプションの調整可能なデータ永続性を提供します。キャッシュ内のデータは揮発性で一時的なものと見なされる傾向がありますが、データをディスクに永続化することは、キャッシュのシナリオで非常に価値があります。再起動直後にキャッシュのデータをロードできるようにすると、キャッシュのウォームアップが大幅に短縮され、プライマリデータストアからのキャッシュコンテンツの再入力と再計算に伴う負荷が軽減されます。

Redisインメモリデータレプリケーション 

Redisは、管理するデータを複製することもできます。レプリケーションは、障害に耐え、アプリケーションに中断のないサービスを提供できる高可用性キャッシュセットアップを実装するために使用できます。キャッシュの障害は、ユーザーエクスペリエンスとアプリケーションのパフォーマンスへの影響という点で、アプリケーションの障害にわずかに及ばないため、ほとんどの場合、キャッシュの内容とサービスの可用性を保証する実証済みのソリューションがあることが大きな利点です。

最後になりましたが、操作の可視性の観点から、Redisは、使用状況と異常な動作を監視および追跡するための多数のメトリックと豊富な内​​省コマンドを提供します。データベースのあらゆる側面、実行中のすべてのコマンドの表示、クライアント接続の一覧表示と管理に関するリアルタイムの統計—Redisにはそれ以上のものがあります。

開発者は、Redisの永続性とメモリ内レプリケーション機能の有効性を認識すると、通常、高速データを分析および処理し、セカンダリ(多くの場合低速)データベースが維持している間にユーザーに応答を提供するために、ファーストレスポンダーデータベースとして使用します。何が起こったかの歴史的記録。このように使用すると、Redisは分析のユースケースにも最適です。

データ分析のためのRedis

3つの分析シナリオがすぐに思い浮かびます。最初のシナリオでは、Apache Sparkのようなものを使用して大きなデータセットを繰り返し処理する場合、以前にSparkによって計算されたデータのサービングレイヤーとしてRedisを使用できます。 2番目のシナリオでは、Redisを共有のメモリ内分散データストアとして使用すると、Sparkの処理速度を45〜100倍高速化できます。最後に、非常に一般的なシナリオは、レポートと分析を次のようにカスタマイズする必要があるシナリオです。ユーザーですが、本質的にバッチデータストア(HadoopやRDBMSなど)からデータを取得するには時間がかかりすぎます。この場合、Redisなどのインメモリデータ構造ストアが、ミリ秒未満のページングと応答時間を取得する唯一の実用的な方法です。

非常に大規模な運用データセットまたは分析ワークロードを使用する場合、すべてをメモリ内で実行しても費用効果が高くない可能性があります。低コストでサブミリ秒のパフォーマンスを実現するために、Redis Labsは、RAMとフラッシュの比率を構成するオプションを備えたRAMとフラッシュの組み合わせで実行されるバージョンのRedisを作成しました。これにより、ワークロード処理を高速化するためのいくつかの新しい手段が開かれますが、開発者は「フラッシュ上のキャッシュ」を実行するオプションも提供されます。

オープンソースソフトウェアは、今日利用可能な最高のテクノロジーのいくつかを提供し続けています。キャッシングによるアプリケーションのパフォーマンスの向上に関しては、RedisとMemcachedが最も確立され、本番環境で実証された候補です。ただし、Redisのより豊富な機能、より高度な設計、多くの潜在的な用途、および大規模なコスト効率の向上を考えると、ほとんどすべての場合において、Redisを最初に選択する必要があります。

---

Itamar Haber(@itamarhaber)は、Redis Labsの主任開発者擁護者であり、開発者向けのフルマネージドクラウドサービスとしてMemcachedとRedisを提供しています。彼のさまざまな経験には、Xeround、Etagon、Amicada、およびMNS Ltdでのソフトウェア製品の開発と管理、およびリーダーシップの役割が含まれます。コンピュータサイエンスの科学の。

New Tech Forumは、前例のない深さと幅で新しいエンタープライズテクノロジーを探索して議論する場を提供します。選択は主観的であり、読者にとって重要で最も興味深いと思われるテクノロジーの選択に基づいています。出版用のマーケティング資料を受け入れず、寄稿されたすべてのコンテンツを編集する権利を留保します。すべてのお問い合わせは[email protected]までお送りください。