ユーザーポイント、投稿数、コメント数など、セクション内の合計投稿数、合計コメント数などのデータの統計を実現したいと考えています。
例: ユーザーの投稿によりポイントが増加したり、投稿数の統計が更新されたり、同じセクション内の投稿の統計が変更されたり、その他の統計の変化が発生する可能性があります。
この場合、必要に応じてデータテーブル count() 統計を直接使用するべきでしょうか、それともテーブルにさまざまな統計フィールドを追加し、トリガーされたときにトランザクションを通じて完了するべきでしょうか?
個人的には後者を好みますが、統計の一貫性を確保するためにトランザクションを使用するのは少し無理があると思いますか? ?
しかし、トランザクションが使用されていない場合、ページング違反と同様に、いくつかの場所での統計エラーによってエラーが発生する可能性があります。
何か良いアイデアや提案はありますか?アドバイスをお願いします!
データ量が大きい場合、データベースはこの種のクエリ、特にユーザーに対するこの種のクエリを処理できません。
定期的にカウントしてからキャッシュに入れます
私はマスターではありませんが、やるならこのようなデータをredisに入れます。
[背景]
1 この問題は、データベースのパフォーマンスが既存のビジネス シナリオを満たしていないことが原因で発生します
2 提供されたビジネス シナリオによれば、データには特定のエラーが許容されます
【プログラム構成】
既存のプログラム構造はデータベースを直接呼び出して動作しますが、現時点ではデータベースの性能が要件を満たせないため、データベース間に[カウンター]の層を追加する必要があります。
リーリープログラムの調整の前後に、データベースの[追加]、[削除]、[変更]の3つのリンクに[アスペクト]を追加する必要があります。これはフックとしても理解できます
。 Redisは永続化できるため、通常[カウンター]に使用されます
【要注意】
1 DBの動作は正常でも、Redisの動作が失敗するため、データエラーが発生する可能性があります
2 エラーが発生する可能性があるため、エラー修正メカニズムが必要です。このメカニズムにより、サーバーへの負荷を軽減できます。小規模な場合は、mysql のカウントまたは合計を使用して
3 を更新するか、別の [トランザクション メカニズム] を使用して DB および Redis 操作のアトミック性を確保します。
InnoDB のカウントはすべてのデータ行をリアルタイムでスキャンする必要があるため、時間がかかります
Myisam はあまり使用すべきではありません
推奨事項
数据表添加统计字段
統計はバックエンド サービスを使用して処理されます。たとえば、バックエンドはスレーブに接続されていますが、ビジネスには影響しません。
初めての人は、データの蓄積に count() 形式を使用することはお勧めしません。累積形式を使用することをお勧めします。
新しいデータが追加されるたびに count() を使用してカウントする必要があるため、データベースにとって非常に負担がかかります。
そのため、これを行うことをお勧めします:
1. すべての統計データを保持するには、nosql を使用します。
2. 新しいデータを追加するときに、モジュールをトリガーして、対応するデータを蓄積し、元のデータを上書きします。
3. nosql ダウンの問題が確実に発生するようにするには、対応する統計データをデータベースに保存し、nosql データを定期的にデータベースに保存するロジック モジュールを作成することをお勧めします。
4. もちろん、定期的に count を使用して (これはサーバーがアイドル状態のときに実行できます)、統計が正しいかどうかを再確認することもできます