グループ疎メンバーの組合せ
Essbaseブロック・ストレージ(BSO)データ・ロードのパフォーマンスを向上させるために、必要なディスクI/O (読取りおよび書込み)数を最小限に抑えるようにデータを構造化します。
この項は、集約ストレージ・キューブには適用されません。
パフォーマンスを向上させる最も効果的な方法は、キューブの読取りまたは書込み中にEssbaseが実行する必要があるディスクI/Oの数を最小限に抑えることです。Essbaseではデータがブロックごとにロードされるため、ソース・データを物理的なブロック編成に対応するように編成すると、Essbaseで実行する必要のある物理的なディスクI/O数が減ります。
ソース・データを整理して、疎ディメンションの同じ一意の組合せを持つレコードをグループ化します。この配列はデータベース内のブロックに対応します。
この章の例では、この戦略に従ってデータを編成する方法を示します。これらの例では、次に説明するように、Sample.Basicキューブのサブセットを使用します。
表33-1例 のディメンションと値
| 疎の属性以外のディメンション | 密次元 |
|---|---|
|
Scenario (Budget、Actual) |
Measures (Sales、Margin、COG、Profit) |
|
製品(コーラ、ルートビール) |
年(1月、2月) |
|
マーケット(フロリダ、オハイオ州) |
ノート:
データを属性ディメンションにロードしないため、この説明には関係しませんが、これらは疎です。
次に示すデータ・ソースについて考えてみます。疎ディメンション・メンバーの組合せ別にグループ化されていないため、このデータは最適化のためにソートは行われていません。Essbaseでの各レコードの読取りのたびに、疎ディメンションの異なるメンバーの処理が必要になります。
Jan
Actual Cola Ohio Sales 25
Budget "Root Beer" Florida Sales 28
Actual "Root Beer" Ohio Sales 18
Budget Cola Florida Sales 30Essbaseでは、1つではなく4つのブロックにアクセスするため、このデータ・ロードには時間がかかります。
同じSample Basicキューブのより最適に編成された次のデータ・ソースには、疎ディメンション・メンバーの一意の組合せでソートされたレコードがあります: Actual -> Cola -> Ohio。Essbaseで1つのブロックにアクセスするだけで、これらのレコードがロードされます。
Actual Cola Ohio Jan Sales 25
Actual Cola Ohio Jan Margin 18
Actual Cola Ohio Jan COGS 20
Actual Cola Ohio Jan Profit 5ソース・データを最適化して、レコードごとに多数のセルをインポートできるようにするには、
-
レコードが、一意の疎ディメンション・メンバーの組合せでグループ化されていることを確認します。
-
複数の値を指定するレコードのディメンションが密ディメンションであるようにレコードを並びます。
次の例では、ヘッダー・レコードを使用して、密ディメンションであるMeasuresディメンションのメンバーを特定しています。データは、最初に密ディメンションであるYEARのメンバーによってソートされた後、他のディメンションのメンバーによって階層的にグループ化されます。各レコードには、Measuresディメンションの複数の値が示されています。
Sales Margin COG Profit
Jan Actual Cola Ohio 25 18 20 5
Jan Actual Cola Florida 30 19 20 10
Jan Actual "Root Beer" Ohio 18 12 10 8
Jan Actual "Root Beer" Florida 28 18 20 8この例では、必要な行が見出しと最初のデータ行の2行であることに注目してください。前の例では、同じデータに対して4行が必要です。