リンクされたSQL Serverにはどのような大きな制限が予想されますか？
当社の製品は、Microsoft SQL Serverに基づいています。現在、3つのデータベースを使用しており、常に1つのSQL Serverインスタンスにそれらを展開しています。
3つのデータベースは、OLTP、OLAP、および監査です。 OLAPデータベースには、データベース間のクエリを使用して、OLTPと監査の両方からのEODに関する大量の受信データがあります。
ご質問
これらの3つのデータベースを3つの別々のStandard Edition instancesに単一の物理サーバー内に展開し、SQL Serverのリンクサーバー機能を使用してそれらをバインドする場合は、次のようになります。
- アプリケーションコードに対してどの程度透過的ですか？どのくらいの変化を期待できますか？
- OLAPへの受信データの量は50k〜100k行、EODあたり200〜500MBのペイロードになります。どのくらいのパフォーマンスの低下が予想されますか？
- 他にどんな大きな制限を期待する必要がありますか？
バックグラウンド
現在、最初の潜在的なクライアントを500人以上の同時ユーザーに売り込んでいます。
64コアと256GB RAMを含むサーバー仕様を作成しています。 SQL Serverがこれらの豊富なリソースをすべて利用するには、クライアントはEnterprise Editionを購入する必要があります。EnterpriseEditionは、SQL Server 2016ではコア単位のライセンスでのみ利用できます。
ライセンスコストだけ（64 x $ 7400）でそれらが下がることを恐れています。したがって、データベースをStandard Editionの3つのインスタンスに分割し、それらをリンクして、リンク機能がアプリケーションコードから透過的になることを期待しています。
アプリケーションコードに対してどの程度透過的ですか？どのくらいの変化を期待できますか？
まったく透過的ではありません。大きな変更が予想されます。
大幅なパフォーマンスの低下に備える必要があります。
分散クエリ（リンクサーバーのフレームワーク）では、反対側のサーバーが何であれ、一般的なOLEDBモデルを使用します。 SQL Serverターゲットがより完全な情報（メタデータ、統計など）を提供できる可能性があることは事実ですが、その結果はネイティブクロスデータベース操作ほど緊密に統合されていないか、または機能していません。
リモートクエリには、パフォーマンスの低下と、オプティマイザによる計画の選択の悪さに対する当然の評判があります。データを変更するステートメント（削除、挿入、更新、マージ）は、基本モデルがカーソルのモデルであることが多いため、特に発生しやすくなります。
ad-hocクロスインスタンスクエリを実行する必要がない場合は、might許容されるパフォーマンスを得るために、保存された各クエリを手動で調整できますが、これは多くの作業であり、成功が保証されるわけではありません。
インスタンス間の一括操作の場合は、実際の一括操作（bcp、BULK INSERT、SSIS ...など）リンクサーバーを使用するよりもインスタンス間で。
とは言っても、基本的な考えは、私にとって価値があるよりもはるかに厄介なようです。 Standard Editionの制約内で機能するハードウェアを指定します。または、クライアントがより高いパフォーマンスを必要とする場合は、より大きなサーバーを取得してEnterprise Editionを使用します。