帖子有id,text,category_id
categories_map包含user_id和category_id
我的目标是使用户可以预览的队列.此外,用户将能够跳过一些帖子或编辑其中的文本.如果用户跳过一个帖子,它将永远不会出现在队列中.但是,用户无法更改序列,因为cron将执行脚本.
我认为的第一种方法是创建一个包含的表
user_id,post_id,text_modified,is_skipped,last_posted.所以当cron作业被执行时,它会留下一个时间戳,所以下次这个帖子不会被抓住,用户可以轻松地改变这篇文章的文字.
第二种方法是创建一个单独的表,其中将为用户user_id,category_id,text_modified生成队列.所以,cron工作可以轻松地按照这个表进行操作,并在完成后删除行.但是,如果我有30个用户,平均有3个类别,每个包含5000个帖子,我的表将已经有45万行.是的,如果它被正确索引,它应该是好的.但是当我有100-200个用户的时候,它可以扩展吗？
用户如何互相交流？
>他们的行为(跳过)需要坚持下去,否则,如果他们超过99.9百分位数失去他们的行为.
>他们的文字是否修改在文章上,全局可见或仅对他们.
用户是否按类别检查帖子？
说了所有这些未知数,我会刺伤一下：
>如果问题4的答案为YES,则选项#2似乎从您的PK中判断出更好的声音.
>如果问题4的答案为否,则从您的PK看,选项#1似乎更加健全.
对于数据库大小,我认为您正在进行一些预优化.您应该考虑表宽度.由于你的表非常狭窄(只有几列,主要是int),你不应该太担心特定表的长度.
当这成为约束(您可以进行基准测试或等待在特定服务器上查看磁盘空间)时,可以轻松地对用户进行分片来扩展数据库.您基本上将不同用户放在不同的数据库服务器
>注意：问题1将决定上述的容易程度.
说出这一切,记住性能意义：
>这些名单将会变得很久.
>如果用户修改会影响其他用户,那么您将需要做相当多的扇出工作,才能将更新发布到特定的队列.
在这种情况下,您可能需要查看一些分布式缓存,如Memcached,Redis.
>注：根据问题2& 3,你甚至可能不需要持久化队列.
