300万レコードのデータベーステーブルがあります。Javaスレッドは、テーブルから10,000レコードを読み取り、それを処理します。処理後、次の10,000にジャンプします。スピードアップするために、同じタスク（読み取り+処理）を実行する25のスレッドがあり、次に同じJavaプログラムを実行する4つの物理サーバーがあります。つまり、事実上、100個のスレッドが同じ作業（読み取り+処理）を実行しています。
私が使用した戦略は、次の10,000レコードを取得し、それらを特定のスレッドによって処理されているものとしてマークする作業を行うSQLプロシージャを使用することです。ただし、スレッドがプロシージャを呼び出して応答を返すのをしばらく待っているように見えることに気付きました。このデータ選択プロセスをスピードアップするために使用できる他の戦略。
私のデータベースサーバーはmysqlで、プログラミング言語はjavaです。
このようなシナリオを処理する慣用的な方法は、プロデューサー/コンシューマーデザイン パターンです。Java ランドでそれを実装する慣用的な方法は、jmsを使用することです。
基本的に、レコードを読み取って JMS キューにプッシュする 1 つのマスター サーバーが必要です。次に、任意の数のコンシューマーがそのキューから読み取り、互いに競合します。これをどのように詳細に実装するかはあなた次第です: レコード全体または ID のみでメッセージを送信しますか? 1 つのメッセージ内の 10000 レコードすべて、またはメッセージごとのレコード?
別のアプローチはmap-reduceです。 hadoopを確認してください。しかし、学習曲線は少し急勾配です。
私には Hadoop の仕事のように思えます。
あなたは主にこのスキームにバインドされたデータベース IO であると思われます。システムのパフォーマンスを向上させようとしている場合は、可能であればデータを複数のデータベース サーバーに分割することをお勧めします。 MySQL には、私が経験したことのないパーティショニング モードがいくつかあります。自分でパーティションを作成すると、データベース スキーマが非常に複雑になる可能性があり、ハッシュ メカニズムを使用してある種のルーティング レイヤーを追加し、レコードを複数のパーティションに分割する必要があります。しかし、速度が大幅に向上し、スレッドの待機時間がほとんどなくなると思います。
データをパーティション分割できない場合は、データベースをSSD メモリ ドライブに移動することで大きなメリットが得られると思います。これらのパーティションの IO レートを向上させるためには何でもかまいません。固有のパフォーマンスの問題があるため、RAID5 には近づかないでください。信頼性の高いファイル システムが必要な場合は、ミラーリングまたはRAID1の方がパフォーマンスがはるかに優れており、RAID50も大きなパーティションのオプションです。
最後に、データベースの IO バスをスラッシングしている場合、スレッドが少ないほどアプリケーションのパフォーマンスが向上することがあります。これは、同時クエリ、データベース レイアウトなどを含む多くの要因によって異なります。クライアントごとのスレッド数を減らしてみて、それが異なるかどうかを確認してください。ただし、効果は最小限にとどめることができます。