ディスクに永続化できるmemcachedの代替

Question

私は現在、Javaアプリでmemcachedを使用していますが、全体としてはうまく機能しています。

私にとって最も重要なmemcachedの機能は次のとおりです。

読み取りと書き込みがメモリ内にあり、ディスクに触れないため、高速です
それはただのキー/値ストアです（これは私のアプリが必要とするものだからです）
配布されています
各オブジェクトを正確に1つのサーバーに配置することにより、メモリを効率的に使用します。
オブジェクトがデータベースからのものであるとは想定していません（私のオブジェクトはデータベースオブジェクトではないため）

ただし、memcachedではできないことを1つやりたいと思います。キャッシュのコンテンツを定期的に（おそらく1日に1回）ディスクに保存します。そして、保存したディスクイメージからキャッシュを復元できるようにしたいと思います。

ディスクの保存は非常に複雑である必要はありません。保存中に新しいキー/値が追加された場合、保存に含まれているかどうかは気にしません。また、保存中に既存のキー/値が変更された場合、保存された値は古い値または新しい値のいずれかである必要がありますが、どちらを選択してもかまいません。

私にとって重要なmemcached機能のすべて（またはかなりの割合）があり、ディスクからキャッシュ全体を保存および復元できる機能を備えた別のキャッシングソリューション（無料または商用）を推奨できますか？

realMarkusSchmidt · Accepted Answer

私のようなあなたの問題かもしれません：私はmemcached用のマシンを数台しか持っていませんが、メモリはたくさんあります。それらの1つが失敗したり、再起動する必要がある場合でも、システムのパフォーマンスに深刻な影響を及ぼします。元のmemcachedの哲学によれば、それぞれより少ないメモリでより多くのマシンを追加する必要がありますが、それはコスト効率がよくなく、正確に「グリーンIT」ではありません;）

このソリューションでは、キャッシュシステムのインターフェイスレイヤーを構築し、基になるキャッシュシステムへのプロバイダーがnestedになり、ストリームでできるように、memcachedと同様にキャッシュプロバイダーを作成しました。独自の非常にシンプルなKey-Value-2-diskストレージプロバイダー。次に、キャッシュから取得できない場合にアイテムを再構築するコストを表すキャッシュアイテムの重みを定義します。ネストされたディスクキャッシュは、特定のしきい値（おそらくすべてのアイテムの約10％）を超えるウェイトを持つアイテムにのみ使用されます。

オブジェクトをキャッシュに保存するとき、いずれかまたは両方のキャッシュへの保存がとにかく非同期実行のためにキューに入れられるため、時間を無駄にしません。したがって、ディスクキャッシュへの書き込みは高速である必要はありません。読み取りについても同じです。まず、memcachedを使用します。それが存在せず、「コストの高い」オブジェクトである場合にのみ、ディスクキャッシュを確認します（memcachedよりもかなり遅いですが、30 GBの再計算よりもはるかに優れています） 1台のマシンがダウンした後のデータ）。

このようにして、memcachedを新しいものに置き換えることなく、両方の世界から最高のものを取得します。

Pascal MARTIN · Answer

試したことはありませんが、 redis はどうですか？
そのホームページには（引用）と書かれています：

Redisはキーと値のデータベースです。これはmemcachedに似ていますが、データセットは揮発性ではなく、値はmemcachedの場合とまったく同じ文字列にすることができますが、プッシュ/ポップ要素へのアトミック操作を含むリストおよびセットも可能です。

非常に高速であると同時に、データセット全体がメモリに保持されるため、および/またはデータセットへの多数の変更が実行されると、ディスク上に非同期的に書き込まれます。多くのアプリケーションで受け入れ可能な最後のいくつかのクエリを失う可能性がありますが、メモリDBと同じくらい高速です（Redisは冗長性によってこの問題を解決するために、非ブロッキングマスタースレーブレプリケーションをサポートします）。

あなたが話したいくつかのポイントに答えているようですので、おそらくあなたの場合、それは役に立つかもしれませんか？

あなたがそれを試してみると、私はあなたが見つけたものにかなり興味があります、btw ;-)

補足として、これをすべてディスクに書き込む必要がある場合、cacheシステムは実際には必要なものではないかもしれません。結局、memcachedをcacheとして使用している場合、必要なときにいつでもオンデマンドで再投入できるはずです-それでも、memcachedクラスター全体が一度に落ちると、パフォーマンスの問題が発生する可能性があります...

それでは、「より多くの」キー/バリューストア指向のソフトウェアが役立つかもしれません。 CouchDB のようなものですか？
データはRAMではなくディスクに保存されるため、おそらくmemcachedほど高速ではありません...

skaffman · Answer

EhCache には、シャットダウン時にキャッシュの内容をディスクにダンプする「ディスク永続的」モードがあり、バックアップを再開するとデータが復元されます。他の要件については、分散モードで実行する場合、1つのノードにデータを保存するのではなく、すべてのノードにデータを複製します。それ以外は、あなたのニーズにうまく合うはずです。他の多くのJavaキャッシングフレームワークはそうではありません。

valyala · Answer

go-memcached を試してください- Go で書かれたmemcacheサーバー。キャッシュされたデータをそのままディスクに保持します。 Go-memcachedはmemcacheクライアントと互換性があります。元の memcached にはない次の機能があります。

キャッシュされたデータは、サーバーのクラッシュや再起動に耐えます。
キャッシュサイズは、使用可能なサイズを超える可能性がありますRAM.
キーサイズに250バイトの制限はありません。
値のサイズに1Mbの制限はありません。値のサイズは実際には2Gbに制限されています。
元の memcached よりも高速です。また、着信要求を処理するときのCPU使用量が少なくなります。

go-memcached-bench で取得したパフォーマンスの数値は次のとおりです。

----------------------------------------------------- | | go-memcached | original memcached | | | v1 | v1.4.13 | | workerMode ---------------------------------------- | | Kqps | cpu time | Kqps | cpu time | |---------------------------------------------------- | GetMiss | 648 | 17 | 468 | 33 | | GetHit | 195 | 16 | 180 | 17 | | Set | 204 | 14 | 182 | 25 | | GetSetRand | 164 | 16 | 157 | 20 | -----------------------------------------------------

go-memcached および go-memcached-bench の静的にリンクされたバイナリは downloads page で入手できます。

Mads Hansen · Answer

Apache Java Caching System（JCS）をご覧ください

JCSは、Javaで記述された分散キャッシュシステムです。さまざまな動的な性質のキャッシュされたデータを管理する手段を提供することにより、アプリケーションを高速化することを目的としています。他のキャッシングシステムと同様に、JCSは読み取りの多い低出力のアプリケーションに最も役立ちます。効果的にキャッシュされたシステムでは、待ち時間が大幅に短縮され、ボトルネックがデータベースから遠ざかります。 JCSの使用を開始する方法を学びます。

JCSは、単にオブジェクトをメモリにキャッシュするだけではありません。多数の追加機能を提供します。
* Memory management * Disk overflow (and defragmentation) * Thread pool controls * Element grouping * Minimal dependencies * Quick nested categorical removal * Data expiration (idle time and max life) * Extensible framework * Fully configurable runtime parameters * Region data separation and configuration * Fine grained element configuration options * Remote synchronization * Remote store recovery * Non-blocking "zombie" (balking facade) pattern * Lateral distribution of elements via HTTP, TCP, or UDP * UDP Discovery of other caches * Element event handling * Remote server chaining (or clustering) and failover * Custom event logging hooks * Custom event queue injection * Custom object serializer injection * Key pattern matching retrieval * Network efficient multi-key retrieval 

Benjamin Nitlehoo · Answer

membase はあなたが望むものだと思います。

Tit Petric · Answer

私の経験では、アプリケーションとバックエンドストレージの間に中間層を記述するのが最善です。このようにして、memcachedインスタンスと、たとえばsharedanced（基本的には同じキーと値のストアですが、ディスクベース）をペアにできます。これを行う最も基本的な方法は、常にmemcachedから読み取り、sharedancedにフェールバックし、常にsharedancedおよびmemcachedに書き込むことです。

複数の共有インスタンス間でシャーディングすることにより、書き込みをスケーリングできます。 repcached（レプリケートされたmemcached）などのソリューションを使用して、読み取りをN倍にスケーリングできます。

これが簡単ではない場合でも、memcachedの基本的な代替としてsharedancedを使用できます。高速で、ほとんどのファイルシステム呼び出しは最終的にキャッシュされます-memcachedをsharedanceと組み合わせて使用すると、memcacheで一部のデータが期限切れになるまでsharedancedからの読み取りのみが回避されます。 memcachedサーバーを再起動すると、すべてのクライアントが共有インスタンスから少なくとも1回読み取ります。同じキーに対して非常に高い同時実行性があり、クライアントが同じキーに対して競合しない限り、実際には問題ではありません。

非常にトラフィックの多い環境を扱っている場合、特定の問題があります。1つはファイルシステムの選択です（reiserfsはfsツリーの内部キャッシュのためにext3より5〜10倍優れています）。udpサポートはありません（TCPキープアライブ共有のみを使用する場合はかなりオーバーヘッドになり、memcachedはFacebookチームのおかげでudpを持ちます）、スケーリングは通常、アプリケーションで行われます（共有サーバーの複数のインスタンス間でデータを分割することによって）。

これらの要素を活用できるなら、これはあなたにとって良い解決策かもしれません。現在の設定では、1台のsharedanced/memcacheサーバーで1日に約1,000万ページビューまで拡張できますが、これはアプリケーションに依存します。私たちはすべて（facebookなど）にキャッシュを使用するわけではないため、アプリケーションに関しては結果が異なる場合があります。