誰でもOLAP Internalsについて知っていますか？

Question

私はデータベース内部について少し知っています。私は実際に、ディスクとBTreeのインデックス上のISAM構造を使用し、すべてのそのようなものを使用する前に、小さな、単純なリレーショナルデータベースエンジンを実装しました。それは楽しく、とても教育的でした。私は、データベーススキーマを慎重に設計し、問合せを作成することについて、RDBMSがどのように機能するかについてもう少し分かりました。

しかし、私は、多次元OLAPデータモデルについて何も知らない、と私はつらい時、インターネット上の任意の有用な情報を見つけることがありました。

どのように情報がディスクに保存されていますか？どのデータ構造がキューブを構成していますか？ MOLAPモデルでテーブルと列とレコードを使用していない場合は、何ですか？特に高次元のデータでは、どのような種類のデータ構造がMOLAPモデルを効率的にするのですか？ MOLAP実装はRDBMSインデックスに類似したものを使用しますか？

なぜアドホッククエリを処理するにはOLAPサーバーの方がずっと優れていますか？通常のリレーショナルデータベースで処理する時間をとする同種の集計は、OLTPキューブでミリ秒単位で処理できます。それを可能にするモデルの根本的な仕組みは何ですか？

Answer 1

は私が何をすべきかOLAPキューブmimicedシステムのカップルを実施し、ここで私たちがやった事のカップルは、彼らが仕事を得るためにあるきました。

1）コア・データは、すべてのメモリでは、N次元のアレイに保持し、そして全てのキーが元の配列へのポインタの階層を介して実施されました。このようにして、同じデータに対して複数の異なるキーセットを持つことができます。配列内のデータはファクト表と同等であり、しばしば2つのデータしか持たないことがありました。ハードコアポインタ演算の多くが、それは働いていた - それが作成された後、我々はメモリを節約するために、すべての空白セルを削除するために使用して

2）基本的な配列は、多くの場合、スパースました。

3）キーの階層があるので、簡単に階層をドリルアップ/アップするためのルーチンを簡単に書くことができます。たとえば、私たちはデータの年にアクセスし、月のキーを経て日や週にマップします。各レベルでは、キューブ製の計算をより迅速に構築するための一環としてデータを集計します。

4）クエリー言語を実装していませんでしたが、私たちはすべての軸（最大の立方体で最大7個）のドリルダウンをサポートしており、ユーザーが好きなUIに直接結びついていました。

5）私たちは、C++でコアのものを実装しますが、これらの日、私はC＃は十分速いかもしれないが、私はスパース配列を実装する方法を心配したい数えます。

希望は、面白いと思います。

Answer 2

まとも詳細にSSAS 2008の特殊性のいくつかを綴るMicrosoft SQL Server 2008 Analysis Services Unleashedブック。 「ここでSSASがどのように機能するかはまったく正確なものではありませんが、特にデータ構造側では示唆的です。 （正確なアルゴリズムについては詳細な/具体的ではありません）この分野のアマチュアとしての私のいくつかは、この本から集められました。

• 多次元キューブ、ファクトテーブル、データがまだある（別名グループを測定する）最初の近似に対して、最終的には基本的に2次元のテーブルに格納され、事実ごとに1行についてのすべての話にもかかわらず、これは、すべてのSSASのMOLAP程度であります。多くのOLAP操作は、最終的には2D表の行を反復することで構成されています。
• MOLAP内のデータは、対応するSQLテーブル内よりもはるかに小さい可能性があります。 1つのトリックは、それぞれの一意の文字列が「文字列ストア」に一度だけ格納されることです。データ構造は、よりコンパクトな形式の文字列を参照することができます（基本的には文字列IDによって）。また、SSASは、MOLAPストア内の行を何らかの形で圧縮します。この縮小することは、より多くのデータをRAMに同時に保存できることを意味します。これは良いことです。
• 同様に、SSASは、完全なデータセットではなく、データのサブセットを反復処理することがよくあります。
  • デフォルトでは、SSASは各ディメンション/属性値のハッシュインデックスを作成します。したがって、ディスク上のどのページに、例えば年= 1997の関連データが含まれているかを「すぐに」知ることができます。
  • データの関連するサブセットがデータセット全体とは別のRAMに格納されるキャッシュアーキテクチャがあります。たとえば、フィールドの数が少なく、1997年のデータにしか関係しないサブキューブをキャッシュしている可能性があります。クエリが1997年についてのみ質問している場合、そのサブキューブ上でのみ繰り返されるため、処理が高速化されます。
  • あらかじめ定義された集約である場合、これらのより小さいサブセットは、単に計算/キャッシュされるのではなく、キューブ処理時に事前計算されることもあります（ただし、「サブキューブ」は最初の近似では2次元テーブルです）。オンデマンド。
• SSASファクトテーブルの行は固定サイズであり、おそらく何らかの形で役立ちます。 （SQLでは、可変的な文字列列を使用することもできます）
• キャッシュアーキテクチャは、集計が計算されると、ディスクから再フェッチする必要はなく、何度も再計算する必要があります。

これは、とにかくSSASでのいくつかの要因です。私は、他にも重要なことはないと主張することはできません。