私はユーザーがプレーヤーの歴史的打撃の統計を分析できるようにする野球ツールを持っています。たとえば、A-Rodは夜間の状態で過去7日間にヒットした回数はいくつですか?私は時間枠を広げて、ユーザーがプレーヤーの打撃の統計を365日後まで分析できるようにしたい。ただし、これを行うには、重大なパフォーマンスの最適化が必要です。膨大な数のレコードを更新する - パフォーマンスの最適化
class AtBat < ActiveRecord::Base
belongs_to :batter
belongs_to :pitcher
belongs_to :weather_condition
### DATA MODEL ###
# id
# batter_id
# pitcher_id
# weather_condition_id
# hit (boolean)
##################
end
class BattingStat < ActiveRecord::Base
belongs_to :batter
belongs_to :recordable, :polymorphic => true # e.g., Batter, Pitcher, WeatherCondition
### DATA MODEL ###
# id
# batter_id
# recordable_id
# recordable_type
# hits7
# outs7
# at_bats7
# batting_avg7
# ...
# hits365
# outs365
# at_bats365
# batting_avg365
##################
end
class Batter < ActiveRecord::Base
has_many :batting_stats, :as => :recordable, :dependent => :destroy
has_many :at_bats, :dependent => :destroy
end
class Pitcher < ActiveRecord::Base
has_many :batting_stats, :as => :recordable, :dependent => :destroy
has_many :at_bats, :dependent => :destroy
end
class WeatherCondition < ActiveRecord::Base
has_many :batting_stats, :as => :recordable, :dependent => :destroy
has_many :at_bats, :dependent => :destroy
end
私はbatting_statsテーブルを更新することはなく、コードの束をコピーしています何を物語るせ、合理的な長さで私の質問を保つのために:ここではモデルの私の現在のセットがあります。 7日から始めましょう。
- 過去7日間のすべてのat_batレコードを取得します。記録at_bat各オーバー
- 反復... at_batレコードを考える
- は、関連する打者と関連するweather_conditionをつかむ正しいbatting_statレコード(BattingStat.find_or_create_by_batter_and_recordable(打者、weather_condition)を見つけ、その後、batting_statレコードを更新。
- 繰り返しを打者と投手のためのステップ3(recordables)
1-4は、他の時間帯のために繰り返される - 。15日、30日など
今私は、これは可能だろうか、面倒な想像に毎日スクリプトを実行して、管理期間を7/15/30から7/15/30/45/60/90/180/365に変更する場合は、これらの更新を行います。
私の質問は、これを最高レベルのパフォーマンスで実行するにはどうすればよいですか?
私はゴルフアプリのために同様のシステムを構築しました。私は共有したいと思っていますが、かなり広範な説明が必要です。あなたはあなたのアーキテクチャを変えようとしていますか、現在持っているアーキテクチャを最適化する方法を探していますか? – mnelson
どうしたのか聞いていただければ幸いです。アーチを更新したいと思っているが、道のりを突き抜ける。 – keruilin
あなたはいくつのレコードを扱っていますか?野球のための多くのデータポイントは、確かに(数十万?)存在することはできません。必要に応じて、プレイヤーがマップにスライスして、その場ですべて計算して、記憶に残しておくことはできませんか? –