Tritonn から Elasticsearch への移行話

Tritonn から
Elasticsearch
への移行話
2019/06/07
MySQL Casual Talks vol.11
do_aki

@do_aki
＠do_aki
http://do-aki.net/

Tritonn
• Tritonn := MySQL + Senna
• MyISAM の全文検索をフックするパッチで
実現 (ストレージエンジンではない)
• MyISAM + Senna インデックス
• 検索は MATCH…AGAINST 構文を利用

CREATE TABLE items (
item_id INT,
name TEXT NOT NULL,
description TEXT NOT NULL,
FULLTEXT KEY USING NGRAM,
NORMALIZE, SECTIONALIZE (name,description)
) ENGINE=MyISAM
SELECT item_id, name, description
FROM items
WHERE MATCH (name, description)
AGAINST ('*E-1*D+*W1:10,2:3 検索語 –除外' IN BOOLEAN MODE)
DDL
SQL

Tritonn の今
• 開発停止
• Groonga ストレージエンジン (現在の
Moronga ストレージエンジン）に移行
• Trironn 最終リリースは 2009/11
(MySQL 5.0.87)

Tritonn の今
• 開発停止
• Groonga ストレージエンジン (現在の
Moronga ストレージエンジン）に移行
• Trironn 最終リリースは 2009/11
(MySQL 5.0.87)
現役で稼働中！！

10年前のMySQL
• ハードウェア特性の相違
• Clientライブラリとの互換性
• OS (glibc) との互換性 / 脆弱性
さすがに MySQL の
バージョンアップを
しないとね！
(脱 Tritonn)

移行にあたって重要視したこと
• 従来の検索エクスペリエンスを大きくは変えない
=> 漏れより網羅性重視 / 正規化 / OR,AND,NOT
• 検索速度が従来より極端に遅くならないようにする
=> 厳密な基準は設けなかったが、現状同等以下
• 運用コストはなるべく抑える
=> Tritonn 自体を運用するコストはほぼ0だった

移行案
LIKE に置き換え
転置インデックステーブル自作
InnoDB 全文検索
Mroonga
MySQLで解決
HyperEstraier
Groonga
Solr
Elasticsearch
他 Middle ware 導入
優先して検討

LIKE に置き換え
• 複数語検索が必要な場合は LIKE を OR で結合していく感じ
• 試しに200万件程度のデータに対して MATCH..AGAINST を単純な
LIKE に置き換えてみたところミリ秒単位で返ってきていたクエリ
が数十秒単位に
• データ量が少なく、今後も急には増えないところに対しての妥協案
としてあり -> 他の条件で十分に絞り込め、単純検索で問題ない
ケースについての置き換え策として採用

InnoDB Full Text Search
• MySQL5.6 以降で利用可能な全文検索インデックス(ngram parser
は 5.7 以降)
• Senna 同様 MATCH..AGAINT を使うので、改修箇所が少なくて済
むかもという期待
↓ ↓ ↓
• ngram parser (bigram)だと十分な速度が出なかった (LIKE同様
のデータで数秒程度)
• 現状の挙動と合わせるためには前処理が必要
• ngram における stopword の扱いが微妙……

Mroonga
• Tritonn の後継プロダクト
• ラッパーモードを利用すればほぼ現状と変わらないはず
• とはいえ、せっかく脱Tritonn するのになーという思いも
• 検証時点では 8.0系には未対応(2019年6月現在も)
-> 今後のバージョンアップの枷になりそう
（ソースコードに手を入れて 8.0 対応の手助けできないか試したのだけど、
力及ばず。。。）

MySQL のみでの解決を断念
-> 他の Middle Ware導入を検討
• Groonga
– 速度は申し分ない
– HAのための冗長構成をすべて自前で組む必要がある
• Solr
– Lucene のフロントエンド
– Solr Cloud
• Elasticsearch
– Lucene をつかった全文検索サーバ
– 組み込みのクラスタ
採用

形態素 vs ngram
• 転置インデックスに格納される語の単位
• 「東京都の水」
– 形態素:「東京」「都」「の」「水」
辞書依存, 一般的に新語や固有名詞に弱い
辞書のメンテが必要
– bigram:「東京」「京都」「都の」「の水」
インデックスサイズが肥大, 網羅的に検索できる
辞書不要
{"type": "kuromoji_tokenizer"}
{"type": "ngram", "min_gram": 2, "max_gram": 2}

USING NGRAM
• 弊社の Tritonn では ngram インデックスが利用されてた
– もともと高速な LIKE がほしい的な理由からだった気がする
– 様々なジャンルの商品 -> 未知語が多い
– 適合性より網羅性重視
• Elasticsearch で ngram を使う事例は少ない？
– 日本語検索の多くは kuromoji 利用
• Elasticsearch 採用決定までに試行錯誤してる

「世界に一つだけの花」に
「世界一」がマッチする問題
趣旨とは関
係ないけど、
S は小文字
が正しいの
でこれは誤
り

ngram と match
• 「世界に一つだけの花」「世界一」
– index: 「世界」「界に」「に一」「一つ」「つだ」
「だけ」「けの」「の花」
– search: 「世界」「界一」
• match query はデフォルトでは OR
– 「界一」にはヒットしないが、「世界」にヒットし
たことでマッチ
– ならば AND にしてやれば……
{"match": {"name": "世界一"}}
↓
{"match": {"name": {"query":"世界一", "operator":"and"}}

そんな甘くはない
• @johtani さんからの指摘
– https://twitter.com/johtani/status/10
58195319228268545

match_phrase
• 「世界に一つだけの花」にはマッチしなくなったが
「MySQL界一の地雷職人、世界のyokuさん」にはマッチ
• 解決するために match_phrase を利用
– match や multi_match を使わないという選択
{"match": {"name": "世界一"}}
↓
{"match_phrase": {"name": "世界一"}}

複数フィールドへの対応
• 例:「世界」と「花」を含む name検索
• description フィールドも対象に
• match が使えないので bool query を駆使
↓ ↓ ↓
{"match" : {"name": "世界花"}}
{"multi_match" :
{"query": "世界花", "fields": ["name", "description"]}
}

bool query
{
"bool": {
"must": [
{
"bool": {
"should": [
{"match_phrase": {"name": {"世界"}}},
{"match_phrase": {"description": {"世界"}}},
]
}
},
{
"bool": {
"should": [
{"match_phrase": {"name": {"花"}}},
{"match_phrase": {"description": {"花"}}},
]
}
},
]
}
}

検索ワードの解析
• "(世界一 OR 日本一) 地雷職人 –yoku"
– Trironn では、そのまま渡せば意図通り
– 簡易パーサを作って対応
{"bool": {"must": [
{"bool": {"must": [
{"bool": {"should": [
{"match_phrase": {"name": {"query": "世界一"}}},
{"match_phrase": {"description": {"query": "世界一"}}
]}},
{"match_phrase": {"name": {"query": "日本一"}}},
{"match_phrase": {"description": {"query": "日本一"}}}
]}}
]}},
{"match_phrase": {"name": {"query": "地雷"}}},
{"match_phrase": {"description": {"query": "地雷"}}}
]}},
{"bool": {"must_not": [
{"match_phrase": {"name": {"query": "yoku"}}},
{"match_phrase": {"description": {"query": "yoku"}}}
]}}
]}}
]}}

一文字にもマッチするように
• Tritonn では基本 bigram のはずなのだけどなぜか 1文字
でも検索可能 (ex:「壺」)
– 単体で検索することは稀かもしれないけど、複合語ではマッチ
させたい (ex: 「漬物」+「壺」)
• bigram だけでなく unigram も作成することで対応
– 単純に作成するだけだとインデックスサイズが肥大化
– stopword で一文字の英字数字記号平仮名片仮名を除外

スペースや # が除外されない
{"type": "stop", "stopwords_path": "stopwords.txt"}
{
"type": "stop",
"stopwords": [
"t", " ", "!", """, "#", "$", "%", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/",
"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", ":", ";", "<", "=", ">", "?", "@",
"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
"[", "", "]", "^", "_", "`",
"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
"{", "|", "}", "~", " ",
"ぁ", "あ", "ぃ", "い", "ぅ", "う", "ぇ", "え", "ぉ", "お", "か", "が", "き", "ぎ", "く", "ぐ", "け", "げ", "こ", "ご",
"さ", "ざ", "し", "じ", "す", "ず", "せ", "ぜ", "そ", "ぞ", "た", "だ", "ち", "ぢ", "っ", "つ", "づ", "て", "で", "と", "ど",
"な", "に", "ぬ", "ね", "の", "は", "ば", "ぱ", "ひ", "び", "ぴ", "ふ", "ぶ", "ぷ", "へ", "べ", "ぺ", "ほ", "ぼ", "ぽ",
"ま", "み", "む", "め", "も", "ゃ", "や", "ゅ", "ゆ", "ょ", "よ", "ら", "り", "る", "れ", "ろ", "ゎ", "わ", "を", "ん",
"ゔ", "ゕ", "ゖ", " ゙", " ゚", "゛", "゜",
"ァ", "ア", "ィ", "イ", "ゥ", "ウ", "ェ", "エ", "ォ", "オ", "カ", "ガ", "キ", "ギ", "ク", "グ", "ケ", "ゲ", "コ", "ゴ",
"サ", "ザ", "シ", "ジ", "ス", "ズ", "セ", "ゼ", "ソ", "ゾ", "タ", "ダ", "チ", "ヂ", "ッ", "ツ", "ヅ", "テ", "デ", "ト", "ド",
"ナ", "ニ", "ヌ", "ネ", "ノ", "ハ", "バ", "パ", "ヒ", "ビ", "ピ", "フ", "ブ", "プ", "ヘ", "ベ", "ペ", "ホ", "ボ", "ポ",
"マ", "ミ", "ム", "メ", "モ", "ャ", "ヤ", "ュ", "ユ", "ョ", "ヨ", "ラ", "リ", "ル", "レ", "ロ", "ヮ", "ワ", "ヲ", "ン", "ヴ",
"ヵ", "ヶ", "ー", "、", "。", "「", "」", "『", "』", "【", "】", "〔", "〕", "〖", "〗", "〘", "〙", "〚", "〛", "〜", "！", "？"
]
}
行単位で除外ワードを記述したファイルで stopword を指定
ファイルを読み込む処理で、# はコメント扱いの上、
スペース除去をしているため、無視されていた
直接列挙することで対応

category_id name code
1 cat1 1010
2 cat2 1011
3 cat3 2010
field化 (非正規化)
item_id name category_id ...
10 商品A 1 ...
20 商品B 2 ...
items table
categories table
{
"item_id": 10,
"name": "商品A",
"category_id": 1,
"categories::name": "cat1",
"categories::code": "1010",
},
{
"item_id": 20,
"name": "商品B",
"category_id": 2,
"categories::name": "cat2",
"categories::code": "1011",
}
items index
0…n
1

item_id plan provide
1 A 2019/06/01
1 B 2019/07/01
2 A 2019/06/07
nested field
item_id ...
10 ...
20 ...
items table
item_provisions table
{
"item_id": 10,
"item_provisions" : [
{
"plan": "A",
"provide": "2019-06-01"
},
{
"plan": "B",
"provide": "2019-07-01"
}
]
},
{
"item_id": 20,
"item_provisions" : [
{
"plan": "A",
"provide": "2019-06-07"
}
]
}
items index
1
0…n

user_id item_id user_price
1 10 1500
1 20 2500
2 10 3000
ユーザー設定価格
item_id default_price
10 1000
20 2000
items table
user_settings table
item_id price
10 1500
20 2500
item_id price
10 3000
20 2000
user_id:1 の場合
user_id:2 の場合
1
0…n
user_settings があれば
user_price を採用。なけれ
ば default_price を採用

user_id:2 が扱う 2000円以上の
商品を抽出するSQL
SELECT item_id,
IFNULL(user_price, default_price) AS price
FROM items
LEFT OUTER JOIN user_settings USING(item_id)
WHERE user_id = 2
AND IFNULL(user_price, default_price) <= 2000

1 10 1500
1 20 2500
2 10 3000
非正規化+展開
10 1000
20 2000
items table
user_settings table
1
0…n
{
"item_id": 10,
"user_settings" : [
{
"user_id": 1,
"price": "1500"
},
{
"user_id": 2,
"price": "3000"
},
]
},
{
"item_id": 20,
"user_settings" : [
{
"user_id": 1,
"price": "2500"
},
{
"user_id": 2,
"price": "2000"
},
]
}
items index

`number of documents in the
index cannot exceed
2147483519`
• 200万以上の商品と70万以上のユーザー
– 1兆4000億以上の nested object が必要
– user_settings は 2500万件程度
• 1シャードあたりの document 上限は 2147483519
– nested object は 1document として格納
– シャードを増やせば格納することは可能
• nested object が多すぎる document の操作でメモリ不足
– java.lang.OutOfMemoryError: Java heap space

1 10 1500
1 20 2500
2 10 3000
DB のデータを
そのまま非正規化
10 1000
20 2000
items table
user_settings table
1
0…n
{
"item_id": 10,
"default_price": 1000,
"user_settings" : [
{
"user_id": 1,
"price": "1500"
},
{
"user_id": 2,
"price": "3000"
}
]
},
{
"item_id": 20,
"default_price": 2000,
"user_settings" : [
{
"user_id": 1,
"price": "2500"
}
/* user_id:2 は含めない */
]
}
items index

price による絞り込みをどう実現するか
• DB と同じデータをつかって実現
– SQL を参考に
• ES で柔軟に値を調整
– 検索スコア
– スコア調整用のクエリ
– painless (スクリプト)が利用可能

user_id:2 が扱う 2000円以上の
商品を抽出するSQL (再掲)
SELECT item_id,
IFNULL(user_price, default_price) AS price
FROM items
LEFT OUTER JOIN user_settings USING(item_id)
WHERE user_id = 2
AND IFNULL(user_price, default_price) <= 2000

{
“function_score”: {
“query”: {
“function_score”: {
“query”: {
“bool”: {
"filter": [
{"match_all": {}}
],
“should”: [
{
“nested”: {
“path”: “user_settings",
"query": {
"function_score": {
"query": {
"term": {
"user_settings.user_id":{"value": 2, "boost": 0}
}
},
"field_value_factor" : {
"field":"user_settings.user_price", "missing": 0
},
"boost_mode": "replace"
}
}
}
}
]
}
},
"script_score": {
"script": {
"source": "0 < _score ? _score : doc['default_price'].value"
}
},
"boost_mode": "replace",
"min_score": 2000
}},
"boost_mode": "replace",
"weight": 1
}
}
1.全体を対象にして
2. user_id:2 の
user_settings があれば
3.user_price を _score に置き換える
（なければ0）
4. _score が 0 の場合は default_price を
_score に置き換え (_score が price になる)
5. _score (price) が 2000 以上のみに絞り込む
6. 重みづけを 1に戻すことで、金額がスコアに影響するのを抑制

• Elasticsearch クラスタが稼働中
• 一部の処理については Elasticsearch
利用の検索に置き換え済み
• MySQL バージョンアップ
(5.0系 -> 8系) は隣の人が頑張ってる

まとめ
• Tritronn から Elasticsearch に移行
しています (現在進行形)
• データ同期の手法とか移行によるパ
フォーマンス改善とか話しきれなかった
ことも多い
• 俺たちの戦いはこれからだ

Tritonn から Elasticsearch への移行話

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Tritonn から Elasticsearch への移行話

Ähnlich wie Tritonn から Elasticsearch への移行話 (17)

Mehr von do_aki

Mehr von do_aki (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

Tritonn から Elasticsearch への移行話

Hinweis der Redaktion