私は、ローンチ後すぐに数百万のユーザーにサービスを提供することが期待されるプロジェクトに取り組んでいます。データベースはpostgresであり、現時点では少なくとも2台のサーバーが必要であると想定しています。システム管理者（明らかにスケーラブルなシステムに精通している）は、Webサーバーとデータベースサーバーの間にロードバランサーを配置することを提案しています。
私の質問は、負荷分散と接続プールの違いについてです。パフォーマンスを維持するために、どちらか、または両方を見る必要がありますか？
回答:
PostgreSQLを使用すると、アプリレイヤー（つまり、jdbc組み込みのプーリングなど）で、またはアプリとデータベースの間にある中間レイヤー（pgbouncerやpgpoolなど）で、プーリングを実行できる2つの異なる領域があります。
pgbouncerやpgpoolなどの中間層でプールを行う場合、その層は選択したクエリの負荷分散も行うことができます。さらに、ロードバランシング時に、2つの方法のいずれかで書き込みを行うことができます。slonyなどのツールまたはpg 9.0で表示された組み込みのストリーミングレプリケーションを使用して、他の方法で読み取りスレーブに複製する単一の書き込みマスターを持つことができます。以上、またはロードバランサーにすべての書き込みを行わせることができます。これにより、受信した読み取りは1つのdbのみにヒットしますが、書き込みは各データベースにヒットし、すべてのデータベースを更新します。
または、冒険心がある場合は、plproxyを使用して、負荷分散レイヤーを別のレイヤーの下のpostgresql自体に移動できます。これは、実際のデータを含まない1つのpgデータベースをフロントエンドに配置できるように設計されたpgsqlのpl言語であり、そのデータベースは、複数の冗長なdbの上で実行して、信じられないほどのスループットを実現できます。plpoxyの設定と実行はかなり複雑ですが、非常にスケーラブルでもあります。あなたのアプリケーションはそれをサポートするために書き直す必要があることに注意してください。そうすれば古いアプリケーションの下で投げられて動作しないだけです。
http://slony.info/ http://wiki.postgresql.org/wiki/PL/Proxy http://pgpool.projects.postgresql.org/
ロードバランシングと接続プーリングは2つの非常に異なるものです。
接続プール（私は世界のMicrosoft側から来ていますが、想定は同様です）を使用すると、アプリケーションはデータベースへの接続を開いたままにして、切断して再接続する代わりに次のクエリで再利用できます。実行する必要があるクエリごとに。
ロードバランシングを使用すると、ロードバランサーの背後に複数のデータベースサーバーを配置できるため、単一のサーバーですべての作業を処理する代わりに、複数のサーバーに負荷を分散できます。
ロードバランシングで接続プールを使用できますが、接続がドロップされることはないため、2つのデータベースサーバー間で負荷のバランスが取れなくなる可能性があることに注意してください。
1つのデータベースサーバーがアプリケーションの負荷を処理できない場合は、3つのサーバーをそこに戻します。そうすれば、アプリをクラッシュさせることなく、必要に応じて再起動できます。