开发者社区> 问答> 正文

模型里包含需要不断增加的数据应该怎么设计?

需要设计的数据模型是一个投票帖子,用户投票后需要记录下来,以免重复投票。 现在的设计是把投过票的用户id保存为在投票贴里的一个数组。

mongodb在文档中嵌入不断增加的数据会对性能有损害,怎么设计能更好一些?

展开
收起
a123456678 2016-06-29 10:18:59 1887 0
1 条回答
写回答
取消 提交回答
  • 设计之前,请先确认你的数据规模:

    如果你的数据规模很小,只有很少的人投票(1000人以下),担心是多余的,尽管会增长,简单放到一个数组也是可以的(注意mongodb一个document的大小限制);
    如果投票人数超过1K,并且随着不断增长,达到以W(万)计的规模,早早地独立出来,另建一个Collection存储帖子的投票记录;
    如果投票人数达到以W计的规模,并且这个投票的频率也比较频繁(或者有恶意刷票),maybe你应该考虑用缓存,将所有投票人的id存到一个集中式缓存中,通过缓存(redis中原生支持Set结构)来确认是否重复投票,然后后台再定时同步到mongodb;
    如果投票人数达到百万级别,且投票频率也客观,这是你肯定要用缓存,而且还是分布式的缓存集群,将所有投票人的id,经过运算(可以简单地做一个mod运算)映射到某一台缓存服务器,然后的处理方式跟3中类似;
    跟4类似的一种处理:在服务器的前端针对用户id通过apache或者nginx进行转发,转到不同的应用服务器进行处理,应用服务器同样是做分布式水平扩展; PS:你所描述的只是业务场景中的很小的一个方面,不管是采用nosql还是SQL,数据规模一上来,单机必然是hold不住的,分布式扩展不可避免,但要注意复杂度也是随着增长,所以需要你根据自己的数据规模和技术条件,合理选择方案。

    2019-07-17 19:48:49
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
动态、高效,蚂蚁动态卡片的内核逻辑 立即下载
图计算优化技术探索 立即下载
存储分层企业数据存储类型选择与优化 立即下载