100テラバイトの容量データベース-リソースと時間の見積もり

100TBのレポートデータベースセットアップの「エンベロープのバック」計算に取り組んでいます。私はここの専門家からの考えを探しています。提案された環境：

1. ストレージ容量〜100TB
2. テーブル〜200、サイズは1GB〜5TB。平均サイズは100 GB〜200 GB
3. ETL-ジョブは、数千万行のテーブル間の結合を必要とする場合があり、結合キーの範囲は10バイトから500バイトです。このような結合は2〜5分以内に完了します
4. ライブ選択-最初は、選択速度のみに関心があります。500選択/秒をサポートする必要があります。1秒あたりの更新数は比較的はるかに少なく、この演習では無視できます。
5. 24時間365日の可用性が必要です。選択した呼び出しに対応するために、2つの独立したDBサーバーを使用できる必要があります（データが複製されます）。

質問：

1. 現在、私はOracleを見ています。大規模なデータベースのための他の商用（または）オープンソースソリューションについて、どのように経験しましたか？
2. どのハードウェアOSが最も効果的だと思いますか？Linux on Dellを計画しています。
3. NetAppなどのネットワークストレージは必須ですか？市販のディスクを使用する場合、どのような問題が予想されますか？
4. ハードウェアとOSの準備ができたら、DB、ストレージなどのセットアップ、構成にどれくらいの時間を確保しますか。
5. 観察した環境で最もよく機能したチーム構成はどれですか。つまり、そのようなセットアップを管理および操作するために必要なさまざまな管理者（OS管理者、Oracle DB管理者？）です。24時間年中無休の稼働時間を実現するために必要な数
6. DBライセンス、ネットワークストレージコストに関する任意の概算/範囲。

私はすべての環境の詳細を持っていないことを知っています。正確な詳細を探すのではなく、概算で十分です。一部の質問にはマネージャーが最もよく答える可能性がありますが、私は管理者の観点に興味があります。ご意見をお待ちしております。

第一印象

1. パフォーマンス要件に応じて、100TBはかなり積極的なデータ量です。Oracleが必要な場合は、Exadataシステムをチェックアウトする必要があります。また、NetezzaまたはTeradataの製品もご覧ください。その大量の選択により、OLAPベースのフロントエンド、または少なくともマテリアライズドビューとクエリの書き換えのかなり積極的な使用を確認することができます。何からでも500テーブルスキャン/秒は得られません。
   
   レイテンシ要件がそれほど厳しくないものについては、ユーザーコミュニティにレポート機能を提供するために、より多くのデータマートを検討することをお勧めします。この場合、SQLサーバーとSSASがデータマートのオプションになる可能性があります。これは、Oracleで同じことを行うよりも、多数のサーバーでのライセンスの方が安価であるためです。

2. （1）を参照してください。共有ディスクアーキテクチャ上の従来のハードウェアは、このサイズのデータ​​セットでは低速になる可能性があります。

3. 番号！誰かがNFSを提案したら、彼らに良い蹴りを与える。直接接続ストレージ、または多数のミッドレンジコントローラーを備えたマルチコントローラーSANのいずれか。目的に合わせて構築された「ビッグデータ」プラットフォームに行かない場合は、多分数ダースのMD3000シリーズコントローラーまたは同様のものについて考えてください。

4. PB範囲のデータウェアハウスプラットフォームの経験を持つストレージスペシャリストを取得してください。おそらく、重要なETL開発ジョブと、厳しいSLAを満たさなければならない場合は、多くのテスト作業が必要です。

5. 24時間365日のデータウェアハウスは、最高の状態では野心的です。これは運用レポートプラットフォームですか？おそらく、要件について少し詳しく説明するかもしれません。

6. 括約筋は圧倒的に高価であり、パフォーマンス要件に依存します。最後に（数年前に）見たNetezzaは、TwinFinシステムに対して$ 20,000 / TBを見積もり、100TBに対してプラットフォームを$ 2mに加え、冗長サーバーとバックアップハードウェアのコストを使用していました。Exadataは少し安いと思いますが、価格を提示する必要はありません。
   
   比較のためにNetezza、Exadata、Teradataプラットフォーム、およびETLツールとしてのAb Initioのコストを見てください。

これはかなり厳しい一連の要件です。データウェアハウスでの24時間365日は通常行われず、データボリュームは「ビッグデータ」プラットフォームの領域に入るのに十分な大きさです。運用レポート要件がある場合は、それが何であるかを注意深く検討する必要があります。特定の理由がない場合（低レイテンシの市場データフィードなど）を除き、分析とは別にしてください。同じプラットフォーム上で運用要件と分析要件を混在させることは悪いモジョです。

要件を評価するには専門家に相談する必要があると思います。あなたが何を達成しようとしているのかをよく見ないで、私が与えることができるすべては、何をすべきか、またはすべきでないかについてのいくつかの経験的な提案です。

このような大量のデータを処理するときに考慮すべきその他のオプションには、次のものがあります。

1. @ConcernedOfTunbridgeWellsが投稿したすべて
2. EMCのGreenplum
3. MicrosoftのParallel Data Warehouse

ハードウェアコストを節約することを計画しないでください。このような仕様のシステムでは、多額の費用がかかります。