データベース接続プールの設定

データベース接続プールの設定は、システムとデータベースとの効率的かつ安定した接続を確保するための重要なステップです。適切な接続プールの設定は、データベース接続数を効果的に管理し、高並行性による接続枯渇問題を回避するだけでなく、適切なタイムアウト設定により無効な接続をタイムリーにクリーンアップし、システム性能を確保することができます。

本記事では、接続プールの基本概念、さまざまな接続プールの比較、選択ガイド、接続プールパラメータの推奨設定、およびJDBC設定における重要なパラメータについて紹介し、開発者がデータベースアクセスを最適化するのに役立てていただきます。

接続プールの基本概念

データベース接続プールは、データベース接続を管理する技術です。アプリケーションとデータベースの間に接続プールを構築し、事前に一定数のデータベース接続を作成してメモリ内に保持します。アプリケーションがデータベースにアクセスする必要がある場合、接続プールから直接接続を取得し、使用後は接続プールに返却します。これにより、毎回新しい接続を作成する必要がありません。

接続プールの主な利点は以下の通りです：

• パフォーマンスの向上：接続の頻繁な作成と破棄に伴うオーバーヘッドを回避します。
• リソース管理：データベース接続数を制御し、接続枯渇を防ぎます。
• 接続の再利用：接続の利用率を高め、リソースの無駄遣いを減らします。
• 接続監視：接続状態の監視と統計情報を提供します。

接続プールパラメータ

接続プール設定の推奨事項

• 管理コンソールの日常的な最小接続数は2つを維持すれば十分です。具体的な数は業務の同時実行数やトランザクション時間に応じて調整してください。

• 接続のアイドルタイムアウト時間を設定します。30分を推奨します。

  MySQLのデフォルトでは、接続は8時間ごとに自動的に切断されますが、クライアント側ではこの動作を検知できないため、ダーティコネクションが発生する可能性があります。接続プールは、ハートビートやtestOnBorrowなどのメカニズムを用いて接続の生存状態を検証し、この時間を超えて接続が使用されない場合は直接切断します。

JDBC設定パラメータ

JDBCで必ず設定が必要な重要なパラメータがいくつかあります。これらはすべて、接続プールのConnectionPropertiesまたはJdbcUrlに設定できます。具体的なパラメータとその説明は以下の表のとおりです。

JDBC設定例

本記事では、JDBC設定の例を紹介します。

JDBCを使用してデータベースに接続する際には、関連パラメータを設定してデータベースの最適なパフォーマンスを引き出す必要があります。ここでは、関連するパラメータの設定例をいくつか推奨します。

JDBC接続の例は以下のとおりです：

conn=jdbc:oceanbase://xxx.xxx.xxx.xxx:3306/test?rewriteBatchedStatements=TRUE&allowMultiQueries=TRUE&useLocalSessionState=TRUE&useUnicode=TRUE&characterEncoding=utf-8&socketTimeout=10000&connectTimeout=30000

この接続において、関連する構成パラメータは以下のとおりです：

• rewriteBatchedStatements：TRUEに設定することを推奨します。

  • OceanBaseのJDBCドライバーはデフォルトでexecuteBatch()ステートメントを無視し、一括実行される一連のSQLステートメントを分解して、データベースに1つずつ送信します。この場合、バッチ挿入は実際には単一挿入となり、性能が低下します。実際にバッチ挿入を実行するには、このパラメータをTRUEに設定する必要があります。そうするとドライバーがSQLを一括実行します。addBatchメソッドを使用して、同一テーブル上の複数のINSERTステートメントを1つのINSERTステートメント内の複数のvalues値の形式でまとめることで、バッチ挿入の性能を向上させます。

  • 各INSERTをprepareStatement方式で準備し、その後addBatchする必要があります。そうでない場合、結合実行はできません。

• allowMultiQueries：TRUEに設定することを推奨します。

  JDBCドライバーは、アプリケーションコードが複数のSQLをセミコロン（;）で結合し、1つのSQLとしてサーバー側に送信することを許可します。

• useLocalSessionState：TRUEに設定することを推奨します。これにより、トランザクションが頻繁にOBデータベースにsession変数のクエリSQLを送信するのを回避できます。

  session変数は主に以下のものです：autocommit、read_only、transaction isolation。

• socketTimeout：SQL実行時に、socketがSQLの返却を待機する時間です。

• connectTimeout：接続確立時に、接続を待機する時間です。

• useCursorFetch：TRUEに設定することを推奨します。

  データ量の多いクエリステートメントについて、データベースサーバーはCursorを確立し、FetchSizeのサイズに応じてClientにデータを配信します。このプロパティをTRUEに設定すると、useServerPrepStmts=TRUEも自動的に設定されます。

• useServerPrepStmts：SQLをデータベースサーバーに送信する際にPSプロトコルを使用するかどうかを制御します。

  TRUEに設定すると、SQLはデータベース内で2段階に分けて実行されます：

  • ？を含むSQLテキストをデータベースサーバーに送信してPrepareを行います(SQL_audit: request_type=5)。

  • 実際のValueを使用して、データベース内でExecuteを行います(SQL_audit: request_type=6)。

• cachePrepStmts：JDBC driverがPS cacheを有効にしてPreparedStatmentをキャッシュし、prepareの繰り返し実行（クライアント側およびサーバー側）を回避するかどうかを制御します。cachePrepStmts=TRUEは、useServerPrepStmts=TRUEを使用し、同一SQLに対してバッチ実行を繰り返すシナリオに役立ちます。各バッチ実行にはprepareとexecutecachePrepStmts=TRUEが含まれるため、繰り返しのprepare操作を回避できます。

• prepStmtCacheSQLLimit：PS cacheに格納できるSQLの長さの上限です。これを超える長さのSQLはキャッシュに入れることができません。prepStmtCacheSize：PS cacheが保存できるSQLの数です。

• maxBatchTotalParamsNum：バッチ操作において、1つのSQLがサポートできる最大パラメータ数（つまり、バッチ内の？の数）です。パラメータ数がこの制限を超えると、バッチSQLは分割されます。