0

1,000 文字から 10,000 文字のオーダーの長いテキスト文字列を OLAP キューブに保存したいと思っていますが、これが道に迷ってしまうのではないかと考えています。(また、OLAP エンジンが文字列を処理する方法についてもう少し知りたいと思っています。) 私が念頭に置いている特定のユース ケースは、OLAP ファクトごとに固有の既存の「レコードの説明」があるということです。 DRILLTHROUGH 操作を実行するときにそれらを取得するオプションがあるように、これらの説明をキューブに入れたいと考えています。対照的に、通常のピボット テーブル/集計タイプの操作を行う場合、レコードの説明を表示する必要はありません。(説明が長すぎて、ピボット テーブルにうまく表示できません。さらに、各ファクトには固有の説明があります。つまり、説明を集計しても意味がありません。) 現在のデータセットには約 700 のデータがあります。

これらの長い文字列をキューブに入れると、OLAP サーバーが適切な処理を実行できるようになることを期待していました。特にSql Server / SSASの場合、メモリ使用量を節約するためにROLAPとしてマークされたディメンションにそれらを配置し、退化したディメンション（SSAS用語では「ファクトディメンション」とも呼ばれます）を使用して回避すると思いました不必要な ETL の複雑さ。しかし、これが何らかの理由で恐ろしい慣行と見なされるのか、それとも何か隠れた落とし穴があるのか​​ 、興味があります。

更新: 私の使用例は、各 OLAP ファクトに関連付けられた文字列がある場合です。しかし、文字列が代わりに特定のディメンションの特定の値に関連付けられている場合を考慮することも有益です。(たとえば、Company ディメンションがあり、各会社にやや長い Company Description 文字列があるとします。)

4

4 に答える 4

3

このような文字列を SSAS、特に SSAS 2008 に格納することの意味について、私が発見できたことは次のとおりです。

まず、Business Intelligence Development Studio などの標準の MS ETL (抽出/変換/読み込み、つまりデータ インポート) ツールは、大きなテキスト フィールド、特に varchar(max) フィールドをインポートできないようにしようとする場合がありますが、回避策があり、効果的であることが証明されています。自分。(BIDS の場合、XML ファイルの DataSize 要素を手動で設定する必要があり、163315555 バイトのマジック サイズになる可能性があります。これを理解したMatija Lahに感謝します。)

第 2 に、私が知る限り、長くて一意の文字列を大量に格納しても、SSAS で使用されるディスク上のデータ構造が混乱することはありません。また、ディスク上の文字列データのサイズは、データ ソース内の文字列データと同じ大きさである必要があります。SSAS ハンドル文字列に関する大まかな情報を次に示します。

  • 中核となる OLAP データ構造 (ディメンションの属性やメジャー グループのファクトなど) には、文字列が直接含まれているわけではありません。代わりに、実際の文字列データを含む「文字列ストア」ファイル (拡張子 .ksstore、.asstore、.bsstore、または .string.data) へのオフセットが含まれます。
  • 特定の文字列ストア内で、各文字列は 1 回だけ表されます。ソース データ テーブルの複数の行に重複した文字列が含まれている場合、SSAS/MOLAP レベルでは、重複した文字列値ではなく、重複したファイル オフセットに変換されます。
  • ソース文字列の長さが n の場合、文字列ストア内の対応するデータ構造には 8 バイト程度のオーバーヘッドがあり、1 文字あたり 2*n バイトが加算されます。(文字列は、本質的に SSAS では 2 バイトの Unicode 形式で格納されます。)
  • この件に関する素晴らしい詳細については、本Microsoft SQL Server 2008 Analysis Services Unleashed、特に第 20 章「The Physical Data Model」をお勧めします。
  • 少なくとも私の実験では、文字列ストア ファイルは圧縮されていないようです。少なくとも、圧縮されていない文字列ストアよりも著しく小さいわけではありません。

SSAS MOLAP に保存されている場合でも、SQL テーブルに保存されている場合でも、テキスト データが同じ大きさのバイト数を取ることを実験的に確認しました。特に、ディメンション テーブルの 1 つから "select sum(len(myfield)) from mytable" を実行し、SSAS データ ディレクトリ内の対応する属性のファイルのサイズと比較しました。サイズは SQL で 172MB、S​​QL サーバーで 304MB でした。(一意のものをすべて合計すると、SQL サイズは 147MB でしたすべての文字列ではなく文字列です。) 私の場合、サイズの違いは主に文字エンコーディングによって説明されました。私のソースSQLデータは1文字あたり1バイトで保存されますが、SSASはすべての文字列を1文字あたり2バイトで保存します。AttributeHierarchyOptimizedState=FullyOptimized を使用して属性を最適化したかどうかに関係なく、.kssstore ファイルのサイズが、この属性に関連付けられている他のすべてのファイルのサイズを完全に支配していることがわかりました。

第 3 に、文字列ストア ファイルのサイズには 4 GB の上限があり、特定のディメンションや属性などに関連付けることができる一意のテキストの量が制限されます。私の場合、限界まであと 10% 未満ですが、これは一部の人に影響を与える可能性があります。(元の投稿の簡単な桁数の計算: 1M ファクト * 10,000 バイト/ファクト = 10GB 相当のテキスト。) この制限に達した場合、キューブの「処理」時間で明らかにヒットします。どうやら、ROLAP ディメンションにも適用されるようです。これを回避するためのハックがあるかもしれません。ここを参照してください。Sql Server 2012 では、この 4 GB の制限がなくなる可能性があることに注意してください。

第 4 に、長い一意の文字列が SSAS で問題を引き起こす場合、それらはメモリ内表現のレベルで発生するようです。潜在的な問題の 1 つ (詳しくは調べていません) は、これらの余分な文字列をメモリにキャッシュすると、SSAS が他の重要なデータ構造をメモリに保持できなくなり、パフォーマンスが低下することです。The Microsoft Data Warehouse Toolkitという本で示唆されているもう 1 つの問題(私はまだこの主張を他の場所で見つけていません) は、SSAS がメモリ内のデータ構造に対して拡張的な文字列パディングを行っていることです。

「リレーショナル データベースには、可変長の文字列列が格納されます...ただし、SQL Server ツールセットの他の部分では、これらの列が最大幅まで埋められます。注目すべき点として、Integration Services と Analysis Services は、文字列列がメモリに読み込まれるときに、文字列列をスペースで埋めます。 Integration Services と Analysis Services はどちらも物理メモリを使用するため、必要以上に広い文字列列を宣言するとコストがかかります。」

結論として、これまでのところ、長い文字列データをキューブに格納することは便利だと思われます。また、問題が発生する理由はまだ見つかっていないので、試してみます。うまくいかない場合は、更新を提供しようとします。

于 2011-12-23T20:31:25.373 に答える
1

値をリレーショナルにテーブルに格納してから、整数の代理キーを作成できます。

整数サロゲートを UDM に追加し、SSRS ドリルスルー アクションを作成します

http://msdn.microsoft.com/en-US/library/ms174526(v=SQL.90).aspx

キー値でテキスト フィールドを検索します。

于 2011-12-31T07:48:17.947 に答える
0

縮退ディメンションを使用しますが、ドリルスルー アクションで要求されるまで SSAS で非表示にします。

ASエンジンの文字列の内部ストレージについてはご案内できませんが、それらをSQLに格納することに関しては、SQLエンジンのスキャンを高速化するために、varchar(MAX)列が列の最後にあることを確認します行。

700,000 行で、十分なメモリとディスク I/O があれば、SQL にそれほど負担をかけることはありません。

于 2011-12-23T20:33:33.950 に答える
0

説明されているすべての可能性とリンクはまだありませんが、2007年のこのスレッドは同じトピックであり、かなり関連しているようです:

http://www.sqldev.org/sql-server-analysis-services/discussion-about-how-to-create-a-fact-drillthrough-dimension-the-best-way-34857.shtml

ここで提起された 1 つの新しい可能性は、ファクト テーブルに格納されたテキストを縮退ディメンションとして扱うのではなく、テキスト値 (対数値)メジャーとして扱う可能性があるということです。最初のグーグル検索では、SSAS がこれをサポートしている可能性があることが示唆されていますが、これを正しく行うにはいくつかのトリックがあります。 SSAS エンタープライズ エディションが必要になる場合があります。

于 2011-12-31T23:16:41.213 に答える