それぞれの方法についての私の考えは次のとおりです。
いいえ、そうすべきではありません。データベースで実行する方がはるかに高速な計算もあれば、そうでない計算もあります。ただし、データベースで実行する必要がある計算を正確にテストするのは難しく、時間がかかります。アルゴリズムの一部がpostgreSQLまたは使用するもので遅いことを適切に経験するでしょう。さらに重要なことに、これはロジックを実行するのに適切な場所ではありません。あなた自身が言うように、テストが難しく、全体的に悪い習慣です。また、データベースがアルゴリズムを計算する必要があるたびに、リクエスト全体のパフォーマンスにも影響します。また、データベースはこれを処理するためにまだ大量のメモリを使用するため、それは利点ではありません。
これまでで最高のソリューションです。詳細については、以下を参照してください。
これは、ナンバーワンよりもはるかに優れたソリューションです。ただし、これはアプリのパフォーマンスが非常に不安定になることを意味します。通常のリクエストですべてのリソースが無料になる場合もあれば、計算にすべてのリソースを使用する場合もあります。
オプション 2 が最善の解決策です。これは、アプリの残りの部分のパフォーマンスに影響を与えず、分離して動作するためスケーリングがはるかに簡単であるためです。たとえば、ワーカーが追いつかない場合は、実行中のプロセスをいくつか追加するだけです。
さらに重要なことは、バックグラウンド プロセスを別のサーバーで実行できるため、メモリとリソースの使用状況を簡単に監視し、必要に応じてサーバーを拡張できることです。
リアルタイムの更新であっても、バックグラウンド ジョブが最適なソリューションです (もちろん、計算がリクエストで実行できるほど小さくない場合)。ほとんど常に空になるのに十分なリソースを持つ「優先度の高い」キューを作成できます。リロードで結果をユーザーに表示する必要がある場合は、バックグラウンド ジョブの完了後に何らかのプッシュ通知を追加する必要があります。この通知は、javascript を介してページの更新をトリガーすることができます ( Rails 4の新しいライブ ストリーム機能を確認することもできます)。
Sidekiq with Redisのようなものをお勧めします。その後、結果を memcache にキャッシュするか、毎回結果を再計算することができます。これは、これを計算する必要がある頻度によって異なります。ただし、このソリューションを使用すると、必要に応じて安定したキャッシュをセットアップするのがはるかに簡単になります。
私が働いている場所には、このような多くの計算を伴う重いクエリを実行するアプリケーションがあります。これらのジョブは毎晩キューに入れられ、その後数時間にわたって隔離されたサーバーで実行されます。これは非常にうまくスケールし、新しいレリックで簡単に監視できます。
これが役に立ち、理にかなっていることを願っています (私の英語が完璧ではないことは承知しています) が、何か誤解していたり、他に質問がある場合はお気軽にお尋ねください。