2016-03-19 11 views
0

Rails 4.2およびPostgreSQL 9.4.5の使用。私は、最後のレコードから開始し、特定の条件が発生するまで処理を続行する、逆の読み込みが必要なトランザクションログテーブル(XLog)を持っています。私はこれを達成することができますが、それは "すべて"の方法を必要とし、効率的ではありません。私のテストシステムでは、最初のレコードは.06秒後に表示され、それ以降のすべてのクエリは0.001秒未満の無限小です。他の多くのクエリを試しましたが、目的の結果が得られません。私はActiveRecordを使用していますが、もちろんネイティブSQLクエリを使用できます。最後のレコードから逆方向または逆方向のテーブルをクエリする効率的なメソッド

これは最後のレコードから逆方向にxlogのを読みに焦点を当ててテストコードです:

class EtlLastProcessed 
    def initialize(company: nil) 
    ActsAsTenant.with_tenant(company) do 
     count = 0 
     clock = Time.now 
     xlogs = XLog.all.order("created_at DESC") 
     xlogs.each do |xlog| 
     puts Time.now - clock 
     clock = Time.now 
     break if count > 1000 
     count += 1 
     puts "Xlog date is #{xlog.created_at.in_time_zone.to_date}" 
     end 
     puts "ETL Last Processed done." 
    end 
    end 
end 
+0

なぜ 'func_each'や' find_in_batches'を使わないのですか?たとえば 'XLog.order(" created_at DESC ")。find_each do'または' ... find_each(batch_size:5000)do'のようにします。すべてがなければ。 –

+0

N> 1000の場合、 'find_each(batch_size:N)'と 'find_in_batches(batch_size:N)'を試してみませんか? –

+0

@IvanBlackはい、私は両方を試しましたが、クエリが最初にレコードを取得してから、ActiveRecordがそれらをバッチします。 find_eachもfind_in_batchesも、一度バッチ処理されたレコードを最初に取得するSQLクエリの一部ではありません。 –

答えて

0

私は効率的に「created_atとASC」を使用するためのロジックを変更しました。私の全体的なロジックの変化には意味があります。

関連する問題