メディアコンテンツ向け記事検索DBとして使うElasticsearch
•
2 gefällt mir•1,934 views
第25回のElasticsearch勉強会で発表した内容です。 Elasticsearchを全文検索を含む記事検索DBとして利用するにあたっての考慮事項などなど。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie メディアコンテンツ向け記事検索DBとして使うElasticsearch
Ähnlich wie メディアコンテンツ向け記事検索DBとして使うElasticsearch (20)
メディアコンテンツ向け記事検索DBとして使うElasticsearch
- 1. メディアコンテンツ向け 記事検索DBとして使うElasticsearch Future Architect, Inc. Yasuhiro Murata 第25回Elasticsearch勉強会 【検索編】 2018/10/17
- 2. Self Introduction 村田 靖拓（むらた やすひろ） l 2014/10 新卒でFuture Architectへ入社 l Technology Innovation Group所属 l PJ配属当初はフロントエンジニア（Web UIコンポーネント開発など） l 最近はAWSを利用したアプリ開発・インフラエンジニア l 趣味はテニスとドラム 水瀬いのりの曲を叩きたいんじゃー l よろしくお願いします！ ぜひお手柔らかにおねがいしますmm @famipapamart
- 4. こんな会社です エンジニアを大切にするITコンサルティング企業です • B to Bでシステムを提案・構築しています • OSSの制作・公開もしています
- 5. 本日のメイントピック • 記事検索DBとして利用するにあたって考慮したこと • データモデリング • 全文検索向け設定 • その他Mapping定義 • パフォーマンス検証の話 • max_result_windowの壁
- 7. もくじ • Introduction ~取り扱うコンテンツについて~ • データモデリングの話 • 全文検索の話 • Mapping定義の話 • パフォーマンス検証の話 • まとめ
- 10. Introduction ~取り扱うコンテンツについて~ 取り扱っているコンテンツはニュース記事素材 • 記事は大きく2つに分類される • 現在執筆中のもの • 過去に執筆されたもの • 記事はフリーワード検索等で頻繁に検索される • 大量の過去記事を参考に新しい記事を書くことは日常茶飯事 • 記事は紙面に載るまでにいくつかのフェーズを経る • 記者が執筆→デスクへ送稿→校閲が確認→紙面へ • フェーズごとに記事を束ねる親グループの概念が登場する • そのため取り扱うデータは親子関係を持っている 記事A 記事B 記事C 記事D 紙面
- 11. データモデリングの話
- 12. データモデリングの話（1/4） 考えたこと • 検索で使う項目はすべてindex内に保持する • Indexを跨いだdocument検索ができないため、必要な項目はすべて1つのindexに保持する サムネイル情報 履歴情報 外部連携情報 コンテンツ本体 ステータス情報 関連情報 { "id": "0001", "data": { "contentBody": { "title": "Elasticsearchチュートリアル", "text": "データの検索と解析をリアルタイムで",... }, "historyInfo": { "version": "6.4.0", "updated": "2018/08/23",... },... },... }
- 13. データモデリングの話（2/4） 考えたこと • 検索で使う項目はすべてindex内に保持する • 親グループと子素材という親子関係の情報を互いに保持させるため、DB Trigger的な仕組みを用いて値の 振り下ろしを行った 親グループ 子素材 親グループステータス情報 子素材 更新情報 レコード更新をtriggerに 検索index側に集計項目をPUT
- 14. データモデリングの話（3/4） 考えたこと • 文字列のtypeは少し悩んだ • 基本はkeyword型 • 全文検索したければtext型 • 基本は↑だが、業務要件次第でanalyzeしたほうが良さそうな項目もkeyword型で持ったりしている { "textInfo": { "properties": { "title": { "type": "keyword" }, "text": { "type": "text" } } } } 例えば... いわゆる「カテゴリ」的な項目でも IF連携時等は完全一致でひっかけたい 単語の活用がある場合には 原則text型にしてanalyzeする
- 15. データモデリングの話（4/4） 考えたこと • 日付検索は必ずしも範囲検索とはならない • 「毎年○月の記事を検索したい」となると範囲検索ではない • Multi-fieldsを使ってkeyword型でもインデクシング 毎年ねぶた祭りの記事って どんなこと書いてるんだろう？ { "createdAt": { "type": "date", "format": "yyyyMMdd'T'HHmmss.SSSZ", "fields": { "string": { "type": "keyword" } } } }
- 16. 全文検索の話
- 17. 全文検索の話（1/3） 考えたこと • あまり深くは考えなかった（もちろんいい意味で、です笑） • 基本的には kuromoji におまかせ • 異体字の展開は character filter を利用して行った • 慶応義塾大学 => 慶應義塾大学 • 大日本東亜帝国 => 大日本東亞帝国
- 18. 全文検索の話（2/3） { "settings": { "analysis": { "filter": { "en_stop": { "type": "stop", "stopwords": "_english_" } }, "char_filter": { "synonym_filter": { "type": "mapping", "mappings": [ "亞 => 亜",... ] } }, "tokenizer": { "kuromoji_token": { "type": "kuromoji_tokenizer", "mode": "extended" } }, "analyzer": { "kuromoji_analyzer": { "type": "custom", "tokenizer": "kuromoji_token", "char_filter": [ "synonym_filter", "icu_normalizer", "kuromoji_iteration_mark" ], "filter": [ "kuromoji_baseform", "kuromoji_part_of_speech", "ja_stop", "en_stop", "kuromoji_number", "kuromoji_stemmer" ] } } } } } 異体字はここで展開 analyzerは用意されているものを 組み合わせるのみ（ほぼ）
- 19. 全文検索の話（3/3） 使用したPlugin名 タイプ 機能詳細 icu_normalizer character filter 文字を正規化する。 ex) → アパート / ｱﾊﾟｰﾄ → アパート kuromoji_iteration_mark character filter 踊り字を正規化する。 ex) 学問のすゝめ → 学問のすすめ kuromoji_tokenizer tokenizer 文章のトークンに分割する。 kuromoji_baseform token filter 活用による表記のゆれを正規化する。 ex) 飲み → 飲む kuromoji_part_of_speech token filter 検索時にノイズとなりうる助詞等を取り除く。 ex) 水を飲む → 水 飲む ja_stop token filter 検索時にノイズになりうる頻出語句（指示語など）を取り除く。 kuromoji_number token filter 漢数字をアラビア数字へ変換する。 ex) 一〇〇〇円 → 1000円 kuromoji_stemmer token filter 単語末の長音を削除して統一する。 ex) サーバー → サーバ
- 20. Mapping定義の話
- 21. Mapping定義の話 考えたこと • アンチパターンかと思ったがDynamic field mappingを有効にしている • 業務要件の変更に伴う項目定義変更に柔軟に対応できる余地を残すため { "textInfo": { "properties": { "title": { "type": "keyword" }, "text": { "type": "text" }, "tags": { "type": "object" } } } } ただし今後変動が予想される項目に関しては object型で定義 原則すべての項目を定義する
- 22. パフォーマンス検証の話
- 23. パフォーマンス検証の話（1/6） Elasticsearch のパフォーマンス特性 • パフォーマンスはQueryとfrom（offset値）に依存する • 初回QueryのQueryLatency速度の担保が難しい • Warm APIなくなったけど... • 性能を担保するに足るQueryの定義が分からない • フリーワード検索は結局 ”入力される単語次第” なところもある • “max_result_window” の壁に出会う（※）
- 24. パフォーマンス検証の話（2/6） “max_result_window” の壁...とは？ • Elasticsearchのパラメータ “max_result_window” のデフォルト値が10,000であ ることに由来する（デフォ値10,000が悪いとかでは全くないです！念のため。） • 100万件以上ヒットするQueryを offset - limit 形式で投げる必要があった • 過去記事を検索するいわゆるアーカイブ記事検索は、大量の記事から探しものを見つける行為 • 素直にSearch API使って ”90万件目から50件取得” と投げようとすると... • じゃあ “max_result_window” をめちゃくちゃあげればすむ話なの？ Result window is too large, from + size must be less than or equal to: [10000]
- 25. パフォーマンス検証の話（3/6） “max_result_window” はめちゃくちゃあげても大丈夫でした but... • “max_result_window” を10,000,000にあげてみてもメモリ使用量が爆上がりする ことはなかった • メモリ使用量にダイレクトにはねたのはsize（同時取得件数）だった shard1 shard2 shard3 shard4 shard5 59= 0 各シャード上位 90万50件を抽出 全てマージし 90万 ~ 90万50件目 を特定
- 26. パフォーマンス検証の話（4/6） from値が大きくなればなるほどLatencyは上がっていった • 1indexあたりのデータ件数はなるべく小さくできると良い • “max_result_window” デフォ値10,000の重要性を改めて理解した アクセス パターン Req/sec from size レイテンシ Min Avg 50th 75th 95th 99th Max Read 3 150 20 256msec 282msec 274msec 281msec 298msec 445msec 764msec 3 1,500 20 251msec 282msec 277msec 283msec 302msec 378msec 700msec 3 15,000 20 266msec 295msec 286msec 294msec 311msec 482msec 803msec 3 150,000 20 389msec 442msec 430msec 450msec 493msec 584msec 846msec 3 1,500,000 20 629msec 738msec 713msec 786msec 883msec 1094msec 1413msec
- 27. パフォーマンス検証の話（5/6） 100万件以上ヒットするQueryを offset - limit 形式で...はどうしたの？ • indexを複数に分割し、Count APIを利用してデータ取得対象indexを特定する方式に • ソート条件が固定(作成年月日)だったため、indexはあらかじめ年月順にならべておく構成をとった index1 - 2014 index2 - 2015 index3 - 2016 index4 - 2017 index5 - 2018 ① 各indexにCount APIを投げ indexごとのヒット件数を取得 ③ 特定したindexにQueryを投げる ② 取得対象データが格納されている indexを特定
- 28. パフォーマンス検証の話（6/6） できるなら前もって... • 大量件数ヒットするようなQueryを扱うならScroll APIの利用が望ましい • しかし要件定義次第ではfrom / sizeの指定による検索が必要になってしまう • 今回はSearch APIを使っています（泣） • 可能であればページネーションはつけない画面設計ができると平和（とても平和） • TwitterとかFacebookのTLを見てみなさい、という話 Lovely♡（私見） NO!（私見）
- 29. まとめ
- 30. まとめ • データモデリング • まずは非正規化（とはいえ親子関係を持ったデータはどう検索させるのが正解だったんだろうか...） • 『Integrate full text search service with Django』 をじっくり読む (https://slideship.com/users/@iktakahiro/presentations/2018/09/DRJxjKfBFEGSRcvYjCA88f/) • 全文検索 • kuromoji ｱﾘｶﾞﾄｳ • 『Elasticsearchを日本語で使う設定のまとめ』 を血眼になって読む (https://qiita.com/shin_hayata/items/41c07923dbf58f13eec4) • Mapping定義 • Dynamic field mapping利用時は運用に注意 • パフォーマンス • max_result_windowのデフォ値10,000は伊達じゃない • Search API / Scroll APIそれぞれの挙動をおさえておく必要あり
- 31. まとめ ~質疑応答編~ • Q「画面にページネーションがあったからSearch APIを選択したってことですか？」 • 村田「はい、そうです。Scroll APIでは無理そうだったのでSearch APIを選択しました。」 ※ちなみにSearch After APIというのもあります。大谷さんが言及してくださいました。 • Q「スコアリングについてはどのように考えてましたか？」 • 村田「スコアリングは今回考慮してないです。」 ※日付でソートして表示する、という感じだったのでスコアについて考慮しませんでした。 • Q「max_result_windowを爆上げしてもメモリがそんなに振れなかったとあったが、私 の検証ではメモリがだいぶ振れた。どんな環境でテストしたんですか？」 • 村田「AmazonES(r4.2xlarge.elasticsearch)でテストを実施しました。メモリが振れなかったわけではないです。リソース 使用率に大きく関わるのはfromの値（max_result_windowを爆上げすれば1千万に設定することも可）ではなくsizeの値でした、とい う検証結果です。」 • Q「なにを持って形態素解析の検索精度を良しと判断したんですか？N-gramとかなんなら grepで良いって考え方もある。」 • 村田「N-gramについては検索結果にノイズがたくさん乗ってしまうであろうことから却下。日本語記事が検索対 象になることから語句を正規化したい意図から形態素解析を採択しました。」 ※精度については絶賛チューニング中です。