-
2022-04-22 PostgreSQL全文検索
PostgreSQL の全文検索モジュール pg_bigm と PGroonga の速度比較(3)
本記事では、PostgreSQL の全文検索モジュールである pg_bigm と PGroonga の全文検索 SQL の実行速度について検証した結果をお伝えしたいと思います。
前回と前々回の速度検証は下記よりご覧ください。
バージョン情報
PostgreSQL とモジュールのバージョンは下記の通りです。
- PostgreSQL 14.2
- pg_bigm 1.2
- PGroonga 2.3.6
用意したデータの内容
wikipedia から
- 最小文字数：6 文字
- 最大文字数：578,911 文字
- 平均文字数：8,056 文字
PostgreSQL オブジェクトのデータサイズ
データを格納した後の各 PostgreSQL オブジェクトのサイズは下記の通りです。
| レコード件数 | テーブルサイズ | pg_bigm のインデックスサイズ | PGroonga のインデックスサイズ |
|---|---|---|---|
| 100,000 件 | 805 MB | 675 MB | 2,347 MB |
| 200,000 件 | 1,609 MB | 1,208 MB | 4,596 MB |
| 300,000 件 | 2,414 MB | 1,652 MB | 6,865 MB |
| 400,000 件 | 3,218 MB | 2,119 MB | 9,169 MB |
| 500,000 件 | 4,023 MB | 2,646 MB | 11,487 MB |
検索対象レコード件数と検索キーワード文字数の関連性を確認
検索対象となるレコード件数と、検索キーワードの文字数で pg_bigm と PGroonga の全文検索 SQL の実行速度がどう変化するのかを確認してみました。
pg_bigm のレコード件数別の実行速度
下記グラフは pg_bigm のレコード件数別の実行速度をグラフです。
縦軸が実行速度（ms）、横軸が検索キーワードの文字列となります。
・上記グラフのとおり pg_bigm の場合、レコード件数と SQL の実行速度は比例しているようです。
PGroonga のレコード件数別の実行速度
下記グラフは PGroonga のレコード件数別の実行速度をグラフです。
縦軸が実行速度（ms）、横軸が検索キーワードの文字列となります。
・PGroonga では、レコード件数と全文検索 SQL の実行速度にある程度の相関はあるようですが、pg_bigm ほどの規則性は見られませんでした。
pg_bigm の recheck 対象レコード件数と実行速度の関連性を確認
今度は、pg_bigm の recheck 対象となったレコード件数や、検索した結果のレコード件数によって、pg_bigm の全文検索 SQL の実行速度がどう変化するのかを確認してみました。
pg_bigm の recheck 対象レコード件数ごとの実行速度(1)
下記グラフは、pg_bigm の recheck 処理対象となったレコード件数ごとの実行速度を折れ線グラフにしたものです。
縦軸が実行速度（ms）、横軸が recheck 処理の対象となった（recheck 処理を行った）レコード件数です。
・recheck 処理対象となったレコード件数が 10130 から 17070 あたりと、60101 以降で実行速度が高速になっています。これは、検索キーワードが 2 文字以下なため、高速となっています。
pg_bigm の recheck 対象レコード件数ごとの実行速度(2)
次のグラフも、pg_bigm の recheck 処理対象となったレコード件数ごとの実行速度を折れ線グラフにしたものです。
検索キーワードを 3 文字以上に限定したものとなります。
（pg_bigm では、検索キーワードが 2 文字以下の場合、高速に実行されますので、検索キーワードを 3 文字以上に限定しました）
・検索キーワード 2 文字以下を省くと、綺麗な右肩上がりのグラフとなりました。
pg_bigm の recheck 処理後のレコード件数ごとの実行速度
次に、pg_bigm の recheck 処理を行った後のレコード件数によって、実行速度がどう変化するかを確認しました。
下記のグラフは、pg_bigm の recheck 処理で正しく検索キーワードに合致していると確認されたレコード件数ごとの実行速度をグラフにしたものです。
縦軸が実行速度（ms）、横軸がレコード件数となります。
・こちらも若干いびつな形となっていますが、おおよそ右肩上がりのグラフとなっています。
PGroonga の結果レコード件数ごとの実行速度
補足な内容となりますが PGroonga についても、キーワードに該当したレコード件数によって、実行速度がどう変化するかを確認しましたので、グラフとしました。
縦軸が実行速度（ms）、横軸がキーワードに該当したレコード件数となります。
・あるレコード件数を境に実行時間が大きくなっているようですが、あまり綺麗なグラフとはなりませんでした。
今回の検証で確認できたこと
- pg_bigm は、検索対象となるテーブルのレコード件数が多いほど、実行速度が遅くなる。
- pg_bigm は、recheck 処理を行ったレコード件数が多いほど、実行速度が遅くなる。
- pg_bigm は、検索キーワードが 2 文字以下だと高速に実行できる。
- PGroonga は、検索対象となるテーブルのレコード件数が多いほど、実行速度が遅くなる傾向がある。
- pg_bigm ほどの規則性はない。
- PGroonga は、検索結果のレコード件数が多いほど、実行速度が遅くなる傾向がある。
- pg_bigm ほどの速度差はない。
まとめ
pg_bigm と PGroonga を直接速度差を検証したわけではないですが、それぞれの特徴が確認できたかと思います。
検索キーワードが 2 文字以下の場合は、pg_bigm でも十分に高速ですが、それ以外の場合では若干物足りない実行速度となっていました。
pg_bigm は、やはり recheck 処理の件数を減らすことが高速化につながるようです。
以前に pg_bigm の高速化手法について、パーティションテーブルを利用する方法をご紹介いたしました（※）が、別の高速化手法についても次回以降の記事でご紹介したいと思います。
※ 該当の記事は下記です。
pg_bigm の全文検索 SQL をパーティションテーブルを使って高速化