6

概要: 私が見た MDX 結合の例のほとんどは、それぞれ数十または数百の項目を持つ、比較的小さなセットの結合を伴います。しかし、それぞれ数千または数万のアイテムを持つセットを結合する (特に「空でない結合」) ことも試してみたいと思っていますが、今のところうまく機能していません。これを機能させることができるかどうか、または Mondrian/OLAP 以外のものを使用することを検討する必要があるかどうか疑問に思っています。

具体的には、会社 (n=7000) とクライアント (n=27000) の間の相互作用を記録するキューブがあります。現在、会社とクライアントはどちらも完全にフラットな階層です。すべてのレベルと個々の会社のレベルがあり、その間に他のレベルはありません。中央のファクト テーブルと、会社用とクライアント用の個別のディメンション テーブルがあります。

私のユーザーは少なくとも、会社とクライアントの間のすべての空ではない対話を集約して、これらの行に沿って要約レポートを取得したいと考えているようです。

select
  [Measures].[Amount] on columns,
  NonEmptyCrossJoin([Firm].Children,
                      [Client].Children) on rows
from MyCube

しかし、このクエリとそのバリエーションは、テスト用の Mondrian セットアップでは機能しません。(2 GB の Java ヒープで) OutOfMemoryException が発生するか、Java が mondrian.rolap.RolapResult$AxisMember.mergeTuple(TupleCursor) で信じられないほど長い時間を費やしているようです。(それが役に立てば、より完全なスタック トレースを提供できます。) 「信じられないほど長い」とは、Java が何時間も何時間もクエリを実行し続けることを意味します。

概念的には、次の行に沿って SQL クエリを実行するだけである程度効率的に実行できるため、最初は上記のクエリが正常に実行されると予想していました。

select Firm, Client, Sum(Amount) as n
from fact, firm, client
where fact.firmid = firm.firmid and fact.clientid = client.clientid
group by Firm, Client

(実際、MySql でこのようなものを直接実行すると、実行に 15 秒もかかりません。)

しかし、デバッグ ログから見ると、Mondrian はこの最適化を試みていないようです。代わりに、内部で結合を行っているように見え、最終的には特に遅くなります。mondrian.properties で mondrian.native.crossjoin.enable=true を設定しましたが、これは Mondrian が「ネイティブにする」ことができる結合タイプの 1 つではないようです。( mondrian.native.unsupported.alert=ERROR をオンにすると、対応する例外が発生します。)

ユーザーがそのような大きな次元/セットで結合を試行するのを防ぐ必要があるのか​​ 、それともMondrianがここで探しているツールではないのか 疑問に思っています. しかし、多分私は何か間違ったことをしているのです。

4

4 に答える 4

2

フォローアップするために、SQL Server Analysis Services（Sql Server 2008）で類似のキューブをセットアップしようとしましたが、icCubeには、さまざまなOLAPツールのパフォーマンスが異なるという点があるようです。

SSASのベストプラクティスについて多くを学ぶ前でさえ、このタイプのMDXのパフォーマンスは大幅に改善されました。これらの行に沿ったクエリ

select
  [Measures].[Amount] on columns,
  NON EMPTY
  crossjoin([Firms].[Firm Name].Children,
            [Clients].[Client Name].Children)
  on rows
from MyCube

Mondrianで実行不可能であったことから、SQLServerで約10秒かかるようになりました。おそらく、これはMSのビジネスインテリジェンス開発スタジオがデフォルトでMOLAPキューブを作成するように案内してくれることと関係があります。あるいは、SSASにはよりスマートなクエリプランナーがあります。

いずれにせよ、おそらくこれは私にとって十分に速いです。そうでない場合、この場合にどれだけ最適化されたSSASを取得できるかはまだわかりません。（残念なことに、クエリを2回再実行しても、約10秒かかります。キャッシュがより劇的な効果をもたらすことを期待していました。）

正直なところ、引用したばかりのMDXで、元のNonEmptyCrossJoinをNONEMPTYと組み合わせた通常のクロスジョインに置き換えたことに気付くかもしれません。これは、少なくともSql Serverの世界では、NonEmptyCrossJoinが非推奨の悪い習慣と見なされているためです。（これは、MicrosoftのMDX言語リファレンスに記載されています。以前のSSAS開発者の1人であるMoshaは、MDXと呼ばれる記事で状況を説明しています：NonEmpty、Exists、evil NonEmptyCrossJoin。短いバージョンでは、NonEmptyCrossJoinのセマンティクスがわかりにくく、アプリケーションが制限されています。SQLServer 2005以降、クエリオプティマイザーは、NonEmptyCrossJoinがなくてもクエリを高速化できるほどスマートになっています。）したがって、上記のMDXで承認された最新の同等のものに置き換えました。 。（NonEmptyCrossJoinは処理をまったく高速化しませんが、NonEmptyCrossJoinでも機能します。）

于 2011-11-30T03:25:22.310 に答える
2

100％確信はありませんが、設定を試しましたか：

mondrian.native.nonempty.enable = true

この最適化は、そのようないくつかの操作をSQLレベルに押し下げるようです-それが役立つように聞こえます.

于 2012-04-02T14:29:16.997 に答える
1

OLAPの部分をお答えします。OLAP ツールには 3 つの大きなファミリがあります。ROLAP、MOLAP、HOLAP。

ROLAP、リレーショナルは、関係データベース上に構築されています。キャッシュが見つからない場合、MDX 要求は、SQL ステートメントを使用してリレーショナル データベースで実行されます。委任によるスケーラビリティの利点がありますが、基礎となるデータベースでのパフォーマンスは依存します。QoS は db QoS であるため、扱いにくい場合があります。

MOLAP、InMemory、データを内部構造 (メモリ) にコピーします。ここでは、すべての処理が同じサーバーで行われるため、QoS (応答時間) がより安定し、高速になります。MOLAP の問題は、メモリ不足 (>100mio) になる可能性があるため、スケーラビリティです。

HOLAP は、ROLAP と MOLAP を組み合わせたものです。私は直接の経験はありませんが、理論的には両方の長所を活かすことができます。

MOLAP ツールで問題にならない数値を見ると、実際には小さな立方体です。

したがって、OLAP の世界を離れる前に、MOLAP サーバーにチャンスを与えてください。OLAP サーバーのリストについては、wikipediaを確認してください。

于 2011-11-20T15:04:54.713 に答える
0

Mondrian OLAPは、大規模なデータベースをサポートしていません。

さて、Javaオープンソースに基づくOLAPツールであるビットマップ結合インデックスOLAPツール（BJIn OLAP）を開発しています。これは、MDXではなくSQL分散構文を使用します。

ここにドキュメント

試用版はこちら

于 2011-12-13T23:34:37.777 に答える