0

シナリオ

レポートをその場で (SQL データベースから取得した情報に基づいて) 生成できる Web アプリケーションを構築しています。これらのレポートにはグラフが含まれており、オンザフライで生成することもできます。これらのチャートには機密情報が含まれているため、サードパーティのチャート API (つまり、Google チャート) を使用することは問題外です。

問題

これらのチャートを生成するために PHP の GD 拡張機能を使用しています。かなり遅いです。キャッシュは有効な方法ですが、問題は膨大な数のチャートが存在することです。ただし、要求されるチャートの大部分は、以前に生成されたものになると思います。

部分解

グラフは、データとその他の情報 (サイズ、グラフの種類など) を使用して生成されます。これらはチャートを一意に識別できるため、この情報に基づいて各チャートに一意のハッシュを与えて保存します。これで、新しくリクエストされたチャートのハッシュを計算し、すでにレンダリングされているかどうかを確認できます。

これに関する問題は、衝突のイベントです。それを回避するために、ハッシュとシリアル化された形式のデータを SQL テーブルに保存することを考えています。その後、キャッシュ ヒットが発生した場合でも、データ自体を比較します。

私はこれを過剰に設計していますか?(これは 160 ビットのハッシュ - SHA1 です)
これを処理するより良い方法はありますか?

4

3 に答える 3

0

これらのチャートを生成するために PHP の GD 拡張機能を使用しています。かなり遅いです。

遅いビットであるGDではないのではないかと思います。最も可能性の高い候補は、データを照合する処理です (データベースから?)。その場合、データベース スキーマを最適化したり、事前に統合されたデータを使用したりすることで大きなメリットが得られる可能性があります。

クエリ出力をキャッシュすることも検討できますが、他の場所で同じデータを使用していない限り、グラフ イメージをキャッシュする方がおそらく簡単です。

これに関する問題は、衝突のイベントです。

時期尚早の最適化 - それは起こりません。ただし、どうしても必要な場合は、グラフの生成に使用しているメタデータを分割し、別のファイルに保存して (同じハッシュを介してインデックスを作成します)、実行時に比較してください。なんとか衝突した場合は、ホイップラウンドを行い、飲み物を購入します.

jpgraph をご覧になることをお勧めします。これは優れたソフトウェアであり、キャッシュが組み込まれています。

C.

于 2010-07-16T12:53:16.657 に答える
0

仕事で使用しているChartDirectorを見てみましょう。これは GD ライブラリに依存していません。より高速である必要があります。

于 2010-07-16T08:05:27.320 に答える
0

ほとんどの場合、ハッシュされたデータの長さが 160 ビット未満であれば安全です。そうしないと、あなたが言うように、衝突が発生する可能性があり、データの比較が必要になります。

于 2010-07-16T08:01:42.660 に答える