多くの用途と大量のデータ（MSMQ？）のためのスケーラブルなアーキテクチャ

Question

私は大量のデータをアップロードする複数のユーザーを持つシステムを設計しています。私の最初の例は毎日100Mbをアップロードする100人のユーザーです。

データを取得し、データベースに挿入し、データベース（ETL）内のデータを処理し、分析用に「研磨済み」データを使用する必要があります。

アップロードされたファイルは、65kチャンク（初期設計）で受信されます。

MSMQを使用してこの問題を回避するには、データをMQに格納し、それを別の「プログラム/ツール」に渡してデータを処理し、それを介してETLツールに信号を送りますMSMQはそのことをやり始めます。

「リニア」アプローチの代わりにイム思考：より良い1であるように見えるアプローチ

--> receive data 
--> save data to sql 
--> wait for upload finish (run the two above until no more chunks) 
--> signal the ETL to do its thing 
--> When ETL is done report "Done" to callee 

？調べるべき選択肢はありますか？私はこのアプローチを見る限り、クライアント/ダウンローダーをロックします。

Answer 1

私は第1のアプローチを好む。 2番目の方法よりも利点は、MSMQメッセージを非同期に送信して処理し、トランザクショナルセキュリティを非常に簡単に保つことができることです。

2番目のエフェクターは機能しませんでしたが、最初のものは私にとってははるかに少ない努力のように見えます。

また、MSMQの上にあるいくつかのフレームワークを調べることをお勧めします。 C＃プログラマーとして私は​​をお勧めしますが、あなたが何を使用しているのかわかりません。

Answer 2

データを受け取った後で、ターゲットテーブルの最も頻繁に使用されるインデックスに従ってデータを並べ替えることをお勧めします。これをRAMで行う必要があります。一度に100MBをソートするか、大規模な100×100MB（RAMは10GBのみ）のソートを行うことができます。そうすれば、ブロック挿入が高速になり（インデックス作成コンポーネントの処理が減ります）、その後の選択では、関連する行が（ディスク上で物理的に隣り合って）一緒に束ねられ、テーブル内で無作為に分散することが少なくなります。これにより、選択されたセクションの物理的な読み込みが少なくなり、実行時間が短縮されます。