MySQL 環境では、専用の MySQL サーバーと専用のアプリ サーバーがあり、どちらが優れているか -
を。データベース サーバーに接続するアプリ サーバーで無限の Java コードを実行し、結合に基づいていくつかのレコードをフェッチしてからデータベースに挿入します。
-また-
b. 結合 (選択) に基づいて挿入を実行するデータベースで無限ストアド プロシージャを実行する
実行時間、データベースの負荷、メモリ要件、およびデータベースが他の挿入/更新を処理し続ける能力に関して回答が必要です
MySQL 環境では、専用の MySQL サーバーと専用のアプリ サーバーがあり、どちらが優れているか -
を。データベース サーバーに接続するアプリ サーバーで無限の Java コードを実行し、結合に基づいていくつかのレコードをフェッチしてからデータベースに挿入します。
-また-
b. 結合 (選択) に基づいて挿入を実行するデータベースで無限ストアド プロシージャを実行する
実行時間、データベースの負荷、メモリ要件、およびデータベースが他の挿入/更新を処理し続ける能力に関して回答が必要です
実行時間、データベースの負荷、およびメモリ要件についてはわかりませんが、私の経験では、(データベースではなく) ビジネス層ですべてのロジック作業を行う方がよいでしょう。その上、ストアド プロシージャはスケーラビリティが低く、大規模なプロジェクトでの保守が困難です。なので私のチョイスはAです。
一部の情報が不足していますが、それについては次のように推測しています。
行は、無限の割合で来ているわけではありません。
あなたはおそらくそれについてポーリングしています。つまり、sleep()サイクルの間に何らかの種類を作成しています。
そうでない場合は、どちらの場合でもデータベース サーバーに高い負荷をかける可能性があることを知っておく必要があります。
したがって、何らかのスリープ (簡単にするために1秒としましょう) があると仮定すると、Java コードと格納されたルーチン コードとの間に大きな違いはないことがわかります。何故ですか?
MAX(id)ほとんどの場合、ターゲット テーブルのいくつかをチェックしている場合INSERT INTO ... SELECT ... FROM ... WHERE id > max_id_as_just_calculated、 、または同様のものをチェックしています。MySQL と Java の間で結果セットをやり取りする必要がないため、実行時間は実際にはルーチン コードにいくらか有利になる場合があります。さらに、INSERT INTO ... SELECT FROM結果セットを Java オブジェクト/プリミティブに変換してから新しいクエリを準備INSERTし、MySQL データに変換する代わりに、1 つのクエリで実行できます。
DB 負荷に関しては、実際の違いは見られませんが、ネットワーク配信時間 (ロックがまだ保持されている可能性がある時間) により、ルーチン側がわずかに改善されています。
考慮事項:
Java からこのプロシージャをどのように呼び出しますか? それは無期限に実行されます。それで、それにスレッドを捧げますか?
クラッシュしたとします (何らかのエラー) -- 再実行できるようにする必要があります (大したことではなく、考慮すべき問題です)。
イベントスケジューラを介して実行できます-これにより、上記の問題の多くが解決されます。ルーチンを介してループする代わりに、スケジューラにX秒ごとに呼び出させます。しかし、もう一度ロックを考えてみてください。
私自身の好み: おそらく Java コードを使用するか、このロジックを RDBMS に追加することに慣れている場合はイベント スケジューラを使用します。
一部のデータベースでは、ストアドプロシージャを選択します。データベースに加えてデータをシフトする理由は、そのデータに関する知識を持っています。
しかし-そして、MySqlをストアドプロシージャ内に持つcommitことができないのは少し失敗しています(IMHO) 。rollbackしたがって、MySqlコンテキストの無限ストアドプロシージャは期待どおりに機能しないと思います。
「無限に実行されるクエリ」などがあるかどうかはわかりません。おそらく、繰り返し実行されるクエリを意味します。
とにかく、原則として、データベースとアプリケーション間で大量のデータを前後に転送するオーバーヘッドを回避できれば、スループットが向上します。一方、やろうとしている「こと」が(データ集約的ではなく)計算集約的である場合、アプリケーション(DBとは別のマシンで実行されている)で計算を行うと、DBの負荷が軽減されます。
実行時間、データベースの負荷、メモリ要件、およびデータベースが他の挿入/更新を処理し続ける能力に関して回答が必要です
一般的なケースでこれらのことを定量化することはできませんが、明らかなトレードオフがあります。
実際にどのように機能するかは、実際のユースケースの詳細に大きく依存します。