データベース

Question

のためのデザイン、私は4つのテーブルがあります：users、posts、categories、categories_map

postsがcategory_id
categories_mapが私の目標は、キューを作ることですuser_idとcategory_id

が含まれ、id、textを持っていますユーザーはプレビューできます。また、ユーザーは一部の投稿をスキップしたり、その中のテキストを編集することができます。ユーザーが投稿をスキップした場合、投稿には表示されません。ただし、cronはスクリプトを実行するため、ユーザーはシーケンスを変更できません。

私が考える最初のアプローチは user_id、post_id、text_modified、is_skipped、last_postedが含まれていますテーブルを作成することです。だから、cronジョブが実行されるとタイムスタンプが残ってしまい、次回はこの投稿は取得されず、ユーザーはこの投稿のテキストを簡単に変更することができます。

2番目の方法は、ユーザuser_id、post_id、category_id、text_modifiedのキューが生成される別のテーブルを作成することです。だから、cronの仕事は簡単にこのテーブルに従って行を終えた後に行を削除することができます。しかし、このアプローチでは、30人のユーザーがいて、平均で3つのカテゴリにそれぞれ5000のポストが含まれていると、私のテーブルにはすでに450000の行があります。はい、それが正しくインデックスされていれば、それはすべて良いものでなければなりません。しかし、100〜200人のユーザーがいる場合はスケーラビリティがありますか？

私はどちらの方法をとるべきですか、それとも他の解決策がありますか？

Answer 1

多くのものは、製品によって異なります。私たちは分かりません：

1. どのようにユーザーが相互に作用していますか？
2. 彼らの行動（スキップ）は永続化する必要がありますか、または99.9パーセンタイルを超えて失われても問題ありません。
3. 投稿に対するテキストの変更は、グローバルに表示されるのか、または表示のみに制限されますか。
4. ユーザーはカテゴリ別に投稿をチェックしていますか？ 4の質問への答えは、YESであれば、オプション＃2は、より多くの音があなたのPKから判断すると思われる
   • ：

は、これらすべての未知数言った、私はそれで刺してみましょう。

質問4の回答がである場合、の場合、オプション1は、あなたのPKから判断するとより健全なようです。

データベースサイズについては、あらかじめ最適化を行っていると思います。テーブルの幅を考慮する必要があります。あなたのテーブルは非常に狭い（2つの列と主にint）ので、特定のテーブルの長さについてあまり心配しないでください。

これが制約になる（ベンチマークできる、または特定のサーバー上のディスクスペースを待つ）場合、ユーザーを簡単にシャーディングすることによってデータベースをスケールアップすることができます。基本的には、異なるユーザーを異なるDBサーバーに配置します。

• 注：質問1は、上記のように簡単にと判断します。リストは本当に長い得ようとしている
  1. ：

は、すべてこれは、心のパフォーマンスに影響してくださいと述べました。

ユーザーの変更が他のユーザーに影響を及ぼす場合は、更新を特定のキューに公開するためにかなりのファンアウト作業を行う必要があります。

この場合、Memcached、Redisのような分散キャッシュを見てみるとよいでしょう。

• 注：質問2 & 3への回答に応じて、あなたも、キューを永続化する必要はないかもしれません。