6

私は非常に大きなデータセットと関連する参照データを保存する必要があるプロジェクトに取り組んでいます。これほど大きなテーブルを必要とするプロジェクトに出くわしたことはありません。少なくとも1つの開発環境では、データベース層で、アプリケーション層が生成するビューに対する複雑なクエリ（複数の内部結合と外部結合を持つビュー、グループ化、合計、および9000万行のテーブルに対する平均化）に必要な処理に対応できないことを証明しました。 ）。

私がテストしたRDBMSは、AIX上のDB2です。失敗した開発環境には、本番環境で処理されるボリュームの1/20がロードされました。本番ハードウェアは開発ハードウェアやステージングハードウェアよりも優れていると確信していますが、膨大な量のデータと複雑なクエリに対応できるとは思いません。

開発環境が失敗する前は、大きなテーブルに対する複雑なクエリ（多くの結合、多くのグループ化、合計、平均化）によって生成された小さなデータセット（数百行）を返すのに5分以上かかりました。

私の直感では、ビューによって現在提供されている集計がオフピークバッチプロセスの一部として実行されるように、dbアーキテクチャを変更する必要があります。

さて、私の質問です。私は、この種のことを経験したと主張する人々（私はそうではありません）によって、私の恐れは根拠がないことを確信しています。彼らは？最新のRDBMS（SQL Server 2008、Oracle、DB2）は、私が説明したボリュームと複雑さに対処できますか（適切な量のハードウェアがあれば）、それともGoogleのBigTableのようなテクノロジーの領域にいますか？

この種のボリュームを非理論的なレベルで実際に処理しなければならなかった人々からの回答を期待しています。

データの性質は金融取引（日付、金額、地理的な場所、ビジネス）であるため、ほとんどすべてのデータタイプが表されます。すべての参照データが正規化されているため、複数の結合が行われます。

4

5 に答える 5

5

私は、数十億の行番号を持つテーブルを含むいくつかのSQLServer2008データベースを使用しています。私たちが遭遇した唯一の実際の問題は、ディスク容量、バックアップ時間などの問題でした。クエリは常に高速であり、通常は1秒未満の範囲であり、結合、集約、およびすぐ。

リレーショナルデータベースシステムはこの種の負荷を確実に処理できます。1台のサーバーまたはディスクに負荷がかかり始めた場合、ほとんどのハイエンドデータベースにはパーティショニングソリューションがあります。

データのインデックス作成方法についての質問には何も言及されていません。SQLのパフォーマンスに関する苦情を聞いたとき、10回のうち9回、インデックスが不十分または存在しないことが問題であることがわかりました。

遅いクエリが表示されたときに常に最初に行う必要があるのは、実行プランをプルアップすることです。完全なインデックス/テーブルスキャン、行ルックアップなどが表示された場合は、クエリのインデックスが不十分であること、またはインデックスをカバーすることを利用できないように作成されたクエリを示しています。非効率的な結合（主にネストされたループ）は、2番目に一般的な原因である傾向があり、クエリの書き換えで修正できることがよくあります。しかし、計画を見ることができなければ、これはすべて単なる憶測です。

したがって、あなたの質問に対する基本的な答えは「はい」です。リレーショナルデータベースシステムはこのスケールを完全に処理できますが、より詳細で役立つものが必要な場合は、スキーマ/テストスクリプトの例、または少なくとも私たちが見渡す。

于 2010-04-07T02:54:30.410 に答える
3

9000万行は約90GBである必要があるため、ボトルネックはディスクです。これらのクエリがめったに必要ない場合は、そのまま実行してください。

これらのクエリが頻繁に必要な場合は、データを分割し、データの変更されていない（または前回から変更されていない）部分の合計と平均を事前に計算する必要があります。

たとえば、今日までの過去N年間の履歴データを処理する場合、一度に1か月（または週、日）処理して、合計と平均をどこかに保存できます。次に、クエリ時に、今日を含む期間のみを再処理する必要があります。

一部のRDBMSでは、ビューがいつ更新されるか（選択時、ソース変更時、オフライン時）をある程度制御できます。複雑なグループ化の合計と平均化が、データベースが正しく理解できるほど単純である場合、理論的には、いくつかを更新できます。妥当な時間内にソーステーブルに挿入/更新/削除するたびにビューの行。

于 2010-06-24T09:14:03.007 に答える
2

正規化されたデータから同じデータを何度も計算しているようです。このような場合の処理​​を高速化する1つの方法は、SQLを優れたレポート、関係、一貫性などで維持し、x分ごとに計算されるOLAPキューブを使用することです。基本的に、非正規化データの大きなテーブルを定期的に作成して、すばやく検索できるようにします。リレーショナルデータはマスターとして扱われますが、キューブを使用すると、事前に計算された値をデータベースから任意の時点ですばやく取得できます。

于 2010-04-07T03:01:02.307 に答える
1

SQL Server 2005のデータウェアハウスのディメンション（Kimball方法論）モデルでは、1か月のパーティションにその数の行を含むファクトテーブルが定期的にあります。

瞬間的なものもあれば、時間がかかるものもあります。それは、操作、結合されている星の数、および何が起こっているかによって異なります。

同じモデルはTeradataでのパフォーマンスが低下しますが、3NFで再モデル化すると、Teradataの並列化がはるかにうまく機能することを理解しています。Teradataのインストールは、SQL Serverのインストールよりも何倍も費用がかかるため、データとプロセスのモデリングと基盤となる機能セットへのマッチングの違いがどれほど重要であるかを示しています。

データについて、またデータが現在どのようにモデル化されているか、どのようなインデックスの選択を行ったかについて詳しく知らなければ、これ以上何も言うことはできません。

于 2010-04-07T02:41:01.753 に答える
1

それがデータの1/20しかない場合は、GoogleのBig Tableなど、よりスケーラブルで効率的なソリューションを検討する必要があります。NoSQLをご覧ください

個人的には、MongoDBはNoSQLとRDMSの中間にある素晴らしいものだと思います。リレーショナルではありませんが、単純なドキュメントストアよりもはるかに多くの機能を提供します。

于 2010-04-07T00:53:55.527 に答える