オンラインユーザーを保存するために別のテーブルを使用する必要がありますか、それとも既存のメンバーテーブルの追加フィールドを使用する必要がありますか？

Question

私は、ユーザーが社会的に対話できるようにするオンラインシステムに取り組んでいます。もちろん、実際にオンラインになっているユーザーを特定できることが重要です。 HTTPがステートレスであり、セッションの使用について知っているので、ユーザーの最後のアクティブ時間を任意の有効期限と比較することでこれを達成する必要があります。

最終的な質問は次のとおりです。既存のメンバーテーブルにいくつかのフィールドを追加する必要があります（ last_active_time 、 is_user_online 、 hide_online_status 私の最初の考えは、簡単にするために既存のテーブルを使用することです。複雑さのレベルを除いて、一方と他方の利点/欠点は何ですか？

Answer 1

別のテーブル内でこれを維持します。 100万人のユーザーがいて、だれがオンラインであるかを知りたい場合、そのテーブルを何度もスキャンしてその情報を見つけることは望ましくありません。あなたの「オンライン」テーブルは比較的小さくなり、過去5分ほどで入っていない人を定期的にスキャンし、オンラインテーブルからそれらを削除して、「last_seen」のメンバーテーブルで必要なものをすべて更新することができます;

Answer 2

新しいテーブルを作成します。

まず、哲学的な理由があります。それは、1つのオブジェクト（読み取り：テーブル）が1つの目的を持つべきだということです。これはデータベースの論理設計ではかなり曖昧になりますが、それでも良い原則です。

しかし、実際の理由は物理的な設計にあります。まず、任意の時点でログオンするユーザーの数は、ユーザーの総数よりもはるかに少ないと想定できるため、ストレージ要件は低くなります。また、ストレージ要件が低いと、読み取りおよび更新するブロックが少なくなるため、データベースの負荷が減少します。

さらに、このデータをメインテーブルに配置すると、それらのブロックははるかに広いスペースに散らばり、データを変更するとブロックの内容が絶えず拡大および縮小します。

最後に、おそらく現在オンラインになっているユーザーを確認するために、いくつかのインデックスが必要になります。そして、これらのインデックスは、（1）さらに多くのスペースを占有し、（2）物理的にディスクに書き込む必要のあるさらに多くのダーティブロックを作成し、（3）更新競合のポイントを導入します。

Answer 3

これは、予想されるユーザー数に依存すると思います。ユーザー数が数千人になる場合は、ユーザーテーブルで、オンラインステータスをユーザーの属性にするだけです。それより多くなる場合は、online_usersテーブルが必要になり、メインのユーザーテーブルへの外部キーを使用して、その情報をそこに保持します。上記のポスターで言及されている利点を享受するには、online_usersテーブルから非アクティブなユーザーを削除するタスクを数時間ごとに実行する必要があります。