Rails で 1 日 1 回スクリプトを実行する必要がある Web サイトを開発しています。スクリプトは xml フィードを読み取り、データベースを更新します。Rails 3.1.1 を使用しており、Heroku で Web サイトを実行しています。
実行時にスクリプトが Web サイトを完全に強制終了しないようにするには、どのようなオプションがありますか? dyno を追加すれば解決すると思いますが、特にスクリプトを実行するときに外部で実際に必要とされないため、非常にコストがかかります。
別のデータベースでスクリプトを実行してコピーできますか? バックグラウンドで実行しますか？要するに、どのようなオプションがありますか?
編集：ここではあまり明確ではありませんでした。ここでの問題は、スクリプトを実行するのではなく、Webサーバー/データベースへの影響をできるだけ少なくすることです(いつでもなど)。できるだけ影響を与えないように夜間にスクリプトを実行する予定ですが、それでもその時間帯に Web サイトが完全にダウンすることは望ましくありません。
これの多くは、スクリプトのパフォーマンス特性に依存します。CPUを非常に集中的に使用するが、影響が少ない場合は、心配する必要はありません。herokuスケジューラのようなものを使用する場合、ジョブは別のdynoで実行されます。これは別のdynoであるため、リクエストを処理している他のdynoには影響しません。
データベースの大量使用は、まったく別のことです。データベースには有限量のIO、キャッシュ、CPUなどがあり、それをハードにプッシュしている場合（多くの書き込みは、多くの読み取りよりも一般的に悪いです。これらのバストキャッシュのため）、他のdynoのパフォーマンスが低下する可能性があります。
Webサイトの動作を完全に停止することも可能です。アプリの残りの部分がアクセスしようとしている行/テーブルのロックをジョブが取得することになった場合、ジョブがそれらのロックを解放するまでWebdynoはブロックされます。
フィードをトラバースするときに更新するdb行を1つずつフィードを解析している場合は、おそらく問題ありません。ロックの競合に関しては、大量の書き込み/読み取りよりも小さな書き込み/読み取りの方が優れていると思います。インデックス付きの列から一度に1行ずつロードし、いくつかのルビー計算を実行してから1行を更新するように思われるため、データベースに大きな打撃を与えることになります。
パフォーマンスが許容できないほど低下していることに気づき、ボトルネックが読み取りである場合、1つの方法は、読み取りスレーブ（レプリカ、またはherokuではフォロワーを話す）を用意することです。一言で言えば、これはメインのデータベースサーバーを追跡する独立した読み取り専用のデータベースサーバーです（したがって、常にほぼ最新です）。このサーバーに対して行うことはマスターデータベースに影響を与えないため、心配することなくクエリを実行できます。
問題が必要な書き込みの数である場合、これは役に立ちません。より強力なデータベースサーバーに切り替えることで、ある程度これを（コストをかけて）解決できます。一部の使用パターンでは、リレーショナルデータベースよりもさまざまなタイプのデータストア（mongo、redisなど）の方が適切な場合があります。パフォーマンスのホットスポットのいくつかを設計することが可能な場合もありますが、それを検討するのに最適なのは明らかにあなたです。
これはすべて非常に抽象的なものです。実際にわかる唯一の方法は、試してみることです。アプリのコピーをセットアップし、このタスクを開始して、パフォーマンスがどのように低下するかを確認します（または、1回限りの影響を心配しない場合は、実際のアプリに対してこれを実行します）
gem resqueとresque-schedulerをお勧めします。私はそれらを本番環境で使用していますが、開発とテストが非常に簡単で便利です（resque_specを参照）
heroku が redis を非常によくサポートしていることは知っています。そして、 gem heroku-schedulerを試すことができます。私はそれを使用しませんでしたが、それもクールだと思います;)
いつでも素晴らしいです。代替案を提案しました。それはあなたの選択です
rails 用のfeedzirraプラグインをチェックアウトします。飼料加工をしたい時にとても重宝します。
また、いつでも宝石をチェックアウトしてください。それをインストールし、フィード処理を行う頻繁に実行されるモデル メソッドを作成します。
このようにして、Web サーバーは完全にループから外れ、リクエストの処理に影響しません。ただし、DB は別の話です。