AzureCosmosDBでキャッシュを使用する方法
録画されたウェビナー
ロン・フセインとサム・アワン
Azure Cosmos DB は、グローバルに分散されたマルチモデルのクラウドベースです。 NoSQL database サービス。 それは非常に人気があります NoSQL database 導入のシンプルさと Microsoft による強力な SLA により、高トランザクション アプリケーション向けのサービスとして最適です。
CosmosDB をさらにスケールアップするには、 NCache. NCache インメモリであるということは、超高速であることを意味します。 と、 NCache 分散されているということは、線形に拡張できることを意味します。 また、 NCache アプリケーションの近くにあるため、アクセスがはるかに速くなります。 を使用して分散キャッシュを Azure Cosmos DB アプリケーションに組み込む方法を学習します。 NCache.
このウェビナーでは、AzureCosmosDBのパフォーマンスを向上させる方法を学びます。 NCache.
このウェビナーの内容は次のとおりです。
- Azure Cosmos DB とその一般的な操作の概要
- を使用した Azure Cosmos DB アプリケーションでの CRUD データのキャッシュ NCache
- コレクションのキャッシュのハンドル
- Azure Cosmos DB とのキャッシュ同期の管理
- 全体にわたる実践的な例とデモンストレーション
今日のトピックは、次の助けを借りて Microsoft Azure Cosmos DB を高速化することです。 NCache. NCache は、当社の主要な分散キャッシュ製品です。 Alachisoft。 .NET内で使用できます。 .NET Core Java アプリケーションやその他の一般的なアプリケーションを使用すると、アプリケーションのパフォーマンス、スケーラビリティ、信頼性を向上させることができます。 今日は、Azure Cosmos DB と一緒に利用できるキャッシュ オプションについて説明します。 Cosmos DB も非常に人気が高まっているためです。 とても重要なことです NoSQL database。 そこで、皆さんが Cosmos DB でのキャッシュと使用を開始できるように、いくつかの実践例を並べました。 NCache そのための製品例として。 だから、すべてがうまくいくと信じています。 それでは、早速始めましょう。さまざまな機能を紹介している間に質問がある場合は、遠慮なく私を止めて、必要なだけ質問を投稿してください。サムがそれらの質問に注目し、私たちがそれらの質問に答えます将来的には。
Azure Cosmos DB の概要
最初のいくつかのスライドは、Microsoft Azure Cosmos DB の概要に関する非常に基本的なスライドです。 誰もが知っていると思いますが、Azure Cosmos DB とは何ですか? ただし、完全を期すために、これはグローバルに分散されたマルチモデル データベースです。 したがって、どこでも使用できます。 これは、Microsoft Azure 内でホストされたフルマネージドのホスト型データベース サービスであり、マルチモデル データベースです。 これは本質的に、キー値、テーブル ファミリー、SQL API、MongoDB コネクタ、そしてグラフ用の Gremlin API を使用できることを意味します。 したがって、これらを使用して、アプリケーション内で Cosmos DB をデータベースとして使用できるさまざまな方法が得られます。
つまり、本質的には、 NoSQL database しかし、Microsoft はそれがマルチモデル データベースであると主張しています。 したがって、それよりもわずかに多くなります NoSQL database その点に関しては。 つまり、定義どおりマルチモデル データベースであり、フルマネージド データベース サービスであるため、非常に柔軟性が高く、導入が容易です。 したがって、アプリケーション内で NuGet パッケージを使用し、Microsoft Azure の Cosmos DB インスタンスを指定するだけで済みます。 オンプレミス アプリケーションの場合は、Microsoft Azure Cosmos DB に接続することができ、Microsoft による包括的な SLA によってバックアップされています。 したがって、完全に管理されているため、展開やその他の問題について心配する必要はありません。 非常に柔軟な JSON 形式をサポートしています。 したがって、非構造化ドキュメント データを使用できます。 JSON 形式を使用してドキュメントを作成し、それを Cosmos DB にプッシュするだけで、それが取得されます。 したがって、非常に柔軟で、非常に使いやすく、これを開始するために必要なコードが少なくて済み、トランザクションの多いアプリケーションで非常に人気があります。 これを使用して Web アプリを実行できます。 これらは、Web サービス、マイクロサービス、バックエンド サーバー アプリケーションなどです。 アプリケーション内でプロセスを取り込み、大量のデータを処理する必要がある場合、あらゆる種類のアプリケーションで Microsoft Azure Cosmos DB を利用できます。
これは、テーブル、SQL、JavaScript、Gremlin、Spark について再度説明した図です。 したがって、使用できるコネクタはさまざまですが、最も一般的なのはキー値です。 次に、列ファミリー、ネストされたドキュメントを含むドキュメント、そしてグラフ用の Gremlin もあります。 したがって、グラフを保存できます。
したがって、それは世界的に配布されるものでもあります。 Microsfot Azure では、複数のデータセンターを持つことができます。 複数のパーティショニングも可能です。 つまり、Microsoft Azure Cosmos DB には優れた機能がすべて備わっています。
Cosmos DB の一般的な使用例
一般的な使用例のいくつか。 IoT やテレマティクスでこれを使用して、大量のデータを取り込み、処理、保存できます。通常、この特定の業界でトランザクションの多いアプリケーションを扱う場合は、Cosmos DB を使用でき、管理について心配する必要はありません。その量のデータとそれらの量のリクエストの管理も行います。 カタログ情報の保存、イベント ソーシング、注文処理、データベース層が重要なコンポーネントであるゲームのための地域マーケティング。 したがって、複数のゲーム アプリを利用したり、異なるプレーヤーが相互に対話したりすることができます。 トーナメントの情報、ハイスコアリーダーボード、さらに言えばソーシャルメディアの統合。
Web およびモバイル アプリケーション、これも別の使用例になる可能性があります。 サードパーティのサービスと統合するもう XNUMX つの例として、ソーシャル アプリケーションが考えられます。 したがって、大量のデータを処理し、プロセスを取り込み、大量のデータを保存する必要があるほぼすべてのアプリケーションで利用できます。 したがって、Cosmos DB が好ましい選択肢となる可能性があります。 さて、導入に関してはこれで詳しいと思います。 ご質問がございましたら、お知らせください。
今日の焦点は、キャッシュの要件は何か、さらに、なぜキャッシュが必要なのかということです。 そのために、Microsoft Azure Cosmos DB には XNUMX つの問題があります。これは、私たちが行ったパフォーマンス テストと、私たちが行ったリクエスト単位コストの見積もりに基づいています。
Azure Cosmos DB の問題
したがって、Microsoft Azure Cosmos DB には主に XNUMX つの問題があります。
パフォーマンスのボトルネック
1 番目で最も重要なのは、パフォーマンスのボトルネックです。 Microsoft Azure は、Cosmos DB によってミリ秒の応答時間が得られると主張していますが、それは私たちのテスト結果からもほぼ真実ですが、ミリ秒未満の応答が必要な場合はどうすればよいでしょうか? だって NCache ローカル テストでは、ローカル キャッシュであっても、異なるパーティション分割や複数のサーバーでキャッシュ データをホストすることについては話していません。ローカル キャッシュであっても、ネットワーク全体に存在する可能性があり、ミリ秒未満の応答を取得できます。 Cosmos DB をテストした比較 NCache.
したがって、Microsoft Azure Cosmos DB と比較すると、パフォーマンスの違いは非常に大きくなります。 NCache。 したがって、応答時間は秒からミリ秒、ミリ秒からミリ秒未満と、Cosmos DB のパフォーマンスの向上が必要であることがわかります。 これをもう少し分析してみると、主に、アプリケーションを運用環境にデプロイする場合、Microsoft Azure Cosmos DB はホスト型サービスであるという事実が原因であることがわかります。 したがって、それは常に独自のサブスクリプション内の VNET 全体に存在します。 サブスクリプションの一部が許可され、リクエスト単位に基づいて料金が請求される可能性がありますが、Microsoft Azure とアプリケーション内でホストされ、すでに仮想ネットワークでホストされている場合、VNET を経由する場合は、そこでネットワーク コストが発生します。それに加えて、レイテンシー部分も増加します。
これが XNUMX つ目であり、XNUMX つ目は、アプリケーションがオンプレミスにある場合、アプリケーションの速度もさらに遅くなるということです。 そこで、最初に Cosmos DB と Cosmos DB の基本的な比較について説明しました。 NCache. NCache これはメモリ内にあるためすでに高速であり、実際にデプロイしてアプリケーションをクラウドでホストする場合、ミリ秒に比べてミリ秒未満の応答が得られます。 Azure の Cosmos DB は、VNET 全体および VNET 間の通信で行われるため、大幅な遅延が発生する可能性があります。複数のパーティション分割があり、XNUMX つのデータセンターがあり、データが行き来している場合、最終的には別のパーティションまたは別のデータセンターに移動することになり、オンプレミスと比較するとさらに遅くなります。 これは、オンプレミス アプリケーションが Microsoft Azure Cosmos DB を使用しているというあまり一般的な使用例ではありませんが、その場合は、Cosmos DB にアクセスするために WAN を経由する必要があります。 したがって、これはあまり高速なオプションではありません。
つまり、Microsoft Azure Cosmos DB がパフォーマンスの点で十分にデプロイされていないことが最大の問題です。 したがって、特にトランザクションが多い場合にはパフォーマンスが低下します。 大量のリクエストが受信され、そのデータを迅速にタイムリーに処理する必要がある場合。 したがって、パフォーマンスが低下する可能性がありますが、解決策は非常に簡単です。次のスライドで説明します。次のようなキャッシュ システムの使用を開始します。 NCache.
高価なリクエストユニット
問題 XNUMX は、リクエスト単位のコストが高くつくことです。これは、多額の損害をもたらすものです。 したがって、各リクエストユニットにはコストがかかります。 読み取り専用データであっても、Microsoft Azure Cosmos DB にアクセスするたびに。 そのデータがそれほど頻繁に変更されていない場合、内容は同じですが、調べているデータである Cosmos DB からのマスター ソースがまだ存在します。そのデータについては、Microsoft Azure と行き来し続ける必要があります。 Cosmos DB ではリクエスト単位に基づいて料金を支払うため、コストが増加します。 したがって、リクエストの負荷が増加するとコストが増加します。 したがって、処理できるリクエストの負荷に限り、非常にスケーラブルですが、そのシナリオではあまりコストに優しいものではありません。 したがって、コスト要因にも影響を与えることになります。 したがって、スケールアウトの潜在的な障害となる可能性があります。 スケールアウトを計画している場合。 複数のパーティションがあり、データ負荷が増加しますが、それに伴いコスト要因も増加します。
したがって、Microsoft Azure Cosmos DB を扱うときは、これら XNUMX つの問題を考慮する必要がある場合があります。
ソリューション： NCache 分散キャッシュ
これらの問題の解決策は非常に簡単で、次のような分散キャッシュ システムを使用します。 NCache。 まず第一に、 NCache メモリ内にあります。 つまり、保存しているものはすべて、 NCache 比較してメモリ内に保存されます。 したがって、すぐに数ミリ秒のパフォーマンスが向上します。次に、同じマシン上のローカルホスト上で実行されている Cosmos DB と、 NCache 同じマシン上で実行されている、 NCache は一因でした。 比較するとかなり速かったです。 同じデータセットの応答がミリ秒単位であるのに比べ、ミリ秒未満でした。
次に、ネットワーク アプリケーション内でもホストでき、Cosmos DB に追加して使用できます。 Cosmos DB に代わるものではありません。 この特定のウェビナーでは、Cosmos DB を併用できるさまざまなアプローチについて説明します。 NCache & NCache は、ほとんどのデータをキャッシュし、コストとパフォーマンスの面で Cosmos DB への高価な移動を確実に節約する、役立つ製品となるでしょう。 第二に NCache 分散キャッシュクラスターです。 したがって、それに応じてスケールアウトできます。 高可用性が組み込まれており、多数のサーバーがあり、各サーバーが別のサーバーにもバックアップを持っているため、非常に信頼性が高くなります。これをサポートする展開図を次に示します。
あらゆる種類のアプリケーション ASP.NET または ASP を使用できます.NET Core Web アプリ .NET または .NET Core Web サービス、そして同様に他のサーバー アプリケーション (Java アプリケーションも含む)。 以前は、クラウドで Cosmos DB を使用していたり、アプリケーションがオンプレミスであったり、すべてがクラウドにあった場合、同じ行にキャッシュ層を導入できました。 Microsoft Azureでは、次のように使用できます NCache Azure で .NET を使用するか、 .NET Core インストール。 で利用可能です Microsoft Azure marketplace 同様に、キャッシュクラスターを形成することもできます。 NCache それは独自の VNET 内に存在することになります。 したがって、ネットワーク遅延は完全に軽減されます。 したがって、それはもう問題ではありません、そしてそれに加えて、 NCache メモリ内にあります。
そう、 NCache 比較するとすでに非常に高速です。 したがって、パフォーマンスはすぐに向上し、オンプレミス アプリケーションのパフォーマンスは向上し続けることができます。 NCache オンプレミスでも Cosmos DB を Microsoft Azure クラウドに常駐させることができるため、パフォーマンスの点ですべてが変わります。 コスト単位に関しては、すべてのデータを保存できます。 ご覧のとおり、100% のトラフィックをルーティングできます。 NCache これにより、Microsoft Azure Cosmos DB への高価な移動が節約され、Cosmos DB への移動が節約されるとすぐに、要求ユニットが低下するため、コストの節約に役立ちます。 それに比べて、要求ユニットのフットプリントが少なくなり、Microsoft Azure Cosmos DB へのアクセスと使用に関連するコストも少なくなります。 Microsoft Azure Cosmos DB に送信できるトラフィックは 20% 以下です。アプリケーションにメリットをもたらすこれらのキャッシュ オプションについて説明します。
それで、何かご質問がございましたら、お知らせください。 次のような製品の使用を検討する必要がある理由について、いくつかの基本的な詳細を作成しました。 NCache アプリケーションを改善するために。 次に、一般的な使用例について説明します。 NCache 次に、サンプルをいくつか用意しますので、それをデモしたいと思います。 それでは、この時点で何かご質問がございましたら、お知らせください。 この時点では質問がなかったと仮定します。 それでは、続けていきます。
の一般的な使用法 NCache
一般的な使用例のいくつか。 私たちは最初に業界全体のユースケースについて話しました。 したがって、これらのアプリケーションはすべて使用できます NCache 同じように。 実際のところ、 NCache より多くのクライアントを抱えており、さまざまなクライアントが使用しています。 NCache。 つまり、それは電子商取引、銀行、金融、自動化、IoT、通信分野である可能性があります。 したがって、あらゆる分野には次の可能性があります。 NCache 活用できるので NCache 通常、データを扱うすべてのアプリケーションで使用されます。 パフォーマンス、拡張性、高可用性と信頼性が必要であり、これらの問題に対処しています。 したがって、彼らは次の主要な候補者です NCache。 ただし、技術的なユースケースに関する限り、次のように使用できます。 NCache アプリケーションデータキャッシング用。
アプリケーションデータのキャッシュ
したがって、最初のユースケースはアプリデータのキャッシュです。 Microsoft Azure Cosmos DB では、Cosmos DB をプライマリ ソースとして使用します。 ここにドキュメントのほとんどまたはすべてが存在し、一部またはすべてを取り込むことができます。 NCache より高速なアクセスを実現します。 したがって、パフォーマンスを向上させ、アプリケーションに対するリクエスト単位の影響を減らすために、さまざまな種類の同期アプローチを使用できます。これについては、このウェビナーでも説明します。 したがって、これは、リレーショナル データベースおよび Cosmos DB に関して最も一般的なユース ケースです。
Ron、質問があります。質問は、同じ Cosmos DB をどのように使用するかということです。 NCache、と変化します NCache? さて、それについて話しました。 そのため、このためにセグメントが用意されています。 Microsoft Azure Cosmos DB 内にメカニズムがあります。 変更フィードを使用します。 観察者パターンがあります。 したがって、追加と更新を管理でき、変更フィードでそれらの追加と更新を追跡できます。 そこで、このウェビナーでは XNUMX つのアプローチを紹介します。そこでは、これらの変更フィード通知を使用して変更を適用する方法について説明します。 NCache 同じように。 したがって、変更が発生するとすぐに、Cosmos DB データベースに自動的に適用されます。 NCache 同じように。 それが今日のデモの XNUMX つに私が並べたものです。
セッションのキャッシュと SignalR Backplane
他の使用例もいくつかあります。 ASP.NETとASPがあります.NET Core Web アプリでも使用できます NCache セッション用、 SignalR、応答キャッシュ、ビューステート、出力キャッシュの場合、 NCache メッセージングプラットフォームでもあります。 使用できます Pub/Sub メッセージ。 SignalR は、Pub/Sub メッセージングによってバックアップされます。 データ駆動型イベント、Pub/Sub イベント、そして継続的なクエリ イベントもあります。 それで、 NCache メッセージ バス、メッセージ プラットフォーム、データ共有プラットフォームとして使用できます。
ハンズオンデモ
わかりました。では、すぐに始める方法を説明します。 NCache。 したがって、キャッシュを作成するだけで、その後、さまざまなアプローチについて説明します。 キャッシングについて、また、キャッシングを始めるにはどうすればよいですか? したがって、いくつかの基本的な例を実際に示し、その上に構築して、同期の使用方法と、コレクションと更新の管理方法を示します。
ということで、まずはデモ環境から始めてみます。 NCache オンプレミスでも Microsoft Azure クラウドでもホストできます。 推奨される導入オプションは、 NCache は VM であり、Windows ボックスだけでなく Linux ボックスも管理できる Web ベースの管理ツールがあります。 そこで、次の助けを借りて、 .NET Core あなたはインストールすることができます NCache Linuxでも同様です。 したがって、それは完全にあなた次第です。 キャッシュを Windows 側の VM に保持するか、Linux 側に保持するか。 Windowsボックスを使用しています。 それでは、キャッシュを作成しましょう。 ということで、まずは作成してみます。
ここでこのウィザードを開始します。 キャッシュに Democache という名前を付けます。
すべてをデフォルトのままにします。これらの設定の詳細は、ドキュメント内と、より重点を置いた他のウェビナーで参照できます。 NCache 建築。 したがって、パーティション分割されたレプリカ キャッシュを保持します。 それが最も好ましいものです。
アクティブなパーティションとそのバックアップの間の非同期レプリケーション。 サーバーが XNUMX 台ある場合、サーバー XNUMX は XNUMX 台にバックアップを持ち、サーバー XNUMX は XNUMX 台にバックアップを持つことになります。 したがって、バックアップの維持は、受信するリクエストに基づいて同期または非同期にすることができます。したがって、やはり非常に高速であり、推奨されるため、非同期を選択します。 そこで、キャッシュをホストする XNUMX つのサーバーを指定します。
NCache はすでにインストールされています。 これらは Windows ボックスです。 TCP/IP設定に関してはすべてデフォルトのままにしておきます。 NCache は TCP/IP ベースのプロトコルです。 したがって、相互に通信するには IP アドレスとポートが必要で、そこからそれを取得します。その後、画面上もすべてデフォルトのままにして、終了時にこのキャッシュを開始します。
したがって、これは構成されてすぐに開始されますが、これには時間がかかり、キャッシュが自動的に作成されます。ここに Azure Cosmos DB エミュレーターがあります。 私はそれのローカルホスト展開を使用しています。 ここには顧客とリースという XNUMX つの文書ストアがあります。
リースは、やはり変更フィードによる同期用です。 これについては、すぐに、または後で同期について説明するときに説明します。 つまり、お客様、これは基本的な顧客ストア、ドキュメント ストアであり、さまざまな顧客がいます。 顧客をクリックすると、名前、ID、住所、都市、国を持つ顧客がいることがわかります。これらは、このデモ全体で操作する顧客です。
{
"id": "Customer:CustomerID:TRAIH",
"CustomerID": "TRAIH",
"CompanyName": "Trail's Head Gourmet Provisioners",
"ContactName": "Helvetius Nagy",
"Address": "722 DaVinci Blvd.",
"City": "Kirkland",
"Country": "USA",
"_rid": "Xpd7ANtwbZjSAAAAAAAAAA==",
"_self":"dbs/Xpd7AA==/colls/Xpd7ANtwbZI=/docs/Xpd7ANtwbZjSAAAAAAAAAA==/",
"_etag":"\"00000000-0000-0000-1649-a9a8daaa01d5"
"_attachements": "attachements/"
"_ts":1559153371
}さて、ここに戻ってくると、キャッシュが完全に開始されました。 これをチェックして詳細を表示し、ボックスをクライアントとして追加できます。 それはオプションのステップです。 NuGet パッケージを使用している場合は、この手順を省略できますが、使いやすさのために省略します。 したがって、GUI マネージャーからすべてを追加するだけで、クライアント マシンに設定が読み込まれます。 私たちは大丈夫だと思います。 もう一つやります。 統計ウィンドウを開き、インストールされている監視ツールも開きます。 NCache。 つまり、これらはパフォーマンスカウンターを提供し、これらのウィンドウは NCache 監視ツールについては、監視の側面を少し見てみましょう。 NCache 次に、PowerShell ウィンドウを開いて、インストールされているストレス テスト ツール アプリケーションを実行します。 NCache この直後に、Cosmos DB 用に用意したサンプル アプリケーションについて説明します。 これはキャッシュ クラスター上でダミーの負荷をシミュレートするツールで、負荷がかかるとすぐに、何らかのアクティビティが表示されるはずです。 XNUMX つのクライアントが接続されています。
そして、XNUMX 秒あたりのリクエストがポップアップ表示され、アクティビティも表示されるはずです。実際、ここでこのボックスにログオンするだけで、別のマシンからこれを表示できるので、これをより迅速に確認できるようになります。 ここでアクティビティを確認できます。 GUIツールが更新できないのだと思います。 許可の問題がいくつかあると思います。 しかし、それにもかかわらず、カウントが更新されていることがわかり、XNUMX 秒あたりのリクエストが表示されます。これがこの特定のデモに必要なすべてです。
Azure Cosmos DB を使用したアプリ データ キャッシュ
したがって、サンプル アプリケーションを使用しても問題ありません。 アプリ データ キャッシュの使用例について簡単に説明します。その一環として、サンプル アプリケーションがどのように動作するかについても説明します。その後、サンプル アプリケーションを段階的にデバッグし、コマンドを示します。これは、キャッシュを開始するために統合しました。 とてもシンプルで基本的なプログラムです。 最初は Hello World で、そこから進みます。
したがって、アプリデータのキャッシュがあります。 最初に行う必要があるのは、参照データを処理することです。 データはそれほど頻繁に変更されず、トランザクション データである可能性もあります。トランザクション データは変化するため、別のセグメントを並べていますが、参照データの場合は主に読み取りを処理します。 したがって、まず Cosmos DB に接続してから、 NCache。 取得操作を実行してから、更新操作も実行する必要があります。 取得操作内で単一のドキュメントまたはドキュメント コレクションをキャッシュでき、更新内でドキュメントを追加、更新、削除できます。 これらはコード スニペットであり、ここで強調表示します。
//Add NCache Nuget and Include Namespaces
using Alachisoft.NCache.Client;
using Alachisoft.NCache.Runtime.Caching;
//Add Cosmos DB Nuget and Include Namespaces
using Microsoft.Azure.Documents;
using Microsoft.Azure.Documents.Client;
...
{
//NCache Connection call
static ICache _NCacheClient = CacheManager.GetCache("DemoCache");
//Cosmos DB Connection call
static DocumentClient _CosmosDbClient = new DocumentClient(
serviceEndpoint: new Uri("https://localhost:8081"),
authKeyOrResourceToken:@"C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==");
}...したがって、私の CRUD 内では NCache Cosmos DB サンプル アプリケーションには、さまざまなケース、さまざまなテスト ケースがあります。 したがって、まず最初に、DemoCache というキャッシュ名を指定します。 大文字と小文字は区別されず、Cosmos DB 接続設定がいくつかあります。 この例として SQL クライアントを使用しています。これは、私が選択した例の観点から最も関連性が高いためです。 ただし、Cosmos DB から任意のクライアントを作成し、引き続き使用できます。 NCache なぜなら NCache API は非常に簡単です。 応答を取得できます。これは JSON オブジェクトである可能性があり、次を使用してキャッシュできます。 NCache API とその内部 NCache キャッシュと対話するさまざまな方法もあります。 したがって、これらから選択することもできますが、キャッシュの考え方はまったく同じです。
わかった。 つまり、Cosmos DB 内では、ここに来たら、URL、主キー、接続文字列が表示されます。 したがって、ここで指定する必要がある設定は次のとおりです。そうすれば、接続を開くことができます。 つまり、これがキャッシュ ハンドル「_cache」、つまり ICache インターフェイスを取得する方法です。 これをお見せすると、管理 API もいくつか提供されます。 そうですね、CacheManager クラスもキャッシュ コレクションを提供します。 それには、ICache、CacheHealth、その他の StartCache メソッドと StopCache メソッドがあります。 これに接続したら、最初に行う必要があるのは、単純にキャッシュ アイテムをフェッチすることです。つまり、Cosmos DB からいくつかのドキュメントをフェッチし、それをキャッシュします。 しかし、私たちが使っているので、 NCache つまり、アプリケーションは、常に最初にキャッシュをチェックするように設計する必要があります。そうすることで、Cosmos DB への高価なアクセスも節約できます。これがまさにこのケースで起こっていることです。ここ。
私たちが実際に行っていることは、取得する予定の顧客 ID を取得することです。 それは顧客 ID であり、顧客 ID に基づくフェッチであり、まず最初に「_cache.Get」を呼び出してキーを提供します。 キーはあなたが定義するものです NCache. NCache すべてをキーと値のペアに保存します。 したがって、キーは顧客であり、顧客 ID はその実行時パラメーターにある可能性があり、キャッシュからデータを見つけた場合は、Cosmo DB にアクセスする必要はありません。 この時点から戻ることができます。 そうしない場合は、常に Cosmos DB API を実行することになります。 たとえば、この場合は、Cosmos DB "_client.ReadDocumentAysnc" を使用して応答を取得し、CollectionID やキーなどのすべての詳細を提供し、それに基づいて Cosmos DB からレコードをフェッチし、キャッシュします。 これは、次回、キャッシュにデータが確実に存在するようにするためです。
そこで、初めてデバッグせずにサンプルを実行します。 すべてのテスト ケースを示してから、これらのテスト ケースを XNUMX つずつ確認し、これがどのように実行されるかを示します。 ご質問がございましたら、お知らせください。
ということで、顧客を追加してみます。 Ross123 だけを入力して Enter キーを押し、次は顧客をレビューするとします。再び Ross123 を入力すると、連絡先名を持つダミーの顧客 Ross123 が作成され、それに日付と時刻が追加されていることがわかります。 。
Cosmo DB に既に存在する他の顧客を探すだけです。 それで、それが得られ、それに基づいてこれを行っているので、キャッシュ内に Ross と ALFKI の XNUMX つのアイテムが既にキャッシュに追加されているのが確認できるはずです。
だから、私はこれを続けることができます。 この顧客を更新できます。 たとえば、Ross123。 パラメーターは取りません。 単に日付/時刻の値を更新しているだけです。 したがって、これをもう一度実行すると、14:27:13 と比較して 14:26:37 が表示されるようになります。 したがって、これはキャッシュ内だけでなく Cosmos DB 内でも更新されており、これをここで表示すると、更新された顧客をエクスプローラー ウィンドウにすぐに表示でき、更新された値が含まれています。 したがって、これら 5 つの情報源を並行して扱っています。 この顧客も削除できます。 実際に顧客を表示できるので、これらのブレークポイントを削除しましょう。 わかりました。6 に達するとすべての顧客が取得され、次に XNUMX に達すると、国に基づいて顧客が取得されます。
そこで、最初に強調したいのは、Cosmos DB を使用してキャッシュから顧客を取得し、 NCache、単一のドキュメントをキャッシュします。 それでは、早速レビューしていきましょう。
Customer GetCustomer (Customer customer)
{
string key = $"Customer:CustomerID:{customer.customerID}";
//Check data in NCache first
Customer customer = _NCacheClient.Get<Customer>(key);
if (customer != null)
{
return customer;
}
//If data is not in NCache then get from Cosmos DB and Cache it
else
{
ResourceResponse<Document> response =
_CosmosDbClient.ReadDocumentAsync(UriFactory.CreateDocumentUri (DatabaseId,CollectionId,key)).Result;
customer = (Customer)(dynamic)response.Resource;
_NCacheClient.Insert(key, customer);
return customer;add はすでに非常に単純なものなので、この時点では説明しません。 そこで、再生ボタンを押してブレークポイントに到達し、その前に変更を加えます。 コンテンツをクリアしていきます。 それで、私は新たに始めます。 わかった。 したがって、両方のサーバーのコンテンツはゼロになります。 それが期待されています。 それでは、これを打ちましょう。 ブレークポイントに入っていますね。 したがって、顧客 ALFAKI を取得することを期待していることがすぐにわかります。これに基づいて、これを初めて打ち続けると、顧客キーが構築されます。 これが私たちが扱っているキーであり、キャッシュからそれを取得しようとすると、明らかに、新たなスタートであるため null が見つかります。
Null の場合、Cosmos DB から取得してキャッシュにも追加します。項目が XNUMX つ追加されていることがわかります。次に、値を取得して画面に表示します。これをもう一度実行します。今度はキャッシュから同じ顧客が期待されます。キャッシュされているため、毎回先に進み、Cosmo DB にあるあらゆる種類の TTL やあらゆる種類のプロパティを指定することもできます。キャッシュからも顧客を取得できます。 まったく同じ顧客で、今回は Cosmos DB にはアクセスせず、同様にこれを画面に表示するだけでした。
つまり、これは単純な hello world プログラムであり、キャッシュから同じ値を取得します。これは、キャッシュされており、そのようにすることではるかに高速になるためです。 Cosmos DB と NCache そしてあなたは見ることができます NCache ははるかに高速であり、Cosmos DB へのアクセスも節約できるため、コスト要因にも影響します。 それだけでも減るでしょう。 これが最初の使用例です。
XNUMX 番目の使用例はコレクションを管理する方法で、ここには XNUMX つのオプションがあります。 コレクション全体を XNUMX つのアイテムとして保持することも、各コレクション アイテムを個別にキャッシュすることもできます。 そのためには、まず XNUMX つを実行し、ここでコードを示すと、リストを単一の項目として保存することができます。 したがって、ここでブレークポイントに到達するだけです。 これは何も期待していません。キャッシュからファイルを取得して、すぐに再生ボタンを押すだけです。
ロン、質問があるんだ。 利用可能な SQL タイプの検索オプションやその他の特別な機能はありますか? はい、とても良い質問です。 これは私が示している基本的な API です。 NCache タグを使用する仕組みもあります。 SQL 検索も使用できます。 LINQ、全文検索も利用できます。 したがって、非常に比較可能です。 SQL に精通している場合は、次の SQL API を使用できます。 NCache。 それは呼ばれています オブジェクトクエリ言語。 LINQ に精通しており、LINQ に基づいて項目を取得することを好む場合は、全文検索がもう XNUMX つの機能です。 わかりやすくするために、キーと値のペアを示しています。 しかし、私が言ったように、これらはすべてその一部として利用できるオプションです。
したがって、最初に再び null 値を取得し、その後再生ボタンを押すと、この顧客が単一のアイテムとしてキャッシュにロードされるはずです。 アイテムは 98 つだけロードされます。 これを何も停止せずにもう一度実行すると、今度はキャッシュからこの顧客コレクションが取り込まれます。 つまり、リスト要素は XNUMX 個ありますが、これは単品ストアとしての顧客の顧客リストです。 したがって、これは XNUMX つのオプションです。 結果セットのキャッシュに興味がある場合は、コレクション全体を XNUMX つの項目としてキャッシュできます。これにより、これが常に必要なコレクションであることがわかり、他のリスト メンバーや結果セットは必要ありません。一つでも大丈夫なので保管しておきたいですね。 ただし、これは主に小規模なコレクションや結果セットのキャッシュに推奨されます。
XNUMX 番目の最も推奨されるアプローチは、各コレクション項目も個別にキャッシュすることです。 したがって、クエリを実行し、Cosmos DB に対して API を実行し、大量のドキュメントを取得し、それらのドキュメントを反復処理して個別に保存し、タグを使用してそれらを論理的にグループ化します。 たとえば、私たちはここでこれを行っています。
void GetCustomersByCity (string country)
{
//Retrieve all customers from NCache first
List<Customer> customers = new List<Customer>();
var tagByCountry = new Tag($"Customer:Country:{country}");
IDictionary<string, Customer> items = _NCacheClient.SearchService.GetByTags<Customer>(new[]{tagByCountry},
TagSearchOptions.ByAnyTag);
//If data is not in NCache then get from Cosmos DB and Cache it
if (items != null && items.Count > 0)
{
IDocumentQuery<Customer> query = _CosmosDbClient.CreateDocumentQuery<Customer>(
UriFactory.CreateDocumentCollectionUri(DatabaseId, CollectionId), new FeedOptions { MaxItemCount = -1,
EnableCrossPartitionQuery=true }).Where(c => c.Country == country
).AsDocumentQuery();たとえばコードをお見せすると、これがここのテストケースです。 国の名前を入力すると、リストが作成され、それに基づいていくつかのチェックが行われ、ランタイム パラメーター country を使用して国別のタグも作成され、「_cache.SearchService」が呼び出されます。また、検索サービスの一部として OQL もあります。 私たちも持っています 継続的なクエリ、LINQ もあり、使用できる他の検索メカニズムもいくつかあります。 ただし、私はタグによる取得を使用しています。
したがって、すでに個別にキャッシュされており、それらの個別の項目はすべてリストではありませんが、タグを使用してコレクションに入れることができることが期待されます。 したがって、そのタグを使用すると、コレクション全体を取得できます。 初めて、キャッシュをチェックインし、返されたものが見つかった場合は、Cosmo DB に移動してクエリを実行し、顧客ごとに個別の顧客アイテムを反復処理します。 キャッシュ アイテムを構築し、個々のアイテムにタグをアタッチし、それに基づいてそれらを次の場所に保存します。 NCache 同様に、cache.InsertBulk を使用します。ここにケース番号 XNUMX を持ってきます。 コレクションを呼び出し、キャッシュ項目リストとcache.InsertBulkを作成しています。
それでは、もう一度実行してみましょう。 選択肢 XNUMX を提示すると、この場合、キャッシュ数も表示されます。今回は、最初に基づいて国名 (たとえば、イギリス) が期待されます。リストを作成します。 最初の反復で Cosmos DB が実行され、キャッシュ アイテムが構築され、それらすべてが反復されるため、List は空になります。 何個あるか見てみましょう。 XNUMX から XNUMX までだと思いますが、これもキャッシュに挿入され、XNUMX とプラス XNUMX が表示されます。 XNUMX つの項目について、XNUMX つの項目が個別に追加されると思いますが、国ごとのタグと呼ばれるグループがあり、そのタグは国ごとにタグ付けされています。これはランタイムパラメータの国であり、ランタイムであり、その点ではこの形式になっていますこれをもう一度実行すると、このコア ブロックにもう一度入ったことになります。 先ほど説明したタグを使用すると、それらすべてを取得できるはずです。 わかった。 そして今回は、個別に保管されているものの、タグで分類され、タグで装飾されたこれらのアイテムをすべて入手できることを期待しています。 つまり、そのタグがあれば、その XNUMX つのアイテムがすべてコレクションとして戻ってくるはずです。 したがって、その一部として顧客のリストが返されます。 つまり、これは顧客の IDictionary であり、それらを反復処理することができ、再生ボタンを押すと、キャッシュからもまったく同じ応答が得られます。 NCache これは、XNUMX つのリクエスト ユニットであっても、パフォーマンスの点、フットプリントの点で大幅な改善となります。 このサンプル アプリケーションでは、何百万ものドキュメントがあり、何百万ものリクエストが送受信されると考えてください。 したがって、これがコレクションを管理し、それらをコレクション、全体、または各コレクション項目として単一の項目としてキャッシュに個別に保存する方法です。
Azure Cosmos DB を使用した更新操作のキャッシュ
次に、Azure Cosmos DB を使用した更新操作を行います。 これらは非常に単純で、ドキュメントを追加する必要があるたびに、同じ行でcache.addを呼び出すことができます。 時間を節約するためにこれらを紹介します。 したがって、Cosmo DB でドキュメント「CreateDocumentAsync」を作成し、cache.Insert を呼び出します。 したがって、データベースに追加し、キャッシュにも追加し、更新の場合は、いつでもキャッシュ、Cosmos DB、さらにキャッシュでも更新でき、削除も非常に簡単です。 "DeleteDocumentAsync" を使用して Cosmos DB から削除し、さらに "cache.remove" を呼び出します。 これで完了し、これらの例が並ぶはずです。 それで、他に質問がある場合は、同期に関する次のセグメントに進むつもりですが、これにも時間がかかります。 質問がある場合はお知らせください。その他の場合は、同期について説明します。 NCache Azure Cosmos DB を使用します。 ロン、質問にはうまく答えています。 製品をうまく紹介できたと思います。 質問が来たら、必ずぶつけます。
同期 NCache Azure Cosmos DB を使用する
OK。 同期は大きな側面です。 データがキャッシュとデータベースの XNUMX つの異なる場所に存在する場合は、キャッシュを Cosmos DB と組み合わせて使用する必要があると私たちが提唱しているのも同様です。 キャッシュに変更があるたびに、その変更をデータベースにも適用します。 アップデートがあるので、そのアップデートを適用してください。 削除、その削除を適用します。 しかし、Cosmos DB でデータが直接変更された場合はどうなるでしょうか。これは、Cosmos DB が別のアプリケーション、別のコネクタ、およびデータが別のソースによって取り込まれ、アプリケーションがそのデータを読み取るだけである可能性がある最も自然なシナリオになります。アプリケーションによって更新されるデータは Cosmos DB 内でも更新されますが、他のアプリケーションの場合は、Cosmos DB 内で直接データが変更されます。
では、何かをキャッシュした場合はどうなるでしょうか。 ここで、Cosmos DB に変更を加え、その変更が Cosmos DB で行われたと仮定します。 ただし、データが XNUMX つの異なる場所に存在し、これら XNUMX つのソースが同期しなくなるため、その変更はキャッシュに反映されません。 したがって、Azure Cosmos DB と NCache ここで使用していた概念は、Microsoft Azure の変更フィード処理に基づいています。 したがって、変更フィード メカニズムがあり、それに基づいて、試していただける XNUMX つの異なるオプションがあります。
0 つは、Cosmos DB トリガーを備えた Azure 関数です。 つまり、暗黙的な変更フィード処理です。 そのため、itXNUMX は多くのバックワークを実行し、追加と更新を管理して開始し、削除の回避策を考え出すことができます。 Microsoft はそれが論理的な削除であると主張しています。 したがって、論理的な削除アプローチを使用できます。これは本質的には更新ですが、ライブアタッチする時間があり、それに何らかのキーワードが添付されているため、アプリケーション内でいくつかのキーワードを使用でき、このアイテムがもう存在しないという通知を受け取ることができます。 Cosmos DB に入る予定です。
XNUMX 番目のオプションは、変更フィード プロセッサの明示的な実装です。 Azure 関数の Cosmos DB トリガーを使用するのではなく、このインターフェイスを自分で実装します。 両方の例を並べてみました。 そこで、まず Azure の機能に注目してみましょう。
Azure 関数 DB トリガー
Azure 関数 DB トリガーを使用すると、これは非常に単純な図になります。
繰り返しますが、Cosmos DB はここにあります。 NCache ここにいます。 あなたのアプリケーションは使用しています NCache Cosmos DB かここのどこか。 ドキュメントが追加、更新、または削除された場合はどうなりますか? つまり、Microsoft Azure では、変更フィードを実装し、その上にプロセッサをベースにすることができます。 したがって、この変更フィードはイベントの追加と更新を管理します。 削除は Microsoft Azure Cosmos DB ではまだサポートされていないため、DB トリガーを使用して Azure 関数を実装できます。 これにより、次のようなソースに変更を追加および更新できます。 NCache そして、私が作っている実装があります NCache 追加、更新、削除コマンド。 論理的な削除については、すぐに説明します。
ということで、全体的な実装はこんな感じです。 このデモの後に何が起こるかというと、Cosmos DB にドキュメントを追加するたびに、そのドキュメントが自動的に反映されます。 NCache。 Cosmos DB に自動的に反映される更新がある場合、 NCache 同様に、削除がある場合は、削除の管理も行います。 したがって、これら 100 つのソースを互いに XNUMX% 同期させると、データの不整合の問題がなくなり、データを最新の状態にする必要がある一貫した形式が必要なアプリケーションにとっては大きな問題になる可能性があります。それはミッションクリティカルなデータであり、非常に機密性の高いデータでもあります。 したがって、それが私たちがそれに対して提示する解決策です。
そこで、まず、DB トリガーを使用した Azure 関数をここで紹介します。
[FunctionName("AzureFunction1")]
public static void Run([CosmosDBTrigger(
databaseName: "CosmosDbNCacheDemo",collectionName: "Customers",
ConnectionStringSetting = "CosmosDbConnection",
LeaseCollectionPrefix ="NCache-CosmosDbTrigger-",
LeaseCollectionName = "leases")]IReadOnlyList<Document> documents,
ILogger log)
{
using (var cache = CacheManager.GetCache("myCache"))
{
Customer customer = null;
foreach (var document in documents)
{
customer = new Customer{Address =
document.GetPropertyValue<string>("Address"),
City = document.GetPropertyValue<string>("City"),
CompanyName =document.GetPropertyValue<string>("CompanyName"),
ContactName =document.GetPropertyValue<string>("ContactName"),
Country = document.GetPropertyValue<string>("Country"),
CustomerID = document.GetPropertyValue<string>("CustomerID")
};そこで、再度キャッシュ名を取得して実装したのがこれです。 Cosmos DB トリガーがあります。 ここに連れて行きましょう。 したがって、リース情報が含まれていることがわかります。リースには、リースという名前のドキュメント ストアがあります。 任意の名前を付けることができ、たとえば 158 が最後のポインタであるなど、ポインタを持つことができます。 したがって、パラメータがたくさんあります。 したがって、チェーンのフードプロセッサーは別のものですが、最後のポインターとして 158 を使用します。 したがって、最後に動作してからメモリ内のすべての更新を追跡します。 したがって、すべてのドキュメントのコレクションがあり、それらの変更を監視していた前回の時点から追加および更新されました。 したがって、これは変更フィード オブザーバー パターンに基づいており、Cosmo DB が一貫して情報をプッシュし、その情報がメモリ内に保持され、Cosmos DB にもそれへの参照があります。
そこで、これのサンプル実装を次に示します。 Azure機能を復活させたら。 したがって、この Cosmos DB トリガーが必要です。 もちろんデータベース名が必要です。 変更フィードを通じて監視しようとしているコレクション。 接続文字列だけでなく、リース コレクションのプレフィックスもリース ドキュメント内に置き、次にリースという名前のコレクションをリースします。 そして、ここでもキャッシュ名が必要です。 たとえば、これが名前です。democache を使用しています。このコレクション内のすべての顧客に対して、その顧客オブジェクトを構築してから、cache.InsertAsync を呼び出します。 それは非同期呼び出しのタスクです。 したがって、これを使用して削除することもできます。これについては後ほど説明します。 しかし、まず最初に挿入部分を確認しましょう。
したがって、このアプリを実行すると、変更が行われるまで待機することになります。 その変更フィード メカニズムを使用して、それらのリース内で、前回から追加および更新されたすべてのドキュメントを待機し、その追加と更新に基づいて、 NCache API呼び出しも同様です。 それでは、これを実行してみましょう。 デバッグには時間がかかります。 私は再構築され、その後、これらを適用できるようになります。 このためのロガーは実装していません。 したがって、私のサンプル実装に基づくと、ロガー エラーが発生する可能性があります。 ただし、それと同時にログの詳細を実装することもできます。 これは私が目的のために使用した完全なコードです。 したがって、デモの終わりに向けてそれを共有することもできます。 これが私の Azure 関数です。 一部のパラメーターが欠落しているため、null 値が取得されますが、全体としては、同期の仕事は完了しています。 NCache Cosmos DB に変更が発生した場合に備えて。
それまでの間、変更する書類を準備しておきます。 Ross123 は最初に作成したものの 123 つであるため、RossXNUMX を使用しましょう。 たとえば、いくつかの値を追加するとします。 今動いているかどうか見てみましょう。 はい、実行中であり、スタンバイ モードになっています。 したがって、ホストが初期化され、アプリケーションが開始されました。 私がプレイしていたので、前回の関数を実行し、いくつかの変更も加えました。 それで、完成させましょう。 さあ、どうぞ。 更新したRossXNUMXさんにお世話になっています。 それで、そのリース文書が更新されました。
それでは、キャッシュの内容をもう一度クリアして、最初からやり直しましょう。 したがって、キャッシュにはアイテムがありませんが、これは実行状態です。 そこで、これをここに保持し、今度は Cosmos DB を開いて、国の末尾にいくつかの文字を追加します。 UK を複数回言い、Ross123 といくつかのランダムな文字列を都市にも追加します。ここで [更新] をクリックすると、Cosmos DB もトリガーされ、Ross123 UK UK になっていることがわかります。 Ross123 44. つまり、そのリース コレクションを使用して、実際にその関数が実行され、その結果、顧客がここに追加され、私がアクセスすると、このアプリケーションは実行され続けました。 。 したがって、Ross123 を表示する場合は、デバッグがあるため、これで再生ボタンを押す必要があります。 それは私が実装していないロガーです。 これには、Ross123 444 と Ross123 にランダムな文字が追加されているはずです。 つまり、Cosmos DB 用の Azure 関数を実装するのは非常に簡単です。
Ron、Azure 関数について質問があります。質問は、これを Azure 関数として使用する必要があるのか、それに関連するコストはいくらなのかということです。 Azure 関数は繰り返しになりますが、これは必須ではありません。次に説明する他のアプローチも使用できます。 変更フィールド オブザーバーのオブザーバーを自分で実装することもできます。 それはインターフェースです。 すべてのメソッドを実装し、Azure 関数で Azure Cosmos DB トリガーを使用しないでください。 それで、それは別の選択肢です。 したがって、必須ではありません。 それが唯一の選択肢ではありません。 Azure 機能は Microsoft Azure でホストされます。 したがって、それに伴うコストも発生します。 しかし、それに関しては最小限です。 使用方法は単純ですが、これが唯一のオプションではありません。
削除の場合は、追加と更新が対象になります。 新しいドキュメントを追加すると、それが自動的にここに表示されます。 追加と更新を使用しているため、これを実行し続ける必要があります。リースコレクションは同じ行で更新されますが、削除はMicrosoftが論理的な削除を使用することを推奨しており、そのためには代わりに更新を使用することを推奨しています。たとえば、これはドキュメント内で削除され、Microsoft Azure Cosmos DB で削除する代わりに、この属性を使用します。 ランダムに削除、破棄し、TTL を使用して更新します。 そして、これに基づいて、これをもう一度実行して、コードも示します。 これは何を行うかというと、プロパティが削除されたドキュメントがあることが判明した場合、キャッシュを呼び出すか、そこから削除し、その TTL に基づいてデータベースからとにかく削除されますが、キャッシュから削除されます。すぐに。
それで、これを実行します。すでに実行されていると思います、はい、実行しています。 ただし、エラーコードはありますが、それはロガーによるものです。 ここに変更を加えてこのドキュメントを更新すると、キャッシュにも適用されます。 関数顧客の Ross123 もキャッシュから削除されました。 ここに来ると、キャッシュにないことがわかります。 さて、次は TTL があるからです。 したがって、10 秒後に Ross123 をここから削除する必要があります。 したがって、これが Microsoft Azure が削除を管理することを推奨する方法です。 現時点では、変更フィード オブザーバーのオプションは追加と更新のみです。 したがって、削除は論理的な削除である必要があり、Microsoft の推奨事項に基づいて、これをお勧めする回避策でもあります。
フィードプロセッサの変更
次のセグメントは、変更フィード プロセッサを通じてキャッシュを Cosmos DB と同期しています。 そこで質問がありましたが、Azure 関数だけが選択肢ではありません。 変更フィード プロセッサを自分で明示的に使用することもできます。これは、実装する IChangeFeedObserver インターフェイスです。 このコードをお見せしましょう。
namespace Microsoft.Azure.Documents.ChangeFeedProcessor.FeedProcessing
{
public interface IChangeFeedObserver
{
Task CloseAsync(IChangeFeedObserverContext context,
ChangeFeedObserverCloseReason reason);
Task OpenAsync(IChangeFeedObserverContext context);
Task ProcessChangesAsync(IChangeFeedObserverContext context,
IReadOnlyList<Document> docs);
}
}それに比べて、より多くの制御が可能になります。 たとえば、ここは私の工場です。 そこで、IChangeFeedObserverFactoryを実装しました。 ここからはこれをお見せしましょう。 OK、それで、たくさんのメソッドがあります。 この IChangeFeedObserver を実装しました。 接続を閉じるメソッドがあります。 コレクションを開くメソッドがあり、キャッシュを初期化して閉じるときに、実際にはcached.Disposeを呼び出してリソースを破棄し、メインメソッドはProcessChangesAsyncです。 つまり、IChangeFeedObserver Context、リスト、キャンセル トークン、およびいくつかの基本的なものが含まれています。 それで、私がここで実際にやっているのは、このコレクションの文書、文書のリストの中でそれを入手しているということです。 それが私と共有されるものです。 そこで、ChangeFeedObserverFactory がすべての関連リソースを取得し、それに基づいて、提供したすべてのリース情報とドキュメント情報に基づいて、削除、追加、更新を迅速に処理できるようにこれを実装しました。 ということで、今回はアップデートをお見せし、これを通じてユースケースも追加し、更新、削除してデモを終了します。
したがって、これは IChangeFeedObserver の明示的な実装です。 これは、Cosmos DB トリガーの助けを借りて Microsoft Azure 機能によって使用されるものです。 したがって、Cosmos DB トリガーはこれを自動的に実装します。これは簡単ですが、Azure 関数が必要です。 しかし、アプリケーションがそれを処理する必要がある場合、これを自分で実装できるとしたらどうでしょうか。 これでキャッシュが開始されました。 実際には別のキャッシュを使用していました。 検索させてください。はい、ちなみにここですべての詳細を提供しています。Cosmo DB デモ、リース ドキュメント、監視対象の顧客ドキュメントです。これらすべてのパラメーターをここで設定し、democache、save、およびそれを実行すると、今度はドキュメントを追加、更新、削除し、それらがそれに応じてキャッシュに適用されることを示します。
実行させてください CRUD操作 同様に、それで、私たちも持っています。 Azure 機能をシャットダウンしているのに、シャットダウンしてしまいます。 これはすでに追加されています。 OK、それで、ここに私のキャッシュがあります。参照が保持されているため、123 つのドキュメントがすでにそこにあります。 もう一度最初からやり直すために、これを削除したいのですが、今回は Cosmo DB に何かを追加します。キャッシュからすぐに取得できるはずです。ここからわかるように、コピーするだけです。これ。 新しい文書。 ここに貼り付けてみましょう。 Ross1122 の代わりに Ron1122 とだけ言って、ここでも同じフィールドを指定します。 このドキュメントはすでに削除されているため、いくつかの値を更新するだけなので、問題ありません。 そして、私たちは大丈夫だと思います。 はい、保存します。 つまり、このドキュメントはここ Ron1122 にあります。変更フィード オブザーバーを表示すると、自動的に処理されます。 あとは、これをキャッシュから表示するだけです。 まず第一に、それはキャッシュにありました。 したがって、キャッシュ内にある場合は、とにかくキャッシュからロードされます。 それで、Ron1122 と言うつもりですが、ご覧のとおり、ID を間違えたようです。 ロンXNUMXです。 さあ、どうぞ。 つまり、同じアイテムが入っています。
これから更新して、更新されたユースケースも確認できるようにします。 繰り返しになりますが、都市内の一部のキャラクターを更新する予定です。 NYK NYK としましょう。今回は UK の代わりに USA USA USA と言います。 つまり、更新が適用され、それがリースに適用され、それに基づいて自動的に適用されるはずです。 ほら、これにどれだけ瞬時に対処しているか。 したがって、これをもう一度実行して顧客 ID Ron1122 を指定すると、NYK NYK USA および USA の更新された値がここで確認できます。
削除の場合も、deleted を使用する必要があります。これは論理的な削除であり、そのために必要なのはランダムな属性を追加することだけです。 ちなみに、これは任意の属性であり、TTL も与えられます。 たとえば、TTL 10 で削除すると更新されるはずですが、コードには削除されたキーワードの処理があり、Time-to-Live によって Cosmo DB からの削除と削除されたキーワードが見つかるとすぐに処理されるため、削除します。 XNUMX つは、Cosmo DB がこのドキュメントを削除するようにアプリケーションが設計されていることを知っています。 したがって、キャッシュから削除する必要があります。 つまり、これは Cosmos DB の論理的な削除であり、ここで気づいたら、それで終わりです。 次のキーが削除されました。これは、これがキャッシュに存在しなくなることを意味します。 指定された ID の項目を入力する必要がある場合は、存在しません。 したがって、次のように使用しても、古いデータは得られません。 NCache この XNUMX つのアプローチを使用します。
それでは、早速まとめていきたいと思います。 サム、あと XNUMX 分だけ時間をいただきます。 そこで、最初はデータ キャッシュと取得操作について説明しました。 シンプルな API から始めることができます。 ドキュメントの取得に関する限り、cache.Get を呼び出します。 まずキャッシュから確認し、見つからない場合は Cosmos DB から取得し、キャッシュにも追加します。 これでサイクルが完了します。 コレクションでは、XNUMX つのアイテムであるコレクション全体をキャッシュするか、各コレクション アイテムを個別にキャッシュします。これら XNUMX つのアプローチの利点について説明しましたが、最も重要な側面は、同じ API を介して追加、更新することです。 の同期 NCache Cosmos DBなら可能です。 それは非常に簡単です。 DB トリガーを備えた Azure 関数または明示的に実装された IChangeFeedObserver インターフェイスの XNUMX つのオプションがあります。 したがって、両方のアプローチについて説明しましたが、どちらかを選択できます。
終わりに向かって、 NCache は、可用性が高く、直線的にスケーラブルで、非常に信頼性の高い .NET 分散キャッシュです。 たくさんのキャッシュ トポロジがあります。 クライアント キャッシュ、WAN レプリケーション ブリッジ。 そのため、Microsoft Azure Cosmos DB オンプレミス、クラウド内、さらにはオンプレミスでも使用できます。 そのため、その一環としてさまざまなオプションが利用可能です。 技術的な詳細に関してご質問がございましたら、お知らせください。そうでない場合は、サムに引き継ぎます。
ロン、少し触れた質問がありますが、質問は、どちらをより推奨しますか、より推奨されるオプションは何ですか? IChangeFeed または Azure 関数? あなたはそれについて話しましたが、それに光を当てたい場合は。 確かに、それは議論です。 使いやすさを重視し、Azure 関数の方が使いやすい場合は、それを使用してください。また、IChangeFeedObserver インターフェイスは接続を開く際に完全に制御できるため、コンポーネントを使用して物事を制御したい開発者であれば、これを使用してください。 、接続を閉じて適用します。 したがって、さらに制御したい場合は、IChangeFeedObserver を使用し、カスタム実装を使用します。 使いやすさを重視する場合は、DBトリガーを備えたAzure機能を使用してください。
OK、別の質問があります。これに関して詳しく説明するウェビナーはありますか? NCache 建築と仕事は？ はいあります。 録画されたウェビナーでは、一連のウェビナーが利用可能であり、ウェビナーの XNUMX つは実際に次のような名前です NCache 建築。 それで、それを調べてみてください。 そして、これらはすべて私たちのウェブサイトで入手可能です、ロン、そうですよね？ はい、実際のところ、この録音は数日以内に公開される予定です。 大丈夫完璧。 それでは、あと XNUMX 分しかありません。 それでは、皆さんご参加いただきまして誠にありがとうございます。 これがお役に立てば幸いです。 できる限り多くの質問にお答えするよう努めます。 さらにご質問がある場合は、こちらまでお問い合わせください support@alachisoft.com。 ご希望の場合は、 パーソナライズされたデモをスケジュールする、私たちも喜んでそうさせていただきます。 販売関連の質問がある場合は、いつでも弊社の営業チームにお問い合わせください。 sales@alachisoft.com。 ということで、ご参加いただきました皆様に改めて感謝申し上げます。 ご質問がございましたら、お気軽にお問い合わせください。お時間をいただきますようお願いいたします。 ありがとう、素晴らしい一日を。