Oracle OLAPオプションを試してみようと考えています。誰でも経験を共有できますか?このテーマに関するディスカッションやブログ活動はあまり見つかりませんでした。特に、私はさまざまな期間にわたる多次元データ(数百の列)とフィルターを使用したレポートに関心があります。したがって、OLAPキューブが内部で実行する事前集計によって、かなりのパフォーマンスが得られるかどうかが心配です。洗練されたフィルタリングの存在下でブーストしますか?
これが私が話しているクエリの例です:
列Bの値が[1、n] OR列Cの値)の範囲にあるテーブル内のすべての人について、過去3年間の月ごとに集計された列Aの平均値を教えてください過去3か月の範囲[1、m]。
OLAPは本当にそのような複雑なクエリを事前に集約することができますか?
また、どのようなパフォーマンスを提供しますか?利用可能な興味深いベンチマークはありますか?
Oracle OLAPオプションは非常にうまく機能します。これはデータベースに隠された宝石であり、すべてのOracleデータベースベースのBIおよびDWソリューションの一部であるべきだと多くの人が認識しているわけではありません。これは新しいサーバー。1970年代初頭から存在しているため、Oracleデータベースよりもさらに古いです。Oracleは1995年に購入し、バージョン9.2以降のデータベースに「埋め込み」ました。
最新バージョンは11.2.0.2です(これを強くお勧めします)。古いバージョンにはいくつかの問題がありました。
いくつかの便利なリンクは ここ
BI/DW環境でのOracle OLAPオプションの使用に関する追加のコメント。
(1)。すべてのデータ/計算はOracleデータベース内にあります。
(2)。すべてのディメンションのすべてのレベルで自動的に機能する単純な分析構文を使用して、キューブ内でどれほど複雑な計算(または計算されたメジャー)を作成できるかは関係ありません。
(3)。ディメンション計算(または計算されたメンバー)は、OBIEEのCalculated-Item機能によって実行するか、データベース内に「プッシュ」して、より複雑なディメンション計算を非常に簡単に処理できます。
(4)。あらゆるタイプの階層(レベルベースまたは親子)を処理できます。
(5)。データは、OLAP_TABLE関数またはCUBE_TABLE関数を使用したSQLクエリを通じて取得されます。
(6)。アドホックレポートのクエリ応答時間を短縮します。
(7)。 OracleのOBIEE(11.1.1.5以降のリリース)を使用している場合、生成されるクエリは単純なSELECT ... FROM..WHERE種類のクエリです。他のレポートツールを使用しても、「リレーショナル」側で行うことはあまりないため、クエリは単純なクエリです。
(8)。要件に応じて、次の機能を簡単に提供できます。ドリルスルーから詳細(集約キューブからリレーショナルトランザクションまで)OR同じレポートでリレーショナルデータとキューブデータを組み合わせる。
(9)。 Oracleデータベースリソースを使用するため、スケーラブルでキューブの構築を高速化し、数百または数千のユーザーを処理できます。
(10)。クエリとキューブのビルドを監視するために、非常に広範なロギング機能が(Oracle DBA用に)すぐに提供されます。これは、DBAが使用する通常の機能(ASH、AWR、OEMなど)に追加されます。
(11)。追加のハードウェアやDBAは必要ありません(他のOLAPサーバーとは対照的に)。
(12)。 1つのキューブで、数十から数十のMVとサマリーテーブルを置き換えることができます。キューブ内では、データはすべてのディメンションのすべてのレベルに存在します。
2005年頃にOracleを評価したとき、主に当時のフロントエンドツールからのサポートが不十分だったため、Oracle OLAPに少し戸惑いました(Discoverer'Drake 'にはドリルスルーサポートがありませんでした。そして、サードパーティのツールからのサポートは事実上ありませんでした。)結局、そのプロジェクトはMSAnalysisサービスを使用しました。
@ALiの投稿は、現在OBIEEからのサポートがあることを示唆しているので、そのライセンスを持っている場合は、おそらくかなりフレンドリーなフロントエンドをキューブに配置できます。やや活気にあふれていますが、彼の主張は基本的に健全です。
あなたの質問に答えて:
OLAPサーバーでは、比率や、ランニングサム、YTD、ローリングウィンドウなどのスマートロールアップを含む、計算されたメジャーを定義できます。比率の計算は、分子と分母の値を集計し、表示しているスライスの集計に基づいて比率を計算することで機能します。組み込み計算は、テクノロジーとしてのOLAP)のユニークなセールスポイントの1つです。
OLAPサーバーでWHERE EXISTS
とほぼ同等のことをしようとしています。パラダイムが少し異なるため、これはやや注意が必要です。実際には、ほとんどのOLAPクエリ言語には、セットを操作するための多くの演算子があります。条件に一致するユーザーのセットを計算し、それをクエリの軸の1つで使用することができます。クエリを記述したり、セットの操作を伴う中間段階を実行したりすることなく、エンドユーザーツールのポイントアンドクリックフロントエンドを介してそれを行うことはできません。
エンドユーザーツールを使用すると、スライスアンドダイスクエリ操作が簡単になりますが、より複雑なクエリは直接サポートされませんが、多くの場合、手書きのクエリを入力できます。
OLAPサーバーは、事前に集計されたデータのロールアップを計算して保持します。集計の1つからクエリを満たすことができる場合、サーバーは基本データの代わりにそれを使用します。事前に集約されたロールアップのこの使用は、OLAPサーバーの高速クエリパフォーマンスの背後にある主な理由の1つです。
キューブ上の集計が正しく調整されていれば、ほとんどのクエリに非常に迅速に答えることができるはずです。ただし、OLAPサーバーで集計を調整することは、少し芸術的な形式です。パフォーマンスは集計に大きく依存するため、クエリパフォーマンスのベンチマークはやや無意味になります。
@ MK01 ...シナリオはOracle OLAPキューブを作成してアドホックレポートを処理するための完全なユースケースです。すべてのOracleBI/DWシステムにはOracle OLAP =設計の一部として(またはDW集約戦略の一部として)キューブ。以前の投稿にはいくつかの有用なリンクがありました。それらのリンクを参照してください。OracleOLAPフォーラムも@- https://forums.Oracle.com/forums/forum.jspa?forumID=16
キューブの更新がはるかに高速になりました。ユーザーがキューブからクエリを実行している場合でも、Oracle OLAPキューブ(バージョン11.2.0.2以降)を1日に複数回非常に迅速にロード/更新することもできます。ダウンタイムはありません。
@ConcernedOfTunbridgeWells ..... Oracleデータベースの11.2.0.2バージョンでは、キューブのチューニングがはるかに簡単になりました。圧縮キューブとコストベースの集計により、すべてのディメンションを「スパース」ディメンションとして設定し、事前計算の%ageを35%に設定するだけで、OLAPエンジンがその魔法を実行します。もう1つの優れたクエリパフォーマンスの向上は、自動の「LOOP OPTMIZATION」手法です。この手法では、データが存在するディメンションの組み合わせのみをループするようになりました。これはすべて内部です。
計算メジャーの作成が簡単になりました。 OLAP dml言語は必要ありません。代わりに、SQL分析構文を使用してOLAP計算されたメジャーを作成します。
要するに、Oracle OLAPキューブは、10gOLAPまたは11.1バージョンのデータベースと比較して、11.2.0.2バージョンでのロードとクエリの両方に関して非常に効率的です。
私のOLAPディスカッションのキーワード(私は何度も繰り返します)は「SIMPLICITY」です。
。