ここに正解はありません。それは詳細に依存します: なぜ膨大な数の行を挿入するのですか? どのくらいの頻度で？これは 1 回限りのブートストラップですか、それともアプリは 10 秒ごとにこれを行いますか? また、利用可能なコンピューティング/IO リソースも重要です。データベースを使用しているのはあなたのアプリだけですか?それとも、他のユーザーのサービス拒否になるようなリクエストでデータベースを爆破していますか?
詳細がなければ、私の経験則では、最大 10 個の挿入を開始し、データベースに別の挿入コマンドを送信する前に、そのうちの 1 つが完了するまで待機するなど、同時実行数の制限が小さい一括挿入になります。これは のモデルに従いますasync.eachLimit。これは、ブラウザーが特定の Web サイトへの同時要求を処理する方法であり、妥当なデフォルト ポリシーであることが証明されています。
一般に、メモリ内オブジェクトのループは非常に高速である必要があります。
CPU のブロックについて心配していることは承知していますが、実行する作業の総量を考慮する必要があります。アイテムを 1 つずつ送信すると、多くのオーバーヘッドが発生します。forDB への各クエリには、おそらく「バッチ処理」forループが非常に小さく見える独自の内部ループのシーケンスがあります。
DB に 1000 個をダンプする必要がある場合、実行できる最小の作業量は、これを一度に実行することです。100 個の「もの」を 10 バッチにすると、同じ作業をすべて実行する必要があり、これらすべての要求を生成して追跡する必要があります。
これらの一括挿入をどのくらいの頻度で行っていますか? これが定期的に発生する場合は、作業の総量を最小限に抑え、すべてを一度に一括挿入することをお勧めします。
ここでのトレードオフは、ログ記録と再試行です。通常、ある種の一括挿入を実行するだけでは十分ではありません。一括挿入は最終的に (完全または部分的に) 失敗し、再試行または統合のために何らかの種類のロジックが必要になります。
それが懸念される場合は、ブロックをインテリジェントに再試行できるように、一括挿入のサイズを管理することをお勧めします。