16

バックグラウンド：

1 日を通して頻繁に更新されるアイテムの大規模な (1500 万以上) テーブルがあります (1 日平均 300K の変更)。保留中の変更はステージング テーブルに格納され、このテーブルから変更を読み取り、更新を行い、変更を処理済みとしてマークするジョブが終日実行されます。

他の多くのアプリケーションは、項目テーブルのデータを使用してさまざまなタスクを実行します。多くの場合、これらのタスクは、ライブ データを古いスナップショットと比較し、それに応じて他のシステムを更新する必要があるため、スケジュール化され集中的に行われます。たとえば、eBay に商品を出品し、ライブの商品データを既存の出品と比較して、新しい eBay 出品を挿入する必要があるかどうか、販売した商品を削除する必要があるかどうか、数量を更新する必要があるかどうかなどを確認します。データが非常に大きいため、ほとんどの場合、これらのアプリケーションのほとんどは実行頻度が低く、多くの場合、最新のものではありません。

私の質問：

Service Broker を使用してパブリッシャー/サブスクライバー パターンを実装することを検討しています。目標は、アイテムが変更されたときにメッセージを発行することです。これにより、他のさまざまなシステム (eBay アプリケーションなど) がサブスクライブできます。これにより、何が変更されたかだけでなく、すべてのデータを照会することを伴う大規模で頻度の低い更新ではなく、より詳細な更新をリアルタイムに近づけることができます。しかし、Google を使用した後では、これは一般的なデータベース パターンではないように思われ、警告が表示されます。これは Service Broker の有効な使用法ではありませんか (ただし、Pro Sql Server 2008 Service Brokerで Pub/Sub の実行に関する小さなセクションを見つけました)。この問題は通常どのように解決されますか? それは十分に一般的な問題のようです。

TL;DR:

目標: 単一の項目が変更されたときに、さまざまなシステムを動的で疎結合の方法で更新します。

質問: Service Broker で実装された pub/sub スタイルのソリューションは、大量の設定で実行可能なソリューションですか?

4

3 に答える 3

3

これは非常に一般的な統合パターンです。

私はSQLServerService Brokerに精通していませんが、統合ミドルウェアスタック（TIBCO、Oracle、webMethods、Mule、Informaticaなど）を見ると、それらはすべて、説明したタスクを実行する「データベースアダプター」を提供します。

一般的なパターンは、データベースの更新がメッセージの公開をトリガーすることです。これは、データベーステーブルのトリガーを介して、または新しい更新のためにテーブルを「ポーリング」するアダプターを介して行われます。どちらの方法にも長所と短所があります。

このパターンの主な利点は、（ご想像のとおり）他のシステムをより頻繁かつタイムリーに更新することです。これは、ビジネスを行うためのより「リアルタイム」な方法です。さらに、正規のメッセージ形式への変換を実行すると、システム間の結合が緩くなり、システムを変更/更新する必要がある場合の苦痛が少なくなります。

于 2012-07-01T08:14:56.213 に答える
0

これは一般的なデータベース パターンではありません。ほとんどのリレーショナル データベースには、すぐに使用できるほどの設備が整っていないからです。Service Broker がなければ、SQL Server も同様です。

Service Broker の開発者の 1 人が、ほとんどの企業が.

Service Broker はまさにあなたが探しているものを実行するためのものであると理解しています。データが変更されたときにカスタム アプリケーションExternal Activationを実行するために使用することもできます。

于 2012-06-30T08:46:25.143 に答える
0

通常、この種の問題は、データベースに焦点を当てた pub/sub 実装が提供できるものよりも (範囲内で) 大きくなります。推奨できる場合は、本格的なサービス バスの使用を検討してください。

nServiceBus (特定のサイズまでは無料、それ以降はかなり安い)

堅固な pub/sub フレームワークが得られますが、操作は簡単で、顧客、記事、およびサンプルの大規模なユーザー ベースがあります。

于 2012-07-09T23:45:24.273 に答える