Redis vs NCache
録画されたウェビナー
ロン・フセイン、ザック・カーン著
NCache は、トランザクション量の多い.NET、.NET Core、Javaアプリケーションで非常に人気のある、ネイティブ.NETオープンソースの分散キャッシュです。 Redis によって開発されている Redis Labs であり、現在 Microsoft によって Azure で使用されています。 このウェビナーでは、その方法を学びます NCache (NAIST) と Redis 互いに比較してください。 このウェビナーの目的は、特に機能、パフォーマンス、スケーラビリティ、高可用性、データ信頼性、管理などの定性的な側面において、XNUMX つの製品を比較するタスクをより簡単かつ迅速に行えるようにすることです。
このウェビナーの内容は次のとおりです。
- パフォーマンスとスケーラビリティ
- キャッシュの弾力性（高可用性）
- キャッシュトポロジ
- SQL と LINQ キャッシュの検索
- サードパーティの統合 (EF、EF Core、NHibernate など)
今日は、非常に似ているようでいて、多くの点で異なる2つの製品を比較するというテーマです。 NCache これは、.NETおよび.NET Coreアプリケーション向けの当社の主要な分散キャッシュ製品であり、次に機能の観点から比較します。 Redisということで、このセッションではたくさんのことをお話しします。まずはプラットフォームとテクノロジースタックから始まり、技術的な詳細について詳しく説明していきます。次にクラスタリングについてお話しします。キャッシュクラスタリングに関して、これら2つの製品を比較するとどうなりますか？また、これらの製品を使用することでどのようなメリットが得られるのでしょうか？ NCache より良いものについては後で別の機能についてお話しします。 機能ごとの比較 これらの製品を使用できるさまざまなユースケースについて、また機能比較の観点からこれら 2 つの製品を比較します。
このウェビナーでは、 NCache Enterprise 5.0.2 では、 Redis 我々はAzureに主に注力します Redisそれがオープンソースです Redis 4.0.1.4. しかし、 Redis オープンソースプロジェクト、そして、 Redis 商業版であるラボ Redisそれで、比較してみましょう NCache これらすべてのフレーバーがありますが、私たちの主な焦点はMicrosoft Azureです Redisのホストモデル Redis Microsoft Azure で取得できます。
スケーラビリティの問題
さて、本題に入る前に、まずはこの2つの製品について基本的な部分から説明したいと思います。では、なぜ分散キャッシュソリューションが必要なのでしょうか？
その後、様々な製品を比較検討することになります。一般的に、アプリケーション内でスケーラビリティとパフォーマンスの課題が発生することがあります。アプリケーションに大量のデータ負荷がかかっている場合、アプリケーション層は非常にスケーラブルで、Webファームを作成したり、アプリケーション層にリソースを追加したりすることはできますが、すべてのアプリケーションインスタンスはバックエンドのデータソースにアクセスする必要があります。そして、これらのデータソースにアクセスする必要がある際にパフォーマンスの問題が発生します。これは、データベース、特にリレーショナルデータベースはトランザクション負荷の処理速度が遅いためです。
これらにはパフォーマンスの問題が伴います。また、スケールアウトに関して言えば、例えば、大量のリクエスト処理能力や要件を満たす必要があり、アプリケーションが大量のユーザー負荷を発生させている場合、データベースはそのような極端なトランザクション負荷に対応できるように設計されていません。大量のデータを保存できるストレージとしては非常に優れていますが、そのデータにトランザクション負荷をかけるのはデータベースにとってあまり適していません。処理が遅くなり、エンドユーザーエクスペリエンスが低下する可能性があります。
そのため、パフォーマンスに影響が出る可能性があり、アプリケーション アーキテクチャ内で容量を増やすことができなくなります。
解決策：インメモリ分散キャッシュ（NCache)
解決策は非常にシンプルで、次のようなメモリ内分散キャッシュシステムを使用します。 NCache これはメモリ内なので超高速です。つまり、リレーショナルデータベースやファイルシステムなど、メモリベースではない他のデータソースと比較すると、ディスクからデータを取得する場合、メモリ上にデータを保存する場合と比べて、インメモリで処理する方が超高速になります。つまり、インメモリで処理することの第一のメリットは、超高速なパフォーマンスが得られることです。 NCache.
2つ目のメリットは、キャッシュクラスターであることです。単一のソースではありません。1台のサーバーから始めることもできますが、通常は少なくとも2台のサーバーを用意してキャッシュクラスターを作成することをお勧めします。キャッシュクラスターを作成したら、すべてのサーバーに負荷を分散し、実行時にサーバーを追加していくことで、パフォーマンスが向上します。
つまり、サーバーを追加することで実行時にキャパシティを拡張でき、バックエンドのリレーショナルデータベースと組み合わせて使用することもできます。これは従来のリレーショナルデータベースを置き換えるものではありません。具体的なユースケースについては後ほどご説明します。
分散キャッシュの導入 (NCache)
典型的な展開は次のとおりです。
私が使用しています NCache 今は例として挙げていますが、このプレゼンテーションでは、 Redis どのように展開されるか NCache どのように展開されるのか、またこれらの製品内でどのような柔軟性が利用できるのかについて説明します。
だから、 NCache非常に柔軟性が高く、Windows環境とLinux環境の両方に展開できます。オンプレミスだけでなく、クラウド環境でも利用可能です。AzureとAWSマーケットプレイスで利用可能です。そのため、構成済みのイメージをすぐに入手できます。 NCache さあ、始めましょう。Windows 用と Linux 用の Docker コンテナが用意されており、必要なプラットフォームであればどこでも使用できます。
通常、アプリケーションはオンプレミスでもクラウドでも、App Service、クラウドサービス、マイクロサービス、Azure Webサイトなど、あらゆるアプリケーションがクライアントサーバーモデルで接続でき、アプリケーションとバックエンドデータベースの間に配置されます。これが典型的な利用モデルです。ここでの考え方は、データを内部に保存することです。 NCache その結果、バックエンドデータベースへの高価なアクセスを節約できます。データベースへのアクセスを可能な限り削減し、データベースにアクセスする必要があるときはいつでも、データベースにアクセスしてデータを取得し、キャッシュに格納します。これにより、次回同じデータが存在する場合は、データベースにアクセスする必要がなくなります。また、メモリ内アクセスが可能になり、パフォーマンスが向上するため、アプリケーションのパフォーマンスと全体的なスケーラビリティが向上します。複数のサーバーがホストされ、リクエスト、つまりデータリクエストを処理します。つまり、比較するとスケーラビリティが向上します。さらに、高可用性とデータ信頼性の機能も組み込まれています。 NCache プロトコル。
NCache アプリケーションが稼働している同じマシン上にホストすることも可能です。あるいは、別の層にすることも可能です。クラウドでは、専用のキャッシュ層を用意し、アプリケーションインスタンスはそれぞれの層で稼働させるのが望ましいアプローチです。ただし、どちらのモデルもサポートされています。 NCache 心配している。
スケーラビリティに関する数値をいくつかご紹介します。最近、AWSラボでこれらのテストを実施しました。読み込みと書き込みのリクエスト負荷をシミュレートし、負荷を上げ続けました。そして、ある時点でサーバーが限界に達していることがわかったため、キャッシュクラスター内のサーバー数を増やしました。その結果、サーバーを2台から3台、そして3台と増やしていくうちに、わずか4台のサーバーで毎秒2万リクエストのスループットを達成できました。 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 バックプレーン。 NCache バックプレーンとしてプラグインできます。ASP.NET Core では、レスポンス キャッシュにも使用できます。IDistributedCache インターフェイスとセッションを介して I分散キャッシュ インターフェースでは、これら2つの機能は NCache また、レガシー アプリケーションの場合は、ビュー ステートおよび出力キャッシュにも使用できます。Ron さん、ちょっと質問させてください。
私たちは来ました、質問は NCache Azure はサーバーレス プログラミング モデルをサポートしていますか?
はい、その通りです。Azureのデプロイメントでは、アプリケーションをサーバー上にデプロイすることも、アプリケーション部分に関してはサーバーレスアプリケーションにすることも可能です。アプリケーション内にNuGetパッケージを含めるだけで、アプリケーションは NCache 必要な時にいつでも電話をかけられます。 NCache アプリケーションリソースに関してはサーバーをセットアップする必要があります。しかし、 NCache サーバー側の展開自体が懸念されるのは NCache はデータ ソースなので、アプリケーションが接続してデータを取得したり追加したりするための VM または VM セットが必要です。
つまり、サーバーから、 NCache キャッシュサーバの観点から、必要な情報源として NCache サーバーはありますが、アプリケーションに関しては完全にサーバーレスで問題ありません。マイクロサービスアーキテクチャでも同様です。これは非常に一般的な例で、マイクロサービスが多数存在します。Azure関数は、単にパフォーマンスだけを追求するだけでなく、大量のデータを処理し、そのデータはさまざまな場所から取得できます。 NCache. だから、あなたは NCache データソースとして。一方、アプリケーションはサーバーレスで NCache そのモデルと完全に互換性があります。
Pub/Sub メッセージングとイベント
もう一つのユースケースは Pub/Subメッセージング これはマイクロサービスを中心に展開されます。なぜなら、マイクロサービスはサーバーレスアプリケーションでメッセージングを活用できる、印象的なユースケースの一つだからです。マイクロサービスは疎結合されたサーバーレスアプリケーションであり、それら間の通信を構築するのは大きな課題です。そこで、イベント駆動型の非同期イベント伝播メカニズムを利用できるPub/Subメッセージングプラットフォームをご利用いただけます。複数のアプリケーションからメッセージをパブリッシュできます。 NCache 加入者はそれらのメッセージを受信できます。
非同期イベント駆動型のメカニズムに基づいているため、パブリッシャーアプリケーションは確認応答やメッセージの配信を待つ必要がなく、同様にサブスクライバーもメッセージの受信を待ったりポールしたりする必要がありません。通知はコールバック経由で受け取ります。そのため、非常に柔軟性が高く、これもまた活用できるユースケースの一つです。 NCache アプリケーション用の Pub/Sub メッセージング プラットフォームとして。
NCache 沿革
もう少し詳しく説明してから、違いについてお話しします。 NCache (NAIST) と Redis. NCache 2005年に発売され、現在では15年以上も市場に出回っています。現在のバージョンは NCache 5.0、15番目のバージョンです。たくさんのお客様にご利用いただいています。 NCache オープンソース版もご用意しております。弊社ウェブサイトおよび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 .NET Framework または .NET Core のどちらでも構いません。一方、 RedisC++ で書かれています。 NCache .NET で書かれています。実際には、100% 開発されており、C# が私たちが使用している主要な技術言語であり、100% ネイティブ .NET および .NET Core です。一方、 Redis C++ Linux ベースのソリューションです。
Windowsの観点から、Windowsのバックグラウンドを持つ方であれば、.NETで書かれたアプリケーションをお持ちであれば、同じテクノロジースタックを使用するために、同じく.NETで書かれた製品を使用するのが自然な選択でしょう。アプリケーション開発スタック内に多くのバリエーションを持つ必要はありません。これが、これら2つの製品間における問題点、あるいは違いの一つです。
2つ目の側面はWindowsとLinuxの比較です。 NCache そして何が利用可能か Redis 側面。窓の観点から NCache デプロイメントは推奨されるデプロイメントですが、.NET Core Server リリースの助けを借りて Linux デプロイメントも利用可能です。そのため、Windows 2012、2016、2019 と完全に互換性があります。Docker イメージは Windows バリアントでも利用可能です。 NCache. Dockerイメージをダウンロードして、Windowsイメージをスピンするだけで、 NCache 必要に応じて、本番環境で完全にサポートします。これは当社からの公式サポートです。一方、 Redis Microsoft Azureでも Redis Linuxでホストされています。推奨されるアプローチ、推奨される展開モデルはLinuxです。 RedisWindows版はサードパーティのプロジェクトです。Microsoft Open Techが移植版を公開しています。公式サポートは提供されていません。 Redis プロジェクト自体が棚上げになっています。バグが多く、不安定で、Azureさえも Redisは、前述のようにLinux版を使用していますが、これの大きな問題は、公式のサポートがないことです。 Redisの、メーカー Redis あるいは、オープンソース プロジェクトを使用し、それを独自の敷地内に展開したいという観点から言えば、そこに多くの問題が出てきます。
この一環として、もう一つ強調したいのは、 NCache オンプレミスから移行してAzureで使用したい場合、同じソフトウェアがそのまま動作します。そのため、移行時に変更する必要はありません。 NCache オンプレミスからAzureへ。同様に、クラウドベンダー内でも、 NCache Azureでは、必要であればAWSに移行できます。なぜなら、すべてのプラットフォームで全く同じソフトウェアが利用できるからです。一方、 Redis 懸念しているAzure Redis ホスト型モデルであり、バックエンドのデプロイメントに関してはLinux上にデプロイされますが、オンプレミスでは同じバージョンが利用できません。そのため、オープンソースを扱う必要があります。 Redis あるいはサードパーティのプロバイダー。その場合でも、全く異なる製品である商用版を使用する必要があります。
ここで私が強調したい主な点は Redis オープンソースや商用版のオンプレミスと Redis Azureまたは Redis AWSのElastic Cacheは完全に別の製品です。そのため、移行が必要で、多くの変更点があります。 Redis 環境の変更なしに、異なる環境へ移行できます。一部の機能セットが欠落しています。一部のAPIが異なります。これらの製品間ではデプロイメントモデルが完全に異なります。そのため、同じ環境を維持すれば変更はありません。 NCache WindowsやLinuxのオンプレミス環境からAzureに移行したい場合、AzureからAWSに変更したい場合、クラウドベンダーを変更したい場合、AzureはAWSに比べてより柔軟です。 Redis。 そう、 NCache はるかに柔軟です。
Linuxサポート、 NCache 完全に互換性があり、公式にサポートされています。パフォーマンスもテストされており、Linuxのパフォーマンスは同等の超高速です。 NCache Windows上でDockerイメージをご利用いただけます。本番環境で完全にサポートされており、完全に統合された監視・管理ツールもご用意しています。 ウェブ管理および監視ツール どこからでもアクセスできます。つまり、Linux環境もWindows環境と同じように管理・監視できます。 NCacheLinuxは以下でもサポートされています Redisそのため、生産サポートは Redis ラボ・アズール Redis Linux版でもホストされています。つまり、ベンダー自身によってサポートされています。
プラットフォームに続く2つ目の側面は、やはり.NETと.NET Core、つまりテクノロジースタックです。公式クライアントが利用可能です。実装済みです。完全にサポートしており、機能セットがあれば、その理由は NCache 全般的に互換性があります。オンプレミス、Azure、AWS環境のいずれを選択しても、 NCache 弊社とクライアントは、全面的に利用可能です。また、変更が必要な場合は、プロジェクトに関わるすべての責任を負っているため、正式に変更内容をご提供いたします。一方、 Redis サードパーティ製です。言語によってサポートされる言語もベンダーも異なります。そのため、機能セットに違いが生じる可能性があります。リリースサイクルにも違いが出る可能性があります。そのため、クライアントの要件を満たす技術面では、サードパーティ製のクライアントに頼らざるを得ません。
そこで、いくつかの点についてお話ししたいと思います NCache ネイティブの.NETおよび.NET Core製品であること。 NCache WindowsだけでなくLinuxでも完全にサポートされています。 Redis Windowsでは安定していません。サードパーティ移植版でLinuxサポートも利用可能ですが、それだけLinuxサポートに頼るしかありません。 Redis 懸念事項です。マイクロソフトの技術系出身者にとって、これは頼りになるものなのです。
キャッシュパフォーマンスとスケーラビリティ
2つ目の側面はキャッシュパフォーマンスです。これも非常に重要な側面です。
どちらの製品も非常に高速であり、それが主な利点です NCache (NAIST) と Redisこのような製品を選ぶ主な理由は、パフォーマンス向上の観点です。データベースは遅く、スケーラビリティも低いことは既に述べました。これらの製品はそれに比べて高速で、スケーラビリティも非常に優れています。ですから、この製品から何かを奪うつもりはありません。 RedisWindows版は安定しておらず、パフォーマンスの問題もありますが、Linux版があれば、非常に高速でスケーラブルで、非常に高速で、 NCache 非常に高速で、拡張性も非常に高いです。当社独自のTCP/IPベースのクラスタリングプロトコルを実装しており、非常に最適化されており、パフォーマンスも非常に堅牢です。
しかし、ここでもいくつか違いがあります。 NCache パフォーマンス向上のための機能が多数あります。最近、ウェビナーも開催し、パフォーマンス向上のための6つの方法を取り上げました。 NCache パフォーマンス。設定すると NCache デフォルトでは、非常に優れたパフォーマンスが得られますが、それに加えて、ユースケースに基づいてさまざまな機能を有効にして、パフォーマンスをさらに向上させることができます。その機能の 1 つがクライアント キャッシュです。
NCache: クライアントキャッシュ（ニアキャッシュ）
クライアントキャッシュは、 NCache. Redis この機能はありません。
これはクライアント側のローカルキャッシュで、サーバーレスアプリケーションでも利用可能です。サーバーレスアプリケーションでは、アプリケーションプロセス内にInProcコピーを配置できます。また、サーバーベースのアプリケーションでは、プロセス外のクライアントキャッシュを使用できます。ここでの考え方は、ネットワーク経由でキャッシュクラスターへの高コストなアクセスを節約することです。このキャッシュは、バックエンドデータソースへのアクセスを既に節約しています。中間にキャッシュを配置し、キャッシュに100個のアイテムがあると仮定します。アプリケーション側でアイテム、例えば10個を入力すると、それらの10個のアイテムは自動的にクライアントキャッシュに戻され、次回アプリケーションはより近い場所でそのデータを見つけることができるため、高コストなネットワークアクセスを節約できます。
これは同期されたクライアントキャッシュです。同期は NCache. 変更があった場合 クライアントキャッシュ サーバーキャッシュはマスターコピーであるため、変更はサーバーキャッシュにも同様に伝播されます。これはデータのサブセットであり、その変更は他のクライアントキャッシュにも伝播されます。参照データのシナリオで、読み取りと書き込みを頻繁に行う場合は、クライアントキャッシュを有効にすることを強くお勧めします。これにより、データベースに対して実行されるキャッシュと比較して、非常に優れたパフォーマンスが得られます。
最近、大手のお客様と概念実証を行いました。そのお客様は、デフォルト設定で約46秒かかるワークフローを使用していました。 NCache 呼び出しとデータの取得です。つまり、これは主に読み取り集中型のユースケースでした。クライアントキャッシュをアウトプロセスで有効にしました。ちなみに、アウトプロセスでは46つの種類があります。アウトプロセスではアプリケーション上で別のキャッシュプロセスが実行されますが、InProcではクライアントキャッシュがアプリケーションプロセス内で実行されます。InProcはシリアル化やプロセス間通信のオーバーヘッドがありません。そのため、非常に高速です。OutProcと比較しても高速です。あるお客様のワークフローでは、開始時に約3秒かかっていました。その後、アウトプロセスクライアントキャッシュを有効にすると、4～400秒に短縮され、さらにInProcクライアントキャッシュを有効にすると、これらすべてを500～46ミリ秒以内に達成できました。400秒から500～XNUMXミリ秒への短縮は、まさに私たちが話しているような改善であり、この機能は他の製品、あるいは他の種類の製品では全く利用できません。 Redis含みます Redis オープンソースプロジェクトやAzureを含むラボ Redis.
つまり、クライアントキャッシュを使えばパフォーマンスを調整でき、コードを変更する必要もありません。設定を有効にするだけで済みます。
一括操作は両側でサポートされていますが、 NCache 一括操作はキャッシュクラスタ全体で実行されます。つまり、10台のサーバーがあり、データが完全に分散している場合、一括呼び出しはすべてのサーバーからデータを取得し、統合された結果を取得します。つまり、これらすべてが相互に連携して結果を作成し、結果として完全な結果が得られます。一方、 Redis 一括操作はシャードレベルで実行されます。つまり、特定のシャード上のデータのみを扱う必要があります。これが制限事項です。例えば、キャッシュクラスターに複数のノードがあり、利用可能なマスターシャードがある場合は、特定のシャードに対して一括操作を実行できます。
これが制限です。それ以外は、これはパフォーマンスを向上させる優れた機能です。個々のリクエストを何度もやり取りする代わりに、大きなリクエストを送信してすべてのデータを一度に取得することで、結果としてパフォーマンスが向上します。
シリアル化は別の機能であり、別の側面もあります。ほとんどの時間はデータのシリアル化とデシリアル化に費やされるからです。 NCache また、 Redisデフォルトでは、両方の製品ともシリアル化とデシリアル化を行いますが、 NCache シリアライゼーションとデシリアライゼーションのオーバーヘッドを改善する方法があります。高速で複雑なシリアライゼーションは、通常アプリケーションでかかるシリアライゼーション時間を最適化します。オブジェクトは複雑になりますが、コードを変更することなく、それらをコンパクト型として定義し、 NCache これにより、実行時にコンパクトなシリアル化が実行され、シリアル化とデシリアル化のオーバーヘッドが改善されます。
最後に、圧縮機能も備えています。圧縮はクライアント側で行われます。通常、2MB、3MB、あるいは500KBといった大きなオブジェクトを扱う場合、それはより大きなオブジェクトです。そのため、通常は小さなオブジェクトで扱うことをお勧めしますが、大きなオブジェクトを扱う場合、ネットワークの使用率が高くなり、パフォーマンスも低下します。 NCache 圧縮をオンにすることができます。これはコード変更なしのオプションで、 Redis キャッシュに追加する際にアイテムを自動的に圧縮します。そのため、小さなオブジェクトが追加され、アプリケーションとキャッシュ間で転送され、同様にアプリケーション側でも同じ小さなオブジェクトが取得されます。ペイロードを小さくすることで、アプリケーションのパフォーマンスが向上します。つまり、圧縮を有効にすると、アプリケーション全体のパフォーマンスが向上します。
したがって、たとえば 100 キロバイトを超えるオブジェクトの場合は、必ず圧縮をオンにすることをお勧めします。有効にできるしきい値があり、それより大きいオブジェクトのみが圧縮され、小さいオブジェクトはそのまま残されます。
つまり、クライアントキャッシュ、バルク操作、コンパクトシリアル化、圧縮といったパフォーマンス向上機能はすべて利用できないか、 Redis例えば、クライアントキャッシュは利用できません。バルク操作は利用可能ですが、制限があります。シリアル化の最適化オプションはなく、圧縮も利用できません。つまり、これらには明確な違いがあります。 NCache (NAIST) と Redisここで、 NCache パフォーマンス重視の機能が多数組み込まれた完全なパッケージです。
高可用性
次のセグメントは高可用性であり、ここで機能セットに大きな違いが見られます。 NCache (NAIST) と Redis高可用性は、これらの部分を比較できるもう一つの側面です。ミッションクリティカルなアプリケーションでは、これは非常に重要な側面であり、ソースが必要になります。通常、データベース内にあるデータを移行しますが、データベース内では何らかのミラーリングやバックアップが行われますよね？
分散キャッシュ製品でデータを移動することで、パフォーマンスは向上し、非常にスケーラブルになりますが、高可用性が非常に重要です。ミッションクリティカルなアプリケーションでは、いかなるダウンタイムも許容されません。ビジネスやユーザーエクスペリエンスに影響を与える可能性があるため、許容できる範囲ではありません。そのため、アプリケーションが常にデータが存在するキャッシュからレスポンスを取得できることが非常に重要です。このように、ここには多くの機能の違いがあります。
キャッシュクラスター
NCache 100% ピアツーピア アーキテクチャのキャッシュ クラスターです。
それは動的で自己治癒的であり、それがどのように機能するかについて話しますが、比較すると Redis マスター/スレーブを使用します。つまり、ピアツーピアアーキテクチャであるため NCache サーバーの追加と削除は自動的に行われ、アプリケーションへの影響はシームレスです。必要な数だけサーバーを追加できます。例えば、2台のサーバーから開始し、3台目のサーバーを追加したい場合も、即座に実行できます。キャッシュや、そのキャッシュに接続されているクライアントアプリケーションを停止する必要はありません。シームレスなエクスペリエンスが保証されます。そのため、当社の高可用性とデータ信頼性機能により、アプリケーションはダウンタイムやデータ損失なしで動作を継続できます。 Redis 新しいシャードを自動的に追加することはできません。自動データリバランスがないからです。これが、キャッシュクラスタの動的な性質の核心です。 NCache新しいサーバーを追加する場合は、データのバランスを自動的に調整します。
つまり、2つのシナリオがあります。1つは、容量を増やして拡張性を高めるために新しいサーバーを追加するシナリオ、もう1つはサーバーを停止するシナリオです。
まず、ノードが追加されるシナリオを考えてみましょう。新しいノードが参加します。 NCache、データは自動的に配布されます。
例えば、サーバーを2台から3台に増やし、さらに2台追加すると、ここには6つのアイテムがあり、さらにサーバーを追加すると、既存のデータが転送され、新しく追加されたサーバーにバランス調整されます。つまり、そのサーバーは既存のサーバーからデータの一部を取得し、自動的に処理されます。これは動的な性質を持ちます。つまり、自動的にデータのバランス調整が行われます。 Redisこれはデータの手動再調整であり、Azureでも同様です。 Redis Azureには様々なレベルのプランが用意されているからです。ベーシック、ミッドレベル、そしてアドバンスドがあります。クラスタリングはアドバンスドプランでのみ機能しますが、これもまた高価で、さらに最低3台のサーバーが必要となり、これもまた制限となります。
自律的AI NCache たった2台のサーバーでクラスタリングを完全に稼働させることができ、さらに新しいサーバーを追加するには手動でデータの再バランス調整が必要になります。これは大きな問題です。つまり、アプリケーションやキャパシティ追加を計画する時期に何らかの制限が生じてしまうのです。一方、 NCache 実行時にこれを実現できます。また、必要に応じてサーバーを追加することも可能です。
2つ目の側面は、サーバーがダウンすることです。 Redis マスターとスレーブの概念があります。マスターはスレーブにデータを複製します。スレーブシャードがあります。つまり、マスターはデータを複製する必要があり、同期または非同期のいずれかの方法で複製できます。 Redisスレーブシャードがダウンすると、マスター自体が停止し、クラスタが使用できなくなります。これは大きな問題であり、常に発生する可能性があります。オープンソースまたは Redis ラボ展開 Redisその場合、マスターシャードのスレーブサーバーがダウンすると、クラスター自体が使用できなくなります。そのため、このシナリオから回復するには、手動で介入する必要があります。 NCache 自動です。つまり、どのサーバーがダウンしても、生き残ったノードがアクティブまたはバックアップとして機能します。
例えば、このサーバーがダウンしたとします。これはアクティブパーティションで、バックアップパーティションも持っています。このサーバー全体がダウンした場合、バックアップがアクティブに昇格します。バックアップパーティションがアクティブに昇格し、生き残ったノードからすべてのデータを取得します。また、接続フェイルオーバー機能が組み込まれています。サーバーがダウンすると、クライアントは実行時にそれを検知し、生き残ったノードにフェイルオーバーするかどうかを判断します。ここで、この概念を強調したいと思います。 Redis 少なくとも3台のサーバーが必要です。これは多数決の概念です。クラスタコーディネータは選挙で勝利する必要があります。 NCacheわずか2ノードで完全に動作するキャッシュクラスタを開始でき、完全な高可用性機能を実現します。いずれかのサーバーがダウンしても、残りのノードは問題なく完全に動作します。これは、 Redis.
動的構成。実行時にクラスタ構成を変更できます。これには、新しいサーバーの追加、サーバーの削除、またはキャッシュクラスタの設定変更が含まれます。これは、クラッシュクラスタ全体に対して実行時にクラスタを停止することなく適用できるものです。一方、 Redis制限があります。手動で適用しなければならない設定が多数あり、また、利用可能なクラスタヘルスイベントも多数あります。 NCache サブスクリプション型のサービスで、監視・管理ツールも利用できます。 Redis これらの機能はありません。
これは非常に重要な概念です。簡単にまとめると、サーバーの追加と削除は Redis これは多くの問題を引き起こす可能性があります。データを追加しても自動的に再バランス調整されません。つまり、100%ピアツーピアアーキテクチャではありません。そのため、キャッシュクラスターの容量には限界があります。同様に、スレーブシャードがダウンすると、クラスター自体が使用できなくなります。これは、分散の問題が発生するため、手動で管理する必要があるためです。フェイルオーバーも手動です。つまり、サーバーがダウンした場合は、手動でフェイルオーバーし、残りのノードを使用して開始する必要があります。新しいサーバーを追加する場合は、新しく追加されたサーバーに手動で切り替える必要があります。
これらはすべて、あなたが直面するであろう制限です。そして、このような性質の本番環境の導入で、キャパシティを増強したり、メンテナンスのためにサーバーを停止したりする必要が生じるのは、想像に難くありません。ですから、このような製品では非常に困難です。 Redis。 一方、 NCache シームレスなエクスペリエンスを提供します。サーバーの追加や削除をリアルタイムで実行でき、何の影響も与えません。
動的パーティション/シャード
さて、クラスター内のもう 1 つの概念は、自己修復メカニズムです。
NCache 動的パーティション機能を備えています。サーバーを追加すると、データが再分配され、実行時に新しいパーティションが作成されます。同様に、サーバーがダウンすると、クラスターはバックアップを利用可能にし、自己修復して、2ノードから3ノードにダウンした場合、正常な2ノードのキャッシュクラスターを構築します。信頼性の面でも優れています。レプリケーションパーティション機能も備えており、こちらも利用可能です。 Redis スレーブとして機能しますが、その高可用性はレプリケーションに依存します。 Redis スレーブシャードが設定されていない場合、高可用性は実現できません。そのため、スレーブシャードを利用できるようにする必要があります。 NCache、トポロジがあります。
例えば、パーティションキャッシュでは、マスターシャードとマスターパーティションが存在します。このサーバーがダウンしても、クライアントはそれを検知し、フェイルオーバーして残りのノードを使い始めるため、高可用性は維持されます。データ損失は発生しますが、これは次のケースにも当てはまります。 Redis レプリケーションがないためデータ損失はありますが、高可用性は維持されています。さらに、レプリケーションサポートも強化されています。このサーバーがダウンした場合、サーバーのバックアップが利用可能になるだけでなく、クライアントも自動的にフェイルオーバーされます。つまり、 Redis 制限があります。高可用性はレプリケーションに依存します。レプリケーションが有効になっていない場合、高可用性は実現されず、これも制限要因となります。
そして、手動による介入を必要としない自己修復メカニズムです。
3台のサーバーで運用を開始し、3台のサーバーがダウンすると、アクティブパーティション（マスター）が使用され、その後、別のサーバーのスレーブも失われます。この場合、サーバー1のバックアップはサーバー2上に存在していたため、これがアクティブになります。実行時にアクティブパーティションに統合されます。介入は必要ありません。手動操作は不要で、その後、パーティションサーバー1がサーバーXNUMX上に正常なパーティションを作成します。つまり、クラスターは自動的に修復されます。これが、クラスタの動的な性質です。 NCache と比較して Redis. どこで Redis実行時にシャードを再調整することはできません。スレーブシャードがダウンするとクラスタは停止します。データの再配分は動的ではありません。高可用性はレプリケーションに依存しますが、 NCache. NCache レプリケーションがなくても高可用性を実現します。
つまり、あなたが得るこれらのメリットは NCacheこれらは完全に欠けているか、制限された機能であるため、はるかに優れた製品になります Redis これはAzureにも当てはまります Redisこれはオープンソースにも当てはまります。なぜならこれらは非常に類似した製品であり、 Redis ラボ Redis 提供も同様です。
NCache デモ
これから、実際の製品の動作をお見せして、どのように機能するかについて理解を深めていただきます。 NCache 設定が完了しました。これがデモ環境です。私はこれで作業を進めてきました。それでは新しいキャッシュを作成します。これはインストール時に付属するWeb管理ツールです。 NCacheシリアル化のモードはバイナリまたはJSONのいずれかを選択できます。完全にあなた次第です。ここではキャッシュに名前を付け、キャッシュクラスターの作成方法、クライアントアプリケーションの接続方法、そして監視と管理の方法を説明します。
このウェビナーの主な焦点は NCache 対 Redisなので、詳細はシンプルにしておきます。パーティションレプリカは、私たちが最も推奨するトポロジです。アクティブとバックアップ間の非同期レプリケーションです。同期を選択できます。非同期の方が高速なので、こちらを選択します。キャッシュクラスタのサイズ。次に、これらのサーバーノードを指定します。 NCache すでにインストールされています。TCP ポート。 NCache TCP/IPベースの通信プロトコルです。ここではすべてをシンプルにし、キャッシュがいっぱいになったときにエビクションを有効にするだけにします。これにより、キャッシュから一部のアイテムが自動的に削除され、新しいアイテムのためのスペースが確保されます。このキャッシュを開始して終了します。サービス起動時にこれを自動開始するように設定すれば、サーバーが再起動されるたびに自動的にキャッシュクラスターに参加します。これで完了です。キャッシュクラスターの設定と使用方法はこれだけです。次に、その仕組みを説明します。
クラウド サポート (Azure および AWS)
マネージドサービスモデルが近づいてきています。次のリリースでは、2～3週間後にリリースされる予定の、完全なマネージドサービスモデルに焦点を当てています。 NCache Azure と AWS におけるサービスとしてのソフトウェア モデル。
現時点では、VMモデルになります。オンプレミスの場合は、物理マシンまたはVMマシンを使用できます。Azureを選択する場合は、マーケットプレイスからVMをセットアップするか、VMをセットアップしてインストールする必要があります。 NCache ソフトウェアは当社のウェブサイトからダウンロードできます。また、コンテナ化された環境も提供しています。Dockerイメージも提供しており、Azure Kubernetes Service、EKS（Elastic Kubernetes Service）、その他OpenShift Kubernetesプラットフォームなど、あらゆるプラットフォームで完全にサポートされています。 NCache これらのプラットフォームに既に完全に統合され、完全にサポートされています。マネージド機能に関しては、今後対応予定です。そのため、2～3週間後には完全に利用可能になる予定です。
それでは、統計ウィンドウを紹介します。これはパフォーマンスカウンタです。ちなみに、これらの監視オプションは NCache、 の面では NCache Windows 環境でも Linux 環境でも同様ですか?
ストレステストツールを実行します。別のキャッシュで既に実行されていると思いますので、もう1つ実行して、キャッシュクラスターへのダミー負荷をシミュレートします。名前を指定するだけで、設定ファイルを使ってサーバーが自動的に検出され、接続されます。
完全接続されたクラスターのステータス、スループットを示す1秒あたりのリクエスト数、キャッシュ操作ごとの平均マイクロ秒単位のレイテンシ、追加、フェッチ、更新、削除、キャッシュサイズ、CPU、メモリなどが表示されています。これにより、集中監視ビューが得られます。このツールをご利用ください。Windowsのperfmonもご利用いただけます。
Linuxベースのサーバー向けには、カスタマイズされた監視ツールをご用意しています。Linuxサーバーにも当社の監視ツールを直接ご利用いただけるほか、サードパーティ製の監視ツールもご利用いただけます。 NCache も同様です。以上がキャッシュ作成プロセスの概要です。監視と管理の側面についても少し触れました。
さて、話を戻します。いくつか詳細についてお話ししましたので、次にクラウドサービスとクラウドサポートについてお話ししたいと思います。 Redis キャッシュ自体は、アンマネージドキャッシュとマネージドキャッシュから選択できます。また、ホスト型サービスも利用可能で、マネージドオプションはサードパーティベンダーから提供されます。ホスト型オプションはAzureから提供されます。 Redis、オープンソース版の Redis マイクロソフトによってカスタマイズされており、ホストモデルとして利用可能です。 NCache キャッシュサーバーモデルとVMモデルがあります。コンテナアプローチについては既に説明しました。WindowsコンテナとLinuxコンテナの両方に完全に互換性があります。Windowsコンテナ向けのAzure Service Fabricとマイクロサービスアーキテクチャの詳細については、ビデオデモをご用意しています。Linuxコンテナを使用するAzure Kubernetes Service、EKS（Elastic Kubernetes Service）、そしてKubernetes経由でRed Hat OpenShift Container Platformも提供していると思います。
これらはすべて利用可能なコンテナ展開オプションであり、柔軟性が高く、プラットフォームに依存しません。つまり、あらゆる種類のコンテナ化されたプラットフォームに問題なく展開できます。マネージドサービスについては既に説明しました。 NCache マネージドサービスもありましたが、それは次のバージョンで行われます。
VMモデルを使用するメリットの一つは、サービスではなくVMに接続する必要があるものの、すべてを制御できることです。サーバーサイドコードも実行できますが、これについては後ほど説明します。最も重要なのはパフォーマンスです。既に説明したように、VMモデルには多くのパフォーマンス機能が搭載されています。 NCache、欠けている RedisAzureを選択した場合 RedisAzureインフラストラクチャに接続する必要があります。つまり、これらはVMであり、別の仮想ネットワークで実行されています。これらは近くにありますが、やはり遠く離れています。これは、Microsoft Azureにある、すべてのアプリケーション展開が存在する独自の仮想ネットワークとは異なります。
自律的AI NCache あなたは私たちの NCache アプリケーション仮想ネットワークと同じ仮想ネットワーク上にデプロイできます。例えば、App Service、Azure Webサイト、Azureマイクロサービスなどは、Azure仮想ネットワーク上で実行されています。Azure VMを同じ仮想ネットワーク上にデプロイすることで、アプリケーションのパフォーマンスを向上させることができます。当社のラボで行った独自のテストに基づき、 NCache SaaSモデルよりも4～5倍高速でした Redis これはMicrosoft Azureで通常得られる機能です。この点は特に強調しておきたい重要な点です。
さらに、VMを細かく制御できます。キャッシュの開始、サイズの増加、フルキャパシティの活用など、あらゆる制御が可能です。リクエスト単位の制限やサイズ制限はなく、使用量のフットプリントも発生せず、それに伴うコストも発生しません。ライセンスはご自身でご用意ください。永久ライセンスやサブスクリプションライセンスも選択可能で、ライセンスに関して非常に柔軟性があります。さらに、VM上でサーバーサイドコードを実行することもできます。 NCache サーバー。これを完全に管理し、完全に最適化できます。リードスルー、ライトスルー、ライトビハインド、キャッシュローダー、そしてMapReduce、アグリゲータ、エントリプロセッサといったコンピューティンググリッド機能など、多くのインターフェースを記述できます。これは、 NCacheホスト型SaaSモデルであっても、これらすべてのサービスが利用可能になりますが、 Redisこれが私たちのプラットフォームです。
キャッシュを最新に保つ
次の15分は、機能レベルの比較についてお話しします。そのために、いくつかセグメントを定義しました。それでは、キャッシュを最新の状態に保つ必要がある場合についてお話しします。これは非常に重要ですので、バックエンドのデータソースやアプリケーションのユースケースに特化してキャッシュを最新の状態に保つ方法について、別途ウェビナーを開催する予定です。
つまり、 Redis、 ほら、 NCache この面でも多くの機能があります。
当社には、絶対的かつスライド式のタイムベースの有効期限があり、そのための自動リロード メカニズムも用意されています。 Redis リロード機構がなく、絶対有効期限とスライド有効期限のみを持つ。リロードのために、リードスルーハンドラと呼ばれるサーバー側コードのインターフェースを実装できる。繰り返しになるが、これが可能なのは NCache VMへのフルアクセスを許可し、 NCache ホストされています。そのため、サーバーサイドのコードを NCache 使用する NCache それを裏付ける計算能力。
キャッシュをデータベースと同期できます。 NCache データベース同期に非常に優れています。SQL依存関係、DB準拠のDB依存関係、そして.NET CLRストアドプロシージャがあります。これらの機能により、キャッシュとデータベースの同期が可能になります。ここでの考え方は、データベースに変更があった場合、つまりデータベースのレコードが変更され、そのレコードがキャッシュされていた場合、これら2つのソースは同期が取れなくなる可能性があるということです。 NCacheデータベースに変更があった場合、そのデータを自動的に無効化または再ロードすることができます。 NCache 実行時に。これは NCache他の製品にはこの機能はありません。そのため、バックエンドデータベースと完全に同期したキャッシュを実現できます。これはリレーショナルデータベースだけでなく、非リレーショナルデータソースにも適用できます。
ファイル依存性は、アイテムをファイルに依存させることができるもう1つの機能です。ファイルの内容が変更されると、アイテムが自動的に削除または再読み込みされます。また、カスタム依存性は、任意のソースで使用できます。NoSQLデータベース、ファイルシステム、リレーショナルデータベース、任意のコネクタ、任意のWebサービスなどです。そのため、柔軟な要件に基づいてアイテムを検証できます。この依存性の実装をCosmos DBで提供しています。そのため、同期を実装しました。 NCache Cosmos DB を使用している場合 NCache Cosmos DB と一緒にカスタム依存関係を使用することもできます。これについてはウェビナーも実施したと思います。
リレーショナルデータの処理。リレーショナルデータには関係性があります。キャッシュ内のアイテムはキーと値のペアなので、異なるアイテム間の関係性を構築できます。これは、 Redis 側面があります。つまり、それぞれの項目を個別に評価する必要があるのです。 NCache アイテムを1対1、1対多、または多対多のグループにまとめることができます。親アイテムに変更が加えられると、子アイテムは必要に応じて自動的に無効化または再読み込みされます。
データのグループ化、SQLおよびLINQ検索
もう一つの側面はデータのグループ化と検索です。 NCache とても強いです Redis 機能がない。これはAzureにも当てはまる。 Redis いずれにせよ、非常に限定的です。オープンソース Redis わずかに先行していますが、機能面ではまだ限られています。 Redis ラボ、商用版 Redis、これらの機能は装備されていません。
SQL検索が利用可能です。 NCache オブジェクト属性に基づいて検索します。オブジェクトはキャッシュに追加されます。属性にはインデックスを定義できます。例えば、商品はID、価格、カテゴリのインデックスを作成でき、これらの属性を使って商品を検索できます。典型的な例としては、「select product where product dot category is something or product dot price is greater than 10 and product dot price is less than 100 and」などがあります。 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アクティブ・パッシブ方式を採用しています。つまり、一方のデータセンターからもう一方のデータセンターへのデータ転送は一方向です。また、アクティブ・アクティブ方式も採用しています。これは、両方のサイトがアクティブ状態にある場合に非常に重要で差し迫ったユースケースです。サイト1の更新情報をサイト2に反映させる必要があり、その逆も同様です。つまり、これは「アクティブ・アクティブ」方式では実現できません。 Redis サイドです。その能力がないので、アクティブ・アクティブサイトを運営することはできません。 Redis NCache これは、両方のサイトでデータが更新されるアプリデータキャッシュのユースケースにも当てはまります。これは、マルチサイトセッションでも同様です。つまり、これはもう1つの領域です。 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バックプレーンとASP.NET Coreレスポンスキャッシュも利用できます。つまり、これらすべてが、Web固有のキャッシュ要件を満たす完全な機能セットを構成しています。詳細については、機能セットをご確認ください。
イベントによる実行時データ共有
そして、Pub/Sub メッセージングがあります。
アイテムレベルのイベントと基準に基づいたイベント通知システムがあり、これは他のものと比べてはるかに優れています。 RedisPub/Subメッセージングに関する別のウェビナーも開催していますので、ご質問があればぜひそちらをご覧ください。それでは、この辺で締めくくりたいと思います。
サードパーティの統合
最後に、サードパーティの統合です。
NHibernate と Entity Framework もあります。 AppFabric ラッパーは利用可能です。 Memcached ラッパーが利用可能です。そのため、これらの製品から移行する場合は、シームレスに移行できます。 NCache と比較して Redis.
セキュリティと暗号化
詳細 セキュリティ暗号化 すでに時間切れになっていると思います。
結論
さて、そろそろ締めくくりにしましょう。まず、いつでも、いつでもwww.alachisoft.comにアクセスして、エンタープライズ版をダウンロードできます。 NCache お客様の環境でどのように機能するかを直接お見せいたします。ぜひウェブサイトにアクセスして、30日間の無料エンタープライズトライアルをお試しください。デモのご予約も承ります。また、このウェビナーの録画も公開いたしますので、配信後、メールやソーシャルメディアでご確認ください。本日中にご質問にお答えできなかった場合は、メールでお問い合わせください。まだ多くのご質問が寄せられており、締め切り間近となっております。 support@alachisoft.com.
技術的な質問があれば、私たちがお答えします。また、先に進んで応募することに興味があれば、 NCache あなたの環境では、連絡を取るだけで sales@alachisoft.com 同様に。