2

各通知に UID があり、複数のユーザーに配信する必要がある通知アーキテクチャを設計しようとしています。各ユーザー デバイスには、最新の通知のローカル キャッシュがあります。ユーザー デバイスがオンラインになると、常に新しい通知がチェックされ、そのユーザー向けの通知がすべてプルされます。デバイスは、同期した最新の通知の UID を保持し、その UID を使用してサーバーから新しい通知をフェッチします。

これを MySQL テーブルに実装して、50 万人以上のユーザーに対応できるようにする最善の方法を考えています。

通知 UID が自動インクリメント主キーである通知詳細テーブルがあります。次のようなユーザーマッピングテーブルに関する提案が必要です（外部キー制約を無視します）

CREATE TABLE user_notifications_mapping ( 
    user_id INT UNSIGNED NOT NULL, 
    notification_id BIGINT UNSIGNED NOT NULL,
    UNIQUE KEY (user_id, notification_id)
) ENGINE=InnoDB;

しかし、次のようなクエリを作成しているときに最高のパフォーマンスになるかどうかは懐疑的です

SELECT notification_id FROM user_notifications_mapping WHERE user_id = <user-id> AND notification_id > <last-notification-uid>
4

1 に答える 1

1

テーブルが適切にインデックス化されている場合、この設計は非常に適しています。同期時に「少数」の通知のみが特定のデバイスに返されると仮定すると、テーブルが巨大 (数百万行) であっても、中距離サーバーは 1 秒あたり数百のそのような要求を処理できます。

今、このテーブルは非常に巨大になります。しかし、1 つの通知を 1 つのデバイスに 1 回だけ送信する必要があると思います。通知が送信されたら、このテーブルのレコードを削除 (または別のテーブルにアーカイブ) することを検討します。概念的には、このテーブルは のようなものになりますpending_notifications。

[編集]

新しい情報を考えると、このテーブルは実用的なサイズを超えて大きくなる可能性があります。別のアプローチを取る必要があります。たとえば、通知をグループ化する方法がおそらくあります (たとえば、特定の種類の通知である、またはアプリケーション内の特定のエンティティから発信されたものであるなど)。同じ概念をユーザーに適用できます。たとえば、すべての「顧客」または「すべての「管理者」に通知を送信したい場合があります。

根底にある考え方は、カーディナリティが小さい 2 つのエンティティ間に nn 関係を確立することです。「一部のユーザーが何らかの通知を受け取る」ケースをモデル化するのではなく、「一部のユーザー グループが何らかの種類の通知を受信する」ケースをモデル化します。

例：

  • 通知は、「お知らせ」、「通知」、または「警告」 (通知タイプ) のいずれかです。
  • ユーザーは「管理者」または「顧客」(ユーザーグループ)

次に、notifications_mappingテーブルは次のようになります。

    + -----------------------+
    | | notifications_mapping |
    + -----------------------+
    | | 通知タイプ |
    | | グループ ID |
    + -----------------------+

対応するクエリは次のようになります。

SELECT notification_id
FROM notifications_mapping AS map
JOIN user ON user.group_id = map.group_id
JOIN notifications ON notifications.type = map.notification_type
WHERE user_id = <user-id> AND notification_id > <last-notification-uid>
于 2013-06-12T07:40:47.180 に答える