2012-02-07 8 views
3

私は、カスタムオブジェクトタイプの約500要素を含む配列での作業が必要なWebプロジェクトの初期段階にあります。オブジェクトには、(ユーザーの入力に基づいて)10〜40のフィールドが含まれている可能性があります。大部分はブーリアン、ストリング、フロートです。私はこのプロジェクトでPHPを使うつもりですが、私はこの問題をJavaでどのように扱うかを知ることにも興味があります。データをデータベースまたはセッションに保存する

「時期尚早な最適化はすべての悪の根源です」と私は知っていますが、私は今、これらの配列をどのように扱うべきかを決定する必要があると思います。 Sessionオブジェクトにそれらを保持するのか、それともデータベース(mySQL)に格納してセッションの最小量のキーだけを保持しますか?セッションでデータを保持するとアプリケーションの処理は高速になりますが、訪問者の数が増え始めると、あまりにも多くのメモリを消費する危険性があります。一方、常にデータベースからの読み書きは、パフォーマンスを低下させます。

私はこれらの2つのアプローチの間の線がどこにあるのかを知りたいと思います。セッションの中でデータを保持するにはあまりにも多くのデータをいつ決めるのですか?

+0

あなたの質問に答えがあります。少なくても頻繁にユーザー、ストアとしてセッションに行く;多くのユーザーがDbベースのアプローチに行きます。今、「less」と「a lot」は相対的な用語です。 – Nishant

+0

良い質問です。アプリの最大メモリサイズと予想される最大ユーザーログインを特定できます。 1人のユーザーのデータを格納するために必要なメモリの量を計算します。ユーザーの数が一定期間(Facebookと違い!)異常に成長しない場合は、セッションに保存できます。 – Jayy

答えて

2

私はこのような問題に直面したとき、私は速く保たれるユーザーデータのサイズを推定しようとします。

たとえば、テキスト、数値、日付などの平均値を50バイトにする40個のフィールドを持つ要素が500個あるとします。したがって、このストレージには1人のユーザーあたり約1MBのメモリを確保する必要があります。そのため、このキャッシュに対してのみ1000人ごとに約1GBのメモリが必要です。

サーバリソースの可用性に応じて、ボトルネックを見つけることができます.1000ユーザがCPU、メモリ、DB、ディスクアクセスを消費します。このシナリオで1GBの問題がありますか?もしそうなら、それらをメモリに保持しないとDBに保管してください。

別のオプションは、いくつかのコストで、インメモリDBまたはあなたのためにすべてを行い分散キャッシュソリューションを使用することです:

  • 建築複雑結局
  • ライセンスコスト
0

私はあなたが各ユーザのためにその量の一意のデータを持っていれば驚くでしょう。理想的には、このデータの一部はユーザー間で共有され、最後に使用されたエントリを格納するアプリケーションレベルのキャッシュがあり、欠落している場合はデータベースから透過的にフェッチできます。

この種の設計は、Javaで実装するのは比較的簡単ですが、PHPにはアプリケーション状態の組み込みサポートがないため、多少複雑です(場合によっては効率が低い)。

関連する問題