Web屋のネタ帳

PostgreSQLにおけるN-Gram方式の高速全文検索アドオンの話。 SennaはSennaで動きはないのだが、PostgreSQL側で状況が変わってきているのでメモ。

• SennaのPostgreSQLバインディングであるところのLudiaは、PostgreSQL8.3.5(もしかして8.3.x全部？）あたりからもう動かない。8.4以降もダメで、サポートされる気配もない。
• そもそもPostgreSQL本体のほうで、GINインデックスと全文検索まわりの組み合わせ方に実装の変更（整理？吸収？統合？）があった。こんな言い方が適切かどうか自信はあまりないんだけど、ver8.3.?あたりから変わったんですよとにかく。
• そこで、最近のPostgreSQLの共通的な全文検索機構にあわせて作られたtextsearch_sennaがおすすめ。Ludia使いはそろそろこっちに乗り換えるべき。
• ぱっと試した感じではtextsearch_sennaはludiaよりさらにインストールや設定が簡単（ludiaも十分簡単だったが）であり、しかもSQL文的にはludiaでの検索演算子と同じにできるので、アプリ影響はほとんどないだろう。
• ところが筆者が試したところ、一つのテーブル上の4，5個のtext型＆varchar型のカラムにそれぞれsennaインデックスを張って、SQL文のwhere句で 「col_a %% 'ほげ' or col_b %% 'ほげ'... 」のようにor句でつなぎまくったら、数百回に1回くらいの確率でPostgreSQL自体がSegmentation Fault起こしてpostgresプロセスが全滅。postmasterは生きてるので接続しなおせばすぐ復活するのだが、これにはちょっと参った。 この原因がtextsearch_sennaのほうにあるのかPostgreSQLにあるのかSennaにあるのかはさっぱりわからん（苦笑）。 64bitのlinux（kernel 2.6.18-164.el5）なんだがこのへんも絡んでるのかねえ？ とりあえずスタックトレース取って調べてやろうかと思ったけど面倒なので挫折。
• 自分のアプリを直すほうが話が早くね？ってことで、 目的のテーブルにtext型カラムをひとつ追加して、そのカラムに、全文検索対象にしたい他の複数のカラムの情報を改行でつなぎ合わせてぶち込んでおくことにした。そのカラムだけにsennaインデックスを張り、検索するSQLでは「カラム名 %% 'ほげ'」 のようにするだけだ。よく考えるとこのほうがSQL文がすっきりするしインデックスの数も減ってメンテしやすそうだねということでこれでGO。快適に運用中。
• もしできましたら早いとこマルチカラムインデックス対応してください^^;) ＞ textsearch_sennaの中の人。
• なお、textsearch_sennaの場合、「カラム名 %% 'ほげ'」のように特別な演算子を使わなくても 「カラム名 like '%ほげ%'」のような普通のlikeであってもsennaインデックスが効いてくれる。 これ結構うれしい人多いんじゃなかろうか。

ちなみに筆者は形態素解析方式よりもN-Gram方式のほうが好みである。 検索結果に多少のノイズが入るデメリットよりも辞書をメンテしなくていいメリットのほうが大きいので。

see also:

• 全文検索、Ludia、PostgreSQL、senna、某巨大掲示板 (2006/10)
• PostgreSQLを高速化する16のポイント (2009/2)
• テキスト検索の方法とインデックス — Let's Postgres　(2009/7)