私は、ユーザーが各投稿に賛成票/反対票を投じることができるコレクションを持っていPostsます。Usersこれをmongodbデータベースに保存して、ユーザーが特定のドキュメントに複数回投票できないようにする最善の方法は何ですか?
私が思いついた最も単純な nosql っぽい解決策は、各Postドキュメント内で投票した user_ids の配列 (または、ユーザーが投票を変更できるように、 (user_id, vote)whereが +1 または -1 の配列) を格納することです。vote各投稿が何千票もある可能性があることを考えると、パフォーマンスの観点からは良い考えですか?
上位の投稿が数十万票を獲得できる Reddit のような本当に人気のある Web サイトについてはどうでしょうか?
上位の投稿が数十万票を獲得できるRedditのような本当に人気のあるWebサイトはどうですか？
彼らをどう思いますか？リレーショナルデータベースでアイデアを使用すると、ユーザーIDポインター用の整数、ポストポインター用の整数、および投票用のバイトが得られます。投票ごとに合計9バイト。
確かに、インデックスのオーバーヘッドがあります。投票ごとに合計15バイトにします。600万票は、90メガバイトのディスク容量を消費します。
Redditは一定期間後に投稿をロックするため、編集したり投票したりすることはできません。したがって、Redditは個々の投票を永久に保存する必要はありません。合計に投票するだけです。
user_id現在、MongoDB ドキュメントは最大 16MB に制限されているため、Gilbert の計算が正確であると仮定すると、600 万個すべてをドキュメントに格納することはできませんPost。
Userただし、代わりに投票をドキュメントに保存することを検討できます(つまりpost_id、特定のユーザーが投票した )。ユーザーが 600 万の異なる投稿に投票する可能性ははるかに低いため、この方法ではサイズ制限にすぐに到達することはありません。
これを処理する別の方法: 特定の投稿に対して多くの投票が予想される場合は、Postドキュメントの外部に投票を別のコレクションに保存し、SQL 方式の多対多 JOIN テーブルと同様に、追加のクエリを実行することをお勧めします。 :
user_votes { user_id: ObjectId(...), post_id: ObjectId(...), vote:-1 }
(user_id, post_id) に複合インデックスを作成します。