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

Question

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ライセンス、ネットワークストレージコストの概算/範囲。

環境の詳細をすべて持っているわけではありません。正確な詳細を探すのではなく、概算で十分です。いくつかの質問はマネージャーが最もよく回答するかもしれませんが、管理者の観点に興味があります。私はあなたの入力に感謝します。

Answer 1

第一印象

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

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

3. NO！誰かがNFSを提案したら、彼らに良い蹴りを与える。直接接続ストレージまたは複数のコントローラーSAN多くのミッドレンジコントローラーを使用。多くの場合、数ダースのMD3000シリーズコントローラーまたは類似のものについて考えてください。専用の「ビッグデータ」プラットフォーム。

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

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

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

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

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

Answer 2

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

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

どこにでもハードウェアコストを節約するつもりはありません。このような仕様のシステムでは、多額の費用がかかります。