9

私は通知システムを実装しており、これらの提案が設定に有効かどうか、一方が他方よりも優れているか、またはより良い解決策が利用可能かどうかを確認しています:

データベースに通知が追加されます。ゲスト/識別可能なユーザーがサイトにログオンまたは使用します。これまで見たことのない通知が表示され、閉じるか後で読むかを選択できます。

  • 通知テーブルには、通知テキストと ID が格納されます。
  • オプション 1: Alerts テーブルには、通知を読んだすべてのユーザーが格納されます
  • オプション 2:アラート テーブルには、通知を読んでいないすべてのユーザーが格納されます

これらのオプションは大したものですか? 潜在的に 100,000 件以上のアラートを追加し、それらのユーザーが通知を破棄または操作すると、ステータスが変更されるか、アラートが削除される可能性があります。これは非常に大きなテーブルになる可能性があります...

ユーザー アクティビティに基づくカスタム通知のより拡張可能な設定は何ですか?

4

3 に答える 3

13

私はそのようにはしません。(ユーザー、通知) ごとにレコードを保存し、各レコードを既読または未読としてマークします。これは、アプリケーションによっては重要になる場合があります (たとえば、何らかの監査証跡が必要な場合)。

100k レコードはそれほど大きくありません。少なくとも 1,000 万レコードに達するまでは、サイズについて心配する必要はありません。必要に応じて、ある時点でそれらをアーカイブします。ただし、1,000 万件のレコードを生成する速度を見積もる必要があります。3日なら問題ありません。3年なら無理です。

もちろん、このオプションには別の表に通知テキストがあります。

これは、ユーザー (インデックス付き) の未読メッセージを選択し、参加して通知テキストを取得するか (テーブルが数千万レコードのサイズの場合)、またはそれらを選択できるため、さらに多くのメッセージで非常にうまくスケーリングする必要があります。メッセージを個別に選択します。

(user,notification) テーブルのパーティション分割は簡単です。ユーザー範囲に基づいて作成します。

また、ユーザーがメッセージを削除する場合は、通常、実際に削除するのではなく、削除済みとしてマークする必要があります。ほとんどの場合、データベース内の何かを削除する理由はほとんどありません。

于 2009-07-25T08:14:28.197 に答える
5

私は自分のウェブサイトをコーディングしていて、同じ質問がありますが、この方法で解決しました：

  1. すべてのレコードを通知テーブルに保存します。
  2. Read/Unread = true/false
  3. CRON ジョブ: ユーザーが 50 件を超える通知を持っている場合、古い 10 件の通知を削除します。

Facebook は定期的に cron ジョブを実行して、制限通知に達した後に表示できない古い通知を削除していると思います。

于 2012-09-08T09:57:00.753 に答える
1

または、まだ読んでいないメモへの参照のセットをユーザー プロファイルごとに保存し、表示されたら削除することもできます (一般的な使用例では、おそらく一度にすべてのメモを読みます)。このようにして、個々のユーザーをプルするときに小さなクエリしかなく、大きな未読メッセージ テーブルをフィルタリングするのではなく、グローバル メッセージの挿入時間にコストがかかります。

于 2009-07-25T08:16:53.713 に答える