PHPで最も信頼性の高いセッションストレージは何ですか：Memcache、データベースまたはファイル？
PHPセッションを処理するための最良かつ最も安全な方法は何ですか。セッションを保存する最良の方法は次のとおりです。
データベース（信頼性は高いが、ボトルネックが高く、速度が遅い、データベース使用率の高いWebサイトには適さない）？
Memcache（超高速ですが、より多くのセキュリティ問題、サーバーの再起動時にデータが失われる可能性、およびキャッシュがいっぱいになるとデータが失われる可能性があります）？
ファイル（デフォルトオプション、ファイルI/Oからの読み取りと書き込み、セキュリティの低下などから遅いと思います）。
どの方法が最適ですか？これらのアプローチのそれぞれの問題と良い点は何ですか？
他の問題（キャッシュサイズ、セキュリティなど）を簡単に解決できるため、Memcachedに保存することをお勧めします。
facebookは、memcachedの＃1コンシューマです。興味のある方はお読みください： http://www.facebook.com/note.php?note_id=39391378919
他の問題を解決するには？
MySQLでMEMORYストレージエンジンを使用するのはどうですか？
Memcacheほど高速ではありませんが、プレーンSQLを使用できるという利点があります。また、通常のストレージエンジンが不要な場合は使用でき、ユーザー/リクエストの数が増えた場合はMEMORYに切り替えることができます。
頻繁に変化するWebアプリに大量の統計データを保存するために使用しているため、セッションの処理には使用されていませんが、この目的には適していると思います。
日常的なアプリケーションの大部分では、データベースにセッションを維持することは問題ありません。 SQLサーバーが処理できる並行性の量とレベルは十分以上です。重要なのは、各エントリのサイズを小さく保ち、不要な行を定期的に削除することです。そしてもちろん、適切な索引付け。
ファイルシステム-これを実行する必要があることを私は見たことがありません。何千もの小さなファイルではなく、テーブルの行を管理するシンプルさを好みます。さらに、セッション統計を調べたい場合は、ファイルをまたがってクエリを実行することはできません。
PHPを使用すると、セッションハンドラーを簡単に交換できることに注意してください。したがって、1つのストレージフォーマットから始めて、それほど面倒な作業を行わずに別のストレージフォーマットに移行できます。
この ブログ投稿 は、Magentoを使用したさまざまなセッションストレージエンジンのパフォーマンス比較の結果を示しており、最大約75人の同時接続ユーザーには実際にはパフォーマンスの違いはないと結論付けているようです。
これらのレベル（1秒あたり約5トランザクション、つまり12時間で約430kヒットになる）では、ファイル/ DB/Memcache/Redisはすべてうまく処理されるため、他のすべてのオーバーヘッドがパフォーマンス数値を支配すると思います適切に使用すれば、汗をかくことのない交通です。
これには、スケーラビリティ、信頼性、セキュリティなどの他の要素が残ります。
攻撃者はアプリケーションコードを変更するか、少なくとも読み取り専用であってもキーとストレージアクセスプロトコル/資格情報を発見することができるため、ファイルストレージを危険にさらすことは他のものも危険にさらす可能性があることを最初に述べたいと思います。アクセス。ファイルストレージは、ボリュームの少ないサイトで適切に機能し、セットアップが簡単で、理由を簡単に判断できます。ディスクをヒットしたと言うだけで、DB読み取りもディスクにヒットし、DBがそれをキャッシュできる場合、OSもセッションファイルをキャッシュしている可能性があります。また、1つのファイルが読み込まれ、ファイル名がわかっている場合は、ファイルシステムがそのファイルシステムにアクセスできます。 PHPを使用している場合、アプリケーションを提供するためだけにシステムが実行する必要があるファイル読み取りの数を知っていますか？欠点は、1つのディスクに保持できるファイル数の制限にすぐに到達するため、あまり遠くに行くことができないことです。
Memcacheは比較的高速であり、Memcacheクラスのソリューション（Redisなど）をより幅広く検討している場合は、メモリ内の読み取りで永続性を保証して速度を上げることもできるため、両方の世界を最大限に活用できます。それらはまた、推論するのが比較的簡単であり、セッションのキーバリューの性質はまさにこれらが行うように設計されているものです。これらのうちの1つを埋めるためにセッションにどれだけの時間を費やす必要があるか知っていますか？いずれにせよ、あなたの選択肢のすべては、あなたが彼らの能力に達した場合にあなたに妥協を強いるでしょう。ディスクはファイル（ここでは数とサイズの要素）でいっぱいになり、キャッシュストアは容量でいっぱいになり、データベースの行数は限られ、ファイルアプローチと同じディスク容量制限があります。また、これらのシステムは、分散方式で実行する場合にのみ分散されます。ほとんどは、単一のサーバー設定で問題なく動作します。それらを配布する場合、おそらくすでに分散Webサーバー/データベースサーバーなどがあるので、分散システムの問題がセッションストレージの選択から明らかになることはありません。ただし、10倍のトラフィック/容量などが必要な場合、ファイルストレージスキームの場合よりも、これを使用した方がはるかに自然です。一部のキー/値ストアでは、セッションデータの簡単な分析を比較的簡単に行うこともできますが、ほとんどの場合、SQLが実行できることの近くに行くことはできません。
データベースが他のオプションよりも信頼性が高いと提案する理由はわかりませんが、PHPアプリケーションがおそらくすでに使用しているため、データベースの魅力を感じます。つまり、別のサーバー依存関係を追加しないでください。おそらく、セッションデータをフェッチしてユーザーデータを取得するために使用するのと同じ接続を再利用できるため、データ用、Memcache用などを確立する必要はありません。テーブルに適切にインデックスを付けると、また、かなり高速に実行され、古いセッションを取得したり、セッションデータを分析したりするためにすでに慣れているかなり単純なセマンティクスを提供します（なぜそうするのかわからないのですが、そうでない場合でも、これはおそらく問題ではありません。大規模なスケールへのスケーリングは、Redisのようなものほど簡単ではありませんが、1つのPHPサーバーから2つのサーバーに同じDBにアクセスすることは非常に簡単です。
この選択は最初はそれほど重要ではないと思います。それぞれのアプローチには、課題と利点、および考慮しなければならないことが含まれています。一般的に言って、PHP /デフォルトのフレームワークを使用するだけで十分ですが、最も簡単な方法でもうまくいくでしょう。後で選択が悪いことが判明した場合は、パフォーマンス分析によって通知され、取得するトラフィックの特定の性質を考慮して、適切な選択を行うために必要なデータを入手できます。事前に、一般的に推測できるのは、一般的な推測だけです。
それはあなたのニーズに依存します。
ファイルとデータベースストレージの間にはいくつかの違いがあります。 この質問 を参照してください。
ただし、Rails 3はデフォルトで行われ、セッションには暗号化されたCookieのみを使用できます。そのため、後で解読できるようにすべての値を暗号化します（例：private /公開鍵）、そしてあなたはクライアントにあなたに代わって状態を維持させる。
一方では4Kbに制限されますが、これは通常は十分です（通常はオブジェクト全体ではなくIDを保存するため）、セッションのクリーンアップについて心配する必要がないという非常に優れた利点があります。それはクライアントに任せ、実際にはする必要があります。
私の特定の状況では、データベース内のセッションが、サーバーのハングアップの最大の原因の1つであると言えるでしょう。セッションテーブルが頻繁に破損するため、先制的に切り捨てました。
memcacheは魅力的に聞こえますが、memcache全体をクリアするプロセスが多すぎるため、ユーザーセッションが頻繁に切断されます。そして、メモリがいっぱいになると、古いセッションはクリアされます...したがって、永続的なログインはありません。
間もなくデフォルトのファイルベースのセッションを試す予定です。
セッションデータのセキュリティが心配な場合は、そのデータをセッションに配置しないでください（セッションを信頼しないでください）。すべてのリクエストでユーザーを検証してください。
Redis でセッションを保存してみてください。 RedisはMemcachedのように高速ですが、いくつかのデータ永続化オプションもあります。さらに、さまざまなPHPクライアントがサポートされています。
さらに、レプリケーションとストレージエンジンの機能が組み込まれている Memcached Cloud のようなサードパーティのサービスを試すことができます。
開示、私はGarantia Dataの共同創設者兼CTOです。