EFコアアプリを最高のパフォーマンスにスケーリングする方法は？
録画されたウェビナー
ロン・フセイン、ザック・カーン著
EF Core は、高トランザクションの .NET サーバー アプリケーション (ASP.NET、Web サービス、マイクロサービス、およびその他のサーバー アプリ) で使用されることが増えています。 また、これらのアプリケーションは、データベースによるスケーラビリティのボトルネックに直面していますが、EF Core 内の分散キャッシュを使用することで解消できます。
- EF Core の新機能の紹介 (モデル、クエリ、データの保存)
- 分散キャッシュが EF Core データベースのボトルネックを解決する方法
- EF Core アプリで分散キャッシュを使用するさまざまな方法
- EF Core 拡張メソッドをキャッシュに使用する方法の詳細
- コレクションとデータ関係のキャッシュの処理
Entity Framework Core (EF Core) は、Microsoft の .NET 用の新しいクロスプラットフォームの軽量オブジェクト リレーショナル マッピング エンジンであり、開発者が作成するデータ アクセス コードのほとんどが不要になります。 に似ている .NET Core, EF Core はクロスプラットフォームでもあるため、Windows、Linux、Mac で使用でき、開発者コミュニティ内で非常に人気が高まっています。
アプリケーションをスケールアウトして、極限のパフォーマンスとリクエスト処理能力の直線的な増加を実現するにはどうすればよいでしょうか? したがって、次を使用してアプリ、Entity Framework Core アプリケーションをスケールアウトできます。 NCache 拡張メソッド。 そこで、活用できるものをいくつか揃えました。 さまざまなシナリオを描き、それをもとに紹介していきます。 NCache 拡張メソッドだけでなく、環境内の一般的な Entity Framework Core アプリケーション内で使用できるオブジェクト キャッシュ機能も含まれます。
Entity Framework / EF Core とは何ですか?
まず、Entity Framework と Entity Framework Core について一般的に説明します。 EF と EF Core については誰もが知っていると思いますが、完全を期すために、いくつかの入門的な詳細を説明します。
Entity Framework は .NET で使用できる ORM であり、EF Core を使用すると、.NET だけでなく .NET でも使用できます。 .NET Core。 Entity Framework はデータベース プログラミングを簡素化します。 概念的なオブジェクト モデルに取り組むことができます。 したがって、データ モデルを直接操作する必要がなく、データ アクセス プログラミング全体が簡素化されます。 永続的なコードを自分で記述する必要はありません。 これにより、アプリケーション内のオブジェクト層と、Entity Framework Core によって生成されるデータベース アクセスを使用したデータ モデルとの間で多くの相互作用が生成される可能性があります。
.NET では非常に人気があり、 .NET Core アプリケーション。 これは、Web アプリケーション、典型的なサーバー アプリケーション、.NET など、あらゆる種類のアプリケーションで使用できます。 .NET Core Web サービス、IoT ユースケース、またはその他のサーバー アプリケーションは、その人気と使いやすさにより、これを利用できます。 セットアップは非常に簡単で、すぐに始めることができます。
Entity Framework Core は新しいバリアントです。 これが Microsoft の新しい方向性であり、まず第一にオープンソースであり、クロスプラットフォームです。 したがって、を使用しているアプリケーションを実行できます .NET Core または .NET をご存知ですか。 Windows 上で .NET と .NET Core Windows だけでなく Linux 環境でも同様に実行できます。 エンティティフレームワークコア 訴訟に従いますよね？ そのため、要件に応じて Windows だけでなく Linux 環境でも実行でき、非常に軽量でモジュール式の性質を持っています。 これは本質的に、これまで使用していた Entity Framework 内のすべてのコンポーネントを実行する必要がないことを意味します。 EF Core では、必要なコンポーネントを操作できます。 そのための NuGet パッケージのみを入手でき、それに基づいてアプリケーション内で段階的に複雑さを構築できます。
したがって、必要に応じて、アプリケーション内の複雑なシナリオを管理する必要があります。 その上、超高速なので、 .NET Core 特定の焦点やパフォーマンス面もあります。 したがって、Entity Framework Core は、パフォーマンスが達成できる重要な要素の XNUMX つである同じガイドラインに基づいて設計されています。
Entity Frameworkのアーキテクチャ図
これが Entity Framework Core のアーキテクチャ図です。
今でも適用できる Entity Framework 図を見つけました。多くのことが Entity Framework Core アーキテクチャにも適用されます。 これは MSDN からのものです。 EF Core を使用すると、ADO.NET データ プロバイダーが使用できます。 データ ソースの例として SQL Server を使用します。次に、コマンド ツリーとデータ アクセス シナリオを構築する Entity Client データ リーダーがあり、次にオブジェクト サービスがあり、アプリケーション側で Entity を操作します。 SQLクエリまたはLINQ エンティティに。 したがって、再びオブジェクト モデルを操作し、舞台裏で Entity Framework Core が他のすべての詳細を処理します。
実行時にマッピングとモデルを生成するために実行するコマンドがあるため、概念モデル、EDMX、これらすべてのマッピング ファイルは Entity Framework Core 内で削除されています。 したがって、再セットアップは非常に簡単です。 繰り返しますが、モジュール式です。 したがって、NuGet パッケージを導入すると、非常に単純な Entity Framework Core アプリケーションを数分で構築できます。
スケーラビリティとは何ですか？
次に、スケーラビリティについて説明します。これも私が強調したいもう XNUMX つの概念です。 Entity Framework Core を使用しているアプリケーションでキャッシュが必要なのはなぜですか? まず第一に、スケーラビリティの概念があります。 これはアプリケーション内で非常に優れた機能であり、ピーク負荷時にも高いアプリケーション パフォーマンスを実現できます。 したがって、待機時間をできるだけ短くすることができ、ユーザー負荷が低い場合 (たとえば XNUMX ～ XNUMX 人のユーザー) でその低待機時間を維持でき、同じように管理できるようなアプリケーション アーキテクチャ設計がある場合は、大量のユーザー リクエストの負荷がかかっても遅延が少ない場合、そのアプリケーションは非常にスケーラブルなアプリケーションとして分類されます。
また、線形スケーラビリティは、さらに多くのサーバーを追加して負荷を分散できる概念であり、複数のサーバーに負荷を分散することで、サーバーの数が実際に増加し、リクエスト処理能力が増加し、その増加は直線的に増加するはずです。 したがって、サーバーを追加するにつれて容量が増加し、直線的に増加するバナーを実行しているアプリケーションがある場合、それは直線的にスケーラブルなアプリケーションとして分類されます。
スケーラビリティが必要なアプリケーションは何ですか?
したがって、通常は、ASP.NET や ASP など、本質的に高トランザクションのアプリケーションが使用されます。.NET Core Web アプリ、Web サービス、IoT、ビッグ データ アプリケーション、またはその他の一般的な .NET または .NET Core Entity Framework コアを使用するアプリケーションでは、高いスケーラビリティが要求されます。 そのため、アーキテクチャ内で高いトランザクション負荷の処理能力が必要になります。
スケーラビリティの問題は一体どこにあるのでしょうか?
では、問題は一体どこにあるのでしょうか? この問題を解決するためになぜキャッシュ システムが必要なのでしょうか? Web ファームとアプリ ファームはいつでも作成できます。Web ファームまたはアプリ ファームを作成することで、Entity Framework Core アプリケーション自体が直線的にスケールアウトできます。 ロードバランサーを前に置くことができます。 したがって、それは主な懸念点ではありません。 アプリケーション層はいつでもスケールアウトできます。 これが、Entity Framework Core と一般的な .NET または .NET Core アプリケーションが設計されています。 リクエストを複数のサーバーにルーティングし、それらを相互に組み合わせて使用できる場所。
主な問題は、データ ストレージのボトルネックです。 通常、リレーショナル データベースの場合は、これが使用される例です。 データベースは通常、すべてのデータ ストレージに対する単一のソースです。 保管にとても適しています。 それは彼らが最も得意とすることです。 しかし、極端な量のリクエスト負荷を処理する場合、たとえば、アプリケーションから大量のトランザクション データや参照データの負荷が入ってくる場合、データベースはその増加した量のリクエスト負荷を処理できるように設計されていません。 ユーザー負荷が低い場合はうまく機能しますが、CPU 側やメモリ側の容量を消費し始めると、すべてのリクエストがルーティングされる DBMS トンネルが存在します。 データ ストレージがスケーラビリティのボトルネックになる可能性があります。 実行時に生成されるリクエストをキューに入れるため、パフォーマンスが低下します。 したがって、別のデータベース サーバーを追加することはできません。
まず最初に費用がかかりますし、XNUMX つのサーバーを組み合わせて使用することはできません。 したがって、パフォーマンスの価値を高めることはできず、パフォーマンスが低下し、エンド ユーザー エクスペリエンスにも影響を及ぼし、ひいてはビジネスにも影響を与える可能性があります。 なぜなら、アプリケーションのパフォーマンスが遅い場合、多くのユーザーはアプリケーションの動作が遅いことを好まないからです。 したがって、アプリケーションは常に低レイテンシと高スループットを必要とし、高スループットを維持するにはパフォーマンスの損失が伴います。データベースでは、アプリケーションの速度が低下するか、ほとんどの場合完全に停止する傾向がデータベースに見られる傾向があります。
ソリューション
このセクションでは、これに対処する方法について説明します。 解決策は非常に簡単です。 使用できます による分散キャッシュ システム NCache。 インメモリなのでとても速いです。 単一のソースではないため、非常に拡張性が高くなります。 必要な数のサーバーをキャッシュ クラスターに追加でき、キャッシュ クラスター内のそれらのサーバーは相互に組み合わせて動作します。 データを分散すると、リクエスト処理の負荷が分散され、サーバーを追加することでシステムの拡張性も向上します。 これは、従来のリレーショナル データベースに代わるものではありません。 EF Core アプリケーション内の分散キャッシュをデータベースと組み合わせて使用します。 したがって、最も簡単にアクセスできるデータ、参照データをキャッシュするか、トランザクション データの一部もキャッシュします。
また、さまざまなキャッシュ シナリオを処理する方法、アプリケーション内で利用できるキャッシュ戦略についても説明します。
デプロイメントアーキテクチャ
ここでは、リレーショナル データベースと比較して、なぜそれがより良い選択肢であるのかをいくつか明確にする展開アーキテクチャを示します。
まず、分散キャッシュはアプリケーションとデータベース層の間に位置します。 そして、その中間にあるということは、基本的に、アプリケーションはここでデータを見つけた場合に最初にキャッシュを使用し、ここでデータが見つからない場合にのみキャッシュを返し、その後バックエンドデータベースに移動する必要があるということですよね？ したがって、論理的には、アプリケーションとデータベースの間に位置します。
デプロイメントに関しては、アプリケーションを VM、物理ボックス、オンプレミス、またはクラウドにデプロイできます。 NCache Microsoft Azure だけでなく、事前構成されたイメージの形式で AWS でもサポートされており、または他のクラウドでも、Web サイトからダウンロードできるインストーラーを使用して、インストールを開始できます。これは非常に簡単です。設定。 NCache 独自のそれぞれの層に、個別の専用サーバーを配置できます。 NCache または、同じボックス上で実行することもできます。 アプリケーションをデプロイするボックスがある場合は、 NCache それも同じ層にあります。 個別のボックスを用意することをお勧めします。最初は XNUMX ～ XNUMX 台のサーバーを追加し、その後、リクエスト処理の要件に基づいてサーバーをさらに追加していきます。
たとえば 10,000 人のユーザーとそれに関連するリクエストの負荷を処理する必要がある場合は、いくつかのテストを実行すると、必要なサーバーの数がわかります。 一般に、最近のテストに基づくと、わずか 4 ～ 5 件のリクエストで XNUMX 秒あたり XNUMX 万件のリクエストを達成できました。 NCache サーバーですよね？ したがって、アプリケーションの負荷要件を処理するために必要なサーバーの数がわかります。 のみの前提条件 NCache .NET または .NET Core。 Windows、Windows Nano、および Linux サーバー上で実行されます。 同様に、アプリケーションは Windows プラットフォームまたは Linux プラットフォーム上に存在できます。
また、強力なデータベース同期機能もいくつかあります。 先ほども述べたように、これは従来のデータベースを置き換えるものではありません。 それはデータベースを使用し、データベースと一緒に使用されます。 したがって、一部のデータはキャッシュになりますが、すべてのデータは常にリレーショナル データベースである永続ストアに存在します。 そして、キャッシングの方法については後ほど説明します。
一般的に使用される 3 つの分散キャッシュの使用例
一般的な使用例をいくつか示します。 分散キャッシュの一般的な使用例で、最も顕著なのはアプリのデータ キャッシュです。 ここにはEntity Framework Coreがあります。
アプリケーションデータのキャッシュ
したがって、最も一般的なユースケースである最初のユースケースは、アプリデータのキャッシュのユースケースです。 この場合、通常はデータベースに属するデータをキャッシュします。 ここでの動機は、高価なデータベースへの移動を可能な限り節約し、データ取得の高いパフォーマンスが得られるというメリットです。 データベースはインメモリ アクセスに比べて遅いため、インメモリであるため超高速であり、アプリケーションからのリクエストをホストして処理する複数のサーバーがあります。 そのため、分散キャッシュに与えられる低遅延を維持しながら、システムからのスケーラビリティとスループットが向上し、複製できないデータベースとは異なり、選択したトポロジに基づいて可用性と信頼性が高くなります。他のサーバー間でも。
アプリ データ キャッシュを使用すると、ほぼすべてのものをキャッシュできます。 直接 API を使用できます。 ドメイン オブジェクト、コレクション、データセット、単一アイテム、結果など、キャッシュしたいデータをキャッシュできます。そのデータが再度必要になった場合は、オブジェクト キャッシュの使用と Entity Framework Core の使用を検討してください。また、直接 API または拡張機能を使用できます。これから紹介する方法。
ASP.NETセッションキャッシュと SignalR Backplane
次に、別のユースケース NCache それはASP.NETとASPですか.NET Core 特定のキャッシュ。 セッションキャッシュがあります。 ASP でのセッション キャッシュ.NET Core IDistributedCache を経由するだけでなく、 NCache セッションプロバイダーも。 これが XNUMX 番目のオプションです。 SignalR Backplane。 それも利用できる別のオプションです。 SignalR アプリケーションをお持ちの場合は、次のように使用できます。 NCache バックプレーンとして。 これもコード変更のないオプションであり、応答キャッシュ、ビューステート、出力キャッシュがあります。 したがって、これらはすべて ASP.NET に固有の機能であり、これに加えて、必要に応じて Web アプリケーション内でアプリ データ キャッシュを使用することもできます。
Pub/Sub メッセージングと継続的クエリ
そして、強力な Pub/Sub メッセージングと継続的クエリ イベント、つまり Pub/Sub メッセージングとイベントが備わっています。 使用できます NCache メッセージング プラットフォームとして使用します。複数のアプリケーションが接続されており、それらのアプリケーションは Pub/Sub メッセージングを使用して相互に通信できます。 アプリケーションはメッセージを次の宛先にパブリッシュできます。 NCache、コミュニケーションチャネルとして機能します。 これにはトピックの概念があり、これらのサブスクライバ アプリケーションは、そのトピックに接続されている場合にそのメッセージを受信できます。 したがって、データを共有したり、必要に応じてカスタム メッセージを共有したりして、相互に調整できます。 そしてソーシャルメディアシステムを構築することもできます。 チャットシステムが使えます。 リーダーボードを持つことができます。 アプリケーションのさまざまなコンポーネントを相互に連携させる必要があるあらゆる種類の業界で、必要に応じて使用できます。
マイクロサービス間の通信
マイクロサービスも別の使用例です。サーバーレス マイクロサービス アプリケーションが必要で、相互に対話し、アプリケーションは次のことを行うことができます。 NCache コミュニケーションのニーズに応えるため、継続的なクエリ イベントもあります。 データが追加、更新、削除される定期的なイベント。 アプリケーションがイベントを送信する代わりに、 NCache データの変更に基づいてアプリケーションにイベントを送信できます。これは、すべての項目、選択した項目、またはデータセットをマップする連続クエリに基づいて行うことができます。 NCache & NCache 指定されたデータセットのイベントのみを送信します。
XNUMX 番目の使用例もあります。 全文検索機能があります。 これは電子商取引アプリケーションでは非常に一般的です。 と NCache Lucene .NET API を実装しました。 全文検索機能に興味がある場合は、 NCache それも完全に装備されています。
EF Core でのアプリ データのキャッシュ
典型的な Entity Framework Core アプリケーションでキャッシュを使用する方法について説明します。
サンプルアプリケーションのセットアップ
それで、まず第一に、私はこのアプリケーションを持っています。 サンプルアプリケーションはここに並んでいます。 これは、インストールされているサンプルの XNUMX つです。 NCache 同じように。 したがって、C:\Program Files\ に移動すると、NCache\、これらのサンプルはここから入手できます。
.NETおよび .NET Core サンプルは別に置いてあります。 それで、私は先に進みます .NET Core およびエントリー フレームワークについては、ここに EF Core サンプルがあります。 ということで、今回使用したサンプルです。
このウェビナーで紹介する予定のシナリオのいくつかを示すために、少し変更しました。 それ以外の場合は、POC の基本的なジョブが完了します。 そうです、これがサンプルです。 次に私が行うことは、デモ環境にログオンし、実際にキャッシュ クラスターを使用してそこから適切に取得できるように、キャッシュ クラスターを作成することから始めます。
クラスター化キャッシュの作成
そのため、キャッシュを作成するために、Web 管理ツールを稼働させています。 早速作成してみます。 それでは、クラスター化キャッシュを追加しましょう。 これをデモキャッシュと名付けましょう。 いくつかの整数、democache111 を追加します。 ちなみに、シリアル化に関する限り、JSON またはバイナリ形式を維持できます。 さあ、どうぞ。 したがって、バイナリまたは JSON シリアル化形式を使用できます。 これがデフォルトのオプションであるため、ここではバイナリを使用していきます。 選択できるキャッシュ トポロジは XNUMX つあり、他にも次のようなウェビナーがあります。 NCache 特に対象となるアーキテクチャについて説明すると、 NCache 建築。 そこで、パーティション レプリカ キャッシュを使用することにします。これは、読み取り、書き込みに非常にうまく機能し、さらにサーバーを追加し続けてレプリカも装備されている場合、読み取りおよび書き込みリクエストの容量に関して非常にスケーラブルであるためです。したがって、アプリケーションのダウンタイムやデータ損失も発生しません。
したがって、私はすべてをデフォルトのままシンプルにします。 アクティブなパーティションとそのバックアップ間の非同期レプリケーション。 それで、私はそれを選択するつもりです、それはより速いです。 キャッシュ クラスターのサイズと、ここでキャッシュ クラスターをホストするサーバーを指定しました。 先ほども言いましたが、主な焦点は Entity Framework Core であるため、すぐにキャッシュを作成します。 それ以外の場合は、定期的なウェビナーで NCache Azure アプリケーションのアーキテクチャまたはスケーリング NCache、これらのウェビナーでは、これらすべての機能について詳細に説明しました。 したがって、この特定のウェビナーでは、先に進み、キャッシュをすばやく作成します。 そうですね、デフォルトのポート TCP/IP を指定し、このキャッシュを起動して自動起動して、サーバーが再起動されたときに自動的に起動するようにします。 それで、ほぼそれだけです。
ストレスのシミュレーションとキャッシュ統計の監視
キャッシュ構成に関しては、このウィザードに従うだけで済み、複数のサーバー上にキャッシュが作成されます。 それも始まったと思います。 統計ウィンドウを開いてから、 NCache モニターウィンドウは、付属のツールとしてインストールされています。 NCache。 現在アクティビティはありませんが、ストレス テスト ツール アプリケーションを実行できます。 これはテスト ストレス ツールと呼ばれるもので、キャッシュ クラスターに対するダミーのアクティビティ、つまりダミーの負荷をシミュレートします。 すべてが正しく構成されていることを確認するためだけに行ってください。 サーバー XNUMX とサーバー XNUMX では、XNUMX 秒あたり約 XNUMX ～ XNUMX のリクエストが発生していることがわかります。 したがって、合計で XNUMX 秒あたり約 XNUMX のリクエストを処理し、レイテンシーを確認できます。 キャッシュ操作あたりの平均待ち時間は非常に最小限のマイクロ秒です。 およそ XNUMX ～ XNUMX マイクロ秒の間のどこかだと思います。
したがって、このグラフは更新され、ユニットはダウンします。 わかったら、さらに負荷を加えます。 実際にやってみましょう。 右。 したがって、別のインスタンスを実行中です。 ここで、増加した値が表示されるはずであることを示します。 つまり、以前は各サーバーで XNUMX 秒あたり約 XNUMX のクエストを処理していました。 現在、各サーバーのリクエスト数は XNUMX 秒あたり XNUMX ～ XNUMX の間であり、キャッシュ操作あたりの平均マイクロ秒は XNUMX 操作あたり約 XNUMX ～ XNUMX マイクロ秒であることがわかります。 これはパフォーマンスが大幅に向上することです。 アプリケーションが最大値に達していないか、サーバーがまったく最大値に達していないことを考慮してください。 したがって、使用時にアプリケーションからのミリ秒未満またはマイクロ秒未満の応答が期待できます。 NCache。 これで環境は設定されました。 すべてが設定されています。 大丈夫だと思います。 これらのテストを中止して、キャッシュ シナリオについて説明するサンプル アプリケーションを作成して確認してみましょう。
どの EF Core エンティティをキャッシュするか?
まず最初に、Entity Framework Core 内でキャッシュを行う方法について説明します。 どの EF Core エンティティをキャッシュするか? 通常、選択肢は XNUMX つあります。 単一のエンティティがある場合もあれば、エンティティ コレクションであるクエリ結果がある場合もありますよね。 単一のエンティティが返されたか、コレクションである可能性があります。 単一のエンティティはそのまま保存されます。 コレクションは単一のアイテムとして保存することも、各コレクション アイテムを個別にキャッシュに追加することもできます。その方法について説明します。
EF Core エンティティ キャッシュ オプション
直接 NCache API。 XNUMX つのアプローチがあります。 まず第一に、あなたが使うことができます NCache API を直接使用しますよね? つまり、これはオープンソース、エンタープライズ、プロフェッショナルでも同様に使用できるものです。 そして、Entity Framework のコア拡張メソッドについては、少し時間をかけて説明します。
EF Core 単一エンティティのキャッシュ: NCache 直接API
直接 API。 ここではダイレクト API について詳しく説明します。 ここから見せてあげましょうね？
Customers GetCustomer (string CustomerId)
{
string key = "Customer:CustomerId:" + CustomerId;
Customers customer = (Customers)_cache.Get(key);
if (customer != null)
{
return customer;
}
else
{
customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FirstOrDefault();
_cache.Insert(key, customer);
return customer;
}
}したがって、通常、これは顧客の取得メソッドです。 直接 API を使用している場合は、顧客 ID を持っている可能性があります。 したがって、まず第一に、キャッシュ キーを構築する必要があります。 したがって、それは必須として行う必要があることです。 なぜなら、その中で、 NCache すべてはキーと値のペアに保存されます。 Key はオブジェクトを識別するための文字列キーです。 オブジェクト部分は、キャッシュに追加する実際の値、実際のプロパティです。 アプリケーション用にキャッシュする実際のデータ。
そこで、私はこの主要な構成を思いつきました。キーワードとして顧客を持ち、次に顧客 ID を持ち、それから私に渡される実行時パラメータを提供します。 つまり、ここでこの特定の顧客を一意の顧客 ID で識別することになりますよね? したがって、これらの顧客を一意に識別できるようにし、cache.Get を呼び出してキャッシュから項目を取得します。 右？ したがって、まず第一に、キャッシュを使用している場合は、キーが構築されていることを確認する必要があります。次に、最初に、cache.Get を呼び出して、キャッシュ内で使用できるデータを確認します。このキャッシュ ハンドルは何かです。それはキャッシュを初期化するときに返されますよね?
それで、私はここでこのキャッシュを使用しています、 NCache.InitializeCache。 これにより、キャッシュを初期化し、キャッシュに接続できるようになります。 キャッシュ内に項目が見つかった場合、つまり顧客が null ではなかった場合は、ここから戻るだけです。 データベースへの高価な移動を節約できます。これがキャッシュ システムを使用する主な動機です。 NCache あなたのデータがあるでしょう。 したがって、バックエンド データベースを通じて高価な旅行を節約できます。 データベースにアクセスする必要はありません。 ただし、このアプリケーションを初めて起動するため。 したがって、その場合、キャッシュにはデータがありません。
したがって、その場合は、Entity Framework Core 内でリンクする Entity Framework Core を実行します。 単一の項目またはコレクションのいずれかを返します。 これは単一アイテムのシナリオであり、次に、cache.Insert を呼び出して、次回使用するためにこれを実際に追加し、顧客も返します。 したがって、次回は、変更されていないか、データと同期されていない限り、このデータは常にキャッシュ内で見つかることになります。 つまり、これがエンティティ、ダイレクト API の唯一の使用法です。
EF Core エンティティ コレクションのキャッシュ: NCache 直接API
コレクションの場合、ダイレクト API は非常に似ています。
List GetCustomersByCity (string CustomerCity)
{
string key = "Customers:City = " + CustomerCity;
List custList;
custList = (List)_cache.Get(key);
if (custList != null)
{
return custList;
}
else
{
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).ToList();
_cache.Insert(key, custList);
return custList;
}
} 都市ごとに顧客がいます。 顧客の都市は実行時パラメータです。 顧客のリストを作成し、そのコレクション リストを NCache cache.Get、顧客のリストを取得します。 それが null でない場合はここから戻ります。null の場合は、バックエンド データベースから取得し、次回使用するためにキャッシュに追加する必要があります。 したがって、これらの顧客アイテムを個別に保存したい場合は、この custList を反復処理し、各コレクション アイテムに一意のキーを提供することで、cache.Insert を個別に呼び出すこともできます。 したがって、それも利用できる別のオプションです。
ただし、最初にキーを作成し、キャッシュから項目を取得する必要があります。 存在する場合は null 処理を実行し、存在しない場合はデータベースから取得し、データ ロジックを実行して追加します。 つまり、それは Direct と関係があるのです NCache API。 これは、典型的なデータベース キャッシュの最も一般的な使用例です。 アプリのデータ キャッシュの場合、これが通常行うことです。
EF Core 単一エンティティのキャッシュ - EF Core 拡張メソッド
しかし、拡張メソッドを使用するという別のアプローチがあり、それが主なハイライトです。 コレクション全体を XNUMX つのアイテムとしてキャッシュしたり、拡張メソッドを使用して各コレクション アイテムを個別にキャッシュしたりすることができます。
Customers GetCustomer (string CustomerId)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
Customers customer = (from cust in database.Customers
where cust.CustomerId == CustomerId
select cust).FromCache(out string cacheKey,
options).FirstOrDefault();
return customer;
} ここで最初に紹介する拡張メソッドを紹介します。 これは From Cache という名前ですが、多くの自動化を行ってくれます。 これは、まず最初にいくつかのキャッシュ オプションを構築できるように機能します。 したがって、まずキャッシュ オプションを作成します。この時点で紹介する属性の XNUMX つは、Store As です。 それで、 NCache これにより、コレクションを単一のアイテムとして保存する必要があるか、個別のアイテムとして保存する必要があるか、コレクション アイテムとして保存する必要があるかを選択できるようになります。 コレクションに 10 個のアイテムがあったとします。 したがって、これらは 10 個の個別の項目として追加されます。 NCache それともここにあるコレクションとして保存したいですよね？ つまり、それが XNUMX 番目のオプションです。 この場合、キャッシュ内に XNUMX つの項目として保存されます。
したがって、私は別のエンティティを使用しています。 したがって、ここでこのコードを実行すると、From Cache という拡張メソッドがあり、この定義を示すと、それは次の場所から来ています。 NCache Alachisoft .NCache.EntityFrameworkCore。 これがメインの名前空間であり、ここに来て NuGet パッケージをお見せします。 「インストール済み」の下には、 Alachisoft .NCache.EFCore NuGet パッケージ。 したがって、これが導入する必要がある NuGet パッケージであり、その後、これらの拡張メソッドを開始できます。 まず、これは出力参照キャッシュ キーなので、キャッシュ キーは次のように生成されます。 NCache そしてあなたに与えられました。 つまり、それが柔軟性であり、オプションをパラメーターとして受け取るだけです。 したがって、多くの自動化が行われ、舞台裏で多くの作業が行われます。 FromCache は、最初にキャッシュ内のデータを自動的にチェックするように動作します。つまり、見つかった場合はデータベースに保存されません。
ただし、キャッシュにない場合は、原則としてデータベースにアクセスしてクエリを実行し、結果セットを取得して、このキャッシュ キーを使用してキャッシュに追加し、そのアイテムにこれらのキャッシュ オプションを設定します。 。 したがって、これと比較すると、キャッシュ キーを構築する必要はありません。 null の処理やキャッシュからの取得を自分でチェックする必要はありません。 キャッシュに挿入する必要はありません。 この拡張メソッドを使用するだけです。 そのため、多くの作業が自動化され、アプリケーションのプログラミング モデルも非常に簡素化されます。
EF Core エンティティ コレクションのキャッシュ: EF Core 拡張メソッド
また、コレクションとして保存する場合と同じように、コレクションとなるキャッシュ オプションを指定するだけです。この場合、返す顧客のリストが得られます。 したがって、クエリを実行して、もう一度 FromCache を呼び出すだけです。 これで、最初の拡張メソッドとその紹介は完了です。
List GetCustomersByCity (string CustomerCity)
{
List custList;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
custList = (from cust in database.Customers
where cust.City == CustomerCity
select cust).FromCache(out string cacheKey,
options).ToList();
return custList;
} EF Core にキャッシュするデータは何ですか?
次に、リファレンスデータとトランザクションデータについて説明します。 これがメインセグメントです。
読み取りが多いアプリケーション、書き込みよりも読み取りが多いデータを扱うことになり、書き込みだけでなく読み取りも行われるアプリケーション シナリオが存在する可能性があります。 たとえば、ルックアップ データ製品や従業員は、それほど頻繁には変更されませんが、静的データではありません。変更されるものですが、変更の頻度はそれほど大きくなく、データ全体がキャッシュに存在する必要があります。 この特定のシナリオでは、数時間または数日後に期限切れにする必要がある理由を説明します。 それはキャッシュを最新の状態に保つ方法であり、それは別のセグメントです。
次に、トランザクションデータがあります。 トランザクションデータのキャッシュを処理する方法について説明します。 動的に作成されます。 注文、アカウントなどは一例です。 トランザクション データは非常に頻繁に変更されるため、通常、トランザクション データはキャッシュに好まれませんでした。 なぜなら、それはユーザーがアクティブな間に変更され、アプリケーションから消えるはずであり、その時点でのみ必要になるからです。 ただし、私たちの経験に基づいて、トランザクション データのキャッシュも有効にすることを強くお勧めします。 なぜなら、データを変更していない間はまだアクティブであるため、そのデータを何度も読み取る可能性があり、何百万ものユーザーがログインしている場合、そのデータに対する何百万ものリクエストがデータベースに戻されることになります。キャッシュされており、変更中に XNUMX ～ XNUMX 回のリクエストが発生する可能性があっても、パフォーマンスの観点からは依然として有益です。 したがって、すべてではないにしても、トランザクションの一部をキャッシュすることを検討することを強くお勧めします。
EF Core での参照データのキャッシュ
さて、EF Core で参照データのキャッシュを処理するにはどうすればよいでしょうか?
これには XNUMX 段階のプロセスがあります。 データ全体をキャッシュにロードできます。これは必須です。 したがって、すべての参照データはキャッシュにロードされる必要があり、それが必須として推奨されます。 なぜ？ データベースにまったくアクセスしたくないからですよね? 先に進み、データベースからすべてのデータのロードを開始する必要があります。 NCache これをすぐに処理し、キャッシュのみを使用してデータベーストリップを回避する拡張メソッドがあります。
ステップ XNUMX では、常に別個のエンティティとしてキャッシュされます。 これは、すべての製品またはその他のすべての製品をコレクションとしてキャッシュすべきではないというもう XNUMX つのヒントです。 それは数千の製品、または数百万の製品になる可能性があります。 ただし、それらを個別に保存すると、後の段階でデータのサブセットをフェッチできるようになります。 したがって、たとえば、すべての製品をロードしても、後でキャッシュから必要となるのは廃止された製品だけです。 したがって、たとえば XNUMX 個の製品を個別にキャッシュに保存した場合、それがこれから示す例です。 その時点で必要なものだけを見つけることができます。 そのため、製品データセット全体を扱う必要がなく、データベースへの高価な移動を再度節約できます。
EF Core での参照データのキャッシュ: 事前読み込みキャッシュLoadIntoCache という拡張メソッドがあります。次にこれを示し、これの実例も示します。
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
// Loads all products into cache as individual entities
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}
さて、LoadIntoCache、まず第一に、キャッシュ オプションを「別個のエンティティとして保存」として設定する必要があります。次に、すべての製品をロードするクエリを実行する必要があります。次に、LoadIntoCache を呼び出してオプションを指定する必要があります。これもまたキャッシュ キーを作成するだけです。これらすべてを個別に自動的に実行します。 そして、これらすべての項目をキャッシュに読み込み続けてから、次のような LINQ クエリを実行できます。この LINQ クエリは NCache。 拡張メソッドは使用していません。 product.Discontinued のデータベース製品で product を呼び出しており、FromCache のみがあります。 データベースにはまったく保存されません。 それはから得ています NCache 直接。
EF Core での参照データのキャッシュ: キャッシュのみから参照データを検索する参照データがある場合は、まず別のエンティティをロードする必要があります。 キャッシュへのロードを使用してすべての製品をロードします NCache。 それが完了したら、データベースにアクセスする必要はありません。 次に、FromCache の代わりに FromCacheOnly を使用します。 最初の拡張メソッドは FromCache で、キャッシュをチェックインし、キャッシュにない場合はデータベースに移動します。 ただし、LoadIntoCache はすべての製品をロードし、その後 FromCacheOnly はすべてのデータがキャッシュにロードされているという前提でキャッシュとのみ通信するようにします。
List<Products> FindDiscontinuedProducts (NorthwindContext database)
{
//Fetch discontinued products only out of all products
List<Products> discontinuedProducts;
discontinuedProducts = (from product in database.Products
where product.Discontinued == true
select product).FromCacheOnly().ToList();
return discontinuedProducts;
}このコードを実行して、実際の動作を確認してみましょう。 このテスト用にキャッシュが設定されているので、統計を表示します。 いろいろ遊んでました。 60,000点の製品が搭載されています。 それでは、コンテンツをクリアしていきましょう。 そうです、それでは統計を確認しましょう。 私のキャッシュはどこにありますか? さあ、どうぞ。 そうですね、アイテムがゼロなので、これを実行します。 単一の項目をキャッシュし、これまでに示したすべてのコード例を収集するだけですが、LoadIntoCache がどのように機能するかを示し、それに基づいてブレークポイントも設定します。
最初の XNUMX つの例は、単一の項目をロードし、次にコレクションをロードするもので、最初に示したコードと、ここで実際にすべての製品をロードして、参照データのシナリオを示しています。 まず第一に、別個のエンティティとして保存し、いくつかの優先順位と依存関係を設定します。その点では複雑です。その後、すべての製品をロードしてデータベースから取得します。実行を続けることを強くお勧めします。プロダクトをロードし、一定の間隔を置いてキャッシュにロードされるため、データベースからデータを取得してキャッシュにロードすると、常にデータベースに対して機能します。 常にデータベースに送信され、データベース内にあるものはすべてデータベースに対して実行され、そのデータがフェッチされます。 NCache その後、FromCacheOnly を使用します。
これが参照データの扱い方です。 まず、それらを個別に個別に保管します。 LoadIntoCache。この拡張メソッド LoadIntoCache を使用します。これは常にデータベースに対して実行されます。 キャッシュを優先しません。 常にデータベースに対して実行され、すべてがフェッチされます。 NCache 次に、FromCacheOnly を使用します。 それはとても簡単です。
EF Core でのトランザクション データのキャッシュ
トランザクションデータ。 ロードできるのはワーキングセットのみです。 それは結果セットのキャッシュのためですよね？
個人的には、都市ごとの顧客や製品に基づいた注文に興味がある場合は、何らかの結果セットのキャッシュを用意し、それを実行することをお勧めします。 それらをコレクションとして保存するか、結果のサイズに基づいて個別のエンティティとして保存する必要があります。コレクションのサイズがそれほど大きくない場合、たとえば最大 100 または 200 のアイテムを扱う場合は、それらをコレクションとして保存します。トランザクションデータとして分類される複数の製品、複数の注文、または顧客情報です。 それらを別の実体として保存します。 そのため、そこからサブセットを取得し、キャッシュを最大限に活用できます。
EF Core でのトランザクション データのキャッシュ - フェッチしてコレクションとしてキャッシュするこの使用例も非常に簡単です。 単にコレクションとして保存するか、FromCache を使用します。データベースがキャッシュにない場合はデータベースにアクセスするため、FromCacheOnly は使用しません。
List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection,
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
//Fetch from cache. If not found then fetch from DB.
orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder)
.FromCache(out string cacheKey, options).ToList();
return orderList;
}ここまでXNUMXつの拡張方法を紹介してきました。 FromCache は、データベースから取得するキャッシュではなく、キャッシュとデータベースを自動的に操作します。 LoadIntoCache は常にデータベースに対して実行されます。 オブジェクトをフェッチしてキャッシュに取り込むと、FromCacheOnly が常にキャッシュに対して実行され、それが唯一の真のデータ ソースになります。 データベースには入りません。 それで、多くのことが明確になることを願っています。
キャッシュを最新に保つ
次のセグメントは、Entity Framework Core でキャッシュを最新の状態に保つ方法に基づいています。これは、XNUMX つの異なるソースを扱うときに理解する必要があるもう XNUMX つの重要な概念です。
キャッシュが有効になっています。 メインのデータ ソースであるバックエンド データベース、永続的なデータ ストア、そしてデータのコピーを持つキャッシュがあります。 では、データベースと比較してキャッシュが最新であることを確認する方法を説明します。 それでは、ここで少し時間を過ごしましょう。
キャッシュを最新の状態に保つ: 参照データ
まず第一に、データセット全体がキャッシュにあるので、データベースに変更があった場合はどうなるかを考えるべきですよね?
したがって、キャッシュからデータを期限切れにする必要があります。そのためには、オプションとして有効期限を設定してからデータの自動再ロードを使用することをお勧めします。 したがって、戦略 XNUMX は、有効期限を使用し、リロードは行わないことです。 したがって、データの有効期限が切れるたびに、キャッシュにも自動的に再ロードされるようにするため、ここで「すべての製品をロード」という設定を行います。
戦略 1: 自動リロードを使用して有効期限を使用するvoid LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
options.SetAbsoluteExpiration(DateTime.Now.AddHours(10));
options.SetResyncProviderName("MyEFCoreResyncProvider");
// Load all products into cache with Expiration and Auto-Reload
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}ここからはちょっとお見せしましょう。 したがって、まず最初に、それらを別のエンティティとして保存します。これは参照データの使用例だからです。 これらをすべての製品としてロードし、何らかの有効期限を設定してから、options.SetResyncProvider を設定します。リロード プロバイダーが存在し、options.IsSyncEnabled を true に設定する必要があります。 つまり、自動リロード、有効期限が切れた場合にキャッシュに自動的にリロードされるということですね。 したがって、これらの XNUMX つのプロパティは、SetResyncProviderName を実行した場合に、自動リロード フラグを自動的に true に設定します。
namespace Alachisoft.NCache.EFSampleResyncProvider
{
public abstract class EFDefaultResyncProvider : IReadThruProvider
{
public virtual void Init(IDictionary parameters, string cacheId)
{
db = InitializedDbContext();
}
public virtual void LoadFromSource(string key, out
ProviderCacheItem cacheItem)
{
cacheItem = new ProviderCacheItem(FetchItemFromDb(key));
cacheItem.AbsoluteExpiration = DateTime.Now.AddHours(10);
cacheItem.ResyncItemOnExpiration = true;
}
public virtual void Dispose()
{
db.Dispose();
}
}
}そして、ここに ResyncProvider が必要です。つまり、サンプル実装がここにあります。
namespace Alachisoft.NCache.EFSampleResyncProvider.Provider
{
public class EFResncProvider : EFDefaultResyncProvider,
IReadThruProvider
{
public override DbContext InitializedDbContext()
{
return new NorthwindContext();
}
}
}さあ、どうぞ。 IReadThruProvider を実装する必要があります。 データ ソースを初期化し、最後に破棄します。その後、LoadFromSource を使用してキーを取得し、そのキーに基づいて SQL コマンドを作成し、データベースから項目をフェッチします。ここでは、所有しているキャッシュ キーからの SQL クエリ。
そうですね、このサンプル実装のキーは GitHub でも入手できます。 したがって、キャッシュにロードされたアイテムにもう一度キャッシュへのロードを実行すると、有効期限が付加されるように機能します。 したがって、有効期限のいずれかである XNUMX ～ XNUMX 時間後に期限切れになり、その後、このプロバイダーが起動し、リード スルー ハンドラーを使用して LoadFromSource が自動的に呼び出され、更新されたデータが取り込まれます。 NCache。 そうです。キャッシュ内のアイテムの有効期限が切れた後、キャッシュは自動的に最新になります。
戦略 2: 有効期限を使用せず、手動でリロードする私が個人的にお勧めする XNUMX 番目のアプローチは、式を使用せず、LoadIntoCache を呼び出して手動でリロードすることです。 もう一度お見せしますが、この LoadIntoCache メソッドを思いつくだけで十分です。 一定の間隔を置いてこのメソッドを呼び出し続け、式は使用しません。 これらを取り除きましょう。
void LoadAllProducts (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities,
};
var res = (from products in database.Products select
products).LoadIntoCache(options).ToList();
}したがって、これは、たとえば XNUMX 時間、XNUMX 時間、XNUMX 日、週、月に対してのみ有効な参照データになることがわかります。 これに基づいて、すべての製品をロードすることを繰り返します。 これは一定の間隔を置いて呼び出されるはずですよね？
つまり、有効期限間隔に関するインテリジェントな推測に基づいてデータを手動でリロードする必要があるという考えですね。 したがって、作業時間を設定し、その後自動的にすべての製品のロードを呼び出す必要があります。 そのため、バックエンド データベースからデータが自動的に取得され、参照データが最新の状態に保たれます。
したがって、これらを繰り返します。 したがって、選択肢は XNUMX つあります。 有効期限を使用している場合、データはキャッシュから削除されます。 したがって、部分的なセットが得られることになるため、必須として自動リロードが必要になります。 ただし、有効期限を使用しない場合は、参照データとしてすべてのデータが常にキャッシュ内に存在することになり、一定の間隔の後にそのデータを手動でリロードできます。 それが明確になることを願っています。
キャッシュを最新の状態に保つ: トランザクション データ
次に、トランザクション データのキャッシュを最新の状態に保つことについて説明しますが、これは非常に簡単です。 自動リロードせずに、常に短い有効期限を使用する必要があります。 これもまた、有効期間が XNUMX ～ XNUMX 分間のみの短命データであり、FromCache を使用する必要があるため、キャッシュにない場合は常にバックエンド データベースから取得する必要があります。
ここにその一例を示します。顧客からの注文を受け取り、それらをコレクションまたは個別のアイテムとして保管するかどうかは、完全にお客様次第です。 必要に応じて有効期限を短くするか、有効期限を使用しないか、または有効期限を使用してから自動リロードを使用しないでください。 そのため、有効期限が切れるとすぐにデータベースから取得されます。 個人的には、構成可能な有効期限を使用するか、このデータ セットの有効期限であることが確実にわかっている有効期限を設定することをお勧めします。 したがって、その後は必要なくなります。 したがって、有効期限が自動的に切れる必要があり、その時点でデータベースへのアクセスが強制され、バックエンド データベースから自動的に取得されます。
有効期限が短く、自動リロードなし private List<Orders> GetCustomerOrders (string CustomerID)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs = StoreAs.Collection
};
options.SetAbsoluteExpiration(DateTime.Now.AddSeconds(60));
List<Orders> orderList = (from customerOrder in database.Orders
where customerOrder.Customer.CustomerId==CustomerID
select customerOrder).FromCache(out string cacheKey,
options).ToList();
return orderList;
}以上、参照データとトランザクション データの処理方法について説明しました。 次に、参照用にキャッシュを最新の状態に保つ方法やトランザクション データについても説明しました。
キャッシュ内の関係の処理
XNUMX対多
キャッシュに関して発生する可能性のあるその他の事柄がいくつかあります。 EF Core のキャッシュ内の関係の処理。 繰り返しますが、とてもシンプルです。 Include がサポートされているため、データベース リージョンを含むリージョンがあり、その隣にregion.Territories が取得されます。 したがって、FromCache を呼び出すと、リージョンとテリトリーを別々に保存し、リージョンとテリトリーの間の関係を定式化します。 したがって、領土のある地域を取得することを示したとします。
List<Region> GetRegionWithTerritories(NorthwindContext database)
{
List<Region> regionDetails;
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.SeperateEntities
};
regionDetails = (from region in database.Region select region)
.Include(region => region.Territories)
.FromCache(options).ToList();
return regionDetails;
}それがここにある例です。 右。 したがって、この領域の詳細には FromCache が含まれており、FromCache を使用しています。 したがって、リージョンとリージョン テリトリーを個別に保存し、項目を分離してから、キー ベースの依存関係を構築します。 リージョンが変更されると、テリトリーも無効になり、その逆も同様です。 したがって、これが XNUMX 対 XNUMX または XNUMX 対多の関係を処理する方法です。
集計操作のキャッシュ
集計操作もサポートされています。 したがって、これらの拡張メソッドを Deferred First または Default、FromCache で実行できます。 これは、遅延カウント、FromCache に基づくことができます。 つまり、結果セットとして保存することになるのですね。 したがって、これは単なる集計操作の結果であるため、コレクションとして保存するか、単一のアイテムとして保存するかは問題ではありません。 つまり、これは Entity Framework の別の可能性です。
集計操作のキャッシュ - エンティティを返す
Shippers GetFirstShipperInstance (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
Shippers shipper = database.Shippers.DeferredFirstOrDefault()
.FromCache(out string cacheKey, options);
return shipper;
}集計操作のキャッシュ - 戻り値
int GetTotalShippersCount (NorthwindContext database)
{
CachingOptions options = new CachingOptions
{
StoreAs = StoreAs.Collection
};
int count = database.Shippers.DeferredCount()
.FromCache(out string cacheKey, options);
return count;
}分散キャッシュアーキテクチャ
それでは、最後に分散キャッシュに関するアーキテクチャの詳細についてお話したいと思います。 なぜそれを検討すべきなのか。 可用性が高く、レプリケーションを備えた非常に信頼性の高いものです。 これはピアツーピア アーキテクチャのキャッシュです。 単一障害点はありません。 実行時にサーバーを追加または削除でき、クライアントには接続フェイルオーバーのサポートが組み込まれています。 したがって、可用性が高く、100% の稼働時間で非常に信頼性が高くなります。 これには、多くのキャッシュ トポロジ、クライアント キャッシュ、WAN レプリケーション、パーティション分割されたレプリカが付属しており、質問があればアーキテクチャの詳細について具体的にお話します。この時点でプレゼンテーションは終わりです。
高可用性
キャッシングトポロジ
クライアントキャッシュ（キャッシュの近く）
キャッシュのWANレプリケーション
まとめ
これについて簡単にまとめてみたいと思います。 このウェビナーでは、キャッシュ オプション、ダイレクト API、Entity Framework コア拡張メソッドについて説明しました。 したがって、これらの中から選択するオプションがあります。 私たちは Entity Framework Core Extension Methods に重点を置きました。それが私たちが投影したいものだったからです。 使いやすくなりました。 参照データとトランザクション データに取り組む方法。 そこで、参照データのデータ全体をロードし、次に個別のエンティティのアプローチを使用して、キャッシュ内にあるすべてのデータに対してのみキャッシュを使用するというアプローチについて説明しました。 トランザクション データの場合は、結果セットにのみキャッシュし、キャッシュにない場合にデータベースにアクセスできるように FromCache 拡張メソッドを使用することをお勧めします。 そして、キャッシュを最新の状態に保つために、参照データの場合は自動リロードで有効期限を使用するか、有効期限を使用せずに一定の間隔後に手動でリロードし、トランザクション データの場合は必ず有効期限を使用する必要があると話しました。 これは有効期限が短いはずですが、自動リロードがないため、データベースに戻って次回の使用時にキャッシュを更新できます。
いつでもご連絡いただけます。 support@alachisoft.com。 技術的な質問がある場合は、次のアドレスまでご連絡ください。 sales@alachisoft.com。 製品をご覧になりたい場合は、ダウンロードできます NCache Enterprise 30日間の無料トライアル。