設計之前，請先確認你的資料規模：

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不住的，分佈式擴展不可避免，但要注意複雜度也是隨著成長，所以需要你根據自己的資料規模和技術條件，合理地選擇方案。