こんにちは、Elastic Certified EngineerのHiroshi Yoshioka です。この記事は Elastic stack (Elasticsearch) Advent Calendar 2019 の16日目の記事になります。
はじめに
本日のテーマは「Elastic Stackを活用したRDB検索の高速化」です。RDBを用いたシステムにおいて、データサイズが肥大化すると一般に検索性能が劣化します。特にLike演算子を用いたテキスト検索は、劣化の度合いが顕著です。
システム構成を変更せずに性能改善を行う場合、データスキーマやSQLを見直すことである程度の性能改善が可能ですが、スキーマ変更に伴うアプリケーション改修量が多く、またそれに見合う性能改善を得られない場合もあります。一方で、Elastic Stackを導入し、検索処理部分のみをElasticsearchに移行するアプローチは、アプリケーション改修量は小さく、また飛躍的な性能改善を実現することが可能です。
検索性能改善：Before/After
以下は、過去Elastic Stackで性能改善した事例の性能数値です。
事例(1)
| 検索時間(Before) | 検索時間(After) | 検索速度 |
|---|---|---|
| 30～60秒 | 50～200ミリ秒 | 300～600倍に向上 |
事例(2)
| 検索時間(Before) | 検索時間(After) | 検索速度 |
|---|---|---|
| 60～220秒 | 100～200ミリ秒 | 600～1000倍に向上 |
コメント
既存システムが遅すぎでは？という指摘があるかもしれませんが、データ設計／データサイズ／SQLによっては検索に数十秒かかるシステムをよく見かけます。これをElastic Stackを導入することで、検索時間を100ミリ秒前後に抑えることができました。
システム構成
Before/Afterのシステム構成は以下のようになります。
「Elastic Stack導入によるRDB検索高速化」のポイント
- データは非正規化してElasticsearchに持たせる（Nested、Parent/Childは使わない）
- 非正規化によりインデックスサイズがRDBのデータサイズよりも大きくなるので、適宜チューニングをしてサイズのダイエットをする
- Elasticsearchへのデータ同期はLogstashを利用する
- Elasticsearchには、検索機能として最低限必要な情報のみをデータ移行しインデックスサイズを抑える
- Elasticsearchは検索結果のIDのみを返却し、画面に必要なデータはRDBから取得する。
- 画面に必要なすべてのデータをElasticsearchに持たせるアプローチの方がシンプルですが、インデックスサイズが膨らみ、それに伴って必要なデータノード数も増えることに注意
最後に
Elastic Stackを導入する上で、インデックス／クエリ設計、データ同期(初期移行、定期同期、障害復旧)、運用設計など、検討事項は多々ありますが、書くと長くなりすぎるので、今回はこの辺で終ります。 RDB検索の高速化に興味がある方は、以下ページにてぜひお問い合わせください。 www.endosnipe.com
Acroquest Technologyでは、キャリア採用を行っています。
- ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
- Elasticsearch等を使ったデータ収集／分析／可視化
- マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
- 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
ユーザに最高の検索体験を提供したいエンジニアWanted！ - Acroquest Technology株式会社のエンジニアの求人 - Wantedlywww.wantedly.com
