pg_bigmを用いた全文検索のしくみ(後編)

Copyright © 2013 NTT DATA Corporation

NTTデータ基盤システム事業本部澤田雅彦

pg_bigm(ピージーバイグラム)を用いた

全文検索のしくみ (後編)

第27回しくみ+アプリケーション勉強会(10/5)

2 Copyright © 2013NTT DATA Corporation

自己紹介

名前

澤田雅彦（さわだまさひこ）

所属

NTTデータ基盤システム事業本部

２年目です

やっていること

去年：pg_bigmの開発、サポート

今年：レプリケーション関係

3 Copyright © 2013NTT DATA Corporation

INDEX

1．前編の復習

2．性能測定(後編)

3．pg_bigm独自機能

4．デモ

5．まとめ

Copyright © 2013 NTT DATA Corporation 4

前編の復習

5 Copyright © 2013 NTT DATA Corporation

DBの全文検索ってなに？

SQL発行

DB

：：

テキスト型の列を持つテーブルから、キーワードを含むレコードを検索すること

全文検索では検索対象のデータが多い

全文検索用のインデックスを作成することで高速にできる

キーワード：「オープンソース」


pg_bigmとpg_trgm

pg_bigm pg_trgm

対応バージョン 9.1~ 9.1~

開発主体 NTTデータ PostgreSQL コミュニティ

日本語対応 ○ △

1，2文字検索 ○ × (インデックスを有効に使えない)

類似度検索 × ○

利用できるインデックスの種類

GINのみ GINとGiST


pg_bigm

pg_trgm

pg_bigmとpg_trgmのインデックス登録時の挙動の説明をしていきます pg_bigmではキーを文字列で持つ pg_trgmではキーをINT値で持つ

pg_bigm,pg_trgmのインデックス登録

キー TID

△△O 100

△OS 100

OSS 100

SSS 100

CRC1 100

CRC2 100

①3文字分割「△△O」、「△OS」、「OSS」、「SSS」、「SSあ」、「Sあ△」

②重複削除「△△O」、「△OS」、「OSS」、「SSS」、「CRC1」、「CRC2」

①2文字分割「△O」、「OS」、「SS」、「SS」、「Sあ」、「あ△」

②重複削除「△O」、「OS」、

「SS」「Sあ」、「あ△」

キー TID

△O 100

OS 100

SS 100

Sあ 100

あ△ 100

TID データ

100 OSSSあ

キーワード

‘OSSSあ’ INSERT

3Byte以上の場合はハッシュ変換される

INT型で格納される

TEXT型で格納される


インデックス検索時の挙動

①2文字分割「OS」「Sぐ」「ぐれ」

キーワード‘OSぐれ’からTID100のデータが検索されるまでの挙動を解説します

②インデックススキャン

TID データ

100 POSぐれ

200 POSぐる

300 ぽSぐれ

キー TID

△P 100, 200

△ぽ 300

OS 100, 200

PO 100, 200

Sぐ 100, 200, 300

る△ 200

れ△ 100, 300

ぐれ 100, 300

：：

③TID候補決定

→TID 100 ④Recheck

検索キーワード

‘OSぐれ’

pg_bigmの場合


性能測定(後編)


性能測定の概要

1．インデックス作成時間

2．インデックスサイズ

3．検索時間

4．データ挿入時間

測定対象 pg_bigm pg_trgm

測定項目

以下の項目を実施


測定環境

項目詳細

CPU Core i7-3630QM

メモリ 16GB

ディスク 512GB SSD

OS CentOS 6.4

DBMS PostgreSQL 9.2.4

ハードウェア環境

ソフトウェア環境


テストデータ

項目詳細

データソース日本語Wikipedia

テーブルサイズ 34GB

データ件数 2.5億件

テーブル定義 CREATE TABLE hoge (col text)

以下のデータを用いて性能測定を実施した


作成時間とインデックスサイズ

対象インデックス作成クエリ

pg_bigm CREATE INDEX hoge_idx ON hoge USING gin(col gin_bigm_ops);

pg_trgm CREATE INDEX hoge_idx ON hoge USING gin(col gin_trgm_ops);

データ全件をロード後、以下のクエリでインデックスを作成

それぞれの作成時間と、インデックスサイズを10回計測


作成時間とインデックスサイズ

pg_bigm pg_trgm

インデックスサイズ 63GB 78GB

インデックス作成時間約3時間約5時間

結果 pg_bigmの方がインデックスサイズが小さく、作成時間が短

い結果となった考察 2文字ずつの分割の方がキーの重複が多いため、pg_bigmの方

がインデックスサイズが小さい →詳細は次のスライド pg_trgmではインデックス作成時に各3-gram文字列をハッ

シュ変換するため、pg_bigmよりも時間がかかる


インデックスキーの重複

「あいあい」を2文字、3文字分割する場合

pg_bigm

△あ

あい

いあ

あい

い△

pg_trgm

△△あ

△あい

あいあ

いあい

あい△



「あいあい」を2文字、3文字分割して追加する場合

pg_bigm

△あ

あい

いあ

あい

い△

pg_trgm

△△あ

△あい

あいあ

いあい

あい△

5個 4個

重複を削除



さらに「あいとあい」を2文字、3文字分割して追加する場合

pg_bigm

△あ

あい

いあ

い△

pg_trgm

△△あ

△あい

あいあ

いあい

あい△

5個 4個



さらに「あいとあい」を2文字、3文字分割して追加する場合

pg_bigm

△あ

あい

いあ

い△

いと

とあ 2個追加

pg_trgm

△△あ

△あい

あいあ

いあい

あい△

あいと

いとあ

とあい

3個追加新しく作られるキーの数が違う


検索時間の検証概要

検索時間の検証では以下の2つの検索時間をそれぞれ20回測定

①検索結果が0件、1件、100件…での検索

②検索文字数が1文字、2文字、3文字…での検索

検索クエリはpg_bigm、pg_trgm共に下記のクエリを実行

対象検索クエリ

pg_bigm SELECT col FROM hoge WHERE col LIKE ‘%東京都%’;

pg_trgm


検索時間の検証概要 ~検索文字列①~

検索文字列結果件数

一日分 0件

明治五 1件

平成一 100件

上野駅 1万件

衆議院 10万件

東京都 60万件

検索結果件数が0件、1件、100件…となる検索文字列(3文字)を検索条件とする検索結果数の変化が、どのように検索時間に影響するのかを確認


検索時間結果①

検索文字列結果件数 pg_bigm pg_trgm SeqScan

一日分 0件 10ms 1ms 138s

明治五 1件 36ms 4ms 136s

平成一 100件 46ms 9ms 136s

上野駅 1万件 36ms 24ms 145s

衆議院 10万件 210ms 190ms 147s

東京都 60万件 1510ms 1050ms 136s

結果検索結果が多い検索条件では、pg_bigmとpg_trgmとの差が開きやすい

結果となった考察

次のスライドから


pg_bigmとpg_trgmのインデックスの違い

キー TID

△東 1,2,4

東京 1,2,4

京都 1,2,3,4

都と 1

と京 1,4

都府 1,3

△京 3

京と 4

キー TID

△△東 1

△東京 1

東京都 1,2

京都と 1

都と京 1

と京都 1,4

△△京 3

△京都 3

京都府 1,3

：：

pg_trgm

pg_bigm

1 : 東京都と京都府 2 : 東京都 3 : 京都府 4 : 東京と京都


pg_bigmとpg_trgmのインデックスの違い

一つのキーあたりのTIDの数はpg_bigmの方が多い

検索に影響


キー TID

△東 1,2,4

東京 1,2,4

京都 1,2,3,4

都と 1

と京 1,4

都府 1,3

△京 3

京と 4

pg_bigm

キー TID

△△東 1

△東京 1

東京都 1,2

京都と 1

都と京 1

と京都 1,4

△△京 3

△京都 3

京都府 1,3

：：

pg_trgm


キー TID

△△東 1

△東京 1

東京都 1,2

京都と 1

都と京 1

と京都 1,4

△△京 3

△京都 3

京都府 1,3

：：

pg_trgm

検索への影響


1個TID

を参照

「京都と」で検索する場合

キー TID

△東 1,2,4

東京 1,2,4

京都 1,2,3,4

都と 1

と京 1,4

都府 1,3

△京 3

京と 4

pg_bigm

5個TID

を参照


検索時間の検証概要 ~検索文字列②~

1文字、2文字、3文字…の検索文字列を検索条件とする検索文字数の変化が、どのように検索時間に影響するかを確認

検索文字列文字数結果件数

駅 1文字 150万件

横浜 2文字 40万件

東京都 3文字 60万件

世田谷区 4文字 4万件

秋葉原駅前 5文字 3000件

東京特許許可局 7文字 5000件

とうきょうスカイツリー

11文字 50件


検索時間結果

検索文字列結果件数 pg_bigm pg_trgm SeqScan

駅 (1文字)

150万件 2440ms 2173000ms 141s

横浜 (2文字)

40万件 780ms 2182000ms 146s

東京都 (3文字)

60万件 1580ms 1010ms 136s

世田谷区 (4文字)

4万件 80ms 70ms 139s

秋葉原駅前 (5文字)

3000件 20ms 10ms 136s

東京特許許可局 (7文字)

5000件 390ms 140ms 133s

とうきょうスカイツリー

(11文字)

50件 2780ms 60ms 161s

1文字、2文字の検索では、インデックスが使えるpg_bigmが早い 3文字以上の検索では、pg_trgmの方が早い


pg_bigm.gin_key_limitでチューニング

pg_bigm.gin_key_limitパラメータで検索時に使用する2-gram文字列の個数の最大数を指定することでチューニングが可能

「とうきょうスカイツリー」で全文検索をした場合、

2-gram文字列は、

うき,うス,きょ,とう,ょう,イツ,カイ,スカ,ツリ,リー,ー△,△と

12個 pg_bigm.gin_key_limitでこの最大数を指定


pg_bigm.gin_key_limitでチューニング

0

500

1000

1500

2000

2500

3000

1 3 5 7 9 10 12(全て)

処

理

時

間

pg_bigm.gin_key_limit

キーワード：とうきょうスカイツリー

pg_bigm

pg_trgm

<2-gram文字列> うき,うス,きょ,とう,ょう,イツ,カイ,スカ,ツリ,リー,ー△,△と pg_bigm.gin_key_limitの値を調整することで、性能改善が可能値が1の時は、recheck処理で多くの候補行を除いている(約21万件) 値が3の時はpg_trgmよりも高速に処理ができた


データ挿入時間

新規にwikipediaのデータを1000件 (約250kBのテキストファイル)を挿入した時の

WAL発生量処理時間

を測定

対象挿入クエリ

pg_bigm COPY hoge FROM ‘/home/postgres/10000.txt’;

pg_trgm


データ挿入時間

pg_bigm pg_trgm

WAL発生量 9*16MB 11*16MB

処理時間 10914.53ms 22906.03ms

結果 pg_bigmの方がWALの発生量が小さい pg_bigmの方がデータ挿入時間が短い

考察 pg_trgmではキー登録時にハッシュ変換があるため、処理時

間に差が出た


pg_bigm独自機能


likequery()

=# SELECT likequery(‘pg_bigmで性能が200％向上'); likequery ----------- %pg¥_bigmで性能が200¥%向上% (1 row)

文字列内の「%」、「_」、「¥」はエスケープされる AP側で検索文字列のエスケープ処理を作らなくていい

実行例


show_bigm()

=# SELECT show_bigm('全文検索モジュール'); show_bigm ------------------------------------------------------- {ジュ,モジ,ュー,"ル ",ール,全文,文検,検索,索モ," 全"} (1 row)

実行例


pg_bigm.gin_key_limit

どのユーザからでも変更可能 2-gram文字列の個数が大きくなりやすいシステムでは、検索性能が劣化しやすい →このパラメータで使用する最大個数を指定することで、性能問題を解決できるただし、2-gram文字列の個数を減らすとrecheck処理への負担が大きくなること

に注意デフォルトは0(すべて使用)

=# SET pg_bigm.gin_key_limit to 10;

実行例


pg_bigm.enable_recheck

どのユーザからでも変更可能運用時は必ずON(デフォルト) recheck処理のオーバーヘッドを評価するなどの、デバック時に

OFFにする

=# SET pg_bigm.enable_recheck to on;

実行例


デモ


デモ

以下のデモを通して、pg_bigmのインストールや、全文検索実行まで紹介いたします。 pg_bigmインストール全文検索インデックス作成全文検索インデックスを用いた検索 SeqScanとの速度の違い 1文字、2文字での検索


まとめ


まとめ

全文検索を高速に行うために、pg_bigmやpg_trgmを用いて全文検索用インデックスを作成する

インデックスサイズ pg_bigmの方が小さい

インデックス作成時間 pg_bigmの方が早い

検索検索結果数が多いほど、pg_trgmの方が早い →pg_bigm.gin_key_limit等でチューニング可能 1，2文字検索ではインデックスを使えるため

pg_bigmの方が早い

pg_bigm新バージョンリリース！


pg_bigm新バージョンがリリース予定

pg_bigm新バージョンでは主に以下の内容が更新されています

類似度検索も

現在開発中


参考資料


(参考)ワイルドカードの有無による検索の挙動の違い

キー TID

△A 1, 2

△X 3

AB 1, 2, 3

BC 1, 2, 3

C△ 1, 3

CD 2

D△ 2

XA 1

TID データ

1 ABC

2 ABCD

3 XABC

検索キーワードキー決定タプル

完全一致 ABC △A AB C△

1

前方一致 %ABC AB BC C△

1, 2

中間一致 %ABC% AB BC

1, 2, 3

後方一致 ABC% △A AB BC

1


(参考)Recheck処理の必要性

キー TID

東京 1

京都 1

京と 1

：：

検索ワード：

‘%東京都%’

「東京」： TID1 「京都」： TID1

TABLE

INDEX

間違った結果を取ってきてしまう

INDEXを検索 TID決定

Recheck処理で再検査！

例えばこんな時。。

1 東京と京都

：：


(参考)pg_bigm.gin_key_limitを変えた時の処理時間

pg_bigm pg_trgm

1 473.04ms

60ms

3 47.64ms

5 467.30ms

7 738.47ms

9 1015.46ms

10 2738.24ms

12(全て) 2737.42ms


(参考)部分一致とは？

①2文字分割「本」

②インデックススキャン

キー TID

：：

末尾 100, 200

本日 200, 300

本屋 500

本当 400

札束 200

：：

③TID候補決定

④Recheck

キーワード

‘%本%’

2文字分割後、1文字のキーワードが生成された場合、部分一致を行う関数が実行される (例)検索キーワードが’%東%’の場合など部分一致では1文字の検索キーワードと各キーの先頭を比較して、一致、不一致を判断す

る pg_bigmでは部分一致関数を実装しているため、2文字”以下”の検索ができる

pg_bigmを用いた全文検索のしくみ(後編)

Documents

Transcript of pg_bigmを用いた全文検索のしくみ(後編)