しくみ製作所の西口です。
今年度よりしくみ製作所では、社内において研究発表会という知見を共有するイベントを開催することになりました。
先日第1回目が終了したのですが、「Elasticsearchで検索システムを構築した話」と題し、私が登壇しましたので、その内容をお伝えできればと思います。
今回の発表では実際の案件において、Elasticsearch を使い高速な検索システムを構築した話をしました。対象となる案件は、条件付きで CMS を再構築するものです。具体的には、「各種データ(5種類)の検索に関して、レスポンス速度が速くかつ柔軟な条件で検索できること」という条件がありました。
この条件をクリアするために Elasticsearch で検索システムを組むことにしました。メインのデータストアである RDB からデータ自身 + データに紐付けられているS3上の添付ファイルの内容などをできるだけ速く同期させる仕組みを作りました。
結果として、一部問題も残っているものの概ね RDB への更新から10秒ぐらいのラグで、最大500万件ぐらいのデータを数ミリ〜数十ミリ秒で検索できるようになりました。
対象となる CMS の刷新にあたって、以下のような柔軟な検索要件がありました。
私は別のシステムで Elasticsearch を使ったことがあり、Elasticsearch を使えば柔軟かつ検索速度も速いという経験があったため使ってみることにしました。
今回の検索システムは、Elasticsearch と Logstash を使って構築しました。
RDB側のテーブルの単位でいうと5テーブルに関してそれらに紐づく親、一部の子テーブルのデータ含めて1テーブル最大500万件ぐらいのデータを Elasticsearch に同期し検索できるようにしました。
RDB と Elasticsearch の同期処理については、Logstash で同期しており、SQL で Easticsearch 側のindex に対応する json を組み立ててそれをそのまま upsert する方式にしました。
添付ファイルについては、ファイルのアップロードと同じタイミングで中身抽出するのが少し難しかったため、別途中身抽出バッチをつくり非同期で添付ファイルの中身を保持するだけのテーブルに更新していき、そのデータの更新をトリガーに Logstash に拾われるようにして同期しました。
一部データ量が多いレコードに関して同期が詰まる問題が合ったりするものの、ほとんどのケースでRDB更新後数十秒程度までには同期され、検索時間も数ミリ〜数十ミリ秒程度で検索できるようになりました。