Block join toranomaki

Block-Join 虎の巻
デジタル・インフォメーション・テクノロジー株式会社
海老澤志信

自己紹介
• 海老澤志信
• 所属
• 現業務
リクルートグループの検索システム
コンサル・開発・保守・運用・サイト導入
• Solr歴
Luceneのリリースノートに日本語で名前が載った唯一の男
(2015/05/13現在)
※詳しくは前回のスライドにて……
http://www.slideshare.net/ebisawashinobu/heliosearch-vs-solr

本日のアジェンダ
(Solr4.10系を調べていた時)
・このschema.xmlのパラメータなんだろう
<field name="_root_" type="string" indexed="true" stored="false"/>

↓
・Block-Join Queryという機能で使うらしい

↓
↓
・Block-Join って何……？

↓
↓
↓
(ネットの海へ)

↓
↓
↓
(ネットの海へ)
あまりにも情報がなかったので
調べてみてわかったアレコレをお届けします！

序章. 見よう！Block-Join

Block-Joinとは
• Solr4.5でリリース
https://issues.apache.org/jira/browse/SOLR-3076
• Document(※)に親子関係を持たせ、
それらのIndex登録と検索を行うための機能
※以降、本資料内ではDocと略す

Block-Joinが出来る事(1)
• 関連付けたいDocをネストすることで
親子関係のDocとして登録できる
id：parent_1
Field1:Foo
Field2:Bar
id:child_1
Field_C1:hoge
Field_C2:any

• 関連付けたいDocをネストすることで
親子関係のDocとして登録できる
※多重ネストは出来ない
id：parent_1
Field1:Foo
Field2:Bar
id:child_1
Field_C1:hoge
Field_C2:any
id:child_1_1
Field:xxx
Field2:yyy

• 親Docを検索軸に設定し
紐付く子Docを取得する
• 子Docを検索軸に設定し
紐付く親Docを取得する
基本的にはこの２パターン。

●在庫(子)にケーキを持つ店舗(親)を検索したい
【親：店舗】【子：在庫】

●在庫(子)にケーキを持つ店舗(親)を検索したい
「コンビニ」を
結果として得る

●スーパー(親)を検索し、在庫(子)を取得したい

●スーパー(親)を検索し、在庫(子)を取得したい
「カステラ」と
「プリン」を
結果として得る

ID 店舗名品名価格
1 A店 ○○ 100
2 A店 △△ 200
3 A店 ☓☓ 300
4 B店 ○○ 100
5 B店 △△ 200
<従来のIndex構成>
ID 店舗名(親) 品名(子) 価格(子)
1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
<Block-Joinを使用したIndex構成>
●Block-Joinの検索軸イメージ

1 A店 ○○ 100
2 A店 △△ 200
3 A店 ☓☓ 300
4 B店 ○○ 100
5 B店 △△ 200
1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
<Block-Joinを使用したIndex構成>
●Block-Joinの検索軸イメージ
店舗でも品名でも
検索できるが
検索軸は並行構成
店舗でも品名でも
検索できるが
検索軸が分かれている

閑話休題：Block-Joinへの興味
●だいたいここまで調べた時点での感覚

複数店舗の商品検索をするサイトとか
コースの予約管理をするサイトで
この機能をいい感じに使えないか？

[既存の課題]
・Solrの1Doc内にマスタとサブの情報が混在している
→マスタ情報更新時の影響がサブ情報にも発生する
・検索軸が複数存在しているケース
→更新頻度の高い情報と低い情報の混在
複数店舗の商品検索をするサイトとか
コースの予約管理をするサイトで
この機能をいい感じに使えないか？

二章. できる！Block-Join

Block-Joinの基本ルール
1. schema.xmlに”_root_”があること
→親子関係を保証するためのFieldと値が
Index内に自動的にセットされる。
(ユーザが意識する必要はない)

2. 全ての親Docには、
識別するための一律のFieldを
定義すること
id：parent_1
Field1:Foo
Doc_Type:”parent”
id:child_1
Field_C1:hoge
Field_C2:any

2. 全ての親Docには、
識別するための一律のFieldを
定義すること
id：parent_1
Field1:Foo
Doc_Type:”parent”
id:child_1
Field_C1:hoge
Field_C2:any識別用のField名・型・値は
検索軸となる親Docで一律であれば
何でもいい

<add>
<doc>
<field name="id">1</field>
<field name="title">Solr has block join support</field>
<field name="content_type">parentDocument</field>
<doc>
<field name="comments">SolrCloud supports it too!</field>
</doc>
</doc>
</add>
Block-Joinのドキュメント登録
・XMLで登録する場合の例

<add>
<doc>
<doc>
</doc>
</doc>
</add>
(1)親Doc識別用Field

<add>
<doc>
<doc>
</doc>
</doc>
</add>
(2)親Docの中に子Docをネスト

・SolrJで登録する場合の例
// Parent Doc
SolrInputDocument product01 = new SolrInputDocument();
product01.addField( "id", "product01" );
product01.addField( "name", "car" );
product01.addField( "content_type", "product" );
// Children
SolrInputDocument part01 = new SolrInputDocument();
part01.addField( "id", "part01" );
part01.addField( "name", "wheels" );
part01.addField( "content_type", "part" );
// Add children to parent
product01.addChildDocument( part01 );

// Parent Doc
// Children
(1)親Docは今までどおり
SolrInputDocumentを生成して
Field設定

// Parent Doc
// Children
(2)子Docも独立した
SolrInputDocumentとして
Field設定

// Parent Doc
// Children
(3)親Docのインスタンスが持つ
addChildDocumentメソッドを呼び出し
子Docのインスタンスを紐付け

Block-Join 検索Query
1. 親Docを検索軸に設定し
基本構文：
q={!child of=<allParents>}<someParents>

1. 親Docを検索軸に設定し
基本構文：
・allParentsは、親Docを識別するためのパラメータ
→親Docに一律定義したFieldと値をセット
・someParentsはメインQueryとなる検索条件
→{!child of}では親Docが検索軸となる
q={!child of=<allParents>}<someParents>

2. 子Docを検索軸に設定し
基本構文：
q={!parent which=<allParents>}<someChildren>

2. 子Docを検索軸に設定し
基本構文：
・allParentsは、親Docを識別するためのパラメータ
→子Doc用の識別Fieldではない
・ someChildrenはメインQueryとなる検索条件
→{!parent which}では子Docが検索対象となる
q={!parent which=<allParents>}<someChildren>

ポイント：
・親Doc検索(parent which)でも
子Doc検索(child of)でも
パラメータは親Doc用の識別Fieldを使用
・親Doc識別パラメータは
単一条件しか指定できない。
(ORやAND、RangeQueryは使用不可能)
{!parent which=DocType:parent}
{!child of=Group:2}

Block-Joinを使うメリット
■ Index更新量の削減
1 A店 ○○ 100
2 A店 △△ 200
3 A店 ☓☓ 300
4 B店 ○○ 100
5 B店 △△ 200

1 A店 ○○ 100
2 A店 △△ 200
3 A店 ☓☓ 300
4 B店 ○○ 100
5 B店 △△ 200
→”A店”の店舗名が”A店X支所”に変わった…

1 A店X支所 ○○ 100
2 A店X支所 △△ 200
3 A店X支所 ☓☓ 300
4 B店 ○○ 100
5 B店 △△ 200
→”A店”の店舗名が”A店X支所”に変わった…
→店舗名が変わるだけで、属する
全てのDocの更新が必要だった

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
→”A店”の店舗名が”A店X支所”に変わった
<親子関係を使用したIndex構成>

1 A店X支所
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
→”A店”の店舗名が”A店X支所”に変わった
→親Docしか持たない情報は
親Docの更新だけで完結する

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
→”A店”が廃止になった

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
→”A店”の親Docを削除すると……

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
→”A店”の親Docを削除すると……
→ネストしている子Docも連動して削除される

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 500
2 B店
2-2 ○○ 100
2-3 △△ 200
→ネストした子Docも独立したDoc扱いなので
子Docだけの更新や削除は可能

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
1-4 □□ 600
2 B店
2-2 ○○ 100
2-3 △△ 200
→ただし、今ある親子関係のDocに対して
子Docだけを追加することはできない

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
1-4 □□ 600
2 B店
2-2 ○○ 100
2-3 △△ 200
→ただし、今ある親子関係のDocに対して
子Docだけを追加することはできない
→追加するDocを含めた親子全てのDoc更新が必要

Block-Joinの気になるところ
(1) Block-Join Queryの検索軸に指定した
親/子Docは検索結果で同時に取得できない

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
・親Docを検索軸にすると
子DocのFieldしか結果で得られない

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
★既存のQueryを使う場合はネストの影響がなく
すべて独立したDocとして扱われる

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-2 ○○ 100
2-3 △△ 200
★既存のQueryを使う場合は
ネストの影響がなく独立したDocとして扱われる親/子Docを同時に検索したい場合は
Block-Join Queryは使用しないこと

(2) ネストした親子Doc間において
直接親子関係を取得する手段がない

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-1 ○○ 100
2-2 △△ 200
検索軸を親Docとして「A店 OR B店」とした時

1 A店
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店
2-1 ○○ 100
2-2 △△ 200
検索軸を親Docとして「A店 OR B店」とした時
Block-Join Queryでそれぞれの子Docがヒットする
子Docがどちらの店舗に属しているかがわからない

ID 店舗名(親) 店舗ID(子) 品名(子) 価格(子)
1 A店
1-1 1 ○○ 100
1-2 1 △△ 200
1-3 1 ☓☓ 300
2 B店
2-1 2 ○○ 100
2-2 2 △△ 200
→必要であれば、親子Doc間で情報を共有するように
Index構成を作る
この例では、子に親DocのIDを持たせることで
親Docの情報を検索して引っ張ることが可能となる。

(3) Block-Join Queryでは検索軸に指定した
親/子Docの絞り込みができない

q={!parent which=DocType:店舗} 品物:○○
→子Docに品物”○○”を持つ店舗(親Doc)を検索する

→子Docに品物”○○”を持つ店舗(親Doc)を検索する
→メインQueryでは、子Docを検索対象とするため
親Docを絞り込む条件を記述することが出来ない

&fq=店舗種別：コンビニ
→絞り込みたい親Docを対象とした
FilterQueryを追加する。

ID 店舗名(親) 店舗種別(親) 品名(子) 価格(子)
1 A店コンビニ
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店ドラッグストア
2-1 ○○ 100
2-2 △△ 200

ID 店舗名(親) 店舗種別(親) 品名(子) 価格(子)
1 A店コンビニ
1-1 ○○ 100
1-2 △△ 200
1-3 ☓☓ 300
2 B店ドラッグストア
2-1 ○○ 100
2-2 △△ 200
→親Docはfqの店舗種別：コンビニで絞りこまれる
“A店”だけがヒットするようになる

補足：
FilterQueryは親子Docの区別なく
フィルタリングしてDocを抽出する

補足：
FilterQueryは親子Docの区別なく
フィルタリングしてDocを抽出する
→検索軸が親/子どちらの場合でも使用できる。
(検索軸側に対して、本来のFilterCache用途で
使用することもできる)

(4) 検索軸に使用した親/子DocのFieldから
Facetを取得することが出来ない

・Facetは検索結果から作成するため

・Facetは検索結果から作成するため
→親/子Doc相互でFacet用に情報を持たせておく
(複数の子→親ならマルチFieldなど)
→子Docを検索軸にした場合の対応については
パッチが提案されている。
https://issues.apache.org/jira/browse/SOLR-5743

(5) Block-Join Queryでは
スコア計算は全て0.0になる

・Lucene内では
スコア計算のパターンはいくつか実装されている
しかし……
検索軸タイプ意味
子Doc
None スコア計算なし(デフォルト)
Avg 子Docのスコア平均
Max 子Docのスコア最大値
Total 子Docのスコア合計
親Doc
false スコア計算なし(デフォルト)
true 親Docのスコアを使う

・Solr上のBlock-JoinQueryパーサ処理にて
None(false)で固定でされている
<BlockJoinParentQParser.java>
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery (
query, getFilter(parentList), ScoreMode.None
);
}

・Solr上のBlock-JoinQueryパーサ処理にて
None(false)で固定でされている
<BlockJoinParentQParser.java>
ソースコードをいじらない限り
Block-JoinQueryの結果でスコア取得する手段はない
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery (
query, getFilter(parentList), ScoreMode.None
);
}

まとめ
• Block-Joinは
「検索軸」を明確に分けるための機能

まとめ
• Block-Joinは
→当初の課題であった
マスタ情報とサブ情報の
検索・更新軸を明示的に分けるという
用途では使えそうな気がする。

まとめ
• Block-Joinは
→当初の課題であった
マスタ情報とサブ情報の
検索・更新軸を明示的に分けるという
用途では使えそうな気がする。
・サブの要素数に左右されにくくなるので
複雑なクエリをスマートにしやすい、とか
Field設計を容易にしやすい、とか……。

課題
・Block-Join Queryがクセモノ
要件によっては、ここまで述べてきた通り
ひと工夫が必要になる。
・パフォーマンスについては未知数……。

課題
商用サイトでの導入と実証検証を目指して
引き続き調査・対応を進めていきます。
・Block-Join Queryがクセモノ
要件によっては、ここまで述べてきた通り
ひと工夫が必要になる。
・パフォーマンスについては未知数……。

Q&A
ご清聴ありがとうございました。
お問い合わせ先・エンジニア募集中
search-info@ditgroup.jp
http://www.ditgroup.jp/

Block join toranomaki

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Block join toranomaki

Similaire à Block join toranomaki (9)

Block join toranomaki