RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

【PostgreSQL】GINインデックスのGIN高速更新手法について検証してみた

f:id:tech-rakus:20200903164106p:plain

はじめに

こんにちは。kkystです。
開発を担当しているプロダクトではpg_bigmを利用して全文検索機能を提供しています。
今回、その全文検索を行っているテーブルにINSERTを行う一部の処理で、応答時間が増えていることを検知しました。
そこでその原因を調査していったところ、GINインデックスのGIN高速更新手法にたどり着き、待機リストの有無による応答時間の検証を行いました。
その結果として、GIN高速更新手法の有効性を確認することができたので、検証の記録を残しておきたいと思います。

概要

GIN高速更新手法とは

GINインデックスは全文検索向けのインデックスで文書中の単語の位置を保持しているため、使用することで特定の単語の検索を効率的に行えるようになります。
基本的には英文(英単語)を意識したものとなっていますが、pg_bigmなどのモジュールを導入することで日本語でも利用できます。
GINインデックスの高速更新手法については、PostgreSQLリファレンスには下記のように記載されています。

1つのヒープ行の挿入または更新によりインデックスへの挿入が多く発生するという、転置インデックスの本質的な性質のためGINインデックスの更新は低速になりがちです。 (各キー用のヒープ行はインデックス付けされた項目から取り出されます。) PostgreSQL 8.4からGINは、新しいタプルを一時的なソートされていない、待機中の項目リストに挿入することにより、この作業の大部分を遅延させることができるようになりました。

(中略)

この手法の大きな欠点は、検索時に通常のインデックス検索に加え待機中の項目リストのスキャンを行わなければならない点です。 このため、待機中の項目リストが大きくなると検索が顕著に遅くなります。 他の欠点は、ほとんどの更新は高速ですが、待機中の項目リストが「大きくなりすぎる」きっかけとなった更新は即時の整理処理を招くことになり、他の更新に比べ大きく低速になります。 自動バキュームを適切に使用することで、これらの両方の問題を最小化することができます。

「整理処理を行う更新処理が大きく低速となる」という部分が実際にどれくらい低速となるの?という疑問が浮んだので、この部分に着目して実際の処理時間を計測することにしました。

検証環境

create table sample_table(id integer, note text);
create index sample_table_ix1 on sample_table using gin (note gin_bigm_ops);

※待機リストを利用しない場合は、WITH (FASTUPDATE = OFF)を付与してインデックス再作成を実施。

検証内容

以下の状態でASCIIコードのランダム1000バイトの文字列データを1件挿入し、処理時間を計測する。

  1. 初期データなし
    1. 待機リストあり(空)
    2. 待機リストあり(最大≒gin_pending_list_limit(4MB):1000バイト * 170件)
    3. 待機リストを利用しない
  2. 初期データ100万件(各行1000バイト)
    1. 待機リストあり(空)
    2. 待機リストあり(最大≒gin_pending_list_limit(4MB):1000バイト * 170件)
    3. 待機リストを利用しない

検証結果

待機リスト(空) 待機リスト(最大) 待機リストなし
初期データなし 89.034ms 97.462ms 83.937ms
初期データあり 70.088ms 863.200ms 827.526ms

この結果より、インデックスへの整理処理そのものに時間がかかり、整理する対象のデータ件数による差はほとんどありませんでした。
また、今回用意したパターンであれば、その整理処理自体も1秒を切っているので、他の処理との兼ね合いもありますがオンラインで利用しても許容できる速度であることがわかりました。
このことから、大半の更新処理が高速になるGIN高速更新手法は非常に有効であり、特別な要件がない限りは有効にしておくべきものだということがわかりました。

おわりに

今回は、GIN高速更新手法の待機リストの整理処理による低速化に着目して検証し、GIN高速更新手法の有効性を実感することができました。
時間の都合もあり現時点における検証はここまでですが、gin_pending_list_limitなどの適切な設定値やデータ量や偏りとの関連などもありそうなので、今後もこのGIN高速更新手法について別な切り口で検証していきたいと思います。

Copyright © RAKUS Co., Ltd. All rights reserved.