このシナリオを考えると、
3カ国の販売情報。
CountryA: 0.9M records.
CountryB: 0.8M records.
CountryC: 0.7M records.
理論的には、次のアプローチ間で予想されるパフォーマンスの違い(*)は何でしょうか?
- 国ごとに1つのパーティションを持つ単一のキューブ。
- 国ごとに1つずつ、3つのキューブ。
(*)単一の国のクエリの場合、もちろんです。
このシナリオを考えると、
3カ国の販売情報。
CountryA: 0.9M records.
CountryB: 0.8M records.
CountryC: 0.7M records.
理論的には、次のアプローチ間で予想されるパフォーマンスの違い(*)は何でしょうか?
(*)単一の国のクエリの場合、もちろんです。
パーティション化されたアプローチのクエリが適切なパーティションを正しくターゲットにしている限り、パフォーマンスの違いはほとんどありません。
ファクト/ディメンションの関係が同じである場合は、パーティションアプローチを使用してください。これにより、パーティション間で結果を返すのがはるかに簡単になります(第1四半期のTotalRevenueやProductAのTotalCostなど)。これらを別々の立方体に分割すると、これらの計算はより困難になります。また、Excelピボットテーブルやレポートビルダーなどのセルフサービスの調査ツールを使用するアナリストが複数のキューブをターゲットにすることは、より複雑になります。
SQLCATチームがパーティションサイズに関して推奨するものは次のとおりです。
ほとんどの場合、パーティションに含まれるレコードサイズは2,000万未満であり、各メジャーグループに含まれるパーティションの合計は2,000未満である必要があります。また、200万未満のレコードを含むパーティションを定義することは避けてください。パーティションが多すぎるとメタデータ操作が遅くなり、パーティションが少なすぎると並列処理の機会を逃す可能性があります。
あなたは明らかに2000万レコードの推奨を下回っています。さらに、各パーティションのデータサイズも確認します。小さなキューブ(必要なメジャー、属性の関係、適切に定義された階層など)は、パーティションごとに大幅に多くのレコードを使用して適切に実行できます。
SQLCATのベストプラクティスの完全なリストは次のとおりです。