3

私の友人のカタログには、現在約 500 行または 500 項目が含まれています。アイテムが閲覧された回数、閲覧された日付を含むカタログに関するレポートを提供できる方法を検討しています。

彼のサイトは 1 か月あたり平均約 25,000 ページのインプレッションであり、これらの半分がカタログ アイテムであると仮定すると、毎月約 12,000 のカタログ アイテムが表示されると想定されます。

私の質問は、データベース内のアイテム ビューを管理する最良の方法です。

最初のオプションは、カタログ ID をテーブルに挿入し、表示回数を増やすことです。これの利点は、そのコンパクトな性質です。テーブルには、カタログ アイテムと同数の行しかありません。

`catalogue_id`, `views`

欠点は、アイテムが最後に表示された時間を維持する以外に、日付情報が保持されていないことです。

2 番目のオプションは、アイテムが表示されるたびに新しい行を挿入することです。

`catalogue_id`, `timestamp`

12,000 アイテム ビューという仮定の数字を続けると、毎月 12,000 行、つまり毎年 144,000 行がテーブルに追加されることになります。これの利点は、アイテムが表示された回数と、表示された日付もわかっていることです。

難点は、テーブルのサイズです。144,000 行のテーブルは MySQL には大きすぎますか?

これを達成する方法についての考えや提案を聞くことに興味があります。

ありがとう。

4

2 に答える 2

1

あなたが言及したように、最初のものははるかにコンパクトですが制限されています。ただし、オプション 2 を詳しく見てみると、次のようになります。たとえば、閲覧数だけでなく、入口/出口ページ、ホスト IP なども保存したい場合などです。この情報は、統計と追跡にとって非常に貴重な場合があります。もう 1 つの質問は、これらの 25,000 インプレッションはユニークかということです。ユーザー名、IP、またはその他の一意の識別子で追跡できない場合、これにより多くの行を使用できなくなる可能性があります。あなたの質問への答えは、保存したい詳細の量に依存しますか? データの重要性は何ですか？

アップデート：

確かに、時間間隔のために特定のアイテムの繰り返しを制限することは良い解決策です. また、誰かが同じアイテムを訪問したかどうかを知ることは、Amazon と同様の提案アイテム perdition ウィジェットに役立つ可能性があります。また、誰かがアイテムを何度も訪れたことを知っていると、メールアウト、ニュースレター、または人気のある製品ページで、これが彼らや他の人に宣伝するのに適したアイテムであることがわかります. ユニーク ビューを追跡すると、より正直なビュー カウントが得られ、表示または保存を選択できます。リピーターの価値を制限するという問題に関しては、これは主に、表示する情報に応じてのみ機能します。それは、あなたに最も適した方法で情報を組み立てることです。

于 2012-05-31T04:37:22.680 に答える
0

問題の説明:特定のカタログ アイテムの閲覧数を追跡できるようにしたいと考えています。

オプションを確認しましょう。

最初のオプション:

このオプションでは、catalogue_id とアイテムのビュー数の整数値を保存します。

利点:

  1. 1 対 1 の関係があるので、新しいテーブルは小さくなります。500 個のアイテムがある場合、500 行になります。このルートを選択して、新しいテーブルを作成するのではなく、カタログ テーブルにビュー数を含む別の列を追加することをお勧めします。

短所:

  1. ここでの問題は、このテーブルを比較的頻繁に更新するため、非常に忙しい小さなテーブルになることです。たとえば、10 人のユーザーが同じアイテムを閲覧しているとします。これらの 10 個の更新プログラムは、次々に実行する必要があります。InnoDB を使用していると仮定すると、最初のビュー アクションがロックされ、行が更新され、カウンターがロックが解放されます。他の更新はその後ろでキューに入れられます。そのため、テーブル上のデータは小さいですが、特にシステムのスケーリングを開始した場合は、後でボトルネックになる可能性があります。

  2. つまり、生データを追跡していないということです。たとえば、ウェブサイトが成長し始め、関心のある投資家がいて、過去 6 か月間の週ごとのビューの内訳を見たいと考えているとします。このオプションを使用すると、投資家に提供するデータがなくなります。基本的に、要約を保持しています。

2 番目のオプション:

このオプションでは、少なくとも次の最小限のフィールド catalogue_id と timestamp を含むログ テーブルを作成します。これを拡張して、ユーザー名/IPアドレスまたはその他の情報を追加して、さらに細かくすることができます.

利点:

  1. 詳細なデータを保持しています。これにより、さまざまな方法でデータを要約できます。たとえば、訪問者の IP を保存する IP アドレス列を追加し、国別に表示された製品を示す月次レポートを作成できます (IP アドレス ルックアップを実行して、訪問者がどの国から来たかを知ることができます)。もう 1 つの例は、前四半期にどの製品が最も多く閲覧されたかなどを確認することです。このデータは、ビジネスを成長させる方法を決定するのに非常に重要です。製品に関する限り、何が機能していて何が機能していないかを知りたい場合、この詳細は絶対に重要です。

  2. 新しいテーブルはログ テーブルになります。挿入操作のみになります。挿入はほとんど並行して行うことができます。このオプションを使用すると、常に更新されるテーブルと比較して、サイトの成長に応じてスケーリングが向上する可能性があります.

短所:

  1. このテーブルは、おそらくデータベース内で最大のテーブルになります。ただし、これは問題ではありません。私は定期的に 500 000 000 行以上のテーブルを扱っています。一部のテーブルは 750 GB を超えていますが、それでもレポートを実行できます。クエリとそれらを最適化する方法を理解する必要があるだけです。MySQL は数百万行を簡単に処理できるように設計されているため、これは実際には問題ではありません。一部の情報を他のテーブルにアーカイブできることに注意してください。3 年ごとにデータをアーカイブするとします。3 年以上前のデータを別のテーブルに移動できます。そこにすべてのデータを保持する必要はありません。144 000 行という見積もりは、テーブルのパフォーマンスを心配することなく、約 15 年以上の価値を安全に保つことができることを意味します。

あなたへの私の提案は、2 番目のオプションを真剣に検討することです。このルートに進むことにした場合は、提案されたテーブル構造で質問を更新し、それを見てみましょう. ビッグデータを恐れないでください。むしろ、対処がはるかに困難な BAD デザインを恐れてください。

ただし、いつものように、選択はあなた次第です。

于 2012-05-31T07:43:28.123 に答える