c# - Windows フォーム アプリケーションの中間層キャッシュ

Question

C# 4.0 で記述された単純な Windows フォーム アプリケーションがあります。アプリケーションは、データベースからのいくつかのレコードを表示します。アプリケーションには、ユーザーが開始するクエリ オプションがあります。

ジョブとして呼び出すことができるデータベース内のレコード JobID と Status の 2 つの列を検討してください。

これらは、実際にはプロデューサー コンシューマー サービスのように機能する 2 つのバックグラウンド サービスによって更新されます。ジョブのステータスは、背後で実行されているこれらのサービスによって更新されます。

データベースからレコードをクエリするオプションを持つユーザーの場合、たとえば、ステータス (送信済み、処理中、完了) に基づいてデータをクエリすることができます。これにより、数千のレコードが発生する可能性があり、GUI はこれらのデータを表示する際にパフォーマンスの不具合に直面する可能性があります。

したがって、クエリ結果のチャンクをページとして表示することが重要です。ユーザーが手動で更新するか、新しいクエリを作成するまで、GUI は更新されません。

たとえば、ジョブはサービスから常に更新されているため、ジョブのステータスはいつでも異なる可能性があります。ページが DB からフェッチされた時点でデータを持っている必要があるという基本的な要件。

DBからデータを取得するためにLINQ to SQLを使用しています。使い方はとても簡単ですが、この需要を満たすために必要な中間レベルのキャッシングはありません。プロセス メモリを使用して結果をキャッシュすると、レコード数が非常に多い場合、ページ メモリが極端に増加する可能性があります。残念ながら、LINQ は DataContext オブジェクトを使用した中間層のキャッシュ機能を提供していません。

C# 4.0 + SQL Server + Windows 環境でページング メカニズムを実装するための望ましい方法は何ですか?

結果を一時的にキャッシュとして保存できる複製されたテーブル/DBが必要だと思う代替案のいくつか。または、エンタープライズ アプリケーション ライブラリのアプリケーション キャッシュ ブロックを使用します。これは、ほとんどの開発者が直面する典型的な問題だと思います。これは、この問題を解決する最も効率的な方法です。(注: 私のアプリケーションと DB は同じボックスで実行されています)

Answer 1

キャッシングはパフォーマンスを向上させる確実な方法ですが、キャッシング戦略を適切に実装することは、思っているより難しい場合があります。問題は、キャッシュの有効期限を管理すること、または基本的にキャッシュが必要な程度まで同期されるようにすることです。したがって、キャッシングを検討する前に、そもそもキャッシングが必要かどうかを検討してください。質問から収集できることに基づいて、データ モデルは比較的単純で、結合を必要としないようです。その場合、テーブルとインデックスをページネーション用に最適化してみませんか? SQL サーバーと Linq To SQL は、何千ものレコードのページネーションを透過的かつ簡単に処理します。

一度にあまりにも多くのレコードを表示することは、GUI にとって禁止であり、ユーザーにとっても禁止であると述べているのは正しいです。任意の時点で画面いっぱいに表示されるよりも多くのレコードを見たいと思うユーザーはいないでしょう。ユーザーが要求するまでデータを更新する必要がないという制約があるため、クエリの数は比較的少ないと想定しても安全です。DB がアプリケーションと同じボックスにあるという追加の制約により、キャッシュが不要であるという点がさらに明確になります。SQL サーバーは既に内部的にキャッシュを行っています。

パフォーマンス チューニングに関するすべてのアドバイスは、最適化を試みる前にパフォーマンスをプロファイリングして測定する必要があることを示しています。Donald Knuthが述べているように、時期尚早の最適化は諸悪の根源です。