6

統計の目的でユーザーのログイン履歴を追跡しようとしていますが、最善の方法が何であるかはわかりません。ユーザーとそのログイン統計を日付とともに記録する別のテーブルを作成することもできますが、そのテーブルは非常に大きくなる可能性があります。ユーザーモデル/オブジェクト自体のいくつかの履歴フィールドを解析可能なフィールドで追跡し、区切り文字列形式でそれを更新するだけです。例: で分割し、含まれている日付コードが今日でない場合は最後のものを取得し、項目 (日付 + カウント) を追加します。少なくともこの 2 番目のアプローチでは、別のテーブルで古いレコードを削除するタスクが必要になるため、古いアイテムを簡単に削除できます (たとえば、毎日のログインまたは IP を 30 日だけ保持するなど)。

私は瞬時の変化の大ファンです。タスクは便利ですが、メンテナンス上の理由から複雑になる可能性があります。

誰にも提案はありますか？外部データ キャッシュ ソリューションなどはまだ用意していません。ポインタも大歓迎です！（私は同様の質問と回答を探してきました）

ありがとう！

4

7 に答える 7

5

Devise を使ってそれを行う良い方法があります。

Warden は、ユーザーの設定後に実行される after_set_user というフックをセットアップします。したがって、ip フィールド、logged_in_at フィールド、および user_id フィールドを含むモデル ログインがあると仮定すると、このフィールドを使用してのみレコードを作成できます。

Warden::Manager.after_set_user :except => :fetch do |record, warden, options|
  Login.create!(:ip => warden.request.ip, :logged_in_at => Time.now, :user_id => record.id)
end
于 2012-05-09T14:58:02.823 に答える
5

@ user208769 の回答に基づいて、コアメソッドは保存前にDevise::Models::Trackable#update_tracked_fields!名前が付けられたヘルパー メソッドを呼び出すようになりました。update_tracked_fieldsつまり、ActiveRecord::Dirtyヘルパーを使用して少し簡単にすることができます。

def update_tracked_fields(request)
  super

  if last_sign_in_at_changed?
    Audit.create(user: self, action: 'login', ip: last_sign_in_ip)
  end
end

auditsがモデルの関係である場合、これはさらに単純化できます (そして、検証が与えられれば、より信頼性が高くなります) 。

def update_tracked_fields(request)
  super
  audits.build(action: 'login', ip: last_sign_in_ip) if last_sign_in_at_changed?
end
于 2015-02-24T20:21:53.467 に答える
4

Devise は、モジュールを使用して、最後にサインインした日付と最後にサインインした IP アドレスの追跡をサポートしてい:trackableます。このモジュールをユーザー モデルに追加し、次の正しいフィールドをデータベースに追加します。

:sign_in_count,      :type => Integer, :default => 0
:current_sign_in_at, :type => Time
:last_sign_in_at,    :type => Time
:current_sign_in_ip, :type => String
:last_sign_in_ip,    :type => String

Devise::SessionsControllerその後、 and のアクションをオーバーライドして、andをコールバック内の別のテーブルにcreate保存できます。その後、好きなだけそれらを保持できるはずです。:last_sign_in_at:last_sign_in_ipbefore_create

于 2012-05-17T00:38:38.830 に答える
3

私は自分の質問に答えるのが嫌いです。特に、あなたが両方とも役に立つ答えをくれたことを考えると. 私が取ったアプローチで私の質問に答えることは、あなたの答えと組み合わせて他の人を助けるかもしれないと思います.

私はImpressionist Gem (廃止された RailStat 以来、唯一の有用なページ ビュー Gem) で遊んでおり、これまでのところ良い結果が得られています。基本的な移行を設定した後、予想される使用法が Rail の MVC 設計に非常に厳密に従っていることがわかりました。「印象派」をコントローラーに追加すると、ページビューをデータベースに記録するときにモデルを探しに行きます。この動作を変更するか、コントローラー (または実際にはどこでも) で自分自身を呼び出して、モデルを持たないコントローラーでテストすることができます。

とにかく、Devise::SessionsController をオーバーライドし、@current_member の印象派メソッドを呼び出すだけで、成功したログインを追跡するために Devise と連携しました: (失敗したログインで nil かどうかを確認することを忘れないでください)

class TestSessionController < Devise::SessionsController
  def create
    if not @current_member.nil?
      impressionist(@current_member)
    end
    super
  end
end

一部の限定的な分析のために後で他のサイト パーツに追加するのは簡単です。他にやらなければならなかったことは、Devise ログイン ルートに新しい TestSessionController を使用するようにルートを更新することだけでした。

post 'login' => 'test_session#create', :as => :member_session

とにかくDeviseを変更する必要なく、Deviseは通常どおりに動作し、印象派のDBテーブルはインデックス化され、ログインを記録しています。後でレーキ タスクが必要になるだけで、週に 1 回程度トリミングできます。

あとは、大量のループする汚いクエリを書かずに、毎日のログインをチャート化する方法を考え出す必要があります...

于 2012-05-09T21:01:55.353 に答える
3

これが例です（scribd_analytics）

create_table 'page_views' do |t|
  t.column 'user_id', :integer 
  t.column 'request_url', :string, :limit => 200
  t.column 'session', :string, :limit => 32
  t.column 'ip_address', :string, :limit => 16
  t.column 'referer', :string, :limit => 200
  t.column 'user_agent', :string, :limit => 200
  t.column 'created_at', :timestamp
end

クエリに応じて、一連のインデックスを追加します

リクエストごとに PageView を作成する

手作りの SQL クエリを使用して、この ActiveRecord のオーバーヘッドを取り除きました。

MySQL の「挿入遅延」を試すかもしれません

分析クエリは通常、手作業でコーディングされた SQL です

「explain select」を使用して、MySQL が期待するインデックスを使用していることを確認します。

かなりうまくスケーリングします

しかし、分析クエリは高価であり、メインの DB サーバーを詰まらせる可能性があります

私たちのソリューション:

use two DB servers in a master/slave setup

move all the analytics queries to the slave

http://www.scribd.com/doc/49575/Scaling-Rails-Presentation-From-Scribd-Launch

確認する別のオプションは、Gattica with Google Analytics です

于 2012-05-08T15:19:07.947 に答える