小さな建設会社のために 2 つのデータベース アプリケーション間の夜間同期を作成し、データベース メールを使用して簡単な通知をセットアップし、ロードが成功したかどうかを数人に知らせました。この通知が機能していることを彼らが確認したので、従業員が 1 日を通して作業指示書に変更を加えたときに、クライアントにステータスの更新を提供するように依頼されました。
私はいくつかの調査を行い、DB メールがこのタイプの機能用に設計されていないことを理解していますが、頻度は問題にならないほど小さいと考えています。1 日あたり 50 ～ 200 通のメールを見積もっています。
DB Mail の実際の制限については何も見つけることができず、誰かが過去に同様のことを試したことがあるかどうか、またはベスト プラクティスを使用してこれらのメールを送信する正しい方向に進むことができるかどうか疑問に思っています。
ここで何百もの話をしているなら、間違いなく先に進むことができます. データベース メールのMSDN ページを参照してください。現在の設計 (つまり、 SQL2000 以降のもの) は、大規模で高性能なエンタープライズ実装向けに特別に設計されています。Service Broker ( SQL Serverのメッセージ キュー バス) の上に構築され、非同期処理と、プロセスの分離、クラスタリング、およびフェールオーバーによるスケーラビリティの両方を提供します。1 つの注意点は、他の実装とは異なり、メッセージが SQL Server によって ACID で保護されているため、トランザクション ログの負荷が増加することです。これにより、障害が発生した場合にキューを完全に回復できます。
専用ソリューションに移行する前に、Service Brokerで何を処理できるか知りたい場合は、 MySpace の優れたケース スタディがあります。最も興味深いフラグメント:
440 のデータベース サーバーで何百万ものユーザーをサポートするために必要なレベルのメッセージを処理できることを実証できない限り、Service Broker の使用を開始したくありませんでした」と Stelzmuller 氏は言います。「ラボに行ったとき、テストの品質を確保するために独自のワークロードを持ち込みました。Service Broker が 1 秒あたり 4,000 メッセージの負荷を処理できるかどうかを確認する必要がありました。私たちのテストでは、1 秒間に 18,000 件以上のメッセージを処理できることがわかりました。カスタム ソリューションを独自に作成するのではなく、Service Broker を使用してソリューションを構築できることを嬉しく思います。