14

したがって、基本的には、StackOverflowと同じ機能を実装したいと思います。

viewed 59344 times

だからここにいくつかの背景情報があります：

  1. ユニーク訪問のみをカウントしたい。登録ユーザーが記事を何度も読むことを前提としています（進化しています）
  2. 私はMongoDBをストアとして使用しています
  3. リアルタイムに近づけたい
  4. 私のシステムには登録がありますが、匿名ユーザーのビューもカウントしたいです

ユニークビジター数を数える最良の方法は登録によることだと理解していますが、ユーザーの大部分は、アプリケーションから情報を読み取るためにアカウントを作成する必要のない受動的なリーダーにすぎないということです。私の知る限り、最も便利な方法は、投稿を読むすべてのユーザーのIPアドレスを保存することです。また、IPアドレスが一意性を提供しないことも理解しています（同じISPの背後にいるため、プロキシやTorなどを使用して1人のユーザーが異なるIPを持つことができるため、一部の異なるユーザーは同じIPを持ちます）

Mongoの使用は絶対に必要というわけではありません。ただ、すべてが現在Mongoで記述されているということです。そのため、はるかに高速で便利な場合にのみ切り替えます。

4

2 に答える 2

23

バックグラウンド

「ユニークな」ビューを追跡する必要があると確信していますか？

私は実際、人気のあるサイトが視聴回数をユニークに保とうとは思っていません。新しいコメントの再訪問は、新しいコンテンツ/コメント/広告を表示するという意味での追加の「視聴」です。クローラーや自社のユーザー/IPを除外するなど、ユースケースにとって重要な場合と重要でない場合がある「正確さ」には他にも微妙な点があります。

ユニークビューの追跡に時間を費やす代わりに（あまり意味がありません）、ページでの投票/いいね/コメントなどのユニークユーザーインタラクションを数えることを検討します。次に、これらのメトリックに基づいて、いくつかの式を使用してページの「人気」を判断できます。Drupalの放射性崩壊モジュールには、このアプローチの興味深い例があります。ここでは、「ホットネス」メトリックが、ユーザーインタラクションの最新性に基づく活動に基づいて計算されます。

考慮すべきアプローチ

1）MongoDBの単純なビューカウンターの$inc場合、ページが読み込まれるときにビュー数を増やすために使用します。必要に応じて、役割ごとにログユーザーを除外できます（たとえば、管理者ユーザー）。

2）より正確なビューカウンターのために、問題をWeb分析プラットフォームに渡します（とにかくより詳細な分析のためにサイトで使用する必要があります）。たとえば、 GoogleAnalyticsAPIまたはPiwikなどのオープンソースアプリケーションを使用できます。Web分析システムには、一意のユーザー/ビューを判別するためのソリューションがすでに用意されており、これらのAPI呼び出しはJavaScriptを介して非同期にすることができます。

3）明確な要件を追跡する独自のビューを実装する場合は、独自の基準（登録ユーザーの場合はペアごとの一意のビュー、非ユーザーの場合はペア）に基づいて、ビューとアップサートを追跡するために別のコレクションを使用します。アップサートの結果が挿入になる場合は、記事ビューのカウンターをインクリメントすることで、これをアプローチ＃1（記事ビューのビューカウンターをインクリメント）と組み合わせます。user,articlesession_id,article

于 2013-03-29T06:17:19.560 に答える
0

この問題を解決する方法の1つは、Cookieを使用することです。ユーザーがページにアクセスすると、ユーザーがすでにページにアクセスしていることを示すCookieを1つ追加して、再度カウントする必要がないようにすることができます。彼が訪れたすべてのページを知るために、いくつかのキーを追加し続けることができます。Cookieは削除できることは知っていますが、どのソリューションでもトレードオフがあります。

mongoDBの展望から、非常に高速な挿入と読み取りが必要な場合は、いくつかの方法を提案します。

1）記事を作成するときに、ログコレクションにこのようなドキュメントを作成します

   {"_id" : "Article URL" , {"Hit" : 0}}

IPアドレスを追加するので、mongoDBを変更するドキュメントのサイズは、新しく割り当てられたスペースを見つける必要があるため、IPアドレスやその他の情報を追加することを提案しないのはなぜですか。これはパフォーマンスの観点からは悪いことです。カウンターをインクリメントするだけなので、ドキュメントのサイズは増えず、場所を変更する必要はありません。+使用できるドキュメントの最大サイズには制限があります。

2）事前にドキュメントを作成しておくと、直接更新ステートメントが表示され、記事IDのドキュメントの存在を確認する必要はありません。

于 2013-03-27T06:44:32.030 に答える