問題タブ [data-warehouse]

かなり大きなデータベースを持つ必要がある新しいプロジェクトを開始しようとしています。

テーブルの数は多くなく (<15)、データの大部分 (99%) は 1 つの大きなテーブルに含まれ、ほとんど挿入/読み取り専用 (更新なし) です。

その 1 つのテーブルの推定データ量は 1日あたり 500.000 レコードで増加し、さまざまなレポートを作成できるように少なくとも1 年間保持する必要があります。

バックアップ/フェールオーバーとして(読み取り専用)複製されたデータベースが必要であり、ピーク時にレポートをオフロードする場合もあります。

私はそのような大規模なデータベースを実際に使用した経験がないので、この状況でどの DB が最適な選択であるかを尋ねています。私はOracleが安全な賭けであることを知っていますが、同様の設定でPostgresqlまたはMysqlを使用した経験がある人にはもっと興味があります。

比較的小規模なデータ ウェアハウス システムに使用する無料のデータベースはどれですか?

自由に利用できる多次元データベースなど、「特別な」データベースはありますか?

無料のリレーショナル データベースのうち、この仕事に最も適しているのはどれですか?

データ ウェアハウス システムとは、いくつかの挿入、いくつかの更新、ほとんどの削除、および多くの複雑な選択を受け取るシステムを意味します。スター スキーマで構造化されている (データベースがリレーショナルの場合)。

小規模とは、メインのファクト テーブルに約 100.000 レコード、おそらく 10 ディメンション、最大で 5.000 レコードを含むことを意味します。

無料であること。つまり、内部の商用利用は無料です。

編集：これまでのところ、ほとんど無料のデータベースのリストしか取得していないため、興味深い/必要な機能をいくつか指定させてください。

• 外部結合 (必須)
• inlineviews / subselects (ほぼ必須)
• マテリアライズド ビュー (いいですね)
• スマート クエリ オプティマイザー (スマートであるほど良い)
• ディメンション、ロールアップ、キューブ クエリのサポート (いいですね)
• 分析関数 (これはオラクルでの名前です。他のデータベースでどのように名前が付けられているかはわかりません) (いいですね)

ソース テーブルからデータを入力するキューブがあります。データを反映させるために、「分析サービス処理タスク」コンポーネントを呼び出しています。キューブが更新されている間、次のエラーが発生します。

説明: OLE DB エラー: OLE DB または ODBC エラー: 通信リンク障害。08S01. End Error エラー: 2009-03-13 02:26:11.24 コード: 0xC11F000C ソース: Process LedgerTransactions01 cube Analysis Services Execute DDL Task 説明: OLAP ストレージ エンジンのエラー: 'Dim Item の ID を持つディメンションでエラーが発生しましたV'、'dimItem' の名前が処理されていました。

キューブは SQL サーバー環境で実行されており、この問題は常に発生しているわけではありません。

次の保管と検索の問題にどのように取り組みますか?

約 2.000.000 行が毎日 (365 日/年) 追加され、行ごとに次の情報が追加されます。

• id (一意の行識別子)
• entity_id (1 から 2.000.000 までの値を取る)
• date_id (毎日 1 ずつ増加 - 1 ～ 3.650 (10 年: 1*365*10) の値を取る)
• value_1 (1 から 1.000.000 までの値を取る)
• value_2 (1 から 1.000.000 までの値を取る)

entity_id と date_id の組み合わせは一意です。したがって、エンティティと日付ごとに最大で 1 行をテーブルに追加できます。データベースは、10 年分の毎日のデータ (7.300.000.000 行 (3.650*2.000.000)) を保持できる必要があります。

以上が書き込みパターンである。読み取りパターンは単純です。すべてのクエリは特定の entity_id に対して行われます。つまり、entity_id = 12345 を記述しているすべての行を取得します。

トランザクション サポートは必要ありませんが、ストレージ ソリューションはオープンソースである必要があります。理想的には MySQL を使用したいのですが、提案は受け付けています。

さて、説明されている問題にどのように取り組みますか?

更新:読み取りと書き込みのパターンについて詳しく説明するように求められました。テーブルへの書き込みは 1 日 1 回のバッチで行われ、新しい 2M エントリが一度に追加されます。読み取りは、1 秒ごとに 1 回の読み取りで継続的に行われます。

Jitterbitを ETL ツールとして使用したことのある人はいますか? レビュー/チュートリアルはありますか?

私はDBにこのような構造を持っています

| RoleID | RoleTypeID | PersonID | OrganizationID | FromDate | ToDate |

各役割は、FromDateからToDateまでの日付に対してのみ有効です。

それぞれの人には、名前、性別、生年月日があります。

この日付をデータウェアハウスに入れて、SSASで使用したいと思います。

そこで、組織ごと、役割の種類ごと、性別ごと、年齢ごとの時間ごとに、役割の数でキューブを構築できるようにしたいと考えています。

これを保存するDWをどのように設計すれば、年齢と性別のデータの組み合わせだけで最大200行を取得できる可能性がありますが、その上に役割の種類と組織があります。

たとえば、次のような行

| 2009-01-01 | RoleTypeID = Employee | Organization = HQ | Gender = Male | Age = 32 | Count = 17 | | 2009-01-01 | RoleTypeID = Employee | Organization = HQ | Gender = Female | Age = 32 | Count = 12 | | 2009-01-01 | RoleTypeID = Employee | Organization = HQ | Gender = Male | Age = 33 | Count = 18 |

腸の感覚は、私がここで間違った方向に進んでいることを教えてくれます…</ p>

csvファイルを解析して、元のcsvファイルよりもフィールドが少ないテーブルに送信しようとしています。余分なフィールドを何も設定しない場合に残っている余分なコンマを削除するにはどうすればよいですか？

元のcsv形式は次のとおりです。

最終的な形式は次のとおりです。

名と姓のコンマが欠落していることに注意してください。

暫定的な行プロセッサは次のとおりです。

SSISを使用して、「db1」の複雑なビューを「db2」のテーブルに変換することをお勧めします。

ビューをテーブルに変換する目的は、レポートを高速化することです。

不利な点やリスクはありますか？

私のデータ ウェアハウジング ストアド プロシージャの一部に、古いプロジェクト データを新しいプロジェクト データ (古いデータはテーブルにあり、新しいデータは一時テーブルにある) と比較し、古いデータを更新するプロシージャがあります。

奇妙な点は、古いデータが null の場合、更新ステートメントが機能しないことです。is null ステートメントを追加すると、更新は正常に機能します。私の質問は、なぜこれが思ったように機能しないのですか?

複数の更新ステートメントの 1 つ:

私たちは銀行のデータ ウェアハウスに取り組んでおり、ステージング テーブル、スター スキーマ、ETL の標準的な Kimball モデルにほぼ従っており、プロセスを通じてデータを取得しています。

Kimball は、データをスター スキーマに入れる準備が整うまで、インポート、クリーニング、処理などすべてにステージング領域を使用することについて話しています。実際には、これは通常、ほとんどまたはまったく変更せずにソースから一連のテーブルにデータをアップロードし、その後、必要に応じて中間テーブルを介してスター スキーマに入る準備ができるまでデータを取得することを意味します。これは単一のエンティティにとっては大変な作業であり、単一の責任はありません。

私が取り組んできた以前のシステムでは、さまざまなテーブル セットが次のように区別されていました。

• テーブルのアップロード: 未加工のソース システム データ、未変更
• ステージング テーブル: 中間処理、型付けおよびクレンジング
• 倉庫テーブル

これらを個別のスキーマに貼り付けて、アーカイブ/バックアップ/セキュリティなどに異なるポリシーを適用できます。他の人の 1 人は、StagingInputとStagingOutputがあるウェアハウスに取り組んでいます。同様の話です。チームは全体として、データ ウェアハウスとその他の両方で多くの経験を積んでいます。

しかし、これらすべてにもかかわらず、Kimball と Web を調べてみると、ステージング データベースに何らかの構造を与えることについて、まったく何も書かれていないようです。キンボール氏が私たち全員に、この巨大で深く暗い構造化されていないデータのプールであるステージングを使用させようとしていると信じることは許されるでしょう。

もちろん、ステージング領域に構造を追加したい場合にどうすればよいかは明らかですが、それについて何も書かれていないように見えるのは非常に奇妙に思えます。

それで、そこにいる他のみんなは何をしているのですか？ステージングは​​、構造化されていない大きな混乱にすぎないのでしょうか?それとも、人々はいくつかの興味深いデザインを持っているのでしょうか?