0

次の問題があります:
データベースにデータを格納する Web アプリケーションがあります。クライアントが、たとえば 2 つのテーブルのデータをファイル (クライアントに対してローカル) に抽出できるようにしたいと考えています。
データベースは任意に大きくなる可能性があります (つまり、データベースに含まれる可能性のあるデータの数はわかりません。巨大になる可能性があります)。
これに最適なアプローチは何ですか？すべてのデータをテーブルから取り出し、ファイルに格納する単一の構造としてクライアントに返す必要がありますか
? それとも、最初の 100 エントリ、次に次の 100 エントリなど、データを部分的に取得し、クライアントで単一の構造を作成する必要がありますか? ここで考慮すべき長所と短所はありますか? SELECT

4

2 に答える 2

1

私は似たようなものを構築しました - 特にファイルサイズがブラウザで快適に処理できる範囲を超えて大きくなる可能性があるため、ここにはいくつかの非常に扱いにくい問題があります。データ量が増えると、ファイルを生成する時間が長くなります。これは、Web アプリケーションが得意とすることではないため、たとえ少数の訪問者がすべて大きなファイルを要求したとしても、Web サーバーが不満を抱くリスクがあります。

私たちが行ったことは、アプリケーションを 3 つの部分に分割することです。

「ファイル要求」は、認証されたユーザーが自分のファイルを要求できる単純な Web ページでした。これにより、Web ページ要求のコンテキスト外で 2 番目の部分が開始されます。

ファイルジェネレーター。私たちの場合、これは Windows サービスで、ファイル リクエストでデータベース テーブルを調べ、最新のものを選択し、適切な SQL クエリを実行し、出力を CSV ファイルに書き込み、そのファイルを出力ディレクトリに移動する前に ZIP しました。ユーザーにリンクをメールで送信します。データベース内のレコードの状態を設定して、任意の時点で 1 つのプロセスのみが発生したことを確認します。

FTP/WebDAV サイト: ZIP ファイルは、FTP および WebDAV 経由でアクセスできるフォルダーに書き込まれました。これらのプロトコルは、標準の HTTP ダウンロードよりも巨大なファイルを処理する傾向があります。

これはうまく機能しました。ユーザーはファイルを待ちたがりませんでしたが、遅延が数分を超えることはめったにありませんでした。

于 2012-07-09T13:15:43.640 に答える
0

約を含むOracleクラスターで同様のユースケースがあります。40GBのデータ。私たちにとって最適なソリューションは、DB のオーバーヘッドを大幅に削減するため、select ステートメントごとのデータを最大にすることです。

そうは言っても、私たちにとって非常にうまく機能した3つの最適化があります。

1.) データをほぼ同じサイズの 10 個のセットに分割し、それらをデータベースから並行して選択します。私たちのクラスターでは、8 つの接続が並行して動作することがわかりました。単一の接続よりも 8 倍高速です。最大 12 接続までの追加のスピードアップがありますが、それはデータベースとデータベースに依存します。

2.) 大量のデータについて話すときは、休止状態やその他の ORM を避け、カスタムメイドの JDBC を使用してください。そこに到達できるすべての最適化を使用します (例: ResultSet.setFetchSize())

3.) データは非常によく圧縮され、データを gziper に通すことで I/O 時間を大幅に節約できます。私たちの場合、クリティカル パスから I/O を除外しました。ちなみに、これはデータをファイルに保存する場合にも当てはまります。

于 2012-07-09T12:54:16.010 に答える