タグ付けされた質問 「data-warehouse」

データウェアハウスモデリングの主要なトポロジ（スター、スノーフレーク）は、1対多の関係を念頭に置いて設計されています。これらのモデリングスキームで多対多の関係に直面すると、クエリの可読性、パフォーマンス、および構造が大幅に低下します。 ディメンション間、またはファクトテーブルとデータウェアハウスのディメンションの間に多対多の関係を実装する方法と、必要な粒度とクエリパフォーマンスに関してどのような妥協がありますか？

25 database-design  data-warehouse 

私の会社では、ETL（extract-transform-load）プロセスを使用する代わりに、ELT（extract-load-transform）プロセスを使用していることに気付きました。 2つのアプローチの違いは何ですか？また、どの状況で一方が他方よりも「良い」でしょうか？いくつかの例を提供できれば素晴らしいと思います。

19 data-warehouse  etl  business-intelligence 

インデックスを使用してデータウェアハウスのパフォーマンスをチューニングしています。私はSQL Server 2014を初めて使用します。Microsoftは次のように説明しています。 「クラスター化された列ストアインデックスは、大規模なデータウェアハウジングファクトテーブルを格納するための標準であり、ほとんどのデータウェアハウジングシナリオで使用されることを期待しています。操作を削除します。」 http://msdn.microsoft.com/en-us/library/gg492088.aspx ただし、ドキュメントをさらに読むと、制限と制限があります。 「一意の制約、主キーの制約、または外部キーの制約を持つことはできません。」 これは私をとても混乱させます！さまざまな理由（データの整合性、セマンティックレイヤーに表示される関係など）のために、データウェアハウスに外部キーを配置することをお勧めします（必須ではありません）。 そのため、Microsoftはデータウェアハウスシナリオのクラスター化列ストアインデックスを推奨しています。ただし、外部キー関係を処理できませんか？！ これは正しいですか？他にどのアプローチをお勧めしますか？過去には、データウェアハウスのシナリオで、クラスター化されていない列ストアインデックスを使用して、データロードのドロップと再構築を行いました。しかし、SQL Server 2014はデータウェアハウスに新しい価値を追加しませんか？

18 sql-server  foreign-key  data-warehouse  sql-server-2014  columnstore 

使用している場合、システムバージョン管理一時テーブル（SQL Serverの2016年新）が、この機能は大規模なリレーショナルデータウェアハウス内の寸法を変更ゆっくり処理するために使用されるクエリのオーサリングおよびパフォーマンスの意味は何ですか？ たとえば、列を含む100,000行のCustomerディメンションと、外部キー列Postal Codeを含む数十億行のSalesファクトテーブルがあるとしCustomerIDます。そして、「顧客の郵便番号別の2014年の総売上」をクエリしたいとします。簡略化されたDDLは次のようなものです（わかりやすくするために多くの列を省略しています）。 CREATE TABLE Customer ( CustomerID int identity (1,1) NOT NULL PRIMARY KEY CLUSTERED, PostalCode varchar(50) NOT NULL, SysStartTime datetime2 GENERATED ALWAYS AS ROW START NOT NULL, SysEndTime datetime2 GENERATED ALWAYS AS ROW END NOT NULL, PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime) ) WITH (SYSTEM_VERSIONING = ON); CREATE …

17 sql-server  data-warehouse  slowly-changing-dimension  sql-server-2016  temporal-tables 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 この質問はまだ聞かれていないのだろうか。Googleでは、高品質のツールを表示しない結果が非常に少ない データウェアハウス、より具体的にはビジネスインテリジェンスツール向けのオープンソース（無料でも構いません）ソリューションとは何ですか？それらとのあなたの経験は何ですか。私は修士課程でコースを受講しており、MS Business IntelligenceとMSSQLをデータウェアハウスストレージとして使用しました。ここで、「オープン」なツールを使用して、このトピックについて詳しく説明します。 ビジネスインテリジェンス（ほとんどデータベースに依存しない）用の比較可能なツールはありますか？ 編集ステファニーの答えに対するマリアンのコメントで、私は質問を間違って定式化したことがわかります。DWHは単なる「レポート用に最適化された」データベースであることを認識しています。Stephanieの説明はそれについて非常に明確でした。WHATの種類のBIソフトウェア/ツール/その他の手法を使用して、データをこのような最適化されたフォームに取り込む方法に興味があります。

16 tools  data-warehouse  database-agnostic  business-intelligence 

私は時折、公開されているデータセットをPostgres dBの形式でダウンロードします。これらのデータセットは、リポジトリホストによって時間の経過とともに更新/変更/拡張されます。 古いと新しいPostgresデータベースの違いを表示できるPostgresコマンドまたはツール（理想的にはFOSS）はありますか？（動作する前提は、エントリの95％が変更されておらず、テーブルと関係も変更されないことです）。

13 postgresql  data-warehouse 

APIリクエストログを保存するために、大きなデータウェアハウスで動的なフィールドと値をサポートする必要があります。私のユーザーケースは、すべてのAPIリクエストクエリ文字列を保存し、将来それらに対してクエリを実行できるようにすることです（したがって、単なるストレージではなく、だから私は彼らのためにブロブを使用することはできません） 例えば http://example.com/?action=test&foo=abc&bar=def... すべてのfield => valueマッピングを保存する必要があります。つまり(action => test), (foo => abc), (bar => def)、フィールドは非常に動的であるため、私が見つけた唯一の解決策はEntity-Attribute-Valueを使用することですが、人々は非常に悪いデザインだと言い続けています。 それで、上記の私のユースケースを考えてください、EAVに適した代替物は何でしょうか？ KAVを使用した現在のスキーマ テーブルrequests (id, timestamp, uri) 例(1, 149382220, '/') テーブルparams (request_id, key, value) 例(1, 'action', 'test'), (1, 'foo', 'abc'), (1, 'bar', 'def') 助言がありますか？ 更新：AWS RedShiftでウェアハウスを実行します

13 database-design  data-warehouse  eav  star-schema  redshift 

私の分析に基づいて、データウェアハウスの完全な次元モデルでは、200を超えるソーステーブルから抽出する必要があります。これらのテーブルの一部は増分ロードの一部として抽出され、他のテーブルは全ロードになります。 注目に値するのは、すべて同じスキーマを持つ約225のソースデータベースです。 私が見てきたことから、OLE DBソースとOLE DB宛先を使用してSSISで単純なデータフローを構築するには、設計時に列とデータ型を決定する必要があります。つまり、最終的には抽出だけのために200以上のデータフローが発生することになります。 保守性の観点から、これは大きな問題として私を襲います。抽出コードに何らかの抜本的な変更を加える必要がある場合、200の異なるデータフローを変更する必要があります。 代替オプションとして、メタデータテーブルのセットから抽出するソースデータベース、テーブル名、および列を読み取る小さなスクリプトを作成しました。コードは複数のループで実行され、動的SQLを使用して、リンクサーバーとOPENQUERYを介してソーステーブルから抽出します。 私のテストに基づいて、これはまだOLEDBのソースと宛先でSSISデータフローを使用するほど高速ではありません。だから私は私がどんな種類の選択肢を持っているのかと思っています。これまでの考えは次のとおりです。 EZAPIを使用して、シンプルなデータフローでSSISパッケージをプログラムで生成します。抽出するテーブルと列は、前述の同じメタデータテーブルから取得されます。 サードパーティソフトウェア（動的データフローコンポーネント）を購入する これにアプローチする最良の方法は何ですか？.NETプログラミングに関しては、私は初心者なので、基本だけで立ち上がるのに必要な時間も心配です。

12 sql-server  sql-server-2005  ssis  data-warehouse  etl 

SQL Serverに200 GBのデータウェアハウスがあります。 一部のクエリの実行時間が非常に遅くなっています。たとえば、をdelete使用した単純なクエリの場合は12時間ですinner join。 実行計画でいくつかの調査を行った後、WITH FULLSCANオプションを使用して、クエリに関連する2つのテーブルの統計を更新しました。 クエリは1秒未満で実行されるようになったため、統計は最新ではなかったようです。 auto update statisticsデータベースを無効にしてUPDATE STATISTICS、データウェアハウスの読み込み後に手動で実行することを検討しています。データウェアハウスは、ソースERPシステムから毎日、夜間に段階的に読み込まれます。 auto update statisticsデータウェアハウジングシナリオでは本当に役に立たないと想定しても正しいですか？代わりに、データのロード後に統計を手動で更新する方が理にかなっていますか？

12 sql-server  data-warehouse  statistics 

私たちはデータマート/倉庫のビルディングブロックを設計し始めており、すべてのタイムゾーンをサポートできる必要があります（私たちのクライアントは世界中から来ています）。オンライン（および本）でのディスカッションを読むと、一般的な解決策は、ファクトテーブルに日付と時刻の個別のディメンションとタイムスタンプを持つことです。 しかし、私が答えるのに苦労している質問は、動的なタイムゾーンの要件を考慮すると、日付と時刻のディメンションが実際にどのように役立つかです。時間ディメンションはもう少し理にかなっていますが、日付ディメンションで苦労しています。日付ディメンションの一般的な設計アプローチには、通常、曜日名、曜日、月名などのプロパティが含まれます。私が抱えている問題は、2013年12月31日火曜日の午後11時（UTC）が水曜日であることです。 、2014年1月1日、UTC + 2以降のすべてのタイムゾーン。 したがって、すべてのクエリ（およびレポート）でこれらすべてのタイムゾーン変換を行う必要がある場合、おそらく使用しない（これらのプロパティのように）これらのプロパティを保持して保存することの意味は何ですか？一部の人々は、タイムゾーンごとにファクト行を持つことを提案しますが、それは私にはばかげているようです。毎月何百万ものレコードを保存できる必要があります。 他の人は、タイムゾーンブリッジテーブルを使用することをお勧めします。これは、ある程度の意味がありますが、クライアントアプリとレポートが日付から簡単に理解できるはずのことを達成するための追加の複雑さと結合のようにも見えます（レポートは主にWebベースになります）日付の変換、表示、およびフォーマットを支援する無数のライブラリがあります）。 私が考えることができる唯一のことは、日付と時間でグループ化することの容易さとおそらくパフォーマンスですが、日付部分でグループ化することはどれほど悪いことですか（MS SQLを使用していますが、数百万の行をクエリすることになります）、または考慮する必要があります月曜日などのほとんどのリテラルはタイムゾーンが機能するときにあまり意味がないので、ほとんどの場合、時間、日、月、年の数以下の非常に単純な日付と時刻のディメンションですか？

12 sql-server-2012  data-warehouse  datetime  timezone 

私が読んだSQL Serverのデータ圧縮に関するいくつかの文献では、書き込みコストが通常必要なものの約4倍に増加すると述べています。また、これがデータ圧縮の主な欠点であることを暗示しているようです。読み取り専用アーカイブデータベースの場合、100％埋められたページのデータ圧縮を使用すると、パフォーマンスが（ほとんど例外なく）向上することを強く意味します。 上記の説明は正しいですか？ データ圧縮とそれ以外の場合の主な「違い」は何ですか（読み取り用） 「CPU + x％」？ 「IO -y％」？ ページ分割発生？ tempdbの使用法？ RAM使用量？ そして書くために？ この質問のために、コンテキストを大きな（> 1TB）データベースのページレベルの圧縮に制限できますが、追加のコメントはいつでも歓迎します。 参照： SQL Serverストレージエンジンブログ（DWシナリオは圧縮が非常に有利であることを示しています） データ圧縮：戦略、容量計画、およびベストプラクティス 圧縮対象を決定するためのより詳細なアプローチには、各テーブルとインデックスのワークロード特性の分析が含まれます。次の2つの指標に基づいています。 U：特定のテーブル、インデックス、またはパーティションに対する更新操作の、そのオブジェクトに対する合計操作に対する割合。Uの値が低い（つまり、テーブル、インデックス、またはパーティションが頻繁に更新されない）ほど、ページ圧縮の候補として適しています。 S：そのオブジェクトに対する操作の合計に対する、テーブル、インデックス、またはパーティションに対するスキャン操作の割合。Sの値が大きいほど（つまり、テーブル、インデックス、またはパーティションがほとんどスキャンされる）、ページ圧縮の候補として適しています。 上記の両方は、DWスタイルのデータベース（読み取り集中型/排他型のビッグデータ操作）のページ圧縮を推奨する方向に明らかに偏っています。

11 sql-server  sql-server-2012  data-warehouse  compression 

PostgreSQLは非常に新しいので、これを使用して大規模な展開を行ったことはありません。しかし、私はエンタープライズソリューションの経験が豊富で、PostgreSQLを使用して学んだことの一部を試して適用したいと思っています。 大量のデータとトラフィックを処理できるサイズのサイトがあります。インフラストラクチャは、EC2インスタンスとEBSボリュームを使用してAmazon（AWS）で構築されます。 設計には、分析とレポートを処理するための2つのデータベース、メイントランザクションデータベースとデータウェアハウスが必要です。 メインのトランザクションデータベース ライブWebサイトに使用されます。サイトは複数のノードで構築され、同時ユーザーをスケールアップします。このケースでは、主にデータベースの読み取り操作が非常に高速であることが必要です。100GBを超えるデータで年間30％の成長が見込まれます。この時点で、2つのEC2サーバーを使用する予定です（必要に応じて後で追加します）。 私の質問、上記の要件の推奨設定は何ですか？さらに、テーブルとボリュームのパーティション分割を管理する方法はありますか？AWSセットアップの使用に関する推奨事項はありますか？ データウェアハウスデータベース 主に、時間ディメンションでメインのトランザクションデータベースからすべてのデータをキャプチャするために使用されます。そのため、メインデータベースから削除されたレコードでもDWHにキャプチャされます。したがって、データは非常に大きくなり、成長はさらに大きくなります。必要に応じて、EC2インスタンスのカップル以上も使用します。 この場合の推奨設定は何ですか？定数書き込み（ETL）のため、高速書き込み操作が必要になります。PostgreSQLでOLAPキューブを構築できますか？はいの場合、誰かが試してみましたか？ データベースに接続する Webサーバーはメインデータベースに接続してクエリと書き込みを行います。現在、接続にネイティブライブラリを使用するdjangoを使用するアプリケーションを開発しています。同じ基本的な方法を使用することをお勧めしますか？または、pgpoolを設定する必要がありますか？ データウェアハウス（ETL） メインから読み取り、データウェアハウスに読み込むETLプロセスを構築するための推奨される方法は何ですか？ツールはありますか？従うべき方法論？PostgreSQLはETLプロセスの構築に役立つ機能/ツールを提供していますか？

11 postgresql  data-warehouse  etl 

Oracle Exadata（11gR2）では、データベースは比較的頑丈です。 cpu_countは24です parallel_server_instancesは2です parallel_threads_per_cpuは2 Oracle Enterprise Manager（OEM）での観察により、クエリが連続して実行されるためパフォーマンスがひどいことに気付きました。これを解決するために、すべてのテーブル、マテリアライズドビュー、およびインデックスが、並列処理を利用するように変更されました。例えば： ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT); 並列化をオンにするようにシステムが変更されました。 ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO'; これによりパフォーマンスが向上しましたが、1つのクエリでDOPが96（利用可能なすべてのリソース）になることがOEMで時々観察されました。これにより、後続のクエリが1のDOPにダウングレードされました（並列化なし）。クエリの処理が完了するまでパフォーマンスが低下します。 これを解決するために、クエリで利用できるDOPを次のように制限しようとしました。 ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24; これは効果がありませんでした。制限（通常は48または96ですが、実際のパターンはありません）を超えるクエリを頻繁に確認します。 単一のクエリが使用可能なすべてのリソースを占有するのをどのように防ぐことができますか？

11 oracle  data-warehouse 

多くのタイムゾーンのデータに対するレポートをサポートするデータウェアハウスの設計を最適化しようとしています。たとえば、アクティビティを1日の時間でグループ化して表示する必要がある、1か月分のアクティビティ（数百万行）のレポートがあるとします。そしてもちろんその日の時間は与えられたタイムゾーンの「ローカル」時間でなければなりません。 UTCと1つの現地時間をサポートしたときにうまく機能するデザインがありました。UTCおよび現地時間の日付と時刻のディメンションの標準設計、ファクトテーブルのID。ただし、100以上のタイムゾーンのレポートをサポートする必要がある場合、そのアプローチは拡張されないようです。 ファクトテーブルは非常に広くなります。また、レポートの特定の実行でグループ化に使用する日付と時刻のIDを指定するSQLの構文の問題を解決する必要があります。おそらく非常に大きなCASEステートメントでしょうか？ カバーしているUTC時間範囲ごとにすべてのデータを取得し、それをプレゼンテーションレイヤーに戻してローカルに変換してそこで集計するといういくつかの提案を見てきましたが、SSRSを使用した限られたテストでは、非常に遅くなることが示唆されています。 私はこの主題についてもいくつかの本を調べましたが、それらはすべて、UTCがあり、ディスプレイで変換するか、UTCと1つのローカルがあると言っているようです。任意の考えや提案をいただければ幸いです。 注：この質問は「データマート/倉庫でのタイムゾーンの処理」に似ていますが、その質問についてはコメントできません。 更新： Aaronが重要な更新を行い、サンプルコードと図を投稿した後、私はAaronの回答を選択しました。彼の回答に対する私の以前のコメントは、回答の元の編集を参照しているため、あまり意味がありません。必要に応じて戻ってきてこれをもう一度更新しようとします

10 sql-server  database-design  data-warehouse  reporting  timezone 

100TBのレポートデータベースセットアップの「エンベロープのバック」計算に取り組んでいます。私はここの専門家からの考えを探しています。提案された環境： ストレージ容量〜100TB テーブル〜200、サイズは1GB〜5TB。平均サイズは100 GB〜200 GB ETL-ジョブは、数千万行のテーブル間の結合を必要とする場合があり、結合キーの範囲は10バイトから500バイトです。このような結合は2〜5分以内に完了します ライブ選択-最初は、選択速度のみに関心があります。500選択/秒をサポートする必要があります。1秒あたりの更新数は比較的はるかに少なく、この演習では無視できます。 24時間365日の可用性が必要です。選択した呼び出しに対応するために、2つの独立したDBサーバーを使用できる必要があります（データが複製されます）。 質問： 現在、私はOracleを見ています。大規模なデータベースのための他の商用（または）オープンソースソリューションについて、どのように経験しましたか？ どのハードウェアOSが最も効果的だと思いますか？Linux on Dellを計画しています。 NetAppなどのネットワークストレージは必須ですか？市販のディスクを使用する場合、どのような問題が予想されますか？ ハードウェアとOSの準備ができたら、DB、ストレージなどのセットアップ、構成にどれくらいの時間を確保しますか。 観察した環境で最もよく機能したチーム構成はどれですか。つまり、そのようなセットアップを管理および操作するために必要なさまざまな管理者（OS管理者、Oracle DB管理者？）です。24時間年中無休の稼働時間を実現するために必要な数 DBライセンス、ネットワークストレージコストに関する任意の概算/範囲。 私はすべての環境の詳細を持っていないことを知っています。正確な詳細を探すのではなく、概算で十分です。一部の質問にはマネージャーが最もよく答える可能性がありますが、私は管理者の観点に興味があります。ご意見をお待ちしております。

10 oracle  database-recommendation  data-warehouse