REST は、サーバー上にクライアント状態のない Web アプリケーションを提唱します。有名なショッピング カートの例は、通常はデータベースに存在するリソースに変換されます。
データベースはすでに多くのアプリケーションでボトルネックになっているため、この種のデータにデータベースを使用することは良い方法なのだろうかと思います。代わりに、ステートフルなエンタープライズ Java Bean を使用したほうがよいのではないでしょうか? アプリケーション サーバーは、クラスタリングを考慮して設計されています。
2 つのアプローチの長所と短所は何ですか?
アプリケーション サーバーへのセッションの保存は、次の場合にのみ機能します。
クライアントがクラスター内の同じアプリケーション ノードに常に接続することが保証されていない場合は、中央データベースや EJB にセッションを格納することはできます。
考慮すべきもう 1 つのアプローチは、memcachedなどのサービスを使用することです。これはどちらの場合でも機能します。
一般に：
データベース
インメモリ (非分散ステートフル Bean)
どちらを選択するかは、アプリケーションの要件と環境に完全に依存します。すべての条件が同じであれば、ロード バランシングと信頼性の利点からデータベース ソリューションを好みますが、これは多くのシナリオで簡単にやり過ぎになる可能性があります。
アプリ サーバーが停止するとどうなりますか。セッション状態はまだ重要ですか? データベースに行きます。
サーバーがすべての同時ユーザーを処理できるよりも多くのセッション状態がありますか? データをデータベースに移動し、その時点で本当に必要なものだけを引き出すことが解決策になる可能性があります。
アプリはクラスター化されていますか? その場合、中央データベースは、セッションデータが常に利用可能であることを確認します。
それ以外の場合: セッションに保存するだけです。
極端なスケーリング要件がありますか (stackoverflow やさらに多くのトラフィックがあるサイトなど)? データベースを使用しない方法を見つけます。
データベースがボトルネックになることが多いのは事実です。ただし、適切にセットアップされたデータベースは、数バイトのセッション データを問題なく処理する必要があります。より複雑なデータとクエリは、パフォーマンスを犠牲にします。
他のすべての項目は良い提案です。もう 1 つ: 絶対に必要でない場合は、セッション状態を使用しないでください。
データベースにセッションを保存することは、(一般的に) いくつかの単純な理由から悪い考えです:
セッションの一般的な使用法は、データベース サーバーから共通データを何度もロードする必要がないようにすることです。セッションが db サーバーに保存されている場合は、実際にはあまり達成していません。
セッションは、単一ページの実行ごとにシリアライズおよびデシリアライズする必要があります。これは、セッション データをサーバーから取得し、使用するかどうかに関係なく、ページが読み込まれるたびにサーバーに書き戻す必要があることを意味します。
私の経験では、実際に必要なときにデータベース サーバーからデータをプルするだけで十分です。ほとんどの場合、実際にはパフォーマンスの問題を悪化させているのに、単にパフォーマンスの問題を解決していると考えているという理由だけで、あらゆる種類の短命のデータをセッションに入れます。
さらに、データの量を制限すると (たとえば、ユーザー ID、名前など)、それを暗号化された Cookie クライアント側に格納でき、まったく心配する必要がなくなります。
MemCache は 1 つのオプションです。ただし、データベースの使用状況を真剣に調べて、最初にクエリとスキーマのパフォーマンスを調整できるかどうかを確認します。