我正在尝试设计一个通知架构,其中每个通知都有一个 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>
最佳答案
如果对表进行适当的索引,这种设计是非常适合的。假设在同步时只有“少量”通知会返回给一个给定的设备,即使表很大(数百万行),中等范围的服务器每秒也能处理数百个此类请求。
现在这张表将变得非常巨大。但我相信一个给定的通知只需要发送到一个给定的设备一次。发送通知后,我会考虑删除(或在另一个表中存档)该表的记录。从概念上讲,此表类似于 pending_notifications
。
[编辑]
根据新信息,该表可能会超出实际大小。您需要采取不同的方法。例如,可能有一种方法可以对您的通知进行分组(例如,它们属于给定类型,或者它们来自您应用程序中的给定实体)。同样的概念可以应用于您的用户:也许您希望将一些通知发送给(例如)所有“客户”或“所有“管理员”。
基本思想是在两个较小基数的实体之间建立 n-n 关系。您不会对“某些用户收到某些通知”的情况建模,而是“某些用户组收到某些类型的通知”。
例子:
- 通知可以是“公告”、“通知”或“警告”(通知类型)
- 用户可以是“管理员”或“客户”(用户组)
notifications_mapping
表将如下所示:
+-----------------------+ | notifications_mapping | +-----------------------+ | notification_type | | group_id | +-----------------------+
And the corresponding query could be:
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>
关于mysql - 设计用于同步通知的 MySql 表,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17059558/