设计之前，请先确认你的数据规模：

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