分散キャッシュでのリレーショナルデータの処理
録画されたウェビナー
RonHussainとAdamJ.Kellerによる
このビデオウェビナーでは、分散キャッシングのために既存のデータ関係をキャッシュオブジェクトに適用する方法を学びます。
あなたはについて聞くことを期待することができます：
- リレーショナルデータベースと分散キャッシュのデータストレージモデル
- オブジェクトリレーショナルマッピングの良さ–オブジェクトレベルでデータ関係を管理する方法
- 'one-one'、'one-many'、および'many-many'関係のマッピング
- 使い方 NCache リレーショナルデータの動作を模倣するためにオブジェクト間の関係を構築する機能
- キーベースの依存関係、オブジェクトクエリ言語、グループ、グループAPI、コレクション、タグの使用
- リレーショナルデータ用のその他の重要な分散キャッシュ機能
分散キャッシングを導入する方法について説明します。 リレーショナルデータベースがある場合、いくつかの課題、パフォーマンスの問題、スケーラビリティの問題があり、その後、リレーショナルデータベースとともに分散キャッシュの使用に移行します。 あなたが得る課題とそれらの課題を管理する方法は何ですか？ それが、今日のウェビナーの議題です。
かなり実践的なものになるでしょう。 いくつかのコード例を紹介したいと思います。 いくつかの実際の例についてお話します。 これを示すために実際に使用するいくつかの例が並んでいます。 そして、最後に、いくつかの基本的なことを学ぶための実践的な部分もあります NCache 構成。
NCache、それが主な分散キャッシング製品です。 この特定のウェビナーのサンプル製品としてこれを使用します。 しかし、全体として、これは一般的なトピックのウェビナーです。 データベースにリレーショナルデータがあり、分散キャッシュがあります。 移行してから、リレーションシップを持つリレーショナルデータ内で分散キャッシュの使用を開始する方法。これは構造化データです。 それでは、これを見ていきましょう。
スケーラビリティとは何ですか？
そこで、まず、スケーラビリティの概念であるスケーラビリティについて説明します。 スケーラビリティは、トランザクションの負荷を増やすことができるアプリケーション内の機能です。 ますます多くのリクエストを処理できる場所では、アプリケーションアーキテクチャからロードされます。 また、パフォーマンスに妥協することはありません。したがって、スループットが高く、レイテンシが低い場合、その機能はスケーラビリティと呼ばれます。 したがって、大量のリクエストの負荷を処理でき、個々のリクエストのパフォーマンスが低下することはありません。 同じです！ また、リソースが増えると、それをさらに増やすことができます。線形スケーラビリティは、サーバーを追加することで、システムに導入された要求負荷処理能力が多い場所を実際にスケールアウトできるようにする関連用語です。 そして、ほとんどの場合、パフォーマンスは低下しません。
したがって、レイテンシが低く、リクエストの負荷が直線的に改善されている場合、以前は10,000秒あたりXNUMXリクエストを処理していましたが、XNUMX人のユーザーの場合でも、XNUMX人のユーザーの場合は数ミリ秒またはサブミリ秒の応答時間などの一定のレイテンシがあります。 ; 同じ種類の応答が必要であり、XNUMX人のユーザーまたはXNUMX万人のユーザーに対して同じ種類のレイテンシーを実行する必要があります。 そして、ユーザーの負荷とそれに関連する要求の負荷を増やし続ける能力は、線形スケーラビリティと呼ばれます。
どのアプリがスケーラビリティを必要としますか？
では、スケーラビリティを必要とする典型的なアプリケーションは何ですか、
公開されているのは、ASP.NET Webアプリケーション、Java Webアプリケーション、または.NETの一般的なWebアプリケーションです。 それは、eコマースシステム、航空券システム、予約システム、または実際に多くのユーザーが公の場を利用している金融サービスやヘルスケアサービスである可能性があります。 これは、WebサービスWCFや、一部のデータアクセスレイヤーと相互作用している、または一部のフロントエンドアプリケーションを処理しているその他の通信サービスである可能性があります。 ただし、任意の時点で何百万ものリクエストを処理している可能性があります。 モノのインターネット、一部のタスクがそれらのデバイスに対して処理するデータをデータ化できる一部のバックエンドデバイスである可能性があります。 そのため、多くのリクエストが読み込まれる可能性があります。 小型で安価なコンピューティングサーバーが多数あり、複数のサーバーにデータを分散することで、実際に大量のデータ負荷を処理する最近の流行語であるビッグデータ処理。
また、同様に、その特定のデータに対して膨大なモデル要求の負荷が発生します。 そして、何百万もの要求、多くのユーザーを処理する可能性のある他の一般的なサーバーアプリケーションや層アプリケーションである可能性があります。これらはスケーラビリティの主要な候補です。 これらは、アーキテクチャ内でスケーラビリティを必要とするアプリケーションです。
スケーラビリティのボトルネック
これは典型的な図です。 スケーラビリティのボトルネックは何ですか？
だから、これらはアプリケーションです。 設計上、これらのフレームワークは非常にスケーラブルです。 ASP.NET WebフォームまたはWCFフォームには、これらのシステムをスケールアウトするために使用できるオプションがあります。 しかし、それらはすべてバックエンドデータベースと通信し、通常はリレーショナルデータベースです。 ASP.NETセッションストレージ、メインフレーム、またはファイルシステムの場合もありますが、それは今日のウェビナーで取り上げているものではありません。 今日のウェビナーは、リレーショナルデータに焦点を当てています。 したがって、リレーショナルデータは単一のソースです。 ここには非常にスケーラブルなプラットフォームがありますが。 この層にさらに多くのサーバーを追加できます。 ロードバランサーを前面に配置することでスケールアウトでき、そのロードバランサーは異なるサーバー間でリクエストをルーティングできます。 しかし、これらすべてのWebサーバーは、それほどスケーラブルではないデータベース層と通信することになります。
だから、それは論争の源になるだろう。 開始に時間がかかり、スケールアウトできなくなります。 これは単一のソースであり、要求の容量を増やすためにデータベースサーバーを追加するオプションはありません。 そのため、リクエストの容量が最大になり、レイテンシが高くなる可能性があります。 したがって、これはリクエスト処理の容量の問題であり、レイテンシの問題が発生する可能性もあるため、リクエストの負荷が大きい場合にシステムが停止する可能性があります。
ソリューション
つまり、これがリレーショナルデータソースの主な問題であり、分散キャッシュの使用を開始するという非常に簡単な解決策です。
のような分散キャッシングシステム NCache これは、比較するとメモリ内にあり、線形にスケーラブルであるため、超高速です。 単一のサーバーだけではありません。 これは、サーバーのチームが容量に結合されている複数のサーバー環境です。 メモリ容量とトランザクション容量をプールすると、非常に線形にスケーラブルなモデルが得られます。 と、 NCache これはまさに、データベースのスケーラビリティの問題を処理するために使用できる種類のソリューションです。
インメモリ分散キャッシュとは何ですか？
のような一般的なメモリ内分散キャッシングシステムとは何ですか NCache？ 特徴は何ですか？
複数の安価なキャッシュサーバーのクラスター
これは、論理容量に結合された複数の安価なキャッシュサーバーのクラスターになります。
だから、これはその一例です。 XNUMX〜XNUMX台のキャッシングサーバーを使用できます。 にとって NCache、Windows 2008、2012、または2016環境を使用できます。 の前提条件のみ NCache は.NET4です。これは、アプリケーションとデータベースの中間層であり、データベース層と比較して非常にスケーラブルですが、高速化された.NETWebから得られるのと同じ種類のスケーラビリティを提供します。フォームまたはWCFWebサービスWebフォーム。
すべてのキャッシュサーバー間でキャッシュの更新を同期します
データの一貫性がプロトコルに組み込まれるように、すべてのキャッシュサーバー間でキャッシュの更新を同期します。 すべての更新は、接続されているすべてのクライアントの一貫したデータビューを理解した上で、自動的に適用されます。
トランザクションとメモリ容量を線形にスケーリングします
トランザクションに対して線形にスケールアウトする必要があります。また、メモリ容量からサーバーを追加するだけで、それに応じて容量が増加することはありません。 XNUMX台のサーバーがあり、XNUMX台目とXNUMX台目のサーバーを追加すると、サービス量がXNUMX倍になるため、基本的にそのシステムの容量がXNUMX倍になるはずです。 だから、それは何です NCache も提供しています。
信頼性のためにデータを複製します
次に、レプリケーションは信頼性のもうXNUMXつの機能です。 サーバーがダウンした場合、まず第一に、データの損失やダウンタイムが発生しないようにする必要があります。 それは高可用性で信頼性の高いシステムである必要があり、それが NCache の世話をします。
NCache 展開
したがって、これについて話し合ったので、リレーショナルデータソースと次のような分散キャッシングシステムにスケーラビリティの問題があります。 NCache はそのソリューションであり、アプリケーションとデータベースの間の中心的な層になり、データはXNUMXか所に存在します。
データベースにデータがあり、次に分散キャッシュにデータがあります。 それで NCache また、XNUMXつの異なるソースにデータがある場合に発生する可能性のあるいくつかの同期の課題も管理します。 このトピックに関する別のウェビナーがありますが、データアクセス層プロバイダーがいくつかあることを知らせるために、設定できる変更通知の依存関係がいくつかあります。
したがって、データベースでの変更は、キャッシュ内のアイテムの無効化または更新をトリガーする可能性があり、同様に、キャッシュで発生する変更または更新は、データベースに適用できます。 したがって、これはデータアクセス層プロバイダーの助けを借りて達成できます。 リードスルーとライトスルー。
また、データベースとキャッシュレコード間の100％の同期を確保するために実際に使用した、データベース変更の依存関係、レコード変更の依存関係もあります。 ただし、通常、データはXNUMXつの異なる場所に存在します。 キャッシュには通常データのサブセットであるデータがあり、次にデータベースに実際のデータがあります。 データを移行する場合、それは本質的にデータの移行です。 これらのXNUMXつのソースを互いに組み合わせて使用していますが、これらはXNUMXつの異なるソースです。
キャッシュするデータは何ですか？
先に進む前に、キャッシュできるデータの種類について簡単に説明します。データは参照データである場合もあれば、トランザクションデータである場合もあります。
通常、リレーショナルデータベースに属するのは、キャッシュする読み取り集中型のデータです。 それが変化していないということではなく、100％静的ではありません。 データは変化していますが、その変化の頻度はそれほど大きくありません。 したがって、それは参照データとして分類されます。 そして、非常に頻繁に変更されるトランザクションデータがあります。 数秒、数分、場合によっては数ミリ秒の頻度で。
そして、ほとんどのキャッシュデータはリレーショナルです。 これはリレーショナルデータベースから取得されたものであり、リレーショナルデータベースにマスターコピーのデータがあり、そのデータのサブセットである参照とトランザクションが分散キャッシュに取り込まれることについてはすでに説明しました。 右！
課題は何ですか？
それで、挑戦は何ですか？ それでは、実際にその課題について話し合いましょう！ データをデータソースからリレーションに分散キャッシュに移動して、システムのパフォーマンスとスケーラビリティ、および信頼性を向上させる場合。 あなたが直面している課題について実際に簡単に話し合いましょう。
それは非常にうまく機能します。 メモリ内にあるため、パフォーマンスが向上します。 線形にスケーラブルであるため、データベースのスケーラビリティの問題に対処します。 複数のサーバーがあり、任意のサーバーをダウンさせることができるため、単一障害点ではありません。 サーバーは問題なく起動できます。 メンテナンスがとても簡単になります。 アップグレードがはるかに簡単になります。 したがって、比較すると、多くのメリットがあります。 ただし、対処する必要のある課題がXNUMXつあり、データを移行するとき、またはデータベースから分散キャッシュにデータを移動して分散キャッシュシステムの使用を開始するときに、それを考慮する必要があります。
したがって、分散キャッシュはインターフェイスのようなハッシュテーブルです。 右！ 各アイテムはキーと値で区切られていますよね？ つまり、これはハッシュテーブルであり、キャッシュ内の各オブジェクト、キャッシュ内の各アイテム、またはキャッシュ内のレコードがキーを使用して表されます。 つまり、テーブルでも、関係のあるリレーショナルデータでもありません。スキーマを定義し、相互に適切な関係を持つエンティティを持っています。 これは、キャッシュ内のオブジェクトを表す個別のKeyValueアイテムになります。 したがって、データベースにはエンティティ間の関係があり、データを移行するとき、またはデータをリレーショナルデータベースから分散キャッシュに移動するとき、そのデータに特徴的な関係が失われます。
したがって、デフォルトではその機能がないため、これを削除できます。 これは主な課題のXNUMXつであり、データベースクエリがオブジェクトのコレクションに帰着する他の関連する課題がいくつかあります。 また、データテーブルまたはデータリーダーになります。 したがって、分散キャッシュでデータテーブルとデータリーダーを処理することはお勧めできません。 したがって、実際にはこれらすべての課題をXNUMXつずつ実行します。
主に、リレーショナルデータソースからキャッシュにデータを取り込んだ後、分散キャッシュ内の関係を管理する方法について説明します。
のぞき見 NCache API
次に、キャッシングAPIについて説明します。
これで、基本的にKeyValueStoreであることが説明しました。 キー「mykey」があるcache.addがあり、次に許可されたデータと許可されたシリアル化されたオブジェクトであるオブジェクトがあります。 これは、顧客オブジェクト、製品オブジェクト、注文オブジェクトのいずれでもかまいません。 しかし、これは非常に単純なhello worldのような例であり、cache.add、cache.updateを使用してKeyValueメソッドを呼び出します。 同様に、cache.getを呼び出して同じアイテムを取得してから、cache.removeを呼び出します。
キャッシュ内の関係を管理する
先に進みます！ では、キャッシュ内の関係を管理する方法は？ これで、キャッシュがインターフェイスのようなハッシュテーブルであり、キーと値のペアであるというこの課題を定義しました。 値は.NETオブジェクトであり、keyはフォーマットする文字列キーであり、これらは互いに独立したオブジェクトです。 また、データベースには、相互に関係のある関係テーブルがあります。 これは、異なるテーブル間のXNUMX対XNUMXのXNUMX対多および多対多の関係である可能性があります。
最初のステップ：キャッシュの依存関係を使用する
まず、キャッシュの依存関係の使用を検討する必要があるXNUMXつのことを検討する必要があります。主に、機能のXNUMXつであるキーベースの依存関係に焦点を当てています。キャッシュアイテム間の一方向の依存関係を追跡します。
したがって、XNUMXつの親オブジェクトを作成してから、その特定のオブジェクトに依存するオブジェクトを作成することができます。 そして、それが機能する方法は、あるアイテムが別のアイテムに依存するということです。 メインアイテム、プライマリオブジェクト、または親オブジェクト。 変更が行われると、更新または削除され、依存アイテムが自動的にキャッシュから削除されます。
次のスライドに並べた典型的な例は、特定の顧客の注文リストです。 つまり、顧客Aがあります。これには注文のリスト（たとえば100件の注文）があり、その顧客が更新された場合、またはキャッシュから削除された場合はどうなりますか。 それに関連付けられた注文は必要ないので、これらの注文コレクションについても何かをしたいと思うかもしれません。これはまさにこの依存関係であり、これら2つのレコードはに関連しているため、これらXNUMXつのレコード間のリンクが必要です。リレーショナルデータベース。
次に、この依存関係は、AがBに依存し、BがCに依存するという性質上、カスケードすることもできます。Cを変更すると、Bが無効になり、Aも無効になります。 したがって、カスケードされた依存関係である可能性があり、さらに複数アイテムの依存関係である可能性もあります。 XNUMXつのアイテムをアイテムAとアイテムBに依存させることができ、同様に、XNUMXつの親アイテムに複数の子アイテムを含めることもできます。 そして、これはASP.NETキャッシュによって最初に導入された機能でした。 それは強力な機能のXNUMXつでした NCache もあります。 これを個別のキャッシュ依存関係オブジェクトとファンシーオブジェクトのXNUMXつとして提供します。これは、この特定のウェビナーの主な焦点になります。
XNUMX番目のステップ：オブジェクトリレーショナルマッピングを使用する
XNUMX番目のステップでは、リレーショナルデータをマッピングするために、ドメインオブジェクトをデータモデルに実際にマッピングすることをお勧めするもうXNUMXつの課題があります。
したがって、ドメインオブジェクトはデータベーステーブルを表す必要があります。 ある種のO/Rマッピングを使用する必要があります。また、いくつかのO/Rマッピングツールを使用することもできます。 これにより、プログラミングが簡素化され、データベーステーブルにクラスをマッピングした後、コードを再利用できます。 EntityFrameworkやNHibernateなどのORMまたはO/Rマッピングツールも使用できます。 これらはいくつかの人気のあるツールです。
ここでの考え方は、アプリケーションにクラスが必要であるということです。 オブジェクト、アプリケーション内のドメインオブジェクト。 したがって、データベースオブジェクト、データテーブル、またはデータリーダーは、ドメインオブジェクトにマッピングされて変換されます。 したがって、顧客テーブルは、アプリケーションの顧客クラスを表す必要があります。 同様に、注文されたコレクションまたは注文テーブルは、注文クラスとアプリケーションを表す必要があります。 そして、それらは、分散キャッシュに処理および保存し、キー依存関係の助けを借りて関係を定式化するオブジェクトです。
関係の例の処理
例を見てみましょう！
そして、Northwindのデータベースモデルがあります。 顧客テーブル、注文テーブル、そして製品があります。 顧客ID、会社名、電話番号、市、州、国、いくつかの属性を持つ顧客のすべての列名があります。 同様に、製品ID、名前、価格、在庫数、注文単位、再注文レベルの製品があります。 つまり、これらは製品のいくつかの属性またはいくつかの列であり、外部キーとして顧客IDと製品IDを持つ注文テーブルもあります。 これで複合主キーが作成され、注文日、出荷日、および注文自体のいくつかの属性が得られます。 また、顧客と注文の間にはXNUMX対多の関係があり、製品と注文の間にはXNUMX対多の関係があります。 同様に、注文と顧客、注文と製品の間には、それぞれ多対XNUMXと多対XNUMXがあります。 そこで、この特定のシナリオに取り組みます。
当初、XNUMXつのXNUMX対多の関係に正規化されたのは、顧客製品の多対多の関係でした。 したがって、これは正規化されたデータモデルであり、この特定のデータモデルにマップされたメインオブジェクトにクラスがある場合の例を使用します。 そこで、プライマリオブジェクトについて少し説明しますが、ここで例を簡単に説明します。
ドメインオブジェクトがデータベースモデルにマッピングされていることに注意してください。 この同じ例では、主キーとして使用される顧客IDを持つ顧客クラスがあり、注文クラスとの関係が多すぎることを表す注文のコレクションがあります。 同様に、これらの製品ID、名前、単価と同じ製品属性を持つ製品がありますよね？ そして、ここにもXNUMX対多の関係を表す注文収集があり、注文側では、ここから顧客IDを取得し、ここから製品IDを取得してから、顧客である顧客を多対多で注文します。 XNUMXつのリレーションシップを作成すると、ドメインオブジェクトの一部としてキャプチャされたXNUMXつのリレーションシップに対して非常に多くの製品を注文できます。
したがって、これは、次のスライドで詳細に説明する手法のXNUMXつです。 Visual Studio内でもこれらのオブジェクトを表示できるので、これはクラスのXNUMXつです。
using Alachisoft.NCache.Web.Caching;
using Alachisoft.NCache.Runtime;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Alachisoft.NCache.Runtime.Dependencies;
using System.Collections;
namespace Relationships
{
public class Customer
{
public long CustomerId;
public string CompanyName;
public string Phone;
public string City;
public string State;
public string Country;
// one-to-many list of Order objects
public IList<Order> Orders;
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// Let's cache each product as seperate item. Later
// we'll search them through OQL
foreach (Product product in products)
{
string productKey = "Product:ProductId:" + product.ProductId;
cache.Add(productKey, product, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
cache.GetGroupData("DummyGroup", "DummySubGroup");
cache.GetByTag(new Alachisoft.NCache.Runtime.Caching.Tag("DummyTag"));
}
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string query = "SELECT Relationships.Product WHERE this.UnitPrice >= ?";
Hashtable values = new Hashtable();
values.Add("UnitPrice", unitPrice);
ICacheReader products = cache.ExecuteReader(query, values, true);
IList<Product> prodList = new List<Product>();
// For simplicity, assume that list is not very large
while (products.Read())
{
prodList.Add((Product)products.GetValue(1));// 1 because on 0 you'll get the Cache Key
}
return prodList;
}
}
}私がお勧めすることのXNUMXつは、これらのクラスをシリアル化可能なタグで装飾することです。 だから、あなたはそれらをキャッシュする必要がありますよね？ したがって、これらのドメインオブジェクトは、クライアントアプリケーションと分散キャッシュの間を行き来するものであるため、シリアル化する必要があります。
つまり、ここに顧客クラスと製品クラスがあります。 注文のリストと、プレゼンテーションスライドに示されているすべての属性を持つ注文クラスがあります。
プライマリオブジェクトとは何ですか？
次に、プライマリオブジェクトについて説明します。 これで、このドメインデータモデルにマッピングされるいくつかの主要なオブジェクトを示しました。 XNUMX対XNUMXのXNUMX対多および多対多の関係を調べるためのいくつかのテクニックを紹介します。
そこで、まず、次のスライドで使用する用語について説明します。
プライマリオブジェクト、それはドメインオブジェクトです。 データベースにマッピングされます。 これはアプリケーションの開始点です。たとえば、顧客オブジェクトがあり、注文が必要な場合は、顧客が開始する必要があります。 つまり、これはアプリケーションがフェッチする最初のオブジェクトであり、これに関連する他のすべてのオブジェクトは、これに関連して持ち込まれますよね？
別の例としては、注文を正しく処理しているため、その処理ユニットで注文を取得し、その特定の注文を発送するように注文した顧客について知りたい場合があります。 したがって、その場合、注文が主要なオブジェクトになり、多対XNUMXの関係になるか、特定の注文を実際に注文した顧客のXNUMX人またはその注文内のすべての製品と関係があります。 したがって、いずれかの方法になりますが、キャッシュするプライマリオブジェクトを使用し、それに依存する他のオブジェクトを作成します。 それが続くアプローチです。
分散キャッシュの関係
それでは、実際にこれから始めましょう。 それでは、まず、最も一般的なシナリオである分散キャッシュ内のXNUMX対XNUMXおよび多対XNUMXの関係について説明します。 したがって、XNUMXつのオプションは、関連するオブジェクトをプライマリオブジェクトと一緒にキャッシュすることです。 ドメインオブジェクトを確認したので、顧客の一部としての注文のリストがあります。 したがって、これらの注文を入力し、顧客がそれらの注文をその一部として持っている場合、すべての注文をその一部として持つキャッシュ内の単一のオブジェクトとして顧客を保存するとしますか？ だから、それは仕事を成し遂げるでしょう。
関連オブジェクトをプライマリオブジェクトにキャッシュする
それで、これがそのコード例です。
// cache order along with its OrderingCustomer and OrderedProduct
// but not the "Orders" collection in both of them
public void CacheOrder(Cache cache, Order order)
{
// We don't want to cache "Orders" from Customers and Product
order.OrderingCustomer.Orders = null;
order.OrderedProduct.Orders = null;
string orderKey = "Order:CustoimerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}キャッシュ注文があり、注文内の注文顧客を「null」に設定します。 わかった！ そのため、顧客への参照もある注文はありません。 冗長です。 これはあまり良いプログラミング手法ではありませんが、これは強制するためだけのものです。 顧客IDと製品IDからの注文をキャッシュする必要はありません。 したがって、キャッシュにXNUMX人の顧客を追加して、その一部として注文を入れたいだけです。
では、これを見てみましょう。 したがって、これをnullに設定してから保存するか、nullに設定しない場合は、実際にそれを参照することができます。 同様に、私たちに顧客がいる場合、そうですか？ したがって、これは別のオブジェクトであるにもかかわらず注文をnullに設定せず、単にこの顧客を保存する場合は、注文のリストがあるため、この顧客を単に保存する場合は、これに移動します。キャッシュ内の単一のオブジェクト。そのオブジェクトの一部としてordersコレクションがあります。 別の例ではnullに設定していますが、この特定のケースを示すために、XNUMXつの大きなオブジェクトを並べ替えることができ、そのオブジェクトの一部としてすべての関連オブジェクトが含まれます。
したがって、ドメインオブジェクトから開始する必要があります。ドメインオブジェクトの一部として関係をキャプチャする必要があり、それに関係なく実行する必要があります。 そして、その後、キャッシュする必要があります。実際には、注文のリスト、関連オブジェクトのリストがその一部として含まれている必要があります。 だから、これはあなたが得ることができる最も簡単なアプローチです。
すべてを表すXNUMXつのオブジェクトがあるという利点がいくつかあります。 ただし、いくつかの欠点もあります。 サイズが大きいオブジェクトになります。 顧客が必要な場合もありますが、その一部として注文を受け取ることになります。 より大きなペイロードを処理することになります。 また、キャッシュ内に個別のアイテムとしてのきめ細かい注文がないため、XNUMXつだけに関心がある場合でも、常に注文のコレクションを処理する必要があります。 つまり、それがXNUMXつのアプローチです。 それが出発点です。
関連オブジェクトを個別にキャッシュする
次に、重み付けされたオブジェクトを個別のアイテムとしてキャッシュにキャッシュします。
public void CacheOrder(Cache cache, Order order)
{
Customer cust = order.OrderingCustomer;
// Set orders to null so it doesn't get cached with Customer
cust.Orders = null;
string custKey = "Customer:CUstomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures order is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
cache.Add(orderKey, order, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}その一例は、キャッシュオーダーがあるオーダークラスですよね？ つまり、これは顧客がいる例です。 まず第一に、そうですか？ そして、顧客を単一のオブジェクトとして保存しているので、注文を受け取ったことがわかります。次に、注文から顧客を抽出し、その顧客オブジェクト内の注文コレクションをnullに設定します。 したがって、これはコンストラクター内で実行する必要があることですが、この顧客オブジェクトにその一部としてこの順序がないことを強制するために、ここで実行されています。 次に、この顧客を単一のオブジェクトとして保存します。 ここで行っているのは、顧客、顧客ID、ランタイムパラメータである顧客キーを作成してから、顧客を単一のオブジェクトとしてキャッシュに格納することです。
次に行うことは、キャッシュの依存関係を作成することです。 そこで、XNUMXつのステップとして、データモデルをドメインオブジェクトにマッピングするというXNUMXつのステップについて説明しました。これにより、ドメインオブジェクトはデータベース内のリレーショナルテーブルを表す必要があり、それらをキャッシュすることを計画すると、プライマリオブジェクトが作成されます。この場合は顧客であり、XNUMX対多の関係で顧客に関連する注文があります。 キャッシュ依存関係オブジェクトを使用して、顧客と注文コレクションの間に依存関係を作成します。 キャッシュの依存関係を作成します。 この同じキャッシュ依存関係はXNUMXつのパラメーターを取ります。 最初はファイルですよね？ つまり、ファイル名に依存する可能性があり、キーにも依存する可能性があります。 したがって、最初のパラメータをnullに設定します。 したがって、ファイルに依存させたくありません。
中に別の機能があります NCache ここで、アイテムを特定のファイルシステムに依存させ、ファイルシステム上のいくつかのファイルを作成できます。 また、キーベースの依存関係を使用する場合は、子アイテムが依存するようになる親アイテムのキーが必要です。 次に、注文のコレクションの注文キーを作成します。 このメソッドに渡される注文コレクション全体がここにあり、Cache.Addorderを呼び出すだけです。
これで、顧客と注文は相互に関連しています。 キャッシュ内の個別のオブジェクトとして表されるこの顧客からの注文のリストがあるため、この特定の顧客のすべての注文が必要な場合は、このキーを使用するだけで済みます。 あなたがする必要があるのは電話することだけです、私はちょうどここでこの例を実際に使用させてください。 申し訳ありません！ Cache.Getを呼び出すと、注文キーを渡すだけで、このメソッド内で作成したこの特定の注文が取得されます。
つまり、この特定の顧客のすべての注文のすべてのコレクションを一度に取得するために必要なのはそれです。 しかし、顧客が変更を行った場合はどうなりますか？ 顧客が更新された場合、注文コレクションはキャッシュにとどまる必要はありません。 削除することも、場合によっては更新することもできますよね？
つまり、これが私たちのアプローチXNUMXであり、ストレージ、使いやすさの点でより洗練されており、XNUMX対多の関係または多対XNUMXの関係のXNUMXつのレコードもマッピングします。 注文のリストを作成し、各注文をそれらの個々の注文にマッピングしたり、複数のIDにマッピングしたりできる場合は、注文を顧客にマッピングしたりすることもできます。その特定のアプリケーションコードの主要なオブジェクトです。 これで、顧客と注文の関係が定義されます。
キャッシュ依存関係機能に関する詳細。
私がここに行くと、まず第一に、露出していますが、 Alachisoft.NCache.Runtime.Dependenciesであり、これは使用するオーバーロードのXNUMXつであり、この特定のメソッドをここで使用するだけです。 また、この動作は、オブジェクト間の一方向の依存関係を簡単に追跡できるようにする方法であり、プレゼンテーションの前半で説明したようにカスケードすることもできます。
XNUMX対多の関係
次に、XNUMX対多の関係について説明します。 注文したXNUMX対XNUMXまたは多対XNUMXの話をしてから顧客がいたので、ほとんどの場合XNUMX対多に似ていますが、開始点が注文だったので挿入しました顧客、顧客を保存し、次に注文のコレクションを保存し、次に注文コレクションとその顧客の間に多対XNUMXの関係を定義しました。
さて、XNUMX対多の関係、それは私たちが議論したものと非常に似ているでしょう。 最初のオプションは、オブジェクトコレクションをプライマリオブジェクトの一部としてキャッシュすることです。したがって、顧客がプライマリオブジェクトであり、注文はその一部である必要があります。
XNUMX番目の項目は、関連するオブジェクトが個別にキャッシュされますが、キャッシュ内の個々の項目ですよね？
XNUMX対多–関連するオブジェクトコレクションを個別にキャッシュするpublic void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
string orderskeys = "Customer:Orders:CustomerId:" + cust.CustomerId;
cache.Add(orderskeys, orders, dep,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}つまり、これは別個のコレクションです。ここで顧客オブジェクトをXNUMX対多で取得した注文があり、顧客はそれから注文コレクションを取得した注文を持っています。次に、顧客注文をnullに設定して、顧客がeになるようにします。オブジェクト、プライマリオブジェクト、注文コレクションは別のオブジェクトであり、顧客を保存し、データキャッシュの依存関係を保存し、注文を保存します。 つまり、コレクション全体がXNUMX対多になります。
XNUMX対多–関連するコレクションの各オブジェクトを個別にキャッシュするXNUMX番目のアプローチは、このコレクションも分解できるということです。
public void CacheCustomer(Cache cache, Customer cust)
{
// Let's preserve "orders"
IList<Order> orders = cust.Orders;
// Let's now empty "orders" so it doesn't get cached with customer
cust.Orders = null;
string custKey = "Customer:CustomerId:" + cust.CustomerId;
cache.Add(custKey, cust, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
// Dependency ensures orders is removed if Cust updated/removed
string[] keys = new string[1];
keys[0] = custKey;
CacheDependency dep = new CacheDependency(null, keys);
// Let's cache each order as seperate item but assign it
// a group so we can fetch all orders for a given customer
foreach (Order order in orders)
{
string orderKey = "Order:CustomerId:" + order.CustomerId
+ ":ProductId:" + order.ProductId;
CacheItem cacheItem = new CacheItem(order);
cacheItem.Group = "Customer:CustomerId:" + cust.CustomerId;
cacheItem.Dependency = dep;
cache.Add(orderKey, cacheItem);
}
}注文コレクションは、そのコレクション内の各アイテムを個別にすることができ、キャッシュ内の個別のアイテムにすることができます。 したがって、この場合、同じアプローチを使用します。 顧客を取得し、注文を取得し、顧客を保存し、キーの依存関係を使用してその顧客の依存関係を作成してから、すべての注文を繰り返し処理します。
ここではより直感的であるため、ここで顧客のキャッシュ方法について説明します。 そこで、注文コレクションを取得し、顧客の注文をnullに設定して、顧客が顧客に関するものになるようにし、cache.Addキーを使用して顧客をキャッシュに保存し、顧客の特定のキーの周りにキャッシュ依存関係を構築し、次に、単純に繰り返します。 この周りにループがあります。 実際にそれを繰り返す必要があります。これは実際に繰り返す方が良いです。その後、キャッシュ内の個々のアイテムとして一度に格納するだけなので、順序ごとに独自のキーがキャッシュ内の個別のアイテムになります。 そして、もうXNUMXつ行ったことは、これらを実際にグループ化したことです。これをキャッシュアイテムの追加グループと呼び、顧客IDもグループです。 したがって、実際にはキャッシュ内のコレクションも管理しています。
私が持っているかどうか見てみましょう..あなたは実際にそこに行きます、例えば、私たちはここにこれを持っています。 実際にこれらの製品をキャッシュすることもできます。これは別の例です。すべての製品コレクションをループしてから個別に保存し、実際にすべてをグループにまとめました。
したがって、アイテムとして保存されているこの製品は、ProdCacheItemがある場合にもこのように保存できます。 キーボードが鳴っていますので、ご容赦ください。 今はこれを使ってみましょう。それから簡単にやります。 実際にグループを追加できます。 だから、これはこれに沿って実際に私がこれのためにグループを設定することを可能にするでしょう。 今ダミーグループとしましょう。 このキャッシュアイテムを保存していて、実際にこのアイテムとして商品を含めることができるとしたら、そうでしょう？ したがって、実際の生のオブジェクトを保存する代わりに、グループに配置することもできます。 商品キャッシュアイテムを簡単に使用できます。 どうぞ！ 右？ つまり、実際にはダミーグループを使用しているか、代わりに製品グループを使用しているとしましょう。これを取得する必要がある場合は、製品グループを使用するだけで、このコレクションのすべてのアイテムを一度に取得できます。 これらは個別に保存されていますが、これらは個別のCache.Get呼び出しです。製品コレクション内の個々の製品は個別に並べ替えられますが、コレクション内のグループに配置してからフェッチすることができます。 しかし、これの良いところは、まだ依存関係を使用しているということですよね？ したがって、XNUMX人の顧客がそれらの個々のアイテムに依存していることを使用しています。
たとえば、XNUMX件の注文があるXNUMX人の顧客がいます。 したがって、合計すると、顧客用にXNUMXつのアイテムがキャッシュに含まれ、XNUMXの注文がXNUMXのアイテムとして個別にキャッシュに保存され、そのXNUMXつの顧客とXNUMXの注文の間には一方向の依存関係があります。 そのXNUMX人の顧客をキャッシュから削除すると、XNUMX件の注文が一度に無効になります。 また、必要に応じて、個々の注文を取得できるというメリットがあります。 したがって、これらのアイテムを個別に操作できます。 一度にXNUMXつのアイテム。 処理できる特定の注文が必要です。これらの注文のコレクション全体が一度に必要な場合は、Cache.GetGroupDataを呼び出すだけで、商品グループを指定できます。サブグループは何でもかまいません。 nullの場合もあり、タグを使用することもできます。
例えば; これを管理するもうXNUMXつの方法は、商品アイテムを使用してそのタグを作成することです。 そして、あなたは..あります..ええ！ そこにあり、製品タグのようなものにできるタグを提供できますよね？ そして、これをその一部として関連付けることができます。
したがって、これは実際には同じ行で機能し、get by tagメソッドを呼び出すこともでき、すべてのアイテムを一度に処理します。 それはあなたに一度にすべてのアイテムを持ってくるでしょう。 したがって、これにより、キャッシュ内のデータの配置をより細かく制御でき、XNUMX対多の関係を維持できます。
したがって、これは、XNUMX対多の関係があり、XNUMXつのオブジェクトが追加され、コレクションが個別にキャッシュに格納されたコレクションからのアイテムを個別に格納した多くの側のアイテムを持っているという非常に特殊なシナリオを処理します。まだ依存関係があり、それらの関連アイテムを使用したコレクションタイプの動作があります。 したがって、これらのアイテムは相互に関連しており、コレクションを形成しており、XNUMX対多の定式化で別のオブジェクトとの関係を持っています。 したがって、このコードスニペット、非常にシンプルで直感的なAPIは、これらすべてのシナリオを処理します。 キーの依存関係を利用して、XNUMX対多の関係をキャプチャします。 これらのアイテムを個別にキャッシュに配置しましたが、それでもグループまたはタグの論理コレクションに配置し、それらのアイテムが個別に必要な場合は、cachestartgetを呼び出します。
したがって、このアイテムを取得するXNUMXつの方法は、Cache.Getを呼び出すことです。 ここでプロダクトキーであるキーを使用しますよね？ だから、これはあなたにこの特定のキーで保存されているこの特定の製品をフェッチしますよね？ また、もうXNUMXつのオプションは、Cache.GetGroupDataを使用できるように、そのコレクション内のすべてのアイテムを一度に必要とすることです。 したがって、収集動作を提供すると同時に、それらの関連アイテムを個人で管理することもできます。
したがって、コレクションとコレクション内のアイテムを一度にXNUMX対多で処理する必要があります。
多対多の関係
次に、多対多の関係があります。
多対多の関係は、通常、ドメインオブジェクトには存在しません。 これは、データベース内でも常にXNUMXつのXNUMX対多の関係に正規化されます。 実際のところ、私たちは顧客と製品の間に多対多の関係を持っていました。 中間オブジェクトの助けを借りて正規化された多対多の関係は、XNUMXつのXNUMX対多の関係になります。 したがって、ここでは顧客の注文と注文から製品の間にそれぞれXNUMX対多と多対XNUMXがあります。 だから、それはあなたが多対多に対処する方法です。 したがって、XNUMX対XNUMXの多対XNUMXまたはXNUMX対多の関係を使用することになります。
だから、これはあなたの多対多の関係の世話をする必要があります。
分散キャッシュでのコレクションの処理
次は、コレクションがあったことです。これについては、製品例を使用してすでに触れましたが、コレクションにXNUMXつのアイテムとしてキャッシュする方法については引き続き説明します。
たとえば、製品を保管します。 それを通り抜けましょう、そうですか？
public void CacheProducts(Cache cache, double unitPrice, IList<Product> products)
{
// cache the entire collection as one item
string productskey = "Product:UnitPrice:" + unitPrice;
cache.Add(productskey, products, null,
Cache.NoAbsoluteExpiration,
Cache.NoSlidingExpiration,
CacheItemPriority.Default);
}
public IList<Product> FindProducts(Cache cache, double unitPrice)
{
string productskey = "Product:UnitPrice:" + unitPrice;
IList<Product> products = (IList<Product>)cache.Get(productskey);
return products;
}つまり、キャッシュ製品があるので、プロダクトキーを作成し、これがここに持ってくる製品のリストを作成し、次にそれらをキャッシュして、単一のオブジェクトを作成します。 そして、前に説明したように、それはあなたに仕事を終わらせるだけでうまくいくでしょう、そしてあなたがそのリストからのすべてのアイテムを一度に必要とするときそれはほとんどうまくいくでしょう。 そのリストの個々のアイテムには興味がありません。 ストア全体のリスト全体をXNUMXつのアイテムとして完全に関心がありますが、オブジェクトが重くなり、コーディング、検索のサポートが提供されなくなります。これが次のトピックです。 それは一般的なリストなので、私はリストします、それはそこに製品を持っていますが、 NCache これは単なるリストです、私はリストします。 右！ そのため、そのリスト内のオブジェクトを特定してから属性を特定することはできず、それらの属性に基づいて検索することはできません。
したがって、これを処理するより洗練された方法は、各コレクションアイテムを個別にキャッシュすることです。 前の例の一部として取り上げましたが、もう一度説明します。 例えば; キャッシュ製品をもう一度見てみましょう。これは、単にそれらを個別のアイテムとして保存するだけです。 この例を見つけましょう！ わかった！ そこにそれがある。
ですから、まずは商品を個別に保管しますよね？ それを中心に、個々の製品のキーを作成します。 これの良い点は、商品コレクションのすべての個別のアイテムが個別のアイテムとしてキャッシュに保存されるため、そのオーバーロードであるキー、そのCache.Getのメソッドを使用してそれらをフェッチできることです。 それらをコレクションとしてフェッチすることもできます。 それは私たちが非常に詳細に議論したことです。 もうXNUMXつのオプションは、クエリも実行することです。これらのSQLのような検索クエリは、オブジェクトの属性に直接適用できます。 また、これを行うことができるのは、コレクション内のすべてのアイテムが個別に保存されている場合のみです。 それらをドメインオブジェクト（この場合は製品）にマップすると、製品コレクション内の製品は個別のアイテムとしてキャッシュに個別に保存されます。
これで、商品の単価、商品IDにインデックスを付けて、次のようなクエリを実行できます。 製品の名前空間である製品を選択します。これにより、単価がランタイムパラメータと等しくなります。 次に、Cache.ExecuteReaderを呼び出すことができます。これにより、反復処理できるすべての製品がフェッチされ、アプリケーションでもフェッチを続けることができます。 同様に、This.Tagの場所を言うこともできます。 その上にタグを関連付けている場合は、その上でクエリを実行することもできます。 これは、検索の利点、パフォーマンスの利点とともにタグのもうXNUMXつの利点であり、検索の観点からも柔軟性を提供します。 また、タグはCache.Get byatagも提供します。 すべてのAPIを提供し、すべてのタグを取得して任意のタグを取得するため、これらのタグAPIを使用して実際にオブジェクトをフェッチすることもできます。 しかし、私が強調したい機能は、それらを個別に配置することです。 それが出発点です。 タグまたはグループを使用して論理コレクションを作成します。 したがって、検索は簡単です。 Cache.Getと呼ばれる個々のアイテムが必要です。 キーに基づいてアイテムを取得します。 表示されるグループまたはタグを使用するコレクションが必要であり、その上にクエリを実行して関連付けることができ、基準に基づいて実際にアイテムをフェッチできます。
この場合、それは単価である可能性があります。 単価は10より大きくXNUMX未満である可能性があります。 したがって、論理演算子がサポートされているため、集計、カウント、合計も可能です。操作中の演算子のようなグループによる並べ替え順序があるため、サポートに関する限り、SQLに似ており、 SQLクエリですが、使用法は非常に柔軟であり、必要なアイテムに関して非常に使いやすくなっています。 キーを操作する必要はもうありません。 したがって、これは、各コレクションアイテムを使用する場合にのみ発生し、キャッシュに個別に保存されます。 それがお役に立てば幸いです。
はじめに NCache
これで今日のトピックは終わりです。 最後に、始めるためのXNUMXつの簡単なステップを紹介します。 NCache ただ行きます NCache 構成を実行すると、これらのAPIを実際のアプリケーションで実行できるようになります。
わかった！ だから、私はすぐにこれを始めるつもりです。 管理ツールを開いています。 ちなみに、最近リリースしましたが、実は4.9をリリースしたばかりです。 だから、それは私たちの最新バージョンなので、あなたはそれを始めたいと思うかもしれません。 したがって、必要なのは、名前でキャッシュを作成し、次に選択し、キャッシュトポロジを選択し、パーティションレプリカキャッシュが最適で、レプリケーションの非同期オプションです。ここで、このキャッシュをホストするサーバーを指定します。 デモXNUMXとXNUMXがすでにインストールされています NCache.
したがって、ステップXNUMXは、ダウンロードしてインストールすることです NCache。 ステップXNUMXは、名前付きキャッシュを作成することです。 それで、私はそれを通過するつもりです、それが今日の議論の主な範囲ではないので、すべてをデフォルトのままにします。 各サーバーにあるキャッシュのデフォルト値とサイズについて説明します。 基本設定を設定し、終了を選択するだけです。
ステップ4は、クライアントノードを追加することです。 自分のマシンを使用します。 私がこれにアクセスできるかどうか見てください、うん！ わかった！ これが私のマシンです。 これを追加したので、ステップXNUMXは完了です。 サーバーとクライアントのすべての構成が完了しました。 ステップXNUMXの一部として、このキャッシュクラスターを起動してテストする必要があります。次に、これを確認して、実際のアプリケーションで使用します。 だから、それは始めるのがいかに簡単かです NCache.
実際の動作を示すための簡単なカウンターをいくつか紹介し、プレゼンテーションも簡単に終了します。 右クリックして、パフォーマンスカウンターを開く統計を選択します。また、監視ツールを開くこともできます。 NCache モニター、付属 NCache.
つまり、パフォーマンスカウンター駆動です。 サーバー側のパフォーマンスカウンターを提供し、クライアント側もカウンターを実行します。 そして、クライアントアプリケーション側では、このストレステストツールアプリケーションを実行できます。 NCache。 構成が行われているため、この名前が付けられています。これにより、キャッシュに自動的に接続され、キャッシュクラスターの負荷のシミュレーションが開始されます。 どうぞ！ そのため、他のサーバーだけでなく、ここからもリクエストの負荷が発生します。
同様に、このサーバーだけでなく、レポートビューアサーバーとクライアントに接続されているクライアントでもアクティビティが表示されます。 また、これらのカウンターのいずれかを接続できる独自のカスタムダッシュボードを作成することもできます。 たとえば、APIログは良い例です。 現在キャッシュで実行されているすべてのリクエストをリアルタイムでログに記録しますよね？
つまり、これは左側のメインからこれらのカウンターを使用する簡単な例のXNUMXつです。 私が言ったように、これはキャッシングがどのように見えるかをあなたに感じさせるためだけのものです。 これで、実際にこれを実際のアプリケーションで使用できます。 ここで自分のマシンを使用でき、付属の基本操作サンプルを簡単に使用できます。 NCache。 あなたがする必要があるのは、使用する限り、サンプル.NETの基本的な操作内に異なる針フォルダーがあることです NCache 使用できるクライアント側ライブラリ NCache SDKNuGetパッケージ。 これは、すべてのクライアント側のリソースを取得するのが最も簡単です。
他のオプションは、実際に使用することです Alachisoft.NCache。ランタイムと Alachisoft.NCache.Webライブラリ自分自身。 それらを含めます。 これらは、これらが最初に来るライブラリです。 NCache Microsoftキャッシュフォルダ内。 インストールしたら NCache それはその一部であり、その後、私はあなたが何をする必要があるかをすぐにあなたに示します。 どうぞ！ したがって、最初に必要なのは、これらXNUMXつのライブラリへの参照を追加することです。 ランタイムとWebには、先ほど強調したこれらの名前空間を含めます。 Web.cachingとそれ以降、このサンプルは、それに接続するキャッシュの基本的な初期化、それを読み取るオブジェクトの作成、削除、あらゆる種類の作成、読み取り、更新、削除操作に十分対応できます。
したがって、これがキャッシュを初期化する方法です。 これがメインコールですよね？ キャッシュ名がキャッシュハンドルを返す必要があります。次に、キャッシュを呼び出すか、すべてをキーと値のペアCache.Getアイテムに追加して保存し、アイテムのキャッシュまたは挿入を更新してから、Cache.deleteを実行します。 また、検索のようにSQLを使用するグループを使用して、タグを使用してキーベースの依存関係を使用するいくつかの詳細な例をすでに示しました。 したがって、これにより、実際に環境のセットアップに関する詳細がわかり、実際のアプリケーションで使用できるようになります。
これでプレゼンテーションは終わりです。