つまり、私のユースケースの概要は次のとおりです-
定期的(24時間ごと)に、非常に大きなファイル(サイズはMBから数十GBまでさまざまです)を取得しますが、24時間以内に処理する必要があります。処理には、レコードの読み取り、一部のビジネスロジックの適用、レコードを使用したデータベースの更新が含まれます。
現在のソリューションはシングルスレッドバージョンであり、
これは、1,000万レコード未満の小さなファイルで機能します。しかし、システムがスケーリングしているため、より大きな負荷、つまりファイルが大きくなっています(たまに1億レコードを超える)。このシナリオでは、タイムアウトが発生します。つまり、24時間以内にファイル全体を処理できません。
そこで、ここで並行性を追加する予定です。
簡単な解決策は
このソリューションはシンプルに見えますが、唯一の欠点は、シングルスレッドであるためファイルの解析に時間がかかる可能性があることです(RAMは問題ではなく、非常に大きなEC2インスタンスを使用しています)。
別の解決策は-
ファイルを複数の小さなファイルに分割する必要があるため、これは少し複雑に見えます。
ここでのアプローチに関する提案についてのご意見をお待ちしています。
これを行う最も可能性の高い効率的な方法は次のとおりです。
正しいことを行うためのガイドとなるため、これには Spring Batch を使用することをお勧めします。しかし、それはやや過剰に設計されていて、使いにくいです。
DBがボトルネックになった場合でも、これらすべてが無駄になる可能性があることに注意してください。これは、非常に簡単に起こり得ることです。SQLデータベースは、同時更新の処理が非常に悪いことで有名です。デッドロック。
基本的な算術から始めましょう。
(* 24 60 60)
86400
つまり、1日は86400秒です。
(/ 100e6 86400)
1157.4074074074074
つまり、1日に1億レコードを処理するには、1秒あたり1157.4レコードを処理できる必要があります。
さらに一歩進んでください:
(/ 1.0 1157.4074074074074)
0.000864
つまり、1つのレコードをエンドツーエンドで864マイクロ秒で処理できる必要があります。
あなたが何をしようとも、これは真実です。レコードを完全に処理するのに864マイクロ秒以上かかる場合、24時間で1億のレコードを処理することはできません。
「スレッディング」を追加すると、オーバーヘッドが追加され、基盤となるワークロードが削除されないため、状況は悪化し、改善されません。
このクレイジーなラケットで40年近く過ごした後、ファイルをメモリに読み込んでDBMSに結果を書き込んでいると、生きたまま食べているのではないかと思います。