データ アナリスト、データ エンジニア、データベース管理者、データ サイエンティスト、データ アーキテクトなどの豊富な仕事を見つけることができる世界では、社会として、データの収集、保存、分析が身近なものであることは明らかです。私たちにとって大切です。 私たちは、特にビジネスにおいて、際限なくデータに依存しています。 そのため、最近の企業は、ハッキング、自然災害、およびその他の形態のデータ損失に対して特に脆弱です。
分散キャッシュは、データに大きく依存するもう XNUMX つの方法です。 そして、これらの脆弱性がそのような不確実性を引き起こしているため、いくつかの分散型キャッシング プラットフォーム ( NCache & Redis) 顧客に安心を提供する 永続ストア. 持続性とは、永続的なストレージとデータのバックアップのために特定の場所にデータを書き込むプロセスを指します。
持続性が必要な理由
しかし、そのようなプラットフォームでは変動性が予想される傾向があるのに、なぜ分散キャッシングにそのようなバックアップが必要なのでしょうか? 同様に、他のソースからキャッシュ データを取得しているのに、なぜこれがそれほど重要なのでしょうか?
すべてのキャッシュ データを (偶然または意図的に、たとえば致命的な障害やノードのメンテナンスによって) 失った場合、アプリケーションは既存のすべてのデータをゆっくりと再処理することを余儀なくされます。さらに、元のデータ ソースへの移動にお金や時間の面でコストがかかる場合、再作成プロセス全体が悪夢になる可能性があります。このような永続ストアは、キャッシング ソリューションが提供する場合に大きな利点があることは明らかです。しかし、誰の解決策がより優れているでしょうか?話し合って決めましょう。
Redis 対。 NCache 永続ストア
彼らはどのように機能するのですか?
NCache永続ストア内のオブジェクトを更新するための の手法全体は非同期であり、不必要な待機時間を節約する永続キューを採用しています。 バックグラウンド スレッドは、このキュー内のすべての操作を (定義済みの間隔で) 単純に調べて、作業を続行しながら、それらをそのままストアにコピーします。 そのため、書き込み操作を実行すると、キャッシュはデータをストアに追加する前にメモリに読み込みます。
一方、 Redis 永続性を使用できる XNUMX つの異なる方法を提供します。 RDB (Redis データベース)、AOF (追加のみのファイル)、および RDB + AOF です。 RDB を使用すると、定期的にデータセットのコピーが作成されます。 彼らはこのプロセスをスナップショットと呼び、Microsoft ソフトウェアで採用されている保存されていないドラフト バージョン システムと同様に機能します。
AOF は操作ログに似ています。 発生したすべての書き込み操作をカタログ化するだけです。 AOF と RDB を一緒に使用すると、キャッシュ内で行われているプロセスの全体像が示されます。
なぜですか NCache より良い Redis?
バックアップ間隔の増加とデータ損失の可能性の減少
まず第一に、 NCache ユーザーは XNUMX 秒以降の任意の間隔を設定できます。これにより、キャッシュ データが失われる可能性が最小限に抑えられます。 あるいは、 Redis バックアップ時間のオプションがいくつかあります (つまり、バックアップなし、1 時間ごと、6 時間ごと、または 12 時間ごと)。 さらに、 Redis データの損失を最小限に抑える場合、特に停電などに対処する場合、RDB は優れた選択肢ではないことを彼ら自身が認めています。
不要なメモリ消費なし
NCache 最適化されたキューを使用して常に更新される永続データのバージョンを XNUMX つだけ作成します。 このプロセスは、オプションと比較してメモリ効率がはるかに優れています Redis 提供します。 たとえば、スナップショット プロセスではデータベースの複数のコピーが作成され、メモリが不必要に消費されます。 AOF ファイルは通常、同じデータセットを考慮した場合でも、同等の RDB ファイルよりもさらに大きくなります。 その間 Redis は、AOF が大きくなりすぎたときに、バックグラウンドで AOF を書き換える機能があると主張していますが、このプロセスにはまったく新しいファイルの作成が含まれます。 そして、使用することを選択した場合、この書き換えは完全に不要になります NCache.
非同期バックアップ操作
NCache queue in は完全に非同期で動作し、特定の時点で永続ストアに書き込めない場合でも、キューに入れられたデータはどこにも行きません。 一方で、 Redis fsync ポリシーを使用して、AOF オプションの操作を記録します。 デフォルトでは、このメカニズムは書き込み操作にバックグラウンド スレッドを使用します。 残念ながら、スレッドがこれらの操作を実行できるのは、fsync が進行中でないときだけです。
ほぼリアルタイムの運用と高可用性
私たちが議論したように NCache 非常に短い時間間隔を設定する機能をユーザーに提供します。 したがって、非同期であるにもかかわらず、データの永続性はほぼリアルタイムであり、アプリケーションのパフォーマンスが低下することはありません。 データ損失の可能性がほとんどまたはまったくないことを繰り返し示す観察 NCache 永続性、特に~と比較して Redis.
さらに、アプリケーションは、キャッシュ クラスターにロードし直しながら、まだキャッシュ クラスターに格納されていないデータにアクセスできます。 このプロセスがまだメモリ内で完了していない場合は、 NCache 永続ストレージから自動的に読み取ります。
Disaster Recovery
データ損失といえば、物事が壊滅的にうまくいかないとき NCache、キャッシュの再起動時にすべてのデータにアクセスできます。 一方、別の方法では、永続化間隔が長いため、古いバージョンのデータしかありません。
最適化されたキュー
さらに、XNUMX つの書き込み操作 (操作の更新と削除) が発生した場合、 NCacheの最適化されたキューは、不要な更新を実行する代わりに単純に削除します。 残念ながら、 Redis 冗長性を考慮していません。
組み込む Redisの強み
最後に、永続ストアがより強力な機能であることは観察できますが、 NCacheの側面の場合 Redisの方法論はあなたにアピールします。それに対する解決策も用意しています。 たとえば、特定の時点でのデータセットを表示する可能性に興味がある場合は、 NCache ユーザーにオプションを提供します キャッシュ データのインポート/エクスポート. 同様に、それはまた広範囲を提供します 監視機能 だけの外 NCache ログ (これは AOF のより最適化されたバージョンです)、それは経由で監視ツールを提供します NCache マネージャー, PowerShellの、さまざまな PerfMon ツール, SNMP カウンター、および次のようなサードパーティ ツール グラファナ & プロメテウス.
まとめ
明らかに、 NCache 永続性に関しては、ユーザーに両方の長所を提供します。 そして、永続性が主な関心事である場合でも、おまけとして得られる一連の管理と構成が簡単なツールについては言及しません。 何を求めている? ダウンロード NCache 今すぐ 60 日間の無料トライアルを始めましょう!