デザインする前にデータサイズをご確認ください:

1. データの規模が小さく、投票する人が少ない場合（1,000人未満）は、大きくなりますが、単純に配列に入れても大丈夫です（サイズ制限に注意してください）。 mongodb のドキュメント);
投票者の数が 1,000 を超え、増加し続けて W (1 万人) の規模に達した場合は、早期に独立して、投稿の投票記録を保存する別のコレクションを作成します。
2. 投票者の数が W に達し、投票の頻度が比較的頻繁である (または投票の悪意のある操作がある) 場合は、キャッシュの使用を検討して、すべての投票者の ID を集中キャッシュに保存し、そのキャッシュを使用する必要があるかもしれません ( Redis はネイティブで Set 構造をサポートしており、繰り返し投票するかどうかを確認し、バックグラウンドで定期的に mongodb に同期します。
投票者の数が数百万に達し、投票の頻度も客観的である場合は、キャッシュを使用する必要があります。また、計算を通じてすべての投票者の ID をマッピングするための分散キャッシュ クラスターでもあります (単純に mod 操作を行うことができます)。特定のキャッシュ サーバーの場合、処理方法は 3 と同様です。
4 と同様のプロセス: サーバーのフロントエンドで Apache または nginx を介してユーザー ID を転送し、処理のために別のアプリケーション サーバーに転送します。アプリケーション サーバーは分散水平拡張も実行します。 PS: あなたが説明しているのはビジネス シナリオのごく一部にすぎません。NoSQL を使用するか SQL を使用するかに関係なく、データの規模が増大すると、必然的に 1 台のマシンでは保持できなくなり、分散拡張が避けられなくなります。時間の経過とともに複雑さも増すため、データ サイズと技術的条件に基づいて合理的にプランを選択する必要があることに注意してください。