0

mySQL-DB に数百のレコードがあり、1 時間ごとに複数回更新する必要がある Rails 3 アプリがあります。実際の更新はdelayed_job、コントローラーロジックでトリガーされることによって行われます (最後の更新から十分な時間が経過したかどうかを確認し、その後にのみ sth. が発生します)。

各更新は遅く、場合によっては最大 1 秒かかることがあります (ただし、平均して 1 秒あたり 3 ~ 5 回の更新です)。コードは次のようになります。

class Thing < ActiveRecord::Base

...

  def self.scheduled_update
    Thing.all.each do |t|
      ...
      t.some_property = new_value
      t.save
    end
  end 

end

300 ~ 400 レコード後に実行が停止し、遅延したジョブがハングアップして最終的にタイムアウトするように見えることを確認しました (エントリはdelayed_job.log)。しばらくすると、次のレコードが開始され、また失敗するなど、すべてのレコードが更新されるわけではありません。

これを行う適切な方法は何ですか?

そのように使用した場合、Rails はデータベース接続をどのように処理しますか? 適切に検出/処理されないタイムアウトの問題でしょうか?

これを行うデフォルトの方法があるはずですが、これまでのところ何も見つかりませんでした..

どんな助けでも大歓迎です。

4

3 に答える 3

2

別のオプションはupdate_allです。

于 2012-06-17T01:53:44.690 に答える
1

Rails は大量のデータ レコードには適していません。アクティブ レコードを回避する SQL ストアド プロシージャまたはその他の方法を作成できるかどうかを確認してください。

  • object.save_with_validation(false)検証を完全にスキップしても問題ない場合に使用します。

  • レコードを検索するときは、必要:select => 'a,b,c,other_fields'なフィールド (この例では「a」、「b」、「c」、および「other」) を制限するために使用します。

  • :include最初に複数のテーブルを選択して結合するときに、一括読み込みに使用します。

于 2012-06-17T01:47:40.070 に答える
0

だから私は自分の問題を解決しました。

レールに問題がありました-私が使用していたバージョン(3.0.3)、タイムアウトは私が疑ういくつかのバグが原因でした。3.0.xブランチの新しいバージョンに更新すると問題が解決し、すべてが完全に実行されるようになりました。

于 2012-06-17T13:49:56.560 に答える