php - セッションをアプリと同じまたは別のデータベースに保存しますか?

Question

ユーザーのセッションをアプリと同じ DB に保存するのは悪い考えですか? MongoHQ で 2 番目の DB を支払う必要がないようにしています。

Answer 1

非常にトラフィックの多いサイト (間違いなく 100 から 200 を超えるユニークな訪問者:S、1 時間ごとに 100 万から 200 万のように試してみてください) 以外のセッション処理のためのデータベース分離は、マイクロ最適化としてカウントできます。これは主に、特に PHP で個別の接続処理を実装するために必要な作業によるものです。

それだけでなく、PHP ドライバーはデータベースごと (資格情報ごと) に接続を保持します。これは、より多くの接続を開くことを意味します。また、接続のインスタンス化に時間がかかるため、通常のセッションのためだけにこのような新しい接続を開くことはパフォーマンスが悪いと見なされます。

@Derickが正しく述べたように、接続は実際にはプロセスごとに1回行われます。これは、ある種の fcgi セットアップでは、接続を確立するプロセスがそれほど問題にならないことを意味します。

これは大した問題ではありませんが、必要のないもののためにリソースが失われているように見えます。

いいえ、セッション処理を別のデータベースに分離することはお勧めしません。実際には、パフォーマンスが低く、マイクロ最適化であると考えています。

Answer 2

それは悪い考えである必要はありません。1 つのデータベースに必要なものがすべて揃っていることを確認するだけでなく、ほとんどの場合、私は同じことをしています。

Answer 3

私が間違っていなければ、WordPress と Joomla もパスワードを同じデータベースに保存しているが、別のテーブルに保存している可能性があります。よくわかりませんが、コードを一度見たので、さらに検証が必要かもしれません。ただし、データベース名を 1 回入力するだけなので、ログインの詳細も同じデータベースにあることは明らかです。そして、今思い出せない他のコードも同じことをしました (学校の管理アプリケーション。名前は忘れました)。すべてのオープン ソース コード。

したがって、データベースが可能な限り安全であることを確認し、パスワードをプレーンテキストで保存しないようにするだけで済みます。アカウントへのアクセスを少し難しくするために、必ず全員に固有のソルトを使用してください。しかし、私はあなたがそれを知っていると確信しています.

しかし、私の結論は、あなたならできるということです。(オープンソースコード)

Answer 4

セッション数がそれほど多くない場合、アイデアは悪くありません。たとえば、1 日に 100 ～ 200 人のユニーク ユーザーがいるとします。

あなたのサイトが人気になる場合、Redisを使用するのは良い考えかもしれません。Redisは、オープン ソースで、BSD ライセンスを取得した、高度なキー値ストアです。