31

データ ウェアハウス システムの適切なソリューションを選択するために、あなたの知恵を活用したいと思います。問題をよりよく理解するための詳細を次に示します。

データは、1 つの BIG ファクトと最大 15 のディメンションを持つスター スキーマ構造で編成されます。
1 か月あたり 200 億のファクト行
10 次元で 100 行 (ある程度の階層)
5 次元で数千行
2 次元で ~200K 行
2 つの大きな次元で 50M ～ 100M 行

この DB に対して実行される 2 つの典型的なクエリ

dimq の上位メンバー:

select    top X dimq, count(id) 
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 
group by  dimq 
order by  count(id) desc

タプル対策：

select    count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),...
from      fact 
where     dim1 = x and dim2 = y and dim3 = z

質問:

  1. そのようなクエリを実行するのに最適なプラットフォームは何ですか
  2. 必要なハードウェアの種類

  3. どこでホストできますか (EC2?)


    (現時点では、インポートと読み込みの問題は無視してください)

Tnx、
ハガイ。

4

7 に答える 7

56

これはいくら強調してもしすぎることはありません。市販のレポート ツールとうまく連携するものを入手してください。

1 か月あたり 200 億行になると VLDB の領域に移動するため、パーティショニングが必要になります。カーディナリティ ディメンションが低いということは、ビットマップ インデックスの方がパフォーマンスが向上することも示唆しています。

  • SQL のサポートが成熟するまで、クラウド システム ( Hive、 Hbase ) は忘れてください。データ ウェアハウス アプリケーションには、従来のレポート ツールで動作するものが必要です。そうしないと、アドホック レポート プログラムの作成と保守に永久に行き詰まることになります。

  • データ ボリュームは、Oracle のような従来型の DBMS で管理できます。私は、 Oracleデータベースに 1 日あたり 600 GB をロードする主要なヨーロッパの電話会社を知っています。他のすべての条件が同じであれば、これはデータ ボリュームよりも 2 桁大きいため、共有ディスク アーキテクチャには余裕があります。NetezzaやTeradataのような 何も共有しないアーキテクチャ はおそらくさらに高速ですが、これらのボリュームは従来の共有ディスク システムを超えるレベルではありません。ただし、これらのシステムはすべて非常に高価であることを覚えておいてください。

  • また、MapReduce は効率的なクエリ選択アルゴリズムではないことに注意してください。これは基本的に、力ずくの計算を分散するためのメカニズムです。Greenplum には MapReduce バックエンドがありますが、専用のシェアード ナッシング エンジンははるかに効率的で、より少ないハードウェアでより多くの作業を実行できます。

これについての私の見解は、Teradata または Netezza がおそらくこの仕事にとって理想的なツールですが、間違いなく最も高価であるということです。 Oracle、Sybase IQ、またはSQL Serverでさえ、関連するデータ ボリュームを処理しますが、遅くなります。これらは共有ディスク アーキテクチャですが、この種のデータ ボリュームを管理できます。Oracle および SQL Server の VLDB 関連機能の概要については、この投稿を参照してください。また、Oracle がExadata ストレージ プラットフォームも導入したばかりであることを覚えておいてください。

私のお決まりのキャパシティ プランでは、Oracle または SQL Server のインデックスを含めて、1 か月あたり 3 ～ 5 TB 程度を提案しています。おそらく、ビットマップ インデックスを使用する Oracle では少ないですが、インデックス リーフには、Oracle では 16 バイトの ROWID があり、SQL Server では 6 バイトのページ参照があります。

Sybase IQ は、ビットマップ インデックスを広範囲に使用し、データ ウェアハウス クエリ用に最適化されています。共有ディスク アーキテクチャですが、このタイプのクエリには非常に効率的です (IIRC は元の列指向アーキテクチャでした)。これは、このタイプの作業に特化しているため、おそらく Oracle や SQL Server よりも優れています。

Greenplum の方が安価なオプションかもしれませんが、実際に使用したことがないので、実際にどれだけうまく機能するかについてコメントすることはできません.

数百行しかない 10 個のディメンションがある場合は、それらを 1 つのジャンク ディメンションにマージすることを検討してください。これにより、10 個のキーが 1 つにマージされてファクト テーブルがスリムになります。ジャンク ディメンションに階層を実装することもできます。これにより、ファクト テーブルのサイズが 1/2 以上減少し、インデックスによる多くのディスク使用量が削減されます。

レポートツールの合理的な断面とうまく機能するものを使用することを強くお勧めします. これは SQL フロントエンドを意味します。Crystal Reportsのよう な商用システムでは、より容易に SQL スキルを習得できる人々がレポートや分析を行うことができます。オープンソースの世界は、 BIRT、Jasper Reports、Pentaho も生み出しました。. Hive や HBase を使用すると、カスタム フロント エンドを構築するビジネスに参加できますが、今後 5 年間 Python でカスタム レポート フォーマッタを作成することに満足している場合を除いて、これは望ましくありません。

最後に、運用システムから高速なデータ フィードを簡単に取得できる場所にホストします。これはおそらく、独自のデータ センター内の独自のハードウェアを意味します。このシステムは I/O バウンドになります。大量のデータに対して単純な処理を行っています。これは、高速なディスク サブシステムを備えたマシンが必要になることを意味します。クラウド プロバイダーは、このタイプのハードウェアをサポートしない傾向があります。これは、これらの組織が従来使用していた使い捨ての 1U ボックスのタイプよりも桁違いに高価であるためです。高速なディスク I/O は、クラウド アーキテクチャの長所ではありません。

于 2008-12-09T21:49:01.247 に答える
9

私はverticaで大きな成功を収めました。私は現在、1 日に 2 億行から 10 億行 (1 か月平均で約 90 億行) をロードしていますが、1 か月で 170 億行にも達しています。21 個近くのディメンションがあり、クエリは非常に高速に実行されます。データロードを行う時間枠がなかっただけで、古いシステムから移行しました。

私たちは、さまざまなソリューションの徹底的な試行と研究を行い、実際に市場に出回っているすべてのものを調べました. Teradata と Netezza はどちらも私たちに適していましたが、私たちにとっては高すぎました。Vertica は、価格/性能比で両方を上回りました。ちなみに、これはカラムナ データベースです。

現在、約 80 人のユーザーがいますが、完全に展開を開始する来年の終わりまでには約 900 人に増えると予想されています。

レポートには ASP.NET/dundas/reporting サービスを広く使用しています。また、サード パーティのレポート ソリューションともうまく機能しますが、試したことはありません。

ところで、dataload には何を使用しますか? 私たちはインフォマティカを使用しており、非常に満足しています。SSIS は、私たちを壁に押し上げました。

于 2008-12-20T00:50:31.873 に答える
3

HBase と jasperserver hbase レポート プラグインを使用すると、適切なレポートを作成できます。低レイテンシーの OLAP を HBase で作成できます。これは、SQL と同じように機能します。Jasperserver HBase プラグインは、拡張 Hbase スキャン コマンドである Hbase クエリ言語を提供します。

于 2012-10-01T09:23:33.043 に答える
2

最終的に何を選んだのか気になります。あなたの質問は 2008 年末までのものでした。現在、状況は異なり、HBase、Greenplum、pig などが SQL のようなアクセスを提供しています。

于 2012-01-25T16:22:36.840 に答える
2

Monash のサイトを読んでください: http://www.dbms2.com/彼は大きなデータベースについて書いています。

おそらく、Oracle Exadata ( http://www.oracle.com/solutions/business_intelligence/exadata.htmlおよび http://kevinclosson.wordpress.com/exadata-posts/ ) を使用するか、Hadoop を使用することができます。Hadoop は無料です。

于 2008-12-20T00:17:04.187 に答える
0

ユーザー数が少ない場合の代替手段は、(beowulf) クラスターです。20K は、それぞれ 500G の 50 台のネットトップを購入します。それは約3KWのピーク電力です。または 4 か月間のクラウド ストレージ。

于 2008-12-11T13:41:20.200 に答える
0

NXC さん、1 日あたり 6,000 億行ということでよろしいですか? 1 行が 1 バイトだとしても、1 日あたり 600 GB のデータになります。より妥当な行あたり 100 バイトを想定すると、1 日あたり 60 TB、1 か月あたり 1.8 PB のデータについて話していることになります。オラクルを介してそれほど多くのデータを送り出している人がいるとは思えません。

他の情報源は、データ量が 2 桁の TB の数値に達すると、Oracle の処理が非常に困難になることを確認しているようです。

于 2008-12-12T13:42:38.237 に答える