4

私は、イントラネットに表示するためにメインオフィスからデータを取得する必要があるサテライトオフィスにいます。両方の場所でMSSQLServerを使用しており、メインオフィスを指すリンクサーバーをサテライトオフィスに作成することを計画しています。2つの間の接続は私が信じているVPNトンネルです（それは正しいと思いますか？私は何を知っていますか、私はプログラマーです！）

低速になる可能性のある接続を介して大量のトラフィックが生成されるのではないかと心配しています。本社のサーバー上のSQLビューにアクセスできるようになります。選択クエリが実行されると、大量のデータ（〜500レコード）ではありませんが、クエリがないとビューは巨大（〜30000レコード）になります。

リンクサーバーでクエリを実行すると、ネットワーク経由で結果のみが返されると思います（ローカルでクエリされるビュー全体ではありません）。その場合、ビューにインデックスが付けられていると仮定すると、接続自体が主なボトルネックになる可能性があります。他に注意すべき落とし穴や潜在的なボトルネック（クエリの構造に基づく）はありますか？

4

1 に答える 1

2

あなたが説明したことから、あなたのつながりがボトルネックになる可能性があります。

また、衛星の場所でデータをキャッシュすることも検討してください。
決定は以下に依存します：
-メインデータベースでデータが更新される行数と頻度
-衛星ロケーションで同じデータセットをロードする必要がある頻度

2つのエッジの例：

  1. データは静的または比較的静的です-メインDBにのみ挿入されます。衛星ロケーションでは、ユーザーは同じデータを何度もクエリすることがよくあります。この場合、衛星の場所でローカルにデータをキャッシュすることは理にかなっています。

  2. データは揮発性であり、多くの更新または/および削除が行われます。衛星ロケーションのユーザーがデータを照会することはめったになく、照会する場合は、場所の条件が常に異なります。この場合、キャッシュすることは意味がありません。接続が遅く、頻繁に変更が行われる場合は、メインDBと同期しなくなる可能性があります。

キャッシュのもう1つの利点は、データ圧縮を実装できることです。これにより、接続速度の低下による悪影響が軽減されます。

ローカルロケーションでキャッシュすることを選択した場合、多くのオプションがありますが、これは別のトピックになると思います。

[編集]

圧縮について：圧縮されたトランザクションログ配布を使用できます。SQL 2008では、圧縮はEnterpriseエディションでのみサポートされます。SQL 2008 R2では、標準バージョンから利用できます。http://msdn.microsoft.com/en-us/library/bb964719.aspx。

トランザクションログを送信する前に、任意の圧縮ライブラリを使用してカスタム圧縮を実装できます。

于 2011-05-07T01:57:55.533 に答える