2

私はNumViews、DBテーブルの各オブジェクト/行のカウンターを保持する必要がある小さなWebプロジェクトに取り組んでいます。行へのすべての更新が開始されると、テーブルのオブジェクト数が増え、サイトの使用が増えるため、パフォーマンスが大幅に低下するのではないかと心配しています。

重要な場合は、MSSQL2K5で.NET3.5を使用しています。

助言がありますか？

前もって感謝します！

--ジョエル

DBの使用に関する現在の推測では、1秒あたり約66回の読み取りが持続します。

カウンターを別のテーブルに分割するというアイデアが好きです。それをサポートする記事やホワイトページを知っていますか、それとも誰もがしていることの1つですか？:-P

また、更新中に、DBはテーブル全体をロックしますか、それともその特定の行だけをロックしますか？私は一列だけを想定しますが、確かではありませんでした。

ありがとう、

--j

4

4 に答える 4

1

私は提案します：

  1. 行->カウントデータを別のテーブル（固定サイズの列）に配置して、カウントを維持するためだけにメインテーブルに継続的に書き込みを行わないようにします

  2. それへのアクセスを抽象化して、アプリケーションが成長するにつれて、DBテーブルをより効率的な構造に置き換えることができるようにします

于 2008-12-02T18:59:14.263 に答える
1

各ビューをタイムスタンプ付きで保存する、書き込み専用の「ビュー」イベント テーブルの使用を検討してください。ロックの問題はなく、汗もかかず、最も詳細なレベルで完全な監査証跡が作成されます。小さなレコード、1 日あたり ~ 5MM のレコード?

誰かが後でそれを欲しがるだろうし、今すぐ追加して使うのは簡単だ。誰かが分析/マイニングをしたい場合、これは役に立ちます。そのボリュームでは、他に使用することはあまり想像できません。

于 2008-12-02T19:24:15.303 に答える
0

これは深刻な問題になると思います。読み取りは100％スケーラブルですが、書き込みにはロックが必要であるため、すべての読み取りに暗黙的にロックオーバーヘッドを課し、それらをシリアル化します。維持しなければならない読み取り率がどのくらいになるか、何か考えがありますか？RDBMSの一部として利用できる監査オプションを確認しましたか？

于 2008-12-02T19:03:53.003 に答える
0

次のいずれかを行うことを検討します。

  • アプリケーション内でバッファを使用し、バッファがいっぱいになるたびに一連のビューをバッチで書き込みます
  • ローカル ログ ファイルを使用し、その結果を時々バッチ ロードに集約する
  • イベント システム (Pub/Sub) を使用して、後で別のアプリケーション (サブスクライバー) によって非同期に処理されるアプリケーションからイベントを発生させます。次のプロジェクトを見てみましょう
于 2008-12-10T21:51:58.637 に答える