小编Ran*_*nty的帖子

我目前正在设计一个项目，我需要 DBA 的专业建议。

我的项目将采用类似于堆栈交换网站中使用的投票系统。我有用户和内容片段，用户可以为他们喜欢或不喜欢的内容片段投票。请注意，我将在提要列表上有投票上/下选项，所以如果我加载 30 个内容片段，我还需要加载用户对每个片段的投票数据，因为如果用户已经，上/下按钮应该高亮已投票支持特定作品。换句话说，我希望votes桌子上的负载很大。我在想这样的基本结构：

表users (user_id, ...)，表content (content_id, ...)，表votes (vote_id, user_id, content_id, datetime, vote)。但是，我对这种设计表示怀疑。

假设我有 10k 个用户和 1k 个内容片段。table 中有多达 1000 万条记录votes。如果我开始考虑扩大规模，我可以想象出一个大问题。内容不会去任何地方，旧的投票也是如此，所以网站运行的时间越长，表中的记录就越多，运行速度就越慢。

假设几年后我将拥有 100k 用户和 20k 内容块。这多达 20 亿条记录。我知道并不是每个用户都会对每个内容块进行投票，但问题很明显 - 该设计有一个限制（限制我的意思是当行数达到某个点时选择查询会很慢）。

所以我的问题是：

1. 这种设计真的有限制吗？如果有，如何处理？1.1. 如果votes表上的选择查询会变慢，我该怎么做才能加快速度？
2. 有没有更好的方法来设计这种关系？
3. 我如何缓存这些数据？或者甚至需要适当的索引？
4. 你会为votes表推荐什么样的索引？我需要一个简单的双字段索引 ( user_id, content_id) 是否正确？
5. 大部分负载都会在最近的内容上进行，也许我应该创建类似recent_votes表格的东西，它会保存重复的数据，但仅在最后说 24 小时内，大多数负载都会继续进行，如果用户想要一些较旧的数据，他会用更大更慢的表来处理所有选票吗？这有任何意义吗？

我真的很想从一开始就做正确的事情，所以在几年内我不会以一个缓慢的网站结束。感谢您的时间。