29

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

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

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

OLAP サーバーがアドホック クエリの処理に優れているのはなぜですか? 通常のリレーショナル データベースでは処理に数時間かかる可能性のある集計と同じ種類の集計が、OLTP キューブでは数ミリ秒で処理できます。それを可能にするモデルの根底にあるメカニズムは何ですか?

4

2 に答える 2

20

私は OLAP キューブの機能を模倣したシステムをいくつか実装しました。これらを機能させるために行ったいくつかのことを次に示します。

  1. コア データはすべてメモリ内の n 次元配列に保持され、すべてのキーは基になる配列へのポインターの階層を介して実装されました。このようにして、同じデータに対して複数の異なるキーのセットを持つことができます。配列内のデータはファクト テーブルと同等で、多くの場合、2 つのデータしかありません。ある例では、これは価格と販売数でした。

  2. 基礎となる配列はしばしばまばらだったので、いったん作成されたら、メモリを節約するためにすべての空白セルを削除していました - 多くのハードコアなポインター演算ですが、うまくいきました。

  3. キーの階層があったので、ルーチンを非常に簡単に記述して、階層を簡単にドリルダウン/ドリルアップできました。たとえば、月のキーを使用して年次のデータにアクセスし、それを日および/または週にマップします。各レベルで、キューブの構築の一環としてデータを集計し、計算を大幅に高速化しました。

  4. クエリ言語は一切実装していませんが、すべての軸 (最大のキューブで最大 7 つ) のドリルダウンをサポートしており、ユーザーが好む UI に直接関連付けられていました。

  5. コア部分は C++ で実装しましたが、最近では C# で十分高速になる可能性があると考えていますが、スパース配列を実装する方法について心配していました。

お役に立てば幸いです。興味深いですね。

于 2009-04-10T05:04:42.990 に答える
6

本Microsoft SQL Server 2008 Analysis Services Unleashedでは、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 で作用する要因の一部です。他にも重要なものがないとは言えません。

于 2012-01-27T03:30:20.783 に答える