减少通知系统上的数据库写操作或更改适当的数据库？

Question

我们有一个Web应用程序，该应用程序需要向用户发送大量通知（每天超过1,000,000条通知）。我们将Laravel和MySQL用于数据库。

我通过一组用户循环发送通知，并将其保存到数据库中。假设我要发送一组1000个用户。数据将被写入数据库1000时间。如我所说，我们每天有超过1,000,000条通知，占用了大量资源。

解决此问题的合适方法是什么？

我应该改用MongoDB这样的新数据库系统，还是应该重新设计通知表架构以及保存到DB的方式？

以下是我的通知表架构。

PS ：：我需要将每个通知保存到数据库，并需要显示给用户。无法跳过这一部分。

Answer 1

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

数据库架构

  

notification_contents（ID，内容，created_by，created_at，updated_at）

     

user_notifications（id，user_id，notification_id，状态，created_at，   

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

然后遍历用户，并将他们插入到user_notifications和user_id的{​​{1}}表中。如果您想为此实现排队机制，请首先将notification_id标志设置为零。

然后编写一项cron作业，以从status表中提取x个用户并将其内容发送给他们。您可以将user_notifications与user_notifications结合使用以获取电子邮件的内容。

发送通知后，将notification_contents标志设置为一个。

Answer 2

缩小数据集。

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

我没有看到类似user_id的东西？