数据库设计

Question

我有4个表:users,posts,categories,categories_map

posts有id,text,category_id
categories_map包含user_id和category_id

我的目标是创建一个用户可以预览的队列.此外,用户将能够跳过一些帖子或编辑其中的文本.如果用户跳过帖子,它将永远不会出现在队列中.但是,用户无法更改序列,因为cron将执行脚本.

第一种方法,我认为是创建包含一个表 user_id,post_id,text_modified,is_skipped,last_posted.因此,当执行cron作业时,它将留下时间戳,因此下次不会抓取此帖子,用户可以轻松更改此帖子的文本.

第二种方法是创建一个队列会为用户生成一个单独的表user_id,post_id,category_id,text_modified.因此,cron作业可以轻松地跟随此表并在完成后删除该行.但是使用这种方法,如果我有30个用户,平均有3个类别,每个包含5000个帖子,我的表已经有450000行.是的,如果它被正确索引,它应该都是好的.但是当我有100-200个用户时,它是否可以扩展？

我应该采取哪种方法,还是有其他解决方案？

Answer 1

很多东西都取决于你的产品.我们不知道:

1. 用户如何互相交流？
2. 他们的行为(跳过)是否需要坚持,或者如果他们失去99.9%以上就可以.
3. 他们的文本修改是在帖子上,全局可见,还是仅对他们进行修改.
4. 用户是否按类别检查帖子？

说了所有这些未知数,我会捅一下:

• 如果对问题4的回答是"是",那么从你的PK判断选项#2似乎更合理.
• 如果问题4的答案为否,那么从您的PK判断选项#1似乎更合理.

对于数据库大小,我认为你正在进行一些预优化.你应该考虑表宽度.由于您的表非常窄(只有几列和主要是整数),因此您不必过于担心特定表的长度.

当这成为约束时(您可以对其进行基准测试,或等待查看特定服务器上的磁盘空间),您可以通过轻松地对用户进行分片来扩展数据库.您基本上将不同的用户放在不同的数据库服

• 注意:问题1将确定上述内容的容易程度.

说这一切,请记住性能影响:

1. 这些名单会变得很长.
2. 如果用户修改影响其他用户,则您将不得不进行相当多的扇出工作,以将更新发布到特定队列.

在这种情况下,您可能需要查看一些分布式缓存,如Memcached,Redis.

• 注意:根据问题2和3的答案,您甚至可能不需要保留队列.