PHPで最も信頼性の高いセッションストレージは何ですか:Memcache、データベースまたはファイル?[閉まっている]


10

PHPセッションを処理するための最良かつ最も安全な方法は何ですか。セッションを保存する最良の方法は次のとおりです。

  1. データベース(信頼性は高いが、ボトルネックが高く、速度が遅い、データベース使用率の高いWebサイトには適さない)?

  2. Memcache(超高速ですが、より多くのセキュリティ問題が分散し、サーバーの再起動時にデータが失われる可能性、およびキャッシュがいっぱいになるとデータが失われる可能性があります)?

  3. ファイル(デフォルトのオプション、ファイルI / Oからの読み取りと書き込み、セキュリティの低下などから遅いと思います)。

どの方法が最適ですか?これらのアプローチのそれぞれの問題点と良い点は何ですか?


2
1台のマシンのみを使用しているか、アプリケーションが分散されているかを指定する必要があると思います。回答に大きな影響を与えるからです。
Arseni Mourzenko 2012年

1
@haylemこれは、この質問をするために最も適切な場所であるその質問はそのプログラミング概念問題、プログラミングではない
user1179459

3
「最善」は特定の状況に依存するため、これは本当に悪い質問です。Facebookの「ベスト」は、個人のホームページの「ベスト」とはおそらく異なります。
GrandmasterB

1
@GrandmasterB私はそのことを知っているので、「これらの各アプローチの問題点と良い点は何ですか」と明確に尋ねました。どちらが私に最適かを調べます。
user1179459

回答:


6

他の問題(キャッシュサイズ、セキュリティなど)を簡単に解決できるため、Memcachedに保存することをお勧めします。

facebookはmemcachedの#1消費者です。興味があれば読んでください:http : //www.facebook.com/note.php?note_id=39391378919

他の問題を解決するには?


4

日常的なアプリケーションの大部分では、データベースにセッションを維持することは問題ありません。SQLサーバーが処理できる並行性の量とレベルは十分以上です。重要なのは、各エントリのサイズを小さく保ち、不要な行を定期的に削除することです。そしてもちろん、適切な索引付け。

ファイルシステム-これを実行する必要があるとは思っていません。何千もの小さなファイルではなく、テーブルの行を管理するシンプルさを好みます。さらに、セッション統計を詳しく調べたい場合は、ファイルをまたがってクエリすることはできません。

PHPを使用すると、セッションハンドラーを簡単に交換できます。したがって、1つのストレージフォーマットから始めて、それほど面倒な作業を行わずに別のストレージフォーマットに移行できます。


4

MySQLでMEMORYストレージエンジンを使用するのはどうですか?

Memcacheほど高速ではありませんが、プレーンSQLを使用できるという利点があります。通常のストレージエンジンを使用する必要がない場合は使用でき、ユーザー/リクエストの数が増えた場合はMEMORYに切り替えることができます。

頻繁に変化するWebアプリに大量の統計データを保存するために使用しているため、セッションの処理には使用されていませんが、この目的には適していると思います。


3

このブログ投稿は、Magentoを使用したさまざまなセッションストレージエンジンのパフォーマンス比較の結果を示しており、最大で約75人の同時接続ユーザーには実際にはパフォーマンスの違いはないと結論付けているようです。

これらのレベル(1秒あたり約5トランザクション、つまり12時間で約430kヒットになる)では、ファイル/ DB / Memcache / Redisはすべてうまく処理されるため、他のすべてのオーバーヘッドがパフォーマンス数値を支配すると思います適切に使用すれば、汗をかくことのない交通です。

これには、スケーラビリティ、信頼性、セキュリティなどの他の要素が残ります。

攻撃者はアプリケーションコードを変更するか、少なくとも読み取り専用であってもキーとストレージアクセスプロトコル/資格情報を発見することができるため、ファイルストレージを危険にさらすことは他のものも危険にさらす可能性があることを最初に述べたいと思います。アクセス。ファイルストレージは、ボリュームの少ないサイトで適切に機能し、セットアップが簡単で、理由を簡単に判断できます。ディスクをヒットしたと言うだけで、DBの読み取りもディスクにヒットし、DBがそれをキャッシュできる場合、OSもセッションファイルをキャッシュしている可能性があります。また、その1つのファイルが読み取られ、ファイル名がわかっている場合は、ファイルシステムがそのファイルシステムにアクセスできます。PHPを使用している場合、アプリケーションを提供するためだけにシステムが実行する必要があるファイル読み取りの数を知っていますか?欠点は、あなたができるということです

Memcacheは比較的高速であり、Memcacheクラスのソリューション(Redisなど)をより幅広く検討している場合は、メモリ内読み取りによる永続性を約束して速度を上げることもできるため、両方の世界を最大限に活用できます。それらはまた、推論するのが比較的簡単であり、セッションのキーバリューの性質はまさにこれらが行うように設計されているものです。これらの1つを埋めるためにセッションにどれだけの時間を費やす必要があるか知っていますか?いずれにせよ、あなたの選択肢のすべては、あなたが彼らの能力に達した場合、あなたに妥協を強いるでしょう。ディスクはファイル(ここでは数とサイズの要素)でいっぱいになり、キャッシュストアは容量でいっぱいになり、データベースの行数は限られ、ファイルアプローチと同じディスク容量制限があります。また、これらのシステムは、分散方式で実行する場合にのみ分散されます。ほとんどは、単一のサーバー設定で問題なく動作します。それらを配布する場合、おそらくすでに分散Webサーバー/データベースサーバーなどがあるので、分散システムの問題がセッションストレージの選択から明らかになることはありません。ただし、10倍のトラフィック/容量などが必要な場合は、ファイルストレージスキームよりもこれを使用した方がはるかに自然です。一部のキー/値ストアでは、比較的簡単にセッションデータの簡単な分析を実行することもできますが、ほとんどの場合、SQLが実行できることの近くには到達できません。

データベースが他のオプションよりも信頼できるかもしれないと提案する理由はわかりませんが、PHPアプリケーションがおそらくすでに使用しているので、データベースの魅力を感じます。つまり、別のサーバー依存関係を追加する必要はなく、セッションデータのフェッチに使用するのと同じ接続を再利用してユーザーデータを取得できるため、データ用、Memcache用などを確立する必要はありません。テーブルも適切に実行され、かなり高速に実行され、古いセッションを取得したり、セッションデータを分析したりするためにすでに慣れているかなり単純なセマンティクスを提供します(なぜそうするのかわからないのですが、そうでない場合は、おそらくこれはおそらくそんなに重要です)。大規模なスケールへのスケーリングは、Redisのようなものほど簡単ではありません。

この選択は最初はそれほど重要ではないと思います。それぞれのアプローチには、課題と利点、および考慮しなければならないことが含まれています。一般的に言って、PHP /デフォルトのフレームワークを使用するだけで十分ですが、最も簡単な方法で作業を進めることもできます。後で選択が悪いことが判明した場合は、パフォーマンス分析によって通知され、取得するトラフィックの特定の性質を考慮して、適切な選択を行うために必要なデータを入手できます。前もって、あなたが合理的に持つことができるのは、一般的な推測だけです。


0

それはあなたのニーズに依存します。

ファイルとデータベースストレージの間にはいくつかの違いがあります。この質問を参照してください。

ただし、デフォルトではRails 3で行われていることを実行でき、セッションには暗号化されたCookieのみを使用できます。したがって、後で解読できる方法ですべての値を暗号化し(たとえば、秘密鍵/公開鍵)、クライアントに状態を保持させることができます。

一方では4Kbに制限されますが、これは通常は十分です(通常はオブジェクト全体ではなくIDを保存するため)、セッションのクリーンアップについて心配する必要がないという非常に優れた利点があります。それは実際にあるべきクライアントに任せます。


2
静的リソースを分離してCookieパスの外側にしない限り、Cookieはすべてのリクエストに対して支払う必要がある固定税です。
Joeri Sebrechts

jQueryとBootstrapは合わせて約150 kbで、他のライブラリはありません。Cookieの最大は4kbで、通常は1Kb未満です。OPが極端な状況について尋ねているのでない限り-その種の課税を誰が気にしますか?
Yam Marcovic

@YamMarcovicいくつかの問題があります1)Cookieもサーバーに送信されます(ユーザーは通常、ダウンロードとアップロードが高速です)2)通常、ページには静的ファイル(画像、js、css)に対する100のリクエストがあるため、リクエストごとに100kbに​​達する可能性があります上がる
Miro Svrtan

@MiroSvrtanユーザーがページごとに何百ものリクエストを送信するようにしている場合(どこで発生したか)、最適化は明らかに問題ではありません。
Yam Marcovic

速度の最適化について相談する前に、サイトがフロントページをロードするために約170のHTTPリクエストを作成しているクライアントがいました。ところで、秘密鍵と公開鍵は非対称暗号法の概念であり、対称暗号と同等で実装が複雑なだけのこのシナリオでは一般に適用されません。また、ほとんどのセッションストレージ実装は、クライアントが管理するCookieに依存しているため、回答の最後の段落で説明されている利点は、それらすべてに適用されます。
jeteon

0

私の特定の状況では、データベース内のセッションが、サーバーのハングアップの最大の原因の1つであると言えるでしょう。セッションテーブルが頻繁に破損するため、先制的に切り捨てました。

memcacheは魅力的に聞こえますが、memcache全体をクリアするプロセスが多すぎるため、ユーザーセッションが頻繁に切断されます。そして、メモリがいっぱいになると、古いセッションはクリアされます...そのため、永続的なログインはありません。

間もなくデフォルトのファイルベースのセッションを試す予定です。

セッションデータのセキュリティが心配な場合は、そのデータをセッションに配置しないでください(セッションを信頼しないでください)。すべてのリクエストでユーザーを検証してください。


0

Redisでセッションを保存してみてください。RedisはMemcachedのように高速ですが、いくつかのデータ永続化オプションもあります。さらに、さまざまなPHPクライアントがサポートされています。

さらに、レプリケーション機能とストレージエンジン機能が組み込まれたMemcached Cloudなどのサードパーティサービスを試すことができます。

開示、私はGarantia Dataの共同創設者兼CTOです。


2
開示ありがとうございます!Doがあなたは、私たちが望むもののあなた自身の製品を挙げることができるポストを超えて、このサイトに参加していることを確認してくださいあなたに貢献する人ではなく、あなたの会社のように。
Martijn Pieters、2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.