私は、約 2,800,000 レコードを含む 1 つのテーブルを持つ Access データベースを備えた VB.net アプリケーションを持っています。各 raw は毎日新しいデータで更新されます。マシンには 64GB の RAM と i7 3960x があり、4.9GHz にオーバークロックされています。
注: データ ソースはローカルです。
〜10個のスレッドを使用すると、データの行への更新がより速く完了するのだろうか。
可能であれば、この大きなループを複数のスレッドに分割するメカニズムは何でしょうか?
更新: ループは、結果に応じて一部の行の計算を繰り返さなければならない場合があります。また、ループには正確に 63 の条件と 242 行のコードがあります。
Microsoft Access は、他のデータベース プラットフォームと比較して、多数の同時更新の処理が特に得意ではありません。
タスクで計算を行う必要があるほど、通常、同時実行/スレッド化のメリットが大きくなります。更新コマンドを Access に送信するだけの 10 個のスレッドをスピンアップしても、スレッドが 1 つだけの場合よりもはるかに高速になる可能性はほとんどありません。
データの読み取りと書き込みの間に重要な計算を行う必要がある場合は、スレッドのパフォーマンスが向上する可能性があります。
以下を試して結果を測定することをお勧めします。
これは Producer / Consumer パターンを使用して実装できます。これはBlockingCollectionで非常に簡単に実行できます。
プロデューサー/コンシューマー パターンの優れた点は、スイート スポットを見つけるための最小限のコード変更でプロデューサー スレッドやコンシューマー スレッドを追加できることです。
補足的な考え
IO はおそらくアプリケーションのボトルネックです。可能であれば、Access ファイルをより高速なストレージ (SSD、RAID、または RAM ディスク) に配置することを検討してください。
2,800,000 件のクエリで 2,800,000 件のレコードを更新している場合、それは間違いなく遅くなります。
通常、複数の接続を開いてデータを更新することは避けたほうがよいでしょう。
現在どのように行っているかを示すコードをいくつか見せてください。そうすれば、何を変更すればよいかがわかります。
したがって、（あなたが提供した情報では）これをマルチスレッドにする方が高速になるとは思いません。さて、更新によって GUI がフリーズするためにマルチスレッド化を考えているのであれば、それはまた別の話です。
処理が遅い場合、個人的にはサーバーのスペックによるものではないと思います。データの更新に使用したロジックに関するものだと思います。
不思議に思わないで、テストしてください。できるだけ多くのスレッドをディスパッチして機能させ、さまざまな数のスレッドでテストできるように記述します。あなたが話しているループはどのように見えますか?
「スレッドを追加すると、より速く動作しますか?」などの質問がありますか? 経験則はありますが、常にテストすることが最善です。DB がローカルにある場合、Oded が正しい可能性があります。