0

おそらくこれに対する特効薬がないことは痛感していますが、それが問題になりつつあります。各ユーザーには、3 つのテーブルにまたがる数十万行のメトリック データがあり、これは 1 秒ごとに更新されます。

ユーザーがログインすると、多くのアセットのトップ ライン統計をすばやく配信したいと考えています (つまり、ナビの各アセットと一緒に、トップ レベルの統計があります)。

私はいくつかのアイデアを試しました。しかし、お願いします-誰かがこの分野でアドバイスや経験を持っていれば、それは素晴らしいことです. これまでに試したり調べたりしたもの：-

  • トップライン統計の静的バージョンを約 1 時間ごとに作成する - これは、すべてのユーザーとすべてのアセットにわたって集中的に行われます。ですから、これを定期的に行う方法はわかりません。
  • ページが読み込まれると、AJAX 経由で統計情報を呼び出して、処理して入力できるようにします (大規模なユーザーの場合、現在、トップレベルの統計情報を取得するには最大 10 秒かかる場合があります)。これにより、セッションの統計をキャッシュして、ページの読み込みごとにクエリをやり直す必要がなくなります。
  • クエリは 30 分間隔で実行されます。つまり、ログオンすると、クエリが実行され、次の 30 分間隔までロードされるたびに (わずか 1/2 秒) クエリ キャッシュが使用されます。

最初のものはほとんどのレッグを持っているようですが、少数のユーザーのみがこれらの統計を必要とすることを考えると、これを行う方法がわかりません.

4

2 に答える 2

2
  1. トップ ライン統計の静的バージョンを約 1 時間ごとに作成する - これは、すべてのユーザーとすべてのアセットにわたって集中的に行われます。ですから、これを
    定期的に行う方法はわかりません。
  2. ページが読み込まれると、AJAX 経由で統計情報を呼び出して、それらを処理して入力できるようにします (大規模なユーザーの場合、現在、トップレベルの統計情報を取得するには最大 10 秒かかる場合があります)。これにより、セッションの統計をキャッシュして、ページの読み込みごとにクエリをやり直す必要がなくなります。
  3. クエリは 30 分間隔で実行されます。つまり、ログオンすると、クエリが実行され、次の 30 分間隔までロードされるたびにクエリ キャッシュが使用されます (わずか 1/2 秒)。

mySQL のオプション 1 と 3 はマテリアライズド ビューとして知られています。MySQL は現在それらをサポートしていませんが、概念を完成させることができます。

数十万のレコードはそれほど多くありません。優れたインデックスと分析クエリを使用すると、かなり遠くまで行くことができます。残念ながら、この概念は完全には実装されていませんが、提供されたリンクに示されている回避策があります。

それは本当にトップラインの統計に依存します。秒単位のリアルタイム データが必要ですか、それとも 10 ～ 20 分または 30 分間隔でも許容できますか? イベント スケジューラを使用すると、集計されたデータを含むレポート テーブルの作成/更新をスケジュールして、より迅速にクエリを実行できます。このデータは、すべての重労働がすでに完了しているため、数分の 1 の納期で利用できます。その後、本番テーブルへの影響を心配することなく、これらのテーブルのインデックス作成に集中してパフォーマンスを向上させることができます。

于 2012-01-04T11:25:22.480 に答える
0

セットアップでデータ ウェアハウジング ドメインにいます。つまり、すべての NF1 ルールが適用されるわけではありません。したがって、私のアプローチは、トリガーを使用して別の統計テーブルを埋めることです。

于 2012-01-04T11:17:00.547 に答える