（次の質問は少し長いので、永続的なキャッシュと通知に興味がない場合は、ブラウザーのxボタンを押してください！）
私たちは、多くの数値情報を保持する永続的なデータストアを実装するという任務を負っています。
基本的に、ユースケースは次のとおりです。
データストアで伝播する必要のあるデータの更新と挿入を含むフィードを取得します。
1.1。現在、更新の頻度は1フィードから1〜10秒の範囲です。しかし、後で、スケーラビリティの問題がさらに増える可能性があります。
1.2。ボリューム。各フィードは約100K行になります（値が変更されない場合でも、フィード内に残ります）
- 値は永続化する必要があります。これが発生したら、C＃サーバーに偶数を通知する必要があります。理想的にはイベントで。フィードには理想的には変更されていないデータが含まれるため、サーバーイベントは、だけでなくデルタとともに発生する必要があります
OnStuffChanged。
実装
システムはSQLサーバーを使用しているため、技術者以外の人が実装のためにSQLサーバーの使用を承認しました。この種の匂いは私には悪かった！しかし、いずれにせよ、いくつかの調査を行い、 SqlDependencyAPIのラッパーについて発見しました。
しかし、appiには、制約の長いリストの形で荷物が付属していることがわかりました（http://msdn.microsoft.com/en-us/library/ms181122%28v=sql.105%29.aspx）。また、MSが、1秒未満のパフォーマンスにはそれほど効率的ではないと言っていることもわかりました（現在はそうではありませんが、将来的にはそうなる可能性があります）。
特にパフォーマンスと信頼性のためにMSは言います
「クエリ通知は、1秒未満の応答時間で通知を受信する必要がある場合、ネットワークインフラストラクチャの速度と信頼性の両方が低い場合、または通知の量が非常に多い場合、アプリケーションにとって最良の選択ではない可能性があります。」
次のようなクエリ通知の代替案を提案します。
- 監視対象テーブルでの更新トリガー（私はトリガーの大ファンではありません）の後、そのアクションはSQLServerサービスブローカーを使用して通知が必要な更新にメッセージを送信することです。
- 保存して通知するカスタムミドルウェアの実装。
（私は辛抱強く感謝しているところまで来ています！）
つまり、カスタムミドルウェア以外のこれらのアイデアはどれも良いものではないと私は本当に感じているということです。
質問
- 誰かがとを実際に体験したことが
SqlDependencyありService Brokerますか？そもそも技術的なミスが発生するのを防ぐために、私は管理に対して十字軍を始めるべきだと思いますか？ redis/memcached/mongoたぶん、データキャッシュのようなものを使うべきだと思います。それらは永続性を提供します。それらをリレーショナルDBとブリッジし、変更された/新しい番号をサーバーに提供して処理する方法を見つけられると確信しています。これはもっと意味がありませんか？- たぶん私は物事を過剰に設計しているだけです。代わりに他の提案を試す必要があります（同様のstackoverflowの質問が提案されています``）？
長い投稿をお詫びします！これまでお読みになりましたら、よろしくお願いします！