4

現在、SQL Federated DB は 10 個のシャードに分割され、クライアント ID でフィルター処理されたデータのほぼ等しい部分になっています。

現時点では、フィルタリングされたクエリの実行でパフォーマンスの問題が発生しています。たとえば、特定のクライアントのクエリを実行すると、一部のシャードで 4000 行を返すのに 3 分以上かかる場合があります。ただし、同じシャードのフィルタリングされていない接続でまったく同じクエリを実行すると、タイムリーに 4 秒以内に返されます。注目すべき側面の 1 つは、速度が低下しているシャードには、データが少ないにもかかわらず、より多くのクライアントが含まれる傾向があることです。最も可能性の高いパフォーマンス阻害要因 (と私は信じています) は、インデックス作成と、フィルター処理された/フィルター処理されていない接続に結び付けられるものです。

検索しても、シャード全体のクエリ パフォーマンスやシャードでの特定のインデックス作成戦略に関する情報はあまり見つかりませんでした (Azure は明らかにインデックス付きビューをサポートしていません)。私の印象 (したがって、明確にする必要がある) は、インデックスはメンバーごとではなく、シャードのすべてのメンバーに適用されるということです。

前者の場合、この特定のシャードをリシャードすることを除けば、データのサイズではなく、クライアントの数だけが異なることを考えると意味がありません。これから試行するいくつかのことは、フィルタをインデックスに明示的に追加すること、またはフィルタを各クエリに追加することです。言うまでもなく、フィルター接続から離れることに満足していません.

他の誰かがこの問題を経験したことがありますか、またはフィルタリングされていない接続がフィルタリングされた接続よりも大幅に優れているという方向性を提供できる可能性がありますか?

前もって感謝します...

4

1 に答える 1

0

フェデレーションのインデックスは、フェデレーション メンバーごとに適用されます。単一のインデックス付きメンバーから始めて SPLIT 操作を実行した場合、インデックスは SPLIT の結果に自動的に適用されます。ただし、複数のメンバーを作成した後にインデックスを適用した場合は、各メンバーに明示的にインデックスを追加する必要があります。

うまくいけば、あなたはピクルスに陥っていません。

この機能は 4 月に発表された新しい SKU ではサポートされていないため、今後フェデレーションの代替案を検討することをお勧めします。

于 2014-05-21T22:27:28.223 に答える