現在、提案されているテーブル構造は次のとおりです。
data_table
->impressions
->clicks
->ctr
また
data_table_1
->ctr
data_table_2
->impressions
->clicks
どのようなクエリが実行されますか? インプレッションは毎秒約 500 回更新されます。クリック数は毎秒約 1 回更新されます。ctr には毎秒約 500 の更新があります。
これで、アプリケーションは ctr を使用してデータを並べ替えます。ctr は によって算出されるクリック率ctr = clicks/impressions
です。クリックの更新がない限り、記事のすべてのインプレッションが増加し、同じ関係で ctr が減少しているため、ctr を更新する必要がないことに気付きました。クリックがない限り、ctr を更新する必要はありません。更新します。
現在、更新クエリは「UPDATE data_table SET インプレッション = インプレッション + 1、ctr = クリック / インプレッション WHERE 何か = 何か」のようなものです。
これは、一度に 2 つのフィールドが更新されても、実行されるクエリは 1 つだけであることを意味します。
現在のボトルネックは、これらの 500 の更新により、このテーブルの選択が遅くなることです。1 秒あたり約 20 の選択があります。そこで、テーブルを分けることにしました。新しいテーブル スタイルでは、更新は別のテーブルで行われ、選択は別のテーブルで行われることが提案されています。インプレッションを含むデータ テーブルは非常に頻繁に更新されるため、インプレッションの更新を実行すると、このテーブルのパフォーマンスが大幅に向上します。これは、data_table_2 の選択も高速になり、誰かがクリックするたびに ctr を更新できることを意味します。
そのため、新しいテーブル構造を使用する必要があるかどうかを知りたかっただけです。あなたは何を提案していますか?私の提案の長所と短所!