分散キャッシュ システムの出現により、データベースが過負荷になり遅延する問題が解決されました。 現在、これらの分散キャッシュは XNUMX 秒あたりに発生する数百万のデータ トランザクションの負荷を処理できますが、問題があります。
ほとんどのエンタープライズ レベルのアプリケーションは、このデータの特定の部分で発生する変更に依存しています。 これらのアプリケーションは、これらの変化に基づいて重要なビジネス上の決定を下す必要がありますが、このデータのサイズは数千ギガバイトであるため、特定の変化を監視することは膨大な作業になります。
この問題に対応するには NCache、インメモリ分散キャッシュは、として知られる機能をもたらします。 連続クエリ。 このブログでは、継続的クエリの仕組みと、継続的クエリの構成方法について説明します。 NCache、そしてそうすることでどのようなメリットが得られるのか。
NCache 詳細 NCache ドキュメント ダウンロード NCache
変更を監視するための継続的なクエリ NCache
継続クエリ機能 NCache を使用すると、分散キャッシュ クラスター内の選択したデータセットで発生した変更を追跡できます。 キャッシュ内のこの選択的なデータセットは、SQL のような方法で定義されます。 OQL (オブジェクトクエリ言語) クエリ。 このデータセット内で発生した変更は、次の形式で (イベントのコールバックを登録した) アプリケーションに伝播されます。 キャッシュレベルのイベント.
キャッシュ クラスターの規模に関係なく、定義してキャッシュ内に登録したデータセットで発生した変更のみが通知されます。 これは、OQL クエリを通じてデータが除外されるときに、Continuous Query がアプリケーションの分離を実現する方法でもあります。 この分離により、アプリケーションが互いに重複しないことが保証されます。
継続的クエリ自体はアプリケーション データを変更しないことにも注意してください。 代わりに、継続的クエリは、実行時にイベントを通じてデータを監視し、アプリケーション間で共有するためのメカニズムを提供します。 次に、開発者は、継続的クエリ イベントのコールバックを登録し、ビジネス ロジックを定義することで、アプリケーションがこのデータをどのように扱うかを確認します。
連続クエリ SQL入力 NCache イベント通知をキャッシュする
継続的クエリの構成 NCache
継続的クエリの設定は簡単です NCache。 XNUMX 段階のプロセスに従うだけです。 これらの手順に従うと、アプリケーションは定義したデータセットに対する通知を受信し、それに応じて動作できるようになります。
これら XNUMX つの手順は次のとおりです。
ステップ1:イベントのコールバックを登録する
キャッシュ レベル イベントのコールバックを登録する必要があります。 アイテム追加, アイテム更新済み、 or アイテムが削除されました。 これらのイベントを通じて、これらのイベントのいずれかが発生した場合にアプリケーションが何をすべきかを指示するビジネス ロジックを定義します。
次のコード例では、イベント ItemAdded にコールバックが登録されます。
1 2 3 4 5 6 7 8 9 |
static void QueryItemCallBack(string key, CQEventArg arg) { switch (arg.EventType) { case EventType.ItemAdded: Console.WriteLine(“Item has been added”); break; } } |
ステップ2:クエリと通知を登録する
イベントのコールバックを登録したら、結果のデータセットの基準を指定する連続クエリを作成する必要があります。 イベントは、この継続的クエリに基づいて発生します。 この後、コールバックがクエリに登録されます。 これが完了すると、クエリは、 CQ を登録する 方法。
以下のコード例は、これらすべてがどのように起こるかを示しています。
1 2 3 4 5 6 7 8 9 10 11 12 |
string query = "SELECT $VALUE$ FROM FQN.Product WHERE Category = ?"; var queryCommand = new QueryCommand(query); queryCommand.Parameters.Add("Category", "Beverages"); // Create Continuous Query var cQuery = new ContinuousQuery(queryCommand); // Item add notification cQuery.RegisterNotification(new QueryDataNotificationCallback(QueryItemCallBack), EventType.ItemAdded, EventDataFilter.None); cache.MessagingService.RegisterCQ(cQuery); |
継続的クエリの登録を解除する
NCache 通知が必要なくなったときに、継続的クエリから通知を登録解除するオプションが提供されます。 これは、 登録解除通知 方法。
次のコード例では、イベント通知が連続クエリから登録解除されます。
1 |
cQuery.UnRegisterNotification(new QueryDataNotificationCallback(QueryItemCallBack), EventType.ItemAdded); |
NCache また、連続クエリ自体をキャッシュ クラスターから登録解除するオプションも提供されます。 リソースを消費するため、不要になったときにキャッシュ内で実行し続ける必要はありません。 連続クエリをキャッシュから登録解除するには、 NCache あなたが与えます CQ の登録を解除する 方法。
次のコード例では、継続クエリがキャッシュ サーバーから登録解除されます。
1 |
cache.MessagingService.UnRegisterCQ(cQuery); |
NCache: 最良のソリューション
大規模で複雑なビジネス アプリケーションに関しては、データの洗練が大きな課題となります。 ストリーム処理 in NCache は、大規模で複雑なデータをデータ ストリームに変換して簡単に処理できるようにすることで、この課題に応えます。
ストリーム処理の一般的なアプリケーションは次のとおりです。 パブリッシャー サブスクライバー のモデル NCache。 ただし、これには次の制限があります。
- メッセージは、サブスクライバに配信されると、アプリケーションによって保持されません。
- データのフィルタリングはクライアント側で行われるため、アプリケーションのアーキテクチャがより複雑になります。
継続的クエリは、次の方法でこれらの問題の両方に対処します。
- 処理後もデータをキャッシュ内に保持することによって。
- クライアント側ではなくサーバー側で非常に単純な OQL ステートメントを通じてデータをフィルタリングすることによって。 これにより、シンプルなアプリケーション アーキテクチャが保証されます。
連続クエリ ストリーム処理 Pub / Subメッセージング
まとめ
NCache は、データベースのボトルネックを効率的かつ効果的に処理する、非常に高速で拡張が容易な分散キャッシュです。 継続的クエリ、ストリーム処理、Pub/Sub メッセージングと同様に、 NCache 他にも豊富で強力な機能がたくさんありますので、ぜひ試してみてください。 これらの機能により、定量的および定性的な結果が得られます。 試す NCache 今!