减少通知系统上的数据库写入或更改认可数据库？答案

【问题标题】：Reduce database write on notification system or change approbate database?减少通知系统上的数据库写入或更改认可数据库？
【发布时间】：2019-06-15 16:04:51
【问题描述】：

我们有一个网络应用程序，它需要向用户发送大量通知（每天超过 1,000,000 通知）。我们使用Laravel 和 MySQL 作为数据库。

我遍历一组用户发送通知并将其保存到数据库中。假设我想发送一组1000 用户。数据将写入 DB1000 时间。正如我所说，我们每天有超过 1,000,000 通知，这需要大量资源。

解决这个问题的适当方法是什么？

我应该改用一个新的数据库系统，比如 MongoDB，或者我应该重新设计通知表架构和我保存到 DB 的方式？

以下是我的通知表架构。

PS:: 我需要将每个通知保存到数据库并需要显示给用户。不能跳过这部分。

【问题讨论】：

通知内容是对所有用户都一样还是因用户而异？

标签： mysql database laravel database-design notifications

【解决方案1】：

如果您要为所有用户发送相同的内容，我建议采用以下方法。

数据库架构

notification_contents (id, content, created_by, created_at, updated_at)

user_notifications (id, user_id, notification_id, status, created_at, 更新时间）

当有新的通知要发送时，将其插入到 notification_contents 表中。如果要自定义内容，可以在内容中使用占位符。例如用户名或电子邮件

然后遍历用户并将它们插入到带有user_id 和notification_id 的user_notifications 表中。如果您想为此实现排队机制，则最初将status 标志设置为零。

然后编写一个 cron 作业，从 user_notifications 表中获取 x 个用户并将内容发送给他们。您可以通过notification_contents 加入 user_notifications 以获取电子邮件内容。

发送通知后将status 标志设置为1。

【讨论】：

【解决方案2】：

收缩数据集。

对 UUID 使用 ascii。你真的需要 UUID 吗？
将 UUID 压缩为 BINARY(16)。（这不会完全解决 UUID 导致的可扩展性噩梦，但会有所帮助。）
使用 ENUM 表示类型和状态，而不是长 VARCHAR。
这两种“类型”有什么区别？
您需要 8 字节 BIGINT 吗？
有 3 个 TIMESTAMP，您需要多个吗？

我没有看到类似user_id??

【讨论】：