Redis vs NCache
録画されたウェビナー
ロン・フセイン、ザック・カーン著
NCache ネイティブの .NET オープンソース分散キャッシュであり、高トランザクションの .NET の間で非常に人気があります。 .NET Core そしてJavaアプリケーション。 Redis によって開発されている Redis Labs であり、現在 Microsoft によって Azure で使用されています。 このウェビナーでは、その方法を学びます NCache & Redis 互いに比較してください。 このウェビナーの目的は、特に機能、パフォーマンス、スケーラビリティ、高可用性、データ信頼性、管理などの定性的な側面において、XNUMX つの製品を比較するタスクをより簡単かつ迅速に行えるようにすることです。
このウェビナーの内容は次のとおりです。
- パフォーマンスとスケーラビリティ
- キャッシュの弾力性（高可用性）
- キャッシュトポロジ
- SQL と LINQ キャッシュの検索
- サードパーティの統合 (EF、EF Core、NHibernate など)
今日は、非常によく似ていますが、多くの点で異なる XNUMX つの製品を比較するというトピックがあります。 それで、私たちは、 NCache これは、.NET 用の主要な分散キャッシュ製品であり、 .NET Core 次に、機能の観点から比較します。 Redis。 したがって、この記事では取り上げなければならないことがたくさんあります。 プラットフォームとテクノロジースタックから始めて、多くの技術的な詳細を説明します。 次に、クラスタリングについて説明します。 キャッシュ クラスタリングに関してこれら XNUMX つの製品を比較する方法と、これらの製品を使用することで得られるさまざまな利点と比較して、 NCache の方が優れています。その後、さまざまな機能について説明します。 私たちは行きます 機能ごとの比較 これらの製品を使用できるさまざまなユースケースについて説明し、機能比較の観点からこれら XNUMX つの製品をどのように比較するかを説明します。
このウェビナーのために私が選んだのは、 NCache Enterprise 5.0.2、限りでは Redis 懸念があるため、主に Azure に焦点を当てます Redis。 それがオープンソースです Redis 4.0.1.4。 ただし、詳細についても説明します。 Redis オープンソース プロジェクトだけでなく、 Redis 商用版であるラボ Redis。 それでは比較してみます NCache これらすべてのフレーバーがありますが、私たちの主な焦点は Microsoft Azure です。 Redisのホストされたモデル Redis Microsoft Azure で入手できます。
スケーラビリティの問題
したがって、始める前に、主にこれら XNUMX つの製品について詳しく説明します。 では、なぜ分散キャッシュ ソリューションが必要なのでしょうか?
それで、その後、さまざまな製品を比較してみることになります。 したがって、通常、アプリケーション内で発生する可能性があるのは、スケーラビリティとパフォーマンスの課題です。 アプリケーションに大量のデータ負荷がかかっている可能性があります。アプリケーション層は非常にスケーラブルですが、いつでも Web ファームを作成でき、アプリケーション層にリソースを追加できますが、それらすべてのアプリケーション インスタンスは戻って相互に通信する必要があります。 -データソースを終了します。 また、これらのデータ ソースに戻って通信する必要がある場合、データベース (通常はリレーショナル データベース) はトランザクション負荷の処理が遅いため、パフォーマンスの問題が発生します。
それらに関連するパフォーマンスの問題があり、さらにスケールアウトの観点から言えば、たとえば、大量のリクエスト処理能力や要件が必要な場合、多くのリクエストを処理する必要があり、アプリケーションが大量のリクエストを生成している場合などです。ユーザー負荷に応じて、データベースはその極端なトランザクション負荷を処理できるように設計されていません。 大量のデータを保存できるストレージには非常に適していますが、そのデータにトランザクション負荷がかかることはデータベースにはあまり適していません。 窒息する可能性があります。 速度が低下し、エンド ユーザー エクスペリエンスが低下する可能性があります。
そのため、パフォーマンスに影響が出る可能性があり、アプリケーション アーキテクチャ内の容量を増やすことはできません。
解決策：インメモリ分散キャッシュ（NCache)
解決策は非常に簡単で、次のようなメモリ内分散キャッシュ システムを使用します。 NCache メモリ内にあるため超高速です。 したがって、リレーショナル データベースやファイル システム、その他のメモリベースではないデータ ソースと比較して、ディスクからデータを取得する場合、データをメモリ上に保存する場合と比較して、メモリ内に保存すると、データ ソースは非常に優れたものになります。速い。 したがって、それによって得られる最初の利点は、超高速のパフォーマンスが得られることです。 NCache.
XNUMX 番目の利点は、キャッシュ クラスターであることです。 それは単一のソースだけではありません。 XNUMX 台のサーバーから始めることもできますが、通常は少なくとも XNUMX 台のサーバーを使用し、キャッシュ クラスターを作成することをお勧めします。そのキャッシュ クラスターを作成したらすぐに、すべてのサーバーに負荷を分散し、継続的に負荷を分散すれば改善されます。実行時にさらにサーバーを追加します。
したがって、サーバーを追加することで容量を拡張したり、実行時の容量を増やしたり、バックエンドのリレーショナル データベースと組み合わせて使用したりできます。 これは従来のリレーショナル データベースに代わるものではありません。いくつかの使用例については後ほど説明します。
分散キャッシュの導入 (NCache)
ここでは典型的な展開を示します。
私が使用しています NCache 現時点では例として説明しますが、最終的にはこのプレゼンテーション内でどのように比較するかを説明します。 Redis 導入とその方法 NCache 導入されるか、またこれらの製品内で利用できる柔軟性は何ですか。
だから、 NCache、非常に柔軟です。 Linux 環境だけでなく Windows にもデプロイすることを選択できます。 オンプレミスでもクラウド環境でもサポートされています。 Azureでも利用可能です AWS marketplaces. したがって、事前に構成されたイメージを取得するだけです NCache そしてそれを始めましょう。 Windows 用と Linux 用の Docker コンテナーが用意されており、これを使用する必要がある任意のプラットフォームで使用できます。
通常、アプリケーションはオンプレミスでホストされているかクラウドでホストされているかに関係なく、アプリ サービスである可能性があります。 Cloud service、それはマイクロサービスである可能性があり、Azure Web サイトである可能性があり、あらゆる種類のアプリケーションがクライアント サーバー モデルでそれに接続でき、アプリケーションとバックエンド データベースの間に配置され、これが一般的な使用モデルです。 ここでのアイデアは、データを内部に保存することです NCache その結果、バックエンド データベースへの高価な移動を節約できます。 データベースへのアクセスを可能な限り節約し、データベースにアクセスする必要があるときはいつでも、常にデータベースにアクセスしてデータをフェッチし、それをキャッシュに取り込むことで、次回そのデータが存在しても、データが存在しないようにします。データベースに移動します。 その結果、メモリ内アクセスが可能になり、パフォーマンスが向上するため、アプリケーションのパフォーマンスと全体的なスケーラビリティが向上します。 リクエストやデータリクエストをホストし、提供する複数のサーバーがあります。 したがって、比較するとよりスケーラブルです。 さらに、高可用性とデータ信頼性の機能も組み込まれています。 NCache プロトコル。
NCache アプリケーションが実行されているのと同じボックス上でホストできます。 あるいは、単に別の層である可能性もあります。 クラウドでは、キャッシュの別の専用層を使用し、アプリケーションをそれぞれの層でアプリケーション インスタンスを実行するというアプローチが推奨されます。 ただし、次の点に限り両方のモデルがサポートされます。 NCache 心配している。
スケーラビリティの数値。 私たちは最近、AWS ラボでこれらのテストを実施しました。そこで、読み取りおよび書き込みリクエストの負荷をシミュレートし、負荷を増加させ続けました。サーバーが最大値に達していることがわかったある時点以降、キャッシュ クラスター内のサーバーの数を増やしました。 したがって、サーバーを 2 台から 3 台に、次に 3 台から 4 台にすると、わずか 2 台で 5 秒あたり XNUMX 万リクエストのスループットを達成できました。 NCache これはサーバーとの違いであり、これは一時的なデータではありませんでした。 これは実際のアプリケーション データですが、アプリケーション内の AWS ラボでシミュレートされました。 また、レイテンシ係数も非常に最適化されました。 これらすべてをマイクロ秒のレイテンシ以内に達成することができました。 したがって、この負荷をすべて達成できた場合、個々のリクエストのパフォーマンスは低下しませんでした。
一般的な使用例: 分散キャッシュ
いくつかのユースケースで、これは一般的なことです Redis 同様ですが、その方法についてはこれから話します NCache 比較するだろう。
アプリのデータキャッシュ
通常バックエンド データベースから取得するほぼすべてのものをキャッシュする場所と、データベース内に存在するデータをキャッシュする必要がある場所。 したがって、データベースへの高価な移動を節約できます。また、データベースが遅く、トランザクションの負荷処理の点で最適ではないことはすでにわかっています。 この回線には多くのデータベース同期機能がありますが、ここでは単に接続するだけです。 NCache 基本的に API を使用して接続を確立し、データ呼び出しを行います。 NCache。 したがって、ほぼすべてのものをキャッシュできます。 データ キャッシュ モデルを使用すると、ドメイン オブジェクト、コレクション、データセット、画像など、あらゆる種類のアプリケーション関連データをキャッシュできます。
ASP.NET / ASP.NET Core キャッシング
次に、ASP.NET と ASP があります。.NET Core 特定のキャッシュ。 これも技術的な使用例であり、ASP.NET または ASP に使用できます。.NET Core セッション状態のキャッシュ。 ASP.NET または ASP.NET Core SignalR Backplane. NCache バックプレーンとして接続できます。 ASP向け.NET Core 応答キャッシュにも使用できます。 IDistributedCache インターフェイスとセッション I分散キャッシュ インターフェイスでは、これら XNUMX つの機能もサポートされています NCache また、レガシー アプリケーションの場合は、ビュー ステートと出力キャッシュにも使用できます。 ロンに簡単な質問を投げたいと思いました。
入ってきました、質問はどうするかです NCache と Azure はサーバーレス プログラミング モデルをサポートしていますか?
絶対。 これは、Azure のデプロイに関して言えば、アプリケーションをサーバーにデプロイすることも、アプリケーション部分に関する限り、サーバーレス アプリケーションにすることもできます。 NuGet パッケージをアプリケーション内に含めるだけで、それらのアプリケーションは NCache 必要なときはいつでも電話をかけます。 をインストールする必要さえありません。 NCache または、アプリケーション リソースに関する限りサーバーをセットアップします。 しかし、これまでのところ、 NCache サーバー側のデプロイメント自体が懸念される理由は、 NCache はデータ ソースであるため、アプリケーションが接続してデータを取得および追加する VM または VM のセットが必要です。
したがって、サーバーから、 NCache キャッシュサーバーの観点から、必要なソースとして NCache ただし、アプリケーションに関する限り、厳密にはサーバーレスである可能性があり、問題はありません。 マイクロサービスアーキテクチャさえも。 これは非常に一般的な例であり、マイクロサービスには多数のマイクロサービスが存在します。 Azure 関数が存在する可能性があります。これは単に実行され、大量のデータを処理し、そのデータは次の場所から取得される可能性があります。 NCache。 それで、あなたは治療します NCache データソースとして。 一方、アプリケーションはサーバーレスにすることができ、 NCache そのモデルと完全に互換性があります。
Pub/Sub メッセージングとイベント
次に、別のユースケースが登場します Pub/Subメッセージング それはマイクロサービスを中心に展開しています。これは、サーバーレス アプリケーションでメッセージングを使用できる印象的な使用例の XNUMX つであるためです。 マイクロサービスは疎結合されたサーバーレス アプリケーションであり、マイクロサービス間の通信を構築することは大きな課題です。 したがって、Pub/Sub メッセージング プラットフォームを使用して、イベント駆動型の非同期イベント伝播メカニズムを利用できます。 複数のアプリケーションがメッセージを公開できる場所 NCache そして購読者はそれらのメッセージを受信できます。
これは非同期イベント駆動型メカニズムに基づいているため、パブリッシャー アプリケーションは確認応答やメッセージの配信を待つ必要がなく、同様にサブスクライバーもメッセージを待ったりポールしたりする必要がありません。 通知時にはコールバックを介して通知が届きます。 したがって、これは非常に柔軟性があり、これも使用できるユースケースです。 NCache アプリケーションの Pub/Sub メッセージング プラットフォームとして。
NCache 歴史
もう少し詳しく説明してから、次の違いについて説明します。 NCache & Redis. NCache は 2005 年に発売され、15 年以上市場に流通しています。 現在のバージョン NCache は 5.0、15 番目のバージョンです。 たくさんのお客様がいらっしゃいます。 NCache オープンソース版でも利用可能です。 当社の Web サイトおよび GitHub リポジトリからダウンロードできます。
いくつかの NCache Customers
弊社のお客様の一部です。 詳細なリストも入手できます。
プラットフォームとテクノロジー
次にその方法について話します NCache と比較する Redis 最初のセグメントは、テクノロジー全般に関するいくつかの入門的な詳細に基づいて構築されています。 これは分散キャッシュ技術に関する情報になります。 ここでは、その方法に直接焦点を当てます。 NCache と比較する Redis 私が定式化したいくつかのセグメントがあります。
したがって、私たちが定義した最初のセクションはプラットフォームとテクノロジーであり、最初に私たちがターゲットにしていると述べました。 NCache 5.0.2。 それで、 NCache 5.0 SP2 がメイン バージョンです。 NCache サイトとから Redis Azureを使用するという観点から Redis 比較として、オープンソースと Redis その一環としてのラボ。 これらの詳細のほとんどは、さまざまなフレーバーに共通です。 Redis.
ネイティブ.NETキャッシュ
Azure のバックグラウンドがあり、製品を選択する予定がある場合、最も重要なのはプラットフォームとの互換性です。
そう、 NCache それ自体は 100% .NET で書かれています。 ネイティブ .NET または.NET Core あなたのアプリケーションに関して言えば、その通りです。 したがって、基本的に、これは主に .NET アプリケーション向けに .NET で書かれており、Windows Server 2016、2019、さらには 2012 にも展開されます。 NCache is .NET framework or .NET Core そのことについては。 一方、 Redis、C++で書かれています。 NCache .NETで書かれています。 これは 100% 開発されており、実際に私たちが使用している主要なテクノロジー言語は C# であり、100% ネイティブの .NET です。 .NET Core。 一方 Redis は C++ Linux ベースのソリューションです。
したがって、Windows の観点、Windows の背景、および .NET で書かれたアプリケーションがある場合、同じテクノロジ スタックに属するように、同じく .NET で書かれた製品を使用するのが自然な選択となります。 アプリケーション開発スタック内に多くのバリエーションを持たせる必要はありません。 つまり、これがこれら XNUMX つの製品の XNUMX つの問題または XNUMX つの違いです。
XNUMX 番目の側面は Windows と Linux であり、Windows と Linux で何が利用できるかがわかります。 NCache そして何が利用できるか Redis 側。 Windows の観点から見ると、 NCache これは推奨されるデプロイメントですが、弊社のサポートを利用して Linux デプロイメントも利用できます。 .NET Core サーバーリリース。 そのため、Windows 2012、2016、2019 と完全な互換性があります。Docker イメージは Windows バージョンでも利用できます。 の亜種 NCache。 したがって、Docker イメージをダウンロードして、Windows イメージをスピンするだけです。 NCache 必要に応じて、実稼働環境で完全にサポートされます。 弊社からの公式サポートです。 一方、比較してみると、 Redis Microsoft Azureでも Redis Linux でホストされています。 推奨されるアプローチ、推奨される展開モデルは Linux です。 Redis。 Windows 版はサードパーティのプロジェクトです。 Microsoft Open Tech にはその移植版があります。 公式サポートはありません Redis 自体。 プロジェクト自体は棚上げされています。 バグが多く、不安定で、さらには Azure です Redis前述のように、Linux バージョンを使用しますが、これに関する大きな問題は、からの公式サポートがないことです。 Redisの、メーカー Redis あるいは、ある観点から見ると、オープンソース プロジェクトを使用し、それを自社の施設に導入したい場合、そこに多くの問題が発生することになります。
この一環として、もう XNUMX つの側面も強調したいと思います。 NCache オンプレミスから移行し、Azure で使用したい場合は、同じソフトウェアがそのまま動作します。 したがって、移転による変更は必要ありません NCache オンプレミスから Azure へ。 同様に、クラウド ベンダー内で使用する予定がある場合は、 NCache Azure では、必要に応じて AWS に移行することができます。 なぜなら、まったく同じソフトウェアがすべてのプラットフォームで全面的に利用できるからです。 一方、これまでのところ、 Redis 心配だよ、アズール Redis バックエンド展開に関する限り、Linux 上に展開されるホスト型モデルですが、オンプレミスでは同じバリアントを利用できません。 したがって、オープンソースに対処する必要があります Redis またはサードパーティのプロバイダー。 たとえ完全に異なる製品である商用バージョンを使用する必要があってもです。
したがって、ここで強調したい主な点は、 Redis オープンソースまたは商用バージョンのオンプレミスと Redis アズールまたは Redis AWSではElastic Cacheです。 これらは完全に別の製品です。 つまり、移行があり、多くの変化があります。 移植はできません Redis 何らかの変更を経ることなく、ある環境から別の環境に移行します。 一部の機能セットが欠落しています。 一部の API は異なります。 これらの製品間では、導入モデルが完全に変更されています。 したがって、そのままにしても何も変化はありません NCache Windows または Linux 上のオンプレミスで、Azure に移行したい場合、まったく同じ製品になります。Azure から AWS に変更したい場合、クラウド ベンダーを変更したい場合、比較すると柔軟性が高くなります。に Redis。 そう、 NCache はるかに柔軟です。
Linuxのサポート、 NCache 完全な互換性があり、正式にサポートされています。 パフォーマンスもテストされており、Linux のパフォーマンスは同等の超高速です。 NCache Windows 上で。 利用可能な Docker イメージを用意しています。 運用環境で完全にサポートされており、完全に統合された監視および管理ツールが用意されています。 Web管理および監視ツール どこからでもアクセスできるようになります。 そのため、Linux 導入環境であっても、Windows 導入環境を導入して管理および監視するのと同じように管理および監視できます。 NCache。 Linux もサポートされています Redis。 そのため、その制作サポートは次の方法で利用できます。 Redis 研究室アズール Redis Linux バージョンでもホストされています。 したがって、ベンダー自体がサポートしています。
プラットフォームに続く XNUMX 番目の側面は、やはり .NET であり、 .NET Core、テクノロジースタック。 弊社では公式クライアントをご用意しております。 実装させていただきました。 私たちはそれを完全にサポートしており、機能セットがある場合、そしてこれが理由です NCache 全面的に互換性があります。 したがって、オンプレミス環境、Azure 環境、または AWS 環境を選択した場合でも、同じフレーバーが得られます。 NCache とそのクライアントは全面的に利用可能です。 また、変更が必要な場合は、プロジェクトに関するものであると同時にすべてを所有しているため、それらの変更を正式に提供します。 一方、 Redis それは第三者です。 したがって、さまざまな言語については、さまざまな言語からのサポートもさまざまなベンダーから提供されます。 したがって、機能セットに違いがある可能性があります。 リリースサイクルに違いがある可能性があります。 したがって、クライアントの要件に関するテクノロジーに関しては、サードパーティのクライアントに依存する必要があります。
そこで、いくつかの側面を強調したいと思います NCache ネイティブ .NET であることと、 .NET Core 製品。 NCache は、Windows だけでなく Linux でも完全にサポートされています。 一方、 Redis Windows ではあまり安定していません。 これはサードパーティの移植バージョンであり、Linux サポートが利用可能です。つまり、次の点については Linux サポートに依存する必要があります。 Redis 心配している。 したがって、Microsoft テクノロジーのバックグラウンドを持っている人にとって、これは信頼できるものです。
キャッシュのパフォーマンスとスケーラビリティ
XNUMX 番目の側面はキャッシュのパフォーマンスです。 それも非常に重要な側面です。
どちらの製品も非常に高速であり、これが主な利点であるという考えです。 NCache & Redis、そのような製品を選択する主な理由は、パフォーマンスの向上の側面です。 データベースは遅く、あまり拡張性が高くないことはすでにわかっています。 これらの製品は、比較すると高速で非常にスケーラブルです。 だから、私は何も奪いません Redis。 Windows バージョンだけが安定しておらず、パフォーマンスの問題がありますが、Linux バージョンを使用している場合は、非常に高速でスケーラブルです。 NCache も非常に速いです。 非常に拡張性があります。 当社では独自に TCP/IP ベースのクラスタリング プロトコルを実装しており、非常に最適化されており、パフォーマンスが非常に堅牢です。
ただし、ここにもいくつかの違いがあります。 内部 NCache パフォーマンスを向上させる機能がたくさんあります。 最近ではウェビナーも開催し、改善できる XNUMX つの異なる方法に取り組みました。 NCache パフォーマンス。 セットアップする場合 NCache デフォルトでは非常に優れたパフォーマンスが得られますが、その上で、ユースケースに基づいてさまざまな機能を有効にすることで、パフォーマンスをさらに向上させることができます。その機能の XNUMX つがクライアント キャッシュです。
NCache: クライアントキャッシュ (ニアキャッシュ)
クライアント キャッシュは、 NCache. Redis にはこの機能がありません。
これはクライアント側のローカル キャッシュであり、サーバーレス アプリケーションでも可能です。アプリケーション プロセス内で InProc コピーを保持したり、サーバーベースのアプリケーションの場合はプロセス外のクライアント キャッシュを使用したりできます。 。 ここでのアイデアは、ネットワークを介してキャッシュ クラスターまでの高価な移動を節約できるということです。 このキャッシュは、バックエンド データ ソースへのトリップをすでに保存していました。 これで、間にキャッシュを入れることができ、キャッシュに 100 個の項目があると仮定します。アプリケーション側でいくつかの項目を入力した場合、たとえば 10 個の項目があると、それらの 10 個の項目は自動的にクライアント キャッシュに戻され、次回はクライアント キャッシュに戻されます。アプリケーションはそのデータをアプリケーションの近くで見つけ、その結果、高価なネットワーク接続を節約できます。
そして、これは同期されたクライアント キャッシュです。 同期は次によって管理されます。 NCache。 変更があった場合でも、 クライアントキャッシュ これはマスター コピーであるため、サーバー キャッシュにも多く伝播されます。 これはデータのサブセットであり、その変更は他のクライアント キャッシュにも伝播されます。 参考データシナリオがある場合。 読み取りと書き込みが頻繁に行われる場合は、クライアント キャッシュを有効にすることを強くお勧めします。これにより、データベースに対して実行されるキャッシュと比較して非常に優れたパフォーマンスが得られます。
私たちは最近、当社の顧客の 46 つ、つまり大規模な顧客の XNUMX つと POC を実施しました。 デフォルト構成では約 XNUMX 秒かかるワークフローがありました。 彼らはたくさん作っていた NCache 呼び出しとデータの取得。 したがって、これは主に読み取り集中型の使用例でした。 プロセス外でクライアント キャッシュを有効にしました。ちなみに、46 つの種類があります。プロセス外に保持することも、アプリケーション ボックス上で別のキャッシュ プロセスが実行されることを意味するか、アプリケーション プロセス内でクライアント キャッシュが実行される InProc を使用することもできます。 InProc にはシリアル化や通信オーバーヘッドを処理するプロセスがありません。 したがって、非常に高速です。 OutProcと比較しても速いです。 つまり、その顧客の場合、ワークフローが開始されるまでに約 3 秒かかったということになります。 次に、アウトプロセス クライアント キャッシュをオンにすると、処理時間が 4 ～ 400 秒に短縮され、さらに InProc クライアント キャッシュをオンにして、これらすべてを 500 ～ 46 ミリ秒以内に達成できました。 400 秒から 500 ～ XNUMX ミリ秒へ、これが私たちが話している種類の改善であり、この機能は他の製品や他のフレーバーの製品ではまったく利用できません。 Redis含みます Redis オープンソース プロジェクトや Azure を含むラボ Redis.
したがって、クライアント キャッシュを使用してパフォーマンスを調整でき、コードを変更する必要はありません。 これは単に設定をオンにするだけです。
一括操作は両側でサポートされていますが、 NCache つまり、一括操作はキャッシュ クラスター全体で機能します。つまり、サーバーが XNUMX 台あり、データが完全に分散されている場合、一括呼び出しによってそれらすべてのサーバーからデータがフェッチされ、統合された結果が取得されます。 したがって、これらすべてが相互に組み合わされて結果を定式化し、本質的に完全な結果が得られます。 一方 Redis 一括操作はシャード レベルで行われます。 したがって、特定のシャード上のデータを処理する必要があります。 つまり、それが限界です。 たとえば、キャッシュ クラスター内に複数のノードがあり、使用可能なマスター シャードがある場合は、特定のシャードに対して一括操作を実行できます。
つまり、それが限界です。 それ以外の場合、これは優れたパフォーマンス向上機能であり、個々のリクエストを行ったり来たりする代わりに、大きなリクエストを送信してすべてのデータを一度に取得し、その結果パフォーマンスを証明できます。
シリアル化、これは別の機能であり、別の側面もあります。ほとんどの時間はデータのシリアル化と逆シリアル化に費やされるため、これはデータのシリアル化と逆シリアル化に当てはまります。 NCache また、 Redis。 デフォルトでは、両方の製品がシリアル化および逆シリアル化されますが、 NCache シリアル化と逆シリアル化のオーバーヘッドを改善する方法があります。 通常、アプリケーションでかかるシリアル化時間を最適化する、高速で複雑なシリアル化が用意されています。 オブジェクトは複雑になります。 したがって、コードを変更することなく、それらをコンパクトなタイプとして定義でき、 NCache これにより、実行時にコンパクトなシリアル化が確実に実行され、シリアル化と逆シリアル化のオーバーヘッドが改善されます。
最後に、圧縮機能もあります。 圧縮はクライアント側で行われます。 通常、2MB、3MB、または 500 キロバイトなど、より大きなオブジェクトを扱う場合、それはより大きなオブジェクトになります。 したがって、通常は小さいオブジェクトを処理することをお勧めしますが、大きいオブジェクトがある場合は、ネットワーク使用量が多くなり、パフォーマンスも低下します。 と NCache 圧縮をオンにすることができます。 これはコード変更不要のオプションであり、 Redis キャッシュに追加するときにアイテムを自動的に圧縮します。 したがって、より小さなオブジェクトが追加され、アプリケーションとキャッシュの間で転送され、同様に同じ小さなオブジェクトがアプリケーション側でも取得されます。 より小さいペイロードを処理すると、アプリケーションのパフォーマンスが向上します。 したがって、圧縮をオンにすると、アプリケーション全体のパフォーマンスが向上します。
したがって、たとえば 100 キロバイトを超えるオブジェクトについては、必ず圧縮をオンにすることをお勧めします。有効にすることができるしきい値があり、より大きなオブジェクトのみが圧縮され、小さなオブジェクトはそのまま残されます。
したがって、これらすべてのパフォーマンス向上機能、クライアント キャッシュ、一括操作、コンパクト シリアル化、圧縮は、利用できないか、または利用できません。 Redis。 たとえば、クライアント キャッシュは使用できません。 一括操作も利用できますが、制限があります。 シリアル化の最適化オプションはなく、圧縮も利用できません。 つまり、そこに明確な違いがあります NCache & Redisここで、 NCache は、パフォーマンスを重視した多くの機能が組み込まれた完全なパッケージです。
高可用性
次のセグメントは高可用性であり、そこに機能セットの大きな違いが見られます。 NCache & Redis。 高可用性は、これらの部分を比較できるもう XNUMX つの側面です。 ミッションクリティカルなアプリケーションの場合、これはソースが必要となる非常に重要な側面です。 ここで、通常はデータベース内にあるデータを持ち込むことになり、データベース内にはある種のミラーリングやバックアップが必要になりますよね。
したがって、分散キャッシュである製品内でデータが移動されると、パフォーマンスが向上し、拡張性が非常に高くなりますが、高可用性が非常に重要な側面となります。 ミッションクリティカルなアプリケーションの場合、いかなるダウンタイムも許容できません。 ビジネスに影響を与え、ユーザー エクスペリエンスに影響を与える可能性があります。 したがって、手頃な価格ではありません。 したがって、アプリケーションがデータが存在するキャッシュから常に応答を取得できることが非常に重要です。 したがって、ここには膨大な機能の違いがあります。
キャッシュクラスター
NCache は、100% ピアツーピア アーキテクチャのキャッシュ クラスターです。
それは動的で自己修復的であり、それがどのように機能するかについては後で説明しますが、比較してみましょう Redis マスター/スレーブを使用します。 したがって、ピアツーピアアーキテクチャであること NCache サーバーを自動的に追加および削除でき、アプリケーションに対してシームレスです。 必要なだけサーバーを追加できます。 たとえば、2 つのサーバーから開始したとします。 ここで 3 番目のサーバーを追加したいと考えていますが、それはその場で行うことができます。 キャッシュやそのキャッシュに接続されているクライアント アプリケーションを停止する必要はありません。 シームレスなエクスペリエンスが観察されます。 そのため、高可用性とデータ信頼性の機能により、アプリケーションはダウンタイムやデータ損失を発生させることなく動作し続けることができます。 一方、では Redis 新しいシャードを自動的に追加することはできません。 自動データ再調整がないためです。 これがキャッシュ クラスターの動的な性質の中核です。 内部 NCache新しいサーバーを追加する場合は、データのバランスが自動的に再調整されます。
したがって、XNUMX つのシナリオがあります。 XNUMX つは新しいサーバーを追加して容量を増やし、拡張性を高めるシナリオであり、もう XNUMX つはサーバーを停止するシナリオです。
そこで、まずノードを追加するシナリオに取り組みましょう。 新しいノードが参加します。 と NCache、データは自動的に配布されます。
たとえば、2 台のサーバーから 3 台のサーバーに、さらに 2 台追加すると、ここには 6 つのアイテムがあり、別のサーバーを追加すると、既存のデータが送信され、新しく追加されたサーバーにバランスがとれます。 したがって、そのサーバーは既存のサーバーからデータの一部を取得し、それは自動的に行われます。 それは本質的にダイナミックです。 したがって、自動的にデータの再調整が行われます。 と Redis、これはデータの手動による再バランスであり、これは Azure にも当てはまります Redis Azure ではさまざまな層のセットが利用できるためです。 基本、中レベル、上級があります。 ここではクラスタリングは高度な場合にのみ機能しますが、これも高価であり、その上に少なくとも 3 台のサーバーが必要であり、これもまた制限となります。
NCache わずか 2 台のサーバーでクラスタリングを完全に稼働させることもできますが、その上に新しいサーバーを追加するには手動でデータの再バランスを行う必要があります。 それは大きな問題です。 したがって、アプリケーションや容量の追加を計画している場合には、ある種の制限が生じることになります。 一方、 NCache これは実行時に実現できます。 さらにサーバーをその場で追加できます。
XNUMX 番目の側面は、サーバーのダウンです。 それで、私たちは、 Redis 私たちはマスターとスレーブの概念を持っています。 マスターはデータをスレーブに複製します。 奴隷の破片があります。 したがって、マスターはデータを複製する必要があり、同期または非同期のいずれかの方法で複製できます。 の Redis, スレーブシャードがダウンするとマスター自体が停止し、クラスターが使用できなくなります。 つまり、これは大きな問題であり、常に起こる可能性があります。 オープンソースまたは Redis ラボへの展開 Redis。 その場合、マスター シャードのスレーブであるサーバーがダウンすると、クラスター自体が使用できなくなります。 したがって、そのシナリオから回復するには、手動で介入する必要があります。 一方、内部では NCache それは自動的です。 したがって、どのサーバーもダウンする可能性があり、生き残ったノードはアクティブまたはバックアップになる可能性があります。
たとえば、このサーバーがダウンした場合、これはアクティブなパーティションであり、バックアップ パーティションもあります。 このサーバー全体がダウンした場合、バックアップによってアクティブなサーバーが昇格されます。 バックアップ パーティションがアクティブに昇格され、生き残ったノードからすべてのデータが取得され、接続フェイルオーバーが組み込まれています。 クライアントがダウンしたサーバーは実行時にそれを検出し、生き残ったノードにフェイルオーバーすることを決定します。ここでは、その概念を強化したいと思います。 Redis 少なくとも 3 つのサーバーが必要です。 これが多数決の考え方です。 クラスターコーディネーターは選挙に勝たなければなりません。 そうではない NCache。 わずか 2 つのノードで完全に動作するキャッシュ クラスターを開始でき、完全な高可用性機能が提供されます。 サーバーがダウンしても、生き残ったノードは問題なく動作することができますが、これは当てはまりません。 Redis.
動的構成。 実行時にクラスター構成を変更できます。これには、新しいサーバーの追加、サーバーの削除、またはキャッシュ クラスターの一部の設定の変更が含まれます。 これは、クラッシュ クラスターを停止せずに実行時にクラッシュ クラスター全体に適用できるものです。 一方、 Redis、限られています。 手動で適用する必要がある構成が多数あり、クラスターの正常性イベントも多数あります。 NCache 側、購読することができます。 その上で監視および管理ツールを使用できます。 一方、 Redis それらの機能はありません。
したがって、これは非常に重要な概念です。 簡単にまとめさせていただきます。 サーバーの追加と削除 Redis 多くの問題を引き起こすものです。 データを追加すると、自動的に再バランスが行われません。 したがって、これは XNUMX% ピアツーピア アーキテクチャではありません。 したがって、キャッシュ クラスターの容量には制限があります。 同様に、スレーブ シャードがダウンすると、クラスター自体が使用できなくなります。 なぜなら、配布の問題があり、手動で管理する必要があるからです。 フェイルオーバーも手動ですよね？ したがって、サーバーがダウンした場合は、手動でフェイルオーバーして、生存ノードの使用を開始する必要があります。 新しいサーバーを追加した場合は、新しく追加したサーバーに手動で移行する必要があります。
これらはすべて制限事項であり、このような性質の実稼働デプロイメントを使用して、キャパシティを確保したり、メンテナンスのためにサーバーを停止したりする必要があるのを見ると驚くでしょう。 したがって、次のような製品ではそれは非常に困難です Redis。 一方、 NCache シームレスな体験を提供します。 何も影響を与えることなく、その場でサーバーを追加または削除できます。
動的パーティション/シャード
さて、クラスタ内のもう XNUMX つの概念は、自己修復メカニズムです。
NCache 動的パーティションがあります。 さらにサーバーを追加すると、データが取得されます redisトリビュートされると、実行時に新しいパーティションが作成されます。 同様に、サーバーをダウンさせると、クラスターがバックアップを利用できるようになり、クラスターが自動的に修復され、2 ノードから 3 ノードにダウンすると、信頼性の面で健全な 2 ノード キャッシュ クラスターが形成されます。 適切なレプリケーション パーティションがあり、以下でも利用できます。 Redis スレーブの形式として機能しますが、その高可用性はレプリケーションに依存します。 彼らは持っていません Redis スレーブ シャードが構成されていない場合、高可用性は得られません。 したがって、利用可能なスレーブシャードを用意する必要があります。 一方、 NCache、トポロジがあります。
たとえば、パーティション化されたキャッシュには、マスター シャード、マスター パーティションがあります。 このサーバーがダウンしても、クライアントがそれを検出し、フェイルオーバーして生存ノードの使用を開始するため、高可用性が維持されます。 データが失われる可能性がありますが、それは次の場合にも当てはまります Redis 同じように。 レプリケーションがないためデータが失われますが、可用性は依然として高いため、これを強化し、レプリケーションもサポートしています。 このサーバーがダウンした場合、サーバーのバックアップだけでなく、クライアントも自動的にフェイルオーバーします。 それで、 Redis 制限されています。 高可用性はレプリケーションに依存します。 レプリケーションが有効になっていない場合、可用性は高くありません。これも制限要因となります。
次に、自己修復メカニズムですが、手動による介入は必要ありません。
3 台のサーバーで開始すると、サーバーがダウンし、アクティブなパーティションとマスターが使用され、その後、別のサーバーのスレーブも失われます。 したがって、この場合、サーバー 3 のバックアップはサーバー 1 にあるため、これがアクティブになります。 実行時にアクティブなパーティションに結合します。 介入は必要ありません。 手動作業が必要な場合は、パーティション サーバー 2 がサーバー 1 上に正常なパーティションを作成します。したがって、クラスターは自動的に修復されます。これがクラスターの動的な性質です。 NCache と比較して Redis。 どこへ Redis、シャードは実行時に再調整できません。 スレーブシャードがダウンするとクラスターが停止します。 データ redis分配は動的ではありません。 高可用性はレプリケーションに依存しますが、レプリケーションには当てはまりません。 NCache. NCache レプリケーションがなくても高可用性を実現します。
つまり、あなたが得られるこれらすべての利点は、 NCache、これらの機能が完全に欠落しているか制限されているため、より優れた製品になります。 Redis これは Azure にも当てはまります Redis。 これらは非常に類似した製品であるため、これはオープンソースにも当てはまります。また、これはオープンソースにも当てはまります。 Redis ラボ Redis 提供品も同様です。
NCache デモ
これから少し時間をかけて、実際の製品が動作している様子を見て、どのように動作するかを理解していただくことにします。 NCache 設定されます。 これが私たちのデモ環境です。 私はそれに取り組んできました。 したがって、新しいキャッシュを作成します。 これは当社の Web 管理ツールであり、インストールされています。 NCache。 シリアル化のモードはバイナリまたは JSON のいずれかです。 それは完全にあなた次第です。 キャッシュに名前を付けるだけで、キャッシュ クラスターを作成し、クライアント アプリケーションに接続し、それを監視および管理する方法も説明します。
このウェビナーの主な焦点は次のとおりであるため、すべてをシンプルにしておきます。 NCache 対 Redis, したがって、詳細はすべて簡単にしておきます。 パーティション化されたレプリカ、これが最も推奨されるトポロジです。 アクティブとバックアップ間の非同期レプリケーション。 したがって、「同期」を選択できます。 非同期の方が速いので、これを使用します。 キャッシュクラスターのサイズ。 次に、これらのサーバー ノードを指定します。 NCache はすでにインストールされています。 TCPポート。 NCache TCP/IP ベースの通信プロトコルです。 したがって、すべてをシンプルにして、キャッシュがいっぱいになるようにエビクションを有効にするだけです。 したがって、キャッシュから一部の項目が自動的に削除され、その結果、新しい項目のためのスペースが確保されます。 このキャッシュを開始して終了します。 これをサービスの起動時に自動的に開始するため、サーバーが再起動されるたびに、サーバーは自動的にキャッシュ クラスターに参加し、それだけです。 キャッシュ クラスターを構成して使用するのは非常に簡単です。これについては、次に説明します。
クラウドサポート (Azure および AWS)
そこで、マネージド サービス モデルが登場します。 私たちの次のリリースは、XNUMX ～ XNUMX 週間後になると思います。 したがって、完全に管理された NCache Azure と AWS のサービスとしてのソフトウェア モデル。
現時点ではVMモデルのどちらかになります。 オンプレミスの場合は、物理ボックスまたは VM ボックスを使用できます。 Azure を選択した場合は、マーケットプレイスを通じて VM をセットアップするか、VM をセットアップしてからインストールする必要があります。 NCache 当社の Web サイトからソフトウェアをダウンロードしてください。 そして、コンテナ化された環境もあります。 Docker イメージがあり、Azure Kubernetes Service、EKS - Elastic Kubernetes Service、およびその他 (OpenShift Kubernetes プラットフォームなど) で完全にサポートされています。 NCache は完全に統合されており、これらのプラットフォームではすでに完全にサポートされています。 マネージドの側面に関する限り、それは近々実現する予定です。 したがって、今から XNUMX ～ XNUMX 週間後には完全に利用可能になるでしょう。
そこで、統計ウィンドウを示します。これは perfmon カウンターであり、これらの監視オプションは次の目的で使用できます。 NCache、 の面では NCache Windows だけでなく Linux 環境でも同じですよね?
そこで、ストレス テスト ツールを実行します。 別のキャッシュ用にすでに実行されているものがあると思います。 そこで、もう XNUMX つ実行して、キャッシュ クラスターへのダミー ロードをシミュレートします。 名前を指定するだけで、構成ファイルを使用してサーバーが自動的に検出され、それに接続するだけです。
つまり、完全に接続されたクラスターのステータス、スループットを示す XNUMX 秒あたりのリクエスト数、キャッシュ操作ごとの平均マイクロ秒単位のレイテンシー、追加、フェッチ、更新、削除、キャッシュ サイズ、CPU、メモリが表示されます。 したがって、一元的な監視ビューが得られます。 このツールを使用できます。 Windows パフォーマンスモンを使用することもできます。
Linux ベースの場合は、カスタマイズされた監視があります。 そのため、Linux サーバーに対して当社の監視ツールを直接使用することも、監視用のサードパーティ ツールを使用することもできます。 NCache 同じように。 以上、キャッシュ作成プロセスについて簡単に説明しました。 いくつかの監視および管理の側面。
それで、戻ってきます。 いくつかの詳細について説明しますので。 次にお話したいのは、クラウド オファリング / クラウド サポートです。 今 Redis それ自体では、アンマネージド キャッシュを選択することも、マネージド キャッシュを選択することもできます。さらに、ホスト型サービスが利用可能であり、管理オプションはサードパーティ ベンダーから提供されます。 ホスト型オプションは Azure からのものです Redis、オープンソースのバリアントを使用できます。 Redis Microsoft によってカスタマイズされており、ホストされたモデルとして利用できます。 一方、 NCache 側には、キャッシュサーバーモデルとVMモデルがあります。 コンテナアプローチについてはすでに説明しました。 Windows および Linux コンテナーと完全な互換性があります。 Windows コンテナー用の Azure Service Fabric、マイクロサービス アーキテクチャの詳細については、ビデオ デモをご利用いただけます。 Linux コンテナーを使用する Azure Kubernetes Service があります。 EKS – Elastic Kubernetes Service、その後、Kubernetes を介して Red Hat OpenShift Container も実行したと思います。
つまり、これらはすべて利用可能なコンテナ デプロイメント オプションであり、柔軟性があり、そのプラットフォームはプラットフォーム固有ではありません。 したがって、あらゆる種類のコンテナ化されたプラットフォームに問題なくデプロイできます。 マネージド サービスが登場する予定なので、それについてはすでに説明しました。 それで、それは何かです NCache サービスを管理することもできましたが、それは次のバージョンで行われます。
重要な側面の XNUMX つは、サービスではなく VM に接続する必要があるものの、すべてを制御できるという VM モデルを使用する利点です。 次に説明するサーバー側のコードを実行することもできますが、最も重要な点はパフォーマンスの点です。 多くのパフォーマンス機能があることについてはすでに説明しました。 NCacheに欠けているもの Redis。 Azure を選択した場合 Redisの場合、Azure インフラストラクチャに接続する必要があります。 つまり、これらは VM であり、別の仮想ネットワークで実行されます。 これらは近くにありますが、やはり遠くにあります。 これは、Microsoft Azure 内にあり、すべてのアプリケーションがデプロイされている独自の仮想ネットワークとは異なります。
NCache あなたは私たちを選ぶことができます NCache アプリケーション仮想ネットワークと同じ仮想ネットワーク上にデプロイします。 たとえば、App サービス、Azure Web サイト、Azure マイクロサービスは、Azure 仮想ネットワーク上で実行されます。 同じ仮想ネットワーク上に Azure VM をデプロイして、アプリケーションのパフォーマンスを向上させることを選択できます。 当社のラボ内での独自のテストに基づいて、 NCache の SaaS モデルよりも XNUMX ～ XNUMX 倍高速でした Redis 通常は Microsoft Azure で取得できるものです。 したがって、これは私が強調したい非常に重要な側面です。
さらに、VM をより詳細に制御できるようになります。 キャッシュの開始、サイズの増加、全容量の取得を完全に制御できます。 リクエスト単位やサイズに制限はなく、使用量のフットプリントもなく、その一部として料金が発生することもありません。 独自のライセンスを持ち込んで、永久ライセンスにすることも、サブスクリプション ライセンスにすることもでき、ライセンスに関しては非常に柔軟です。 その上で、サーバー側のコードを実行できます。 NCache サーバー。 これを完全に管理できます。 これを完全に最適化できます。 たくさんのインターフェースを書くことができます。 リードスルー、ライトスルー、ライトビハインド、キャッシュ ローダー、および MapReduce、アグリゲーター、エントリ プロセッサなどの一部のコンピューティング グリッド機能など。これは、 NCache。 これらすべてのサービスを利用できるホスト型モデルとなる SaaS モデルであっても、これは当てはまりません。 Redis。 つまり、それが私たちのプラットフォームです。
キャッシュを最新に保つ
次のセグメント、次の 15 分は機能レベルの比較に費やすことになり、そのためにいくつかのセグメントを定義しました。 それでは、キャッシュを最新の状態に保つ必要がある場合に始めます。これは非常に重要です。これについては、特にバックエンド データ ソースやアプリケーションの使用に関してキャッシュを最新の状態に保つ方法について、別のウェビナーがあるはずです。ケース。
したがって、比較すると、 Redis、 ほら、 NCache この面でも多くの機能があります。
時間ベースの有効期限は絶対的でスライド式ですが、これにも使用できる自動リロード メカニズムがあります。 Redis 絶対有効期限とスライド有効期限のみがあり、リロード メカニズムはありません。 リロードの場合、サーバー側コードであるリードスルー ハンドラーと呼ばれるインターフェイスを実装できます。 繰り返しますが、それは可能です。 NCache VM への完全なアクセス権を与えることができます。 NCache が主催されています。 したがって、サーバー側のコードを上にデプロイできます。 NCache 使用する NCache それをバックアップする計算能力。
キャッシュをデータベースと同期できます。 NCache データベースの同期に非常に強力です。 SQL 依存関係があります。 DB のみに準拠する DB 依存関係があります。 .NET CLR ストアド プロシージャがあります。 したがって、これらすべての機能により、キャッシュをデータベースと同期することができます。 ここでの考え方は、データベースに変更があり、データベース内のレコードが変更され、そのレコードがキャッシュされていた場合、これら XNUMX つのソースが同期していない可能性があるということです。 それで、 NCache、データベースに変更があった場合、そのデータを自動的に無効にするか再ロードできます。 NCache 実行時。 これは独自の機能です NCache。 他の製品にはこの機能はありません。 そのため、バックエンド データベースとキャッシュを完全に同期させることができます。これはリレーショナル データベースだけでなく、非リレーショナル データ ソース側にも機能があります。
ファイル依存関係は、項目をファイルに依存させることができるもう XNUMX つの機能です。 ファイルの内容。内容が変更されると、項目は自動的に削除または再ロードされます。 カスタム依存関係は、任意のソースで使用できます。 それは可能性があります NoSQL database、ファイル システムまたはリレーショナル、任意のコネクタ、任意の Web サービスの可能性があります。 したがって、柔軟な要件に基づいてアイテムを検証済みにすることができます。 Cosmos DB を使用してこの依存関係を実装しました。 そこで、次の同期を実装しました。 NCache Cosmos DB を使用します。 使用している場合 NCache cosmos DB と並行して、カスタム依存関係を使用できます。これについてはウェビナーも行ったと思います。
リレーショナル データの処理。 したがって、リレーショナル データには関係があります。 キャッシュ内の項目はキーと値のペアであるため、異なる項目間の関係を作成できます。これは、キャッシュ内では利用できないものです。 Redis 側。 したがって、項目をそれぞれのメリットに基づいて処理する必要があります。 一方、 NCache 項目を XNUMX 対 XNUMX、XNUMX 対多、または多対多のグループで組み合わせることができます。 親アイテムは変更され、子アイテムは必要に応じて自動的に無効化または再ロードされます。
データのグループ化、SQL および LINQ 検索
もう XNUMX つの側面は、データのグループ化と検索です。 NCache とても強いです＆ Redis 何も特徴がありません。 繰り返しますが、これは Azure にも当てはまります Redis とにかくそれは非常に限られています。 オープンソース Redis はわずかに進んでいますが、機能の点ではまだ制限されています。 さえも Redis Lab、商用版 Redis、これらの機能は装備されていません。
SQL検索が可能です。 内のアイテムを検索できます NCache オブジェクトの属性に基づいて。 オブジェクトがキャッシュに追加されます。 属性のインデックスを定義できます。 たとえば、製品の ID、価格、カテゴリのインデックスを作成できるため、これらの属性を使用してこれらの製品の検索を実行できるようになります。 典型的な例は、製品ドット カテゴリが何かであるか、製品ドット価格が 10 より大きく、製品ドット価格が 100 未満である製品を選択することです。 NCache すべてのサーバー上ですべての項目に対してメモリ内検索を実行し、結果を統合して結果セットを返します。 したがって、キーを扱う必要はもうありません。 基準に基づいてデータを取得します。
LINQ検索も利用可能です。 .NET と .NET Core アプリ。 LINQ 検索を使用している場合は、LINQ 検索を実行できます。 NCache 同じように。 つまり、それはユニークな機能です NCache コラボレー Redis サポートはありません。 Redis どれでも、すべての味 Redis、このサポートはありません。
グループ、サブグループを持つことができます。 内部で論理的にコレクションを作成できます NCache。 それは利用できません Redis そして、それらのグループに基づいてデータを取得、更新、削除できます。
タグと名前付きタグに属性を付けることができます。 たとえば、商品に付けられるキーワードを使用できます。 典型的な例としては、すべての顧客に顧客タグを付けることができます。 注文タグのあるすべての注文と特定の顧客の注文に、顧客 ID をタグとして添付することもできます。 注文が必要な場合は、「タグで取得」と言って注文をタグとして指定するだけで、すべての注文を取得できます。 特定の顧客の注文が必要な場合、「任意のタグで取得」または「タグで取得して顧客 ID を指定すると、その顧客 ID のみを除くすべての注文が取得されます。」 これが、タグと名前付きタグを使用する柔軟性です。 NCache. Redis はこれらをサポートしていません。
サーバー側の .NET コード
通常はキャッシュ アサイド パターンを使用することについてはすでに説明しました。このパターンでは、最初にキャッシュ内のデータをチェックし、そこでデータが見つかった場合は戻り、キャッシュ内にデータが見つからない場合はアプリケーションのバックエンド データベースに移動します。そしてそのデータをフェッチしてキャッシュに入れます。 つまり、null があり、null を取得してからデータベースにアクセスします。 Read-Thru ハンドラーを使用してこれを自動化できます。 これは、上で実行されるサーバー側のコードです。 NCache サーバー。 弊社のマネージド サービスにもこの機能があります。 したがって、任意のデータ ソースに接続できるようにするこのインターフェイスを実装します。 それは Web サービスである可能性があり、リレーショナル データ ソースまたは非リレーショナル データ ソースである可能性があり、キャッシュ内に null が見つかるとすぐに呼び出されるメソッドが多数あります。
そこで、Cache.Getメソッドを呼び出し、Read-Thruフラグを有効にします。 アイテムがキャッシュにない場合、呼び出しは Read-Thru ハンドラーに渡され、その結果、そのハンドラー コードを経由してバックエンド データベースからデータをフェッチすることになります。 実行されているユーザーコードはどれですか NCache サーバ側。 したがって、シームレスに通過できます NCache そして必要なデータを取得します。
ライトスルーはその逆であり、これもサポートされています。 Redis には、キャッシュ内の何かを更新してデータベースを更新する機能がありません。ライトスルー ハンドラーを呼び出すことでデータベースを更新できます。 このライトスルー ハンドラーを実装して登録すると、 NCache バックエンドデータベースを更新するためにそれを呼び出しますが、ライトビハインドはその反対です。 キャッシュ上の更新、クライアント アプリケーションの戻り、 NCache バックエンド データベースを舞台裏で非同期的に更新します。 それで、 NCache データベースへの書き込み操作のパフォーマンスも向上しますが、これは不可能です。 Redis サーバー側のコードを実行できない場合は、他の製品を使用してください。 そして、これは純粋にネイティブな .NET であり、 .NET Core クラス ライブラリは、インターフェイスを介して読み取りおよび書き込みとして実装および登録できます。これは、 NCache.
キャッシュ ローダーも別の機能です。 インターフェイスを実装して登録することでキャッシュを事前に設定できる場所 NCache。 したがって、キャッシュを再起動するたびに、重要なデータの一部が自動的にキャッシュ内にロードされます。 NCache これはすべてのサーバーで同時に実行されます。 つまり、超高速です。 したがって、すべてのデータを事前に入力できるため、データベースに再度アクセスする必要はありません。 データは事前にロードされているため、いつでも見つけることができます。
カスタム依存関係、エントリープロセッサー、これらもまた、 にのみ固有の機能です。 NCache およびこれらの機能を使用できない主な理由。 初めに、 Redis にはこれらの機能がないため、モジュールは Azure でサポートされていません Redis あるいはオープンソースでも Redis。 サーバー側、Azureではコード作成不可 Redis。 主な理由は、基盤となる VM にアクセスできないためであり、これが先ほど言及した主な理由です。 NCache 現時点では、VM モデルでは、それを展開する場所、制御方法、管理方法に完全にアクセスできます。 したがって、完全に制御できます。 ブラックボックスではないので、 Redis です。
マルチデータセンター向けの WAN レプリケーション
もう少し詳しく説明して、これで終わりにしたいと思います。 WAN レプリケーションは別の側面です。
アクティブ/パッシブは以下でサポートされています Redis、データセンター全体を転送し、あるデータセンターから別のデータセンターにキャッシュすることができます。 の NCache、アクティブ-パッシブがあります。 つまり、あるデータセンターから別のデータセンターへのデータの一方向の移行です。 また、両方のサイトをアクティブにする可能性がある、非常に差し迫った非常に重要なユースケースであるアクティブ/アクティブもあります。 サイト XNUMX の更新をサイト XNUMX で行う必要があり、その逆も同様です。 つまり、それは能力ではありません Redis 側。 あなたにはその能力がないので、アクティブ/アクティブサイトを実行することはできません。 Redis NCache これは、両方のサイトのデータが更新されているアプリのデータ キャッシュの使用例に当てはまります。これは、マルチサイト セッションを通じても可能です。 つまり、そこは別の空間です NCache 明らかに勝者です。
キャッシュトポロジ
次に、その他の詳細について説明します。 キャッシュトポロジ。 当社には、キャッシング トポロジの膨大なリストがあります。 Redis.
そこで、さまざまなユースケースに基づいて、ミラーリング、レプリケート、パーティション化、そしてレプリカのパーティション化を行い、すでに議論しましたが、その方法について議論しました。 NCache 一般にクラスタリングの方が優れており、クラスタリングと比較してより多くのオプションがあります。 Redis 提供。
GUI ツール - キャッシュ管理と監視
次に、GUI ツールがあります。 ここで比較してみましょう。 マネージャーさん、モニターさん。
一方、PowerShell ツール、ダンプおよびリロード ツール、完全な管理、監視の側面が組み込まれています。 一方、 Redis その点でも制限があり、その一環としていくつかの詳細を示しましたが、これは Windows だけでなく Linux の展開にも当てはまります。 NCache.
ASP.NET固有の機能
いくつかの ASP.NET 固有のキャッシュ機能。
セッション。ASP.NET から ASP へのマルチサイト セッションがあります。.NET Core セッション共有が近づいています。 マルチサイト ASP.NET および ASP.NET Core セッションが利用可能です。 ビューステート、出力キャッシュ。 Redis セッションのみがあり、これと比較すると非常に基本的です。 NCache。 セッションのロック、セッション共有はその一部です NCache。 出力キャッシュは両端でサポートされており、さらに SignalR Backplane、ASP.NET Core 応答のキャッシュ。 したがって、これらすべてにより、Web 固有のキャッシュ要件に対応する機能セットが完成します。 したがって、機能セットを詳細に確認できます。
イベントとの実行時データ共有
そして、Pub/Sub メッセージングがあります。
当社にはアイテムレベルのイベントがあり、基準に基づいたイベント通知システムもあります。これは、他のものと比較してはるかに優れています。 Redis。 Pub/Sub メッセージングに関する別のウェビナーを開催しています。 したがって、質問がある場合は確認することを強くお勧めします。 ということで、この辺で結論を出そうと思います。
サードパーティの統合
最後に、サードパーティの統合です。
NHibernate と Entity Framework もあります。 AppFabric ラッパーが利用可能です。 Memcached ラッパーが利用可能です。 したがって、これらの製品から移行する場合は、次の製品にシームレスに移行できます。 NCache と比較して Redis.
セキュリティと暗号化
詳細については、 セキュリティ暗号化 すでに予定時刻に達していると思います。
まとめ
それでは、そろそろ結論を出しておきたいと思います。 まず最初に、いつでも好きな時に www にアクセスできるということです。alachisoft.com からエンタープライズ バージョンをダウンロードできます。 NCache お客様の環境でどのように機能するかを個人的にお見せします。 そのため、Web サイトに直接アクセスして、エンタープライズの 30 日間無料トライアルを取得することをお勧めします。 デモの予定を立てるのは私たちの喜びです. それに加えて、このウェビナーの録画を利用できるようにします。 そのため、私たちがあなたにそれを伝えたら、あなたの電子メールやソーシャルメディアに注目してください. 今日あなたの質問に答えられなかった場合は、さらに多くの質問が寄せられていて、まさに限界に達していることを私は知っています。 support@alachisoft.com.
技術的なご質問がございましたら、お答えいたします。ご興味がございましたら、お申込みください。 NCache あなたの環境ではあなただけが連絡できます sales@alachisoft.com 同様に。