キャッシュすることでレポートのサーバーヒットを減らすRESTリソース
データベースにSQLServerを使用するASP.NetWebフォームを使用して構築された従来のアプリケーションがあります。レポートはSSRSを使用して生成されます。 ManifestContainerDetailsというメインテーブルがあります。このテーブルはレポート用です。マニフェストの発送が完了すると、そのコンポーネントの詳細がこのテーブルに保存されます。このデータは、出荷が完了するとシステムによって変更されません。
この表に基づく多くの報告があります。そして、多くのユーザーが同じレポートにアクセスします。テーブルは巨大ですが、ほとんどの場合、ユーザーは過去1週間以内に出荷されたマニフェストのレポートに関心があります。そのため、ほとんどの場合、ユーザーは複数の表現を持つ同じリソースを要求しています。
これは、リソースをキャッシュする良い機会のようです。そして、RESTは、http intermediariesの機能を利用してキャッシュを約束します。 キャッシュが行うこと--Ryan Tomayko および 中間HTTPキャッシュとは何ですか？
XSLTを使用して複数のリソースからレポートを作成することについての記事 RESTレポート-Eric Gropp を見つけました。
今、私は黒板の前にいる間に、実現可能性調査を設計するために次の質問があります：-
- 上記のシナリオをRESTサービスとして作成し、それに基づいてレポートを作成することは実行可能なアイデアですか？
- そのようなシナリオでキャッシュは可能ですか？
- 複数のRESTリソースに基づいて高度なレポートを生成するためのツールはありますか？
今、私は黒板の前にいる間に、実現可能性調査を設計するために次の質問があります：-
上記のシナリオをRESTサービスとして作成し、それに基づいてレポートを作成することは実行可能なアイデアですか？そのようなシナリオでキャッシュは可能ですか？複数のRESTリソースに基づいて高度なレポートを生成するためのツールはありますか？
データウェアハウスが必要なようです。キャッシングは両刃の剣であり、実装以上に不思議に思う傾向があります。顧客がレポートを取得している場合は、notレポートデータを取得して、データがアプリケーションに影響を与えることを望んでいます。
テーブルは巨大ですが、ほとんどの場合、ユーザーは過去1週間以内に出荷されたマニフェストのレポートに関心があります。
カスタムエクスポートSSIS（ETL）でデータをスライスすると、単一のデータソースに対してレポートを作成するのではなく、アプリケーションでデータを変更する必要があります。すべてのFACTデータを使用してFACTテーブルをクエリする方が、多数のビットフラグを使用してシステムにまだポンプされているレコードをクエリするよりも簡単です。