ほとんどのWebサイトでメッセージの表示が遅れるのはなぜですか？

YouTube動画の再生回数が常に遅れていることに注意してください。たとえば、動画には1000件のコメントがあり、500ヒットがあり、数時間後には10000ヒットになります。

これはYouTubeだけではありません。ほとんどのメッセージボードはそのように実装されており、再生回数は10分ごとなどに更新されます。

誰かがこの背後にある理由を知っていますか？

ありがとう。

ビューの記録は非常に単純です。「ビュー」アクションを表す行をテーブルに追加するだけです。データベースでロックが必要ないため、これは高速です。ヒープの最後に行を追加するだけです。

これをビューの合計数に集約するには、次のようなことが必要ですSELECT COUNT(*) FROM ...。つまり、計算の進行中にテーブルをロックする必要があります。または、UPDATE ... SET num_views = num_views + 1誰かがその行を表示するたびに、その特定の行をロックすることも必要です。

したがって、スケーラビリティの観点からは、誰かがビデオを見るたびに行を追加してからSELECT COUNT(*) FROM ...、10分ごとに行う方がはるかに効率的です。

YouTubeのアーキテクチャ、またはリレーショナルデータベースを使用してデータを保存するかどうかは実際にはわかりませんが、使用する原則はほとんど同じです。データの挿入は安価で、値の集計は（比較的）高価です。

ほとんどの場合、値は途中のどこかにキャッシュされているため、古いデータが表示されています。このデータが正確であることは重要ではないため、開発者は最新のデータよりもパフォーマンスを優先することにしました。データベースにアクセスして、サイトでのヒットごとに行カウントを実行して、この数値を更新しないようにします。そうしないと、しばらくキャッシュされます。

大規模なサイトを拡張するには、いくつかの段階でキャッシュを実行する必要があります。これは、ページキャッシング、サブページキャッシング、および/またはレコードキャッシングです。これらすべての組み合わせが有効になっている可能性があります。たとえば、新しいコメントが追加されるまでYouTubeページがキャッシュされている場合、誰かがコメントを投稿するまでに少し遅れが生じます。

ページビューを測定する方法はいくつかあります。

• レコードとしてデータベースに保存します。挿入は簡単ですが、カウントを提供するだけのレコードの場合、メンテナンスのオーバーヘッドが大きくなります。
• それをレコードとしてデータベースに保存し、定期的にカウントをロールアップします。挿入が簡単で、バッチ処理で必要な統計を収集し、その後クリーンアップします。
• データベースのカウント列を更新します。更新に費用がかかり（行ロックを想定）、メンテナンスのオーバーヘッドがなく、同時に同じページを要求する複数のユーザーを処理するときにパフォーマンスが低下します。
• ロールオーバー時にアクセスログファイルを処理します。データベースに余分なデータはありません。すべての処理はオフラインでバッチで行われ、必要なときに、必要な要約統計情報が更新されます。

上記の項目のうち、1つのオプションを除くすべては、更新がバッチで行われることを示唆しています。ビューの数は、時間的に重要な属性ではないため、これで問題ありません。ただし、バックエンドデータベースが追いつけないために、YouTubeで動画を視聴するのを待たせることは、時間を要する行動です。つまり、データベースの列を更新しても、YouTubeほどの規模のサイトでは機能しません。彼らが最後のオプションを選んだとしても、私は個人的には驚かないでしょう。Webサーバーは、使用しているIP、ページへの参照方法など、訪問ごとに多数の情報を記録します。これらをバッチで処理し、必要に応じて結果を要約することは意味があります。

これにはいくつかの理由が考えられます。すべては、それぞれのWebサイトで使用されているアルゴリズムに要約されます。ここの誰かが実際にYouTube開発者でない限り、私はあなたがここで正確な答えを得るつもりはないと思います。