透過パーティション

透過パーティションを使用すると、ローカル・データベースの一部であるかのように、リモートに格納されているデータを操作できます。リモート・データは、データ・ターゲットのユーザーがリクエストするたびにデータ・ソースから取得されます。ユーザーは、データが格納されている場所を知る必要はありません。これは、データがローカル・データベースの一部として表示されるためです。

図9-5 透過パーティション

この図は、透過的パーティション・データ・ターゲットのユーザーが3つのデータ・ソースからのデータをどのように表示するかを示しています。

データはデータ・ソースから直接取得されるため、ユーザーには最新バージョンが表示されます。データを更新すると、更新はデータ・ソースに書き戻されます。このプロセスは、データ・ソースおよびデータ・ターゲットの他のユーザーが、これらの更新に即座にアクセスできることを意味します。

透過パーティションを使用すると、ユーザーがソース・データにアクセスするにつれて、データ・ソースおよびデータ・ターゲットのユーザーのパフォーマンスが低下することがあります。

たとえば、TBCのDBAは、透過パーティションを使用して、個別のコンピュータ上のScenarioディメンションの各メンバーを計算できます。このプロセスにより、ユーザーにデータの同じビューを提供しながら、計算の経過時間が短縮されます。

透過パーティションを使用して、次の目標を達成します:

ユーザーにデータの最新バージョンを表示
データ・ターゲットのユーザーにデータの更新を許可
ディスク領域の削減

透過パーティションのルール

透過パーティションは、次のルールに従う必要があります:

データ・ソース・アウトラインとデータ・ターゲット・アウトラインの共有透過領域は同一である必要はありませんが、ディメンションをマップできる必要があります。データ・ソースの各ディメンションおよびメンバーがデータ・ターゲットの各ディメンションおよびメンバーにどのようにマップされるかをEssbaseに指示する必要があります。
非共有領域のデータ・ソースとデータ・ターゲットのアウトラインはマップ可能である必要はありませんが、属性の関連付けは同一である必要があります。そうしないと、一部の取得の結果が正しくなくなる可能性があります。たとえば、製品100-10-1010がソースのGrape Flavor属性に関連付けられているが、製品100-10-1010がターゲットのGrapeに関連付けられていない場合、New YorkのすべてのGrapeフレーバの総販売高は正しくありません。
パーティション定義には、保管済メンバーのみを含める必要があります。属性ディメンションまたはメンバーを使用して透過パーティションを定義することはできません。たとえば、Marketディメンションに関連付けられているMarket Type属性ディメンションには、メンバーUrban、SuburbanおよびRuralがあります。 Urban、SuburbanまたはRuralにはパーティションを定義できません。
セルがデータ・ソースから集約ストレージ・データベースにターゲットとしてマップされる場合、すべてのセル依存性も同じパーティション定義にマップされる必要があります。
レプリケート・パーティションの上に透過パーティションを作成できます。つまり、次の図に示すように、レプリケート・パーティション・ソースを使用して透過パーティション・ターゲットを作成できます:

図9-6 有効な透過パーティション
次に示すように、他の複数のパーティションの上に透過パーティションを作成することはできません。つまり、データベース内の各セルはローカル・ディスクまたはリモート・ディスクのいずれかのロケーションからのみ取得する必要があるため、複数のソースから透過的パーティション・ターゲットを作成することはできません。

図9-7 透過パーティションが無効です
データ・ソースおよびデータ・ターゲットのメンバーに割り当てる式を慎重に検討してください。

透過パーティションのメリット

透過パーティションは多くのデータベースの問題を解決できますが、透過パーティションは必ずしも理想的なパーティション・タイプではありません。

1つのデータベースにデータを格納するため、必要なディスク領域が少なくなります。
データ・ターゲットからアクセスされるデータは常に最新バージョンです。
ユーザーがデータ・ソースのデータを更新すると、Essbaseはデータ・ターゲットでこれらの変更を行います。
個々のデータベースは小さくなるため、より迅速に計算できます。
データの分散は、エンド・ユーザーおよびエンド・ユーザーのツールからは見えません。
データ・ソースまたはデータ・ターゲットからデータをロードできます。

透過パーティションのデメリット

これらのデメリットが深刻すぎる場合は、かわりにレプリケート・パーティションの使用を検討してください。

透過パーティションは、Essbaseがデータ・ソースのデータをネットワーク経由でデータ・ターゲットに転送するため、ネットワーク・アクティビティが増加します。ネットワーク・アクティビティが増加すると、ユーザーの取得時間が遅くなります。
データ・ソースにアクセスしているユーザーが多いため、取得時間が長くなる可能性があります。
データ・ソースに障害が発生した場合、データ・ソースとデータ・ターゲットの両方のユーザーが影響を受けます。したがって、ネットワークおよびデータ・ソースは、データ・ソースまたはデータ・ターゲットのユーザーが必要とするときは常に使用可能である必要があります。
一部の管理操作は、ローカル・データに対してのみ実行できます。たとえば、データ・ターゲットをアーカイブする場合、Essbaseはデータ・ソースではなくデータ・ターゲットのみをアーカイブします。次の管理操作は、ブロック・ストレージ・データベースのローカル・データに対してのみ機能します:
- CLEARDATA計算コマンド
- DATACOPY計算コマンド
- EXPORTコマンド
- VALIDATEコマンド
- BEGINARCHIVEおよびENDARCHIVEコマンド
透過パーティションで計算を実行すると、Essbaseはローカル・データおよび透過依存の現在の値を使用して計算を実行します。データ・ソースとデータ・ターゲットのアウトラインが非常に異なる可能性があり、そのような計算が不正確であるため、Essbaseは透過的な依存の値を再計算しません。すべてのパーティションを計算するには、個々のパーティションに対してCALC ALLコマンドを発行し、各パーティションの新しい値を使用して最上位レベルでCALC ALLコマンドを実行します。

次に例を示します:
- データ・ターゲット・アウトラインには、East、West、SouthおよびCentralメンバーを含むMarketディメンションが含まれています
- データ・ソース・アウトラインには、New YorkおよびNew Jerseyメンバーを含むEastディメンションが含まれています
データ・ターゲット・アウトラインを計算しようとした場合、Eastがレベル0のメンバーであると仮定します。ただし、データ・ソースでは、EastはNew YorkおよびNew Jerseyを追加することで導出されます。ただし、データ・ターゲットの計算ではこの情報が認識されず、データ・ソースのNew YorkおよびNew Jerseyに加えられた変更を反映できませんでした。したがって、正確な計算を実行するには、データ・ソースのEastを計算してからデータ・ターゲットを計算します。
データ・ソースのメンバーに割り当てられた式は、データ・ターゲットで定義された式または集計と矛盾する計算結果を生成する場合があります。その逆も同様です。

透過パーティションのパフォーマンスに関する考慮事項

透過パーティションのパフォーマンスを向上させるには、パーティションの作成時に次のガイドラインを考慮してください:

データ・ブロックの構造と内容を決定するために密ディメンションが使用されるため、透過パーティションの密ディメンションに沿ってパーティション化すると、パフォーマンスが大幅に低下する可能性があります。データベースがターゲットの密ディメンションに沿ってのみパーティション化されている場合、Essbaseでは、透過パーティションのリモート・データおよびブロックのローカル部分のディスクI/Oに対してネットワーク・コールを実行して、データ・ブロックを構成する必要があります。

パフォーマンスを向上させるには、必要なブロック数が疎メンバーとの組合せに制限されるように、領域定義に1つ以上の疎ディメンションを含めることを検討してください。
ディメンションの属性値に基づいて透過パーティションを作成すると、属性が疎ディメンションに関連付けられるため、取得時間が長くなる可能性があります。このような場合、属性に関連付けられたレベルより高いレベルでパーティション化すると、取得時間が短縮されます。たとえば、Sample.BasicデータベースのProductディメンションで、子の100-10、200-10および300-10 (レベル0)が属性に関連付けられている場合、取得パフォーマンスを向上させるために親の100、200および300 (レベル1)をパーティション化します。
データ・ターゲットからデータ・ソースにデータをロードすると、パフォーマンスが大幅に低下する可能性があります。可能な場合は、データをデータ・ソースにローカルにロードします。
ユーザーがネットワーク経由でデータにアクセスするため、取得時間が長くなります。
透過的パーティション・ターゲットが集約ストレージ・データベースの場合、MAX_REQUEST_GRID_SIZEおよびMAX_RESPONSE_GRID_SIZEの構成設定を使用して、リクエスト・グリッドおよびレスポンス・グリッドの最大サイズを指定できます。
ベース・ディメンションをパーティション化すると、パフォーマンスが大幅に低下する可能性があります。
「透過的パーティション計算のパフォーマンスに関する考慮事項」を参照してください。

透過パーティションの計算

透過パーティションで計算を実行すると、Essbaseはローカル・データおよび透過依存の現在の値を使用して計算を実行します。リモート・データに依存するローカル・データを計算する場合、Essbaseはボトムアップ計算を実行します。ボトムアップ計算は、ターゲット・データベースの計算機キャッシュが適切に使用されている場合にのみ実行できます。「ボトムアップ計算の使用」を参照してください。

計算機キャッシュに割り当てられたメモリーを増やすと、透過パーティションを使用した計算パフォーマンスが大幅に向上します。計算が開始されると、アプリケーション・ログ・ファイルのメッセージに、ターゲット・データベースで計算機キャッシュが有効か無効かが示されます。ターゲット・データベースで計算機キャッシュを使用すると、計算中にデータ・ソースからリクエストされるブロック数が減ります。リクエストされるブロックを減らすと、ネットワーク経由でブロックを転送することで生成されるネットワーク・トラフィックが減少します。

透過的パーティション計算のパフォーマンスに関する考慮事項

データ・ターゲットでデータを計算すると、データ・ターゲットがネットワーク全体の各依存データ・ブロックを取得してから計算を実行する必要がある場合に、パフォーマンスが大幅に低下する可能性があります。

Essbaseで、トップダウン・メンバー式を含むデータ・ターゲットのいずれかの部分に対してトップダウン計算を実行する必要がある場合は、透過的計算のパフォーマンスも低下する可能性があります。データ・ターゲットにトップダウン・メンバー式が含まれていない場合、Essbaseではデータ・ターゲットに対してボトムアップ計算を実行できるため、はるかに高速です。

Essbaseは、データ・ソースに対して計算を実行するときに、いつでもボトムアップ計算を実行できます。トップダウン計算とボトムアップ計算の比較は、「ボトムアップ計算の使用」を参照してください。

次の計算方法を使用することを検討してください:

ターゲット・パーティション計算スクリプトにリモート・データへのアクセスが含まれていないことが確実な場合は、計算スクリプトでSET REMOTECALC OFF計算コマンドを使用して、ソース・パーティションからの取得作業を停止できます。
透過的データの親としての「動的計算」メンバー。これにより、データは取得時に即時計算されます。このプロセスにより、バッチ処理時間が短縮されます。 Essbaseは、ユーザーが計算をリクエストした場合にのみ計算を実行します。
低レベルの透過的データと高レベルのローカル・データ間のレプリケート・レイヤー。

次のパフォーマンス戦略を検討してください:

パーティションを計算機キャッシュ領域内に完全に保持します。つまり、パーティション定義の疎メンバーは計算機キャッシュ内に含まれている必要があります。たとえば、Sample.Basicデータベースでは、パーティション定義に@IDESC(East)が含まれている場合、Eastのすべての子孫が計算機キャッシュ内に存在する必要があります。
計算機キャッシュを有効にし、十分な量のメモリーを割り当てます。
パーティションを定義するメンバーでは、複雑な式を使用しないでください。たとえば、Sample.Basicでは、複雑な式をNew Yorkまたは新規Jersey (東部の両方の子)に割り当てると、Essbaseではトップダウン計算メソッドが強制的に使用されます。「ボトムアップおよびトップダウンの計算」を参照してください。

透過パーティションおよびメンバー式

データ・ターゲットとデータ・ソースのアウトラインが異なるメンバー式を除いて同一である場合は、パーティション定義で必要な計算結果が生成されることを確認してください。

たとえば、データ・ソース・アウトラインとデータ・ターゲット・アウトラインの両方に、NorthおよびSouthメンバーを持つMarketディメンションとNorthおよびSouthの子が含まれているとします。データ・ターゲットでは、Marketはデータ・ソースのNorthおよびSouthメンバー(およびその子)のデータから計算されます。データ・ソースのこれらのメンバーのいずれかにメンバー式が含まれている場合、これらの式が計算され、データ・ターゲットのMarketの計算値に影響します。これらの結果は、これらの式が存在しない可能性があるデータ・ターゲットのNorthおよびSouthメンバーからMarketメンバーを計算する方法とは異なる場合があります。

データ・ソースおよびデータ・ターゲットのメンバーに割り当てる式によって、必要な結果が生成されることを確認します。

透過的パーティションおよびポートの使用状況

ユーザーとマシンの一意の組合せごとに1つのポートが使用されます。ユーザーが同じユーザー名を使用して1つのサーバーに複数の透過パーティションを定義すると、1つのポートのみが占有されます。

透過パーティションでは、ユーザー(user1)がソース・データにアクセスするターゲット内の領域にドリルすると、user1はパーティション定義で宣言されたユーザー名(パーティション・ユーザー)を使用してソース・データベースのデータにアクセスします。このアクセスにより、様々なユーザー(user1およびパーティション・ユーザー)がアプリケーションに接続しているため、追加のポートが使用されます。

別のユーザー(user2)がターゲット・データベースに接続し、ドリルダウンしてソース・データにアクセスする場合、user2はパーティション定義で宣言されたユーザー名(パーティション・ユーザー)も使用します。パーティション・ユーザーはすでにソース・データベースに接続されているため、user2が同じソース・データベースにアクセスしているかぎり、パーティション・ユーザーに追加のポートは必要ありません。