MENU

全文検索機能をリリースしました

エンジニアブログ

2018-12-04

andyです。
久々のエントリになってしまいました。。

本日、ECサイトでは当たり前機能の一つである全文検索機能をリリースしました。
リリースが今さらになった理由は色々あるのですが。。
本記事では技術的な観点で色々と試行錯誤などを行った経緯などを書いていきたいと思います。

前提として、wajaではサービス構築当初からDBMSとしてPostgreSQLのみを利用しています。
バージョン7.4から利用を開始し、現在は9.5まで、継続的にバージョンアップしながら利用しています。

そして、wajaの商品一覧の検索に利用しているデータは、検索用に複数のテーブルを結合したデータになっています。
サービス初期の頃はそれらを一括JOINしたviewに直接アクセスしていたのですが、商品数が多くなるにつれ、検索対象軸(ジャンルやブランドなどです)が多くなるにつれ、viewのパフォーマンスがどんどん低下してくようになりました。
※集計データも含めいつの間にか30テーブル近くJOINするように。。
そこで、viewの内容を1つのテーブルに保持し、検索用に大量のインデックスを張る、というviewテーブルを作成することにしました。
(今はこのテーブルはよく検索される条件に従ってパーティショニングされています。)

このテーブル自体もどんどん巨大化しており、今ではカラム数100,データ総量2GB、インデックス数も60程度となり、そもそも検索という機能に対してRDBMSを使うのはどうか?という議論も内部では良く行われるようになっていました。
そこでElasticsearchなど、必要なデータそのままを投入して、どの軸でも検索できるようなDBMSを調査するなど、別の技術の方向性を探っていました。
※ただし、Elasticsearchを実用的なレベルで利用するにはかなり大量のサーバインスタンスとスペックが必要(かつ開発期間も半年レベルでかかりそう)ということが分かり、リソース的な部分で断念する、、などもあり。。

そのような中、今回採用したPGroongaと出会うことができました。
採用理由としては、以下のような点が挙げられます。

・既存テーブルと整合性が取れる
・十分に高速
・既存クエリ(LIKE句)も場合によっては高速化する
・インデックスを追加するだけで全文検索機能が追加できる
・類義語、オートコンプリート機能も通常のテーブルメンテナンスで機能追加できる
・pg_tgrmなどよりも日本語の扱いが上手

既存テーブルと整合性が取れる、というのは、商品一覧で絞り込んだ条件と連動するメニュー(ジャンルやブランドでさらに絞り込める機能)の作り方を変えずに実装が可能、という意味です。
例えばキーワードとして素材(シルクなど)を入れて検索して、その素材名にあたる商品が存在しないブランドは絞り込み条件から外す、といった機能です。

今年の夏頃から検証を進め、PGroonga, Groonga共に検証中に発見した不具合を何度か修正いただいてようやく日の目を見ることができるようになりました。
修正いただいた開発者の方には感謝してもしきれないくらいです。
なお、PGroongaとの出会いは開発者ご本人のエントリでした。
ありがとうございました。

wajaのキーワード検索機能はまだ産声を上げたばかりで、これから同義語、オートコンプリートを充実させてよりユーザビリティを上げていきたいと考えています。
また、「それっぽい順」のソートにうまく対応できていないため、こちらはPGroongaの使い方をより研究しつつユーザの意図を汲んだ検索結果になるようブラッシュアップしていきたいと思います。

スマホ、PC共に「画面の上の方」にキーワード検索欄がありますので(PCは以前ブランド検索欄があった場所です)、是非色々と使ってみてください。

JUnit5試したみた #2

2018-01-05

BLOG/エンジニアブログ

wajaの開発フロー

2017-12-29

BLOG/エンジニアブログ

JUnit5試したみた #1

2017-12-26

BLOG/エンジニアブログ

カード番号をカメラでスキャンする

2017-12-19

BLOG/エンジニアブログ