OLAP Internals について何か知っている人はいますか?

Question

データベースの内部構造については少し知っています。実際、私は以前、ディスク上の ISAM 構造や BTree インデックスなどを使用して、小規模でシンプルなリレーショナル データベース エンジンを実装したことがあります。楽しかったし、とても勉強になりました。RDBMS が内部でどのように動作するかについて少し理解できたので、データベース スキーマを注意深く設計し、クエリを作成することについて、より理解できるようになりました。

しかし、私は多次元 OLAP データ モデルについては何も知らず、インターネット上で有益な情報を見つけるのに苦労しました。

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

OLAP サーバーはなぜアドホック クエリの処理においてこれほど優れているのでしょうか?必要となる可能性のある同じ種類の集計 時間 通常のリレーショナル データベースで処理する処理が、OLTP キューブではミリ秒単位で処理できます。それを可能にするモデルの基礎的な仕組みは何ですか?

Answer 1

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

1）コア・データは、すべてのメモリでは、N次元のアレイに保持し、すべてのキーは、下にあるアレイへのポインタの階層を介して実施されました。このように、私たちは、同じデータのキーの複数の異なるセットを持つことができます。配列内のデータは、多くの場合、それだけで、これは販売価格と番号だった1例では、データのカップルを持っているだろう、ファクトテーブルの同等だった。

2）基本的な配列は、多くの場合、スパースだったので、それを作成した後、私たちは、メモリ節約するために、すべての空白セルを削除するために使用 - ハードコアポインタ演算の多くをが、それは働いていた。

。 私たちは、キーのheirarchiesを持っていたとして

3）、我々は簡単に階層をダウン/ドリルアップするために非常に簡単にルーチンを書くことができます。たとえば、私たちは順番に日および/または数週間にマッピングされた数ヶ月キー、経由することで、データの年にアクセスします。各レベルでは、我々は、キューブ構築の一環としてデータを集計う - 。ずっと速く計算を

4）私たちは、クエリ言語のいずれかの種類を実装していませんでしたが、我々はサポートが私たちの最大のキューブで7件までのすべての軸（上ドリルダウンしなかった）、そしてそれは、ユーザーが気に入ったUIに直接接続した。

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

数えます

面白い音、お役に立てば幸いです。

Answer 2

本 Microsoft SQL Server 2008 分析サービスの解放 SSAS 2008 の特徴のいくつかを詳細に説明しています。これは、「SSAS が内部でどのように動作するかを正確に説明します」というものではありませんが、特にデータ構造の面で非常に示唆的です。(正確なアルゴリズムについてはそれほど詳しく/具体的ではありません。) この分野のアマチュアである私がこの本から集めたもののいくつか。これは SSAS MOLAP に関するすべてです。

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

いずれにせよ、これらは SSAS に関係する要因の一部です。他にも重要なものがないとは言えません。