概要

データベースを扱うと、パフォーマンス向上を考えた際に必ず出てくるコネクションプーリングについてです。

今回はコネクションプーリングの種類とその特徴についてと、各データベースの特性に合わせてどんな選択を取るのが良いかを説明します。

コネクションプーリング

コネクションプーリングのメリットは

です。後述しますが、例えばPostgreSQLは1コネクション＝1プロセスモデルであるため、

であった場合、接続プールがなかったとすると 1秒あたり900件のデータベース接続が開閉＝毎秒900のプロセスが作成・破棄されるという無駄な処理が発生します。

そこで接続をプール（保持）し、再利用することで無駄を省くのがコネクションプーリングです。

コネクションプーリングはアプリケーション（クライアントサイド）で実現する方法と、ミドルウェアレイヤのProxyで実現する方法が主にあります。

クライアントサイドではSDKが内部でコネクションを保持してくれます。

一方Proxy型では、アプリケーションサーバとデータベースサーバの間にPgpool-IIやPgBouncerなどの接続管理のためのミドルウェアを挟んでプーリングさせます。

次にデータベース毎のコネクションの作り方を説明します。

PostgreSQLは1コネクション = 1プロセスモデルです。

メリット
- OSプロセスに隔離されるため、安定性・安全性が高い
  - ある接続がクラッシュしても他に影響しにくい
- 実装がシンプルでデバッグ・運用がしやすい。
- CPU資源をプロセス単位で扱えるため、マルチコアで安定して動作。
デメリット
- プロセス生成・コンテキストスイッチのオーバーヘッドが大きい。
- 大量接続に弱い（数千〜数万接続はプロセス数的に厳しい）。
- 接続管理を外部（PgBouncer等）に委ねるケースが多い。

なのでPostgreSQLは基本的に最大接続数の上限値が低く設定（デフォルト100）されています。

MySQLは1コネクション = 1スレッドモデルです。

メリット
- プロセスより軽量なので、Postgresより高い接続数に耐えやすい。
- 実装も比較的シンプル。運用実績も豊富。
- スレッドプールを導入すれば、さらに効率的に接続を処理できる。
デメリット
- 1接続1スレッドなので、数万接続レベルではスレッド数がボトルネックになりやすい。
- スレッドスタックのメモリ消費が積み上がる。
- スレッド切り替えのオーバーヘッドがある。

なのでPostgreSQLほどコネクション数が問題になることは少ないです。

MongoDBはイベントループ + スレッドプールモデルです。

PostgreSQLが1996年、MySQLが1995年に生まれた一方で、MongoDBは2009年と比較的最近です。

でまとめたように、当時のC10K問題のような大量接続に対応してこのモデルになったと思われます。
NoSQL自体がデータ整合性よりもスケーラビリティを重視したソリューションですしね。

メリット
- 接続が非常に軽量
  - ノンブロッキングI/Oで管理するため、数万〜数十万接続にも耐えやすい）
- CPUバウンド処理はスレッドプールに渡すので効率が良い。
- 大規模スケールやクラウド環境に向いている設計。
デメリット
- 実装が複雑で、デバッグやチューニングの難易度が高い。
- イベント駆動特有の「1つの処理が長引くと全体に影響」というリスク
  - 多数の接続を捌けるが、重いクエリが多いと結局スレッドプールが詰まる。

まとめると以下になります。

とは言えPostgreSQLが大規模トラフィックに向いていないのか？と言われればPgBouncerなどのコネクションプーリングなどを挟めば対応できるので、互換性やプロダクトの思想を変えてまでスレッドモデルなどに移管することはないと推測しています。

各データベース毎のコネクションモデルと、コネクションプーリングの影響度を考えると以下の様になります。

データベース	クライアントサイドプール	Proxy型プール	備考
PostgreSQL	必須	強く推奨（PgBouncer/Odyssey）	プロセスモデルで重いので両方併用が定石。
MySQL	推奨	中規模以上は有効（ProxySQL）	スレッドモデルで比較的軽いが、大規模接続はProxyで制御すると安定。
MongoDB	ドライバが標準でプール持ち（十分）	通常不要	接続軽量。Proxyを置くのはシャーディングや多リージョンの特殊用途のみ。